사례4건

4건 중 1~4번째

1. IL-0497 Postgres 가 설정된 최대 연결 수에 닿아 하루에 두 번 새 요청이 연결을 얻지 못하고 실패했다

   Buttondown2026

   증상

   2026년 3월 31일 Buttondown 이 두 번 멈췄다. 약 7분과 약 13분 동안 새 요청이 데이터베이스 연결을 얻지 못해 실패했고, 팀은 자동 알림이 아니라 사용자 신고와 직접 관찰로 장애를 알았다.

   커넥션 풀 고갈서비스 중단

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대순환 의존

   감지

   팀은 자동 시스템이 아니라 사용자 신고와 직접 관찰로 장애를 알았다. 헬스 체커는 대체로 정상으로 보고했고 외부 모니터링도 알림을 내지 않았다.

   조치

   • 첫 번째 장애에서 연결 고갈을 확인하고 실행 중인 쿼리를 죽여 연결을 풀었다.
   • 두 번째 장애에서는 쿼리를 죽이려고 접속할 연결조차 없어 데이터베이스를 재시작해 실행 중인 쿼리를 강제로 끝냈다.

   후속 조치

   • Postgres 에서 관리용 접속에만 쓰는 연결을 몇 개 예약해 둔다.
   • 설정된 최대치 대비 연결 수의 비율을 데이터베이스에서 직접 감시하고 상한에 가까워지면 알린다. 이 감시는 HTTP 요청의 성공 여부와 상관없이 데이터베이스 자체를 본다.
   • 늘 200 으로 응답하던 헬스 체크 엔드포인트가 가벼운 쿼리를 실행해 보도록 바꿔, 연결 고갈이 헬스 체커와 로드 밸런서에 바로 보이게 한다.
   • 분기별 용량 검토에 연결 상한을 넣는다.
   • 관리용 접속까지 막혔을 때를 대비해, 데이터베이스 연결 없이 워커를 강제로 재활용해 연결을 푸는 대체 절차를 문서와 스크립트로 만든다.

   교훈

   관리용 연결을 하나라도 예약해 뒀다면 두 번째 장애에서도 첫 번째처럼 쿼리를 죽일 수 있었다. 두 번째 장애가 첫 번째보다 거의 두 배 길었던 것은 복구에 쓰던 수단 자체를 쓸 수 없었기 때문이었다. 가장 흔한 장애를 잡지 못하는 헬스 체크는 헬스 체크 구실을 하지 못한다. 오래전에 정하고 다시 보지 않은 연결 상한은 트래픽이 바뀌면서 서서히 모자라게 됐다.

   사례 보기
2. IL-0301 Basecamp 3 의 주 데이터베이스가 정시 부하에 락 경합으로 30초 만에 완전히 막혔다

   37signals2022

   증상

   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 는 이 시스템을 잘 알면서도 결정적인 단서가 없고 데이터베이스 내부를 깊이 들여다볼 수단이 없어 확신을 갖고 대응하지 못했다고 썼다. 그래서 문제 하나를 고치는 대신 위험을 줄이고 확신을 쌓아 가는 길을 택했다.

   사례 보기
3. IL-0300 Basecamp 3 의 events 테이블이 데이터베이스 한도에 닿아 서비스가 다섯 시간 가까이 읽기 전용이 되었다

   37signals2018

   증상

   Basecamp 3 가 읽기 전용 상태가 되었다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 새 내용을 넣을 수 없었고 기존 내용도 고칠 수 없었다.

   쓰기 거부

   촉발

   사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿아, 이 테이블에 새 이벤트를 쓸 수 없게 되었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재

   조치

   • Rails 5.1 이 모든 테이블의 새 기본값으로 바꾼 것과 같은 변경을 Basecamp 의 테이블에 적용해 레코드 한도를 9,223,372,036,854,775,807 로 올렸다.

   교훈

   37signals 는 이 장애를 피할 수 있었다고 밝혔다. 장애 전 며칠 동안 events 테이블의 용량을 늘리는 작업을 하면서도 여유가 줄어드는 속도를 제대로 따지지 않았다. 37signals 의 CTO 는 Rails 5.1 이 새 기본값을 발표했을 때 회사의 데이터베이스 스키마를 더 주의 깊게 살폈어야 했다고 썼다. 해결 작업을 시작한 뒤에도 끝까지 챙기며 꼭 필요한 질문을 했어야 했다고 덧붙였다.

   사례 보기
4. IL-0282 US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다

   Amazon Web Services2015

   증상

   2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.

   오류율 상승데이터베이스 과부하

   촉발

   2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위

   감지

   주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다.

   조치

   • 용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다.
   • 메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다.
   • 메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다.
   • 받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다.

   후속 조치

   • 메타데이터 서비스의 용량을 이미 크게 늘렸다.
   • 멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다.
   • 스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다.
   • 메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다.
   • DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다.
   • SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다.
   • Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다.
   • 더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다.
   • 스케일링 작업을 처리하는 용량을 늘린다.
   • CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다.
   • write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다.
   • 타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다.

   교훈

   AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다.

   사례 보기

원인별1