사례2건
2건 중 1~2번째
- 증상
2026년 3월 31일 Buttondown 이 두 번 멈췄다. 약 7분과 약 13분 동안 새 요청이 데이터베이스 연결을 얻지 못해 실패했고, 팀은 자동 알림이 아니라 사용자 신고와 직접 관찰로 장애를 알았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 자동 시스템이 아니라 사용자 신고와 직접 관찰로 장애를 알았다. 헬스 체커는 대체로 정상으로 보고했고 외부 모니터링도 알림을 내지 않았다.
- 조치
- 첫 번째 장애에서 연결 고갈을 확인하고 실행 중인 쿼리를 죽여 연결을 풀었다.
- 두 번째 장애에서는 쿼리를 죽이려고 접속할 연결조차 없어 데이터베이스를 재시작해 실행 중인 쿼리를 강제로 끝냈다.
- 후속 조치
- Postgres 에서 관리용 접속에만 쓰는 연결을 몇 개 예약해 둔다.
- 설정된 최대치 대비 연결 수의 비율을 데이터베이스에서 직접 감시하고 상한에 가까워지면 알린다. 이 감시는 HTTP 요청의 성공 여부와 상관없이 데이터베이스 자체를 본다.
- 늘 200 으로 응답하던 헬스 체크 엔드포인트가 가벼운 쿼리를 실행해 보도록 바꿔, 연결 고갈이 헬스 체커와 로드 밸런서에 바로 보이게 한다.
- 분기별 용량 검토에 연결 상한을 넣는다.
- 관리용 접속까지 막혔을 때를 대비해, 데이터베이스 연결 없이 워커를 강제로 재활용해 연결을 푸는 대체 절차를 문서와 스크립트로 만든다.
- 교훈
관리용 연결을 하나라도 예약해 뒀다면 두 번째 장애에서도 첫 번째처럼 쿼리를 죽일 수 있었다. 두 번째 장애가 첫 번째보다 거의 두 배 길었던 것은 복구에 쓰던 수단 자체를 쓸 수 없었기 때문이었다. 가장 흔한 장애를 잡지 못하는 헬스 체크는 헬스 체크 구실을 하지 못한다. 오래전에 정하고 다시 보지 않은 연결 상한은 트래픽이 바뀌면서 서서히 모자라게 됐다.
- 증상
2022년 6월 27일 13:00 UTC 에 Basecamp 3 가 갑자기 아주 느려졌고 곧 오류 페이지를 보였다. 같은 30초 사이에 Basecamp 3 의 주 데이터베이스가 정상에서 완전한 정체 상태로 넘어갔다.
- 촉발
13:00 UTC 에 예약 알림을 대량으로 묶어 보내는 시각에 맞춰 부하가 큰 데이터베이스 쿼리가 한꺼번에 몰려들었고, 이 쿼리들이 주 데이터베이스에서 락 경합을 연쇄로 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- 감지
37signals 는 13:00:00 과 13:00:30 UTC 사이에 Basecamp 3 의 주 데이터베이스가 완전히 정체되는 것을 보고 곧바로 대응을 시작했다.
- 조치
- 주 데이터베이스의 부하를 덜려고 Basecamp 3 의 일부 기능을 멈췄다. 진행 보고 이메일을 그날 늦게 보내도록 미룬 것이 그 예다.
- 막힌 주 데이터베이스에서, 이런 장애에 대비해 대기 중이던 복제본 데이터베이스로 절차대로 페일오버했다.
- 페일오버 뒤 데이터베이스가 다시 무너지자 Basecamp 3 를 곧바로 유지보수 모드로 바꿨다.
- 데이터베이스 쿼리 시간에 강제 상한을 걸었다.
- 쿼리 시간 상한을 안전장치로 두고 기능을 한 단계씩 다시 켜서 서비스를 모두 되살렸다.
- 후속 조치
- 데이터베이스 쿼리에 강제 시간 상한을 둔다. 평소 빠르던 쿼리가 일정 수준 넘게 느려지면 기다리며 쌓이게 두지 않고 실패하게 한다.
- 동시 실행 한도를 조정한다. 일정 수준을 넘으면 병렬로 도는 작업이 많을수록 시스템 전체가 느려지기 때문이다.
- 서비스 수준 기대치를 더 엄격하게 잡고, 예약 알림과 보고서를 몇 분 안에 대량으로 보내며 생기던 정시 데이터베이스 부하 급증을 더는 용인하지 않는다. 제품 설계부터 데이터베이스 내부까지 이 부분을 살핀다.
- 일부 예약 작업을 돌리는 병렬 워커 수를 줄여 동시 실행과 락 경합을 낮춘다.
- 일부 예약 작업을 한꺼번에 끝내지 않고 몇 분에 걸쳐 돌려 데이터베이스 부하를 시간에 나눈다.
- 한꺼번에 몰려드는 쿼리 다수를 주 데이터베이스에서 읽기 전용 복제본 데이터베이스로 옮긴다.
- 지난 1년의 데이터베이스 지표에서 찾은 성능 저하 여러 건을 하나씩 고친다. 이 저하는 알림을 울리지 않았지만 주 데이터베이스 부하를 서서히 늘렸다.
- 한꺼번에 몰려드는 다른 작업을 찾아 분산해, 데이터베이스의 특정 지점에 부하가 몰리지 않게 한다.
- 높은 부하와 높은 동시성에서 더 예측 가능하게 동작하도록 데이터베이스를 조정한다.
- 데이터베이스 내부의 락과 트랜잭션 상태를 더 잘 볼 수 있도록 관측성을 높인다.
- 장애 중에 부하가 큰 Basecamp 3 기능을 골라 끌 수 있는 더 쓰기 편한 도구를 만든다.
- 멈춘 데이터베이스에 대응하는 운영 훈련을 잡아 대응을 연습하고 다듬는다.
- 앞으로 몇 년의 Basecamp 성장에 맞춰 확장할 수 있도록 데이터베이스 소프트웨어와 하드웨어 업그레이드를 검토한다.
- Basecamp 3 를 받치는 구성 요소에 서비스 수준 목표, 곧 SLO 를 정해 데이터베이스 성능 변화를 더 일찍, 더 분명하게 알아챈다.
- 분기마다 성능과 부하를 검토해 눈에 띄지 않게 진행되는 성능 변화를 찾는다.
- 교훈
37signals 는 이번 장애에 원인 하나가 없었다고 밝혔다. 시스템이 한계를 조금만 넘어도 순식간에 안정에서 불안정으로 넘어가는 지점이 있고, 그 지점은 특별한 계기 없이 성장과 함께 서서히 다가온다. 막힌 쿼리를 종료하는 일은 트랜잭션 롤백 때문에 같은 락에서 다시 막혀 정체를 키울 수 있다. 37signals 는 이 시스템을 잘 알면서도 결정적인 단서가 없고 데이터베이스 내부를 깊이 들여다볼 수단이 없어 확신을 갖고 대응하지 못했다고 썼다. 그래서 문제 하나를 고치는 대신 위험을 줄이고 확신을 쌓아 가는 길을 택했다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.