사례4건

4건 중 1~4번째

1. IL-0313 자체 운영 PgBouncer 로 옮기는 운영 카나리에서 일부 요청이 정확히 300초 멈추고 SQLAlchemy 커넥션 풀이 고갈됐다

   Decagon2026

   증상

   GCP 의 관리형 커넥션 풀러에서 자체 운영 PgBouncer 로 옮기는 첫 운영 카나리에서, 일부 음성 요청이 대화 도중 멈췄다가 정확히 300초 뒤 타임아웃됐다. 다른 요청은 그보다 훨씬 일찍 SQLAlchemy 커넥션 풀 고갈로 실패했다.

   간헐적 타임아웃커넥션 풀 고갈

   촉발

   Decagon 이 GCP 의 관리형 커넥션 풀러에서 자체 운영 PgBouncer 로 옮기면서 PgBouncer 와 Postgres 사이의 TLS 경로가 바뀌었다. 첫 운영 카나리에서 이 바뀐 경로 때문에, PgBouncer 에 숨어 있던 버그가 드러날 마지막 조건이 갖춰졌다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러

   기여 요인

   스테이징 불일치미검증 가정

   감지

   운영 카나리 중 일부 음성 요청이 대화 도중 멈추고 정확히 300초 뒤 타임아웃됐다. Sentry 에 "SSL connection has been closed unexpectedly" 오류가 몇 건 찍혔고, 다른 요청은 SQLAlchemy 커넥션 풀 고갈로 실패했다.

   조치

   • 애플리케이션에서 application name 값을 줄여 ParameterStatus 패킷이 PgBouncer 의 작은 패킷 파싱 기준 아래에 머물게 했고, 버그의 세 조건 중 하나를 없애 마이그레이션을 계속했다.

   후속 조치

   • PgBouncer 업스트림에 이벤트 루프 버그의 수정을 머지했다. epoll() 대기로 돌아가기 전에 SSL_pending() 을 확인하고, OpenSSL 에 복호화된 바이트가 남아 있으면 계속 읽는다.

   교훈

   인프라 마이그레이션은 자기 시스템만 바꾸는 것이 아니라 스택의 다른 곳에 숨어 있던 버그를 드러낼 수 있다. 이번에는 자체 운영 PgBouncer 로 옮긴 일이 SQLAlchemy, PgBouncer, OpenSSL, PostgreSQL wire protocol 이 얽힌 오래된 예외 상황이 드러날 마지막 조건을 만들었다. 버그는 응답이 정확히 그 모양일 때는 늘 재현됐지만, 그런 응답 자체가 드물어 스테이징에서 나타나지 않았다.

   사례 보기
2. IL-0329 Postgres 17 업그레이드 뒤 다시 켠 PGAudit 가 마이그레이션 중 락을 쥔 채 멈춰, 서비스 전반이 느려지고 데이터베이스가 2분 동안 내려갔다

   incident.io2025

   증상

   2025년 4월 9일 14:16 UTC 부터 대시보드, 모바일 앱, Slack 앱, API 가 간헐적으로 느려졌고, 모니터링이 곧 문제를 알렸다. 14:25 부터 14:27 UTC 까지 2분 동안은 데이터베이스가 완전히 내려가 제품 전체가 영향을 받았다.

   잠금 경합과 교착간헐적 타임아웃지연 시간 증가서비스 중단

   촉발

   PGAudit 를 다시 켠 운영 데이터베이스에서 빈 테이블을 만들고 인덱스를 더하는 평범한 마이그레이션을 14:16 UTC 에 실행했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

   모니터링이 문제를 빠르게 알렸다.

   조치

   • PGAudit 프로세스를 죽이는 시도가 계속 실패하자 데이터베이스를 재시작해 멈춘 프로세스를 강제로 끝냈다. 이 때문에 주 데이터베이스가 14:25 부터 14:27 UTC 까지 2분이 조금 안 되게 내려갔다.
   • 서비스를 되살린 뒤 PGAudit 확장을 잠시 껐다가 완전히 지웠다.

   후속 조치

   • PGAudit 가 안전하다고 보장할 수 있을 때까지 확장을 지운 상태로 두어, 실수로 다시 켜질 위험을 없앤다.
   • 원인 조사를 계속한다.
   • 내부 회고를 한다.
   • 비슷한 상황을 더 잘 감지하고 막고 대응하도록 절차와 모니터링을 보강한다.

   사례 보기
3. IL-0330 Go database/sql 커넥션 풀을 기다리던 요청이 2주 동안 간헐적으로 타임아웃됐고, 한 요청은 거의 20초를 기다렸다

   incident.io2023

   증상

   2023년 초 incident.io 애플리케이션이 데이터베이스를 쓰는 동안 간헐적으로 타임아웃이 났다. 고객 신고가 들어왔고, 오류 수집 도구 Sentry 에 context canceled 오류가 한꺼번에 쏟아졌다.

   커넥션 풀 고갈간헐적 타임아웃

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스

   기여 요인

   모니터링 사각지대

   감지

   고객 신고가 들어왔고 Sentry 에 context canceled 오류가 쏟아지면서 알아챘다. 온콜 엔지니어가 장애를 열고 Grafana 의 API 대시보드에서 타임아웃을 확인했다. 두 번째 타임아웃 때는 장애가 자동으로 열리고 온콜 엔지니어가 호출됐다.

   조치

   • 정책 위반은 요청마다 정책과 관련 장애를 모두 가져와 계산해 왔는데, 이 계산을 머티리얼라이즈드 뷰로 옮겼다.
   • 느린 쿼리를 빠르게 하려고 데이터베이스 인덱스를 새로 더했다.
   • 인덱스 없는 열로 조인한 뒤 거르던 쿼리를, 조인에 이미 들어 있는 테이블의 인덱스 있는 같은 열로 거르도록 다시 썼다.
   • 어떤 요청이 트랜잭션을 오래 쥐고 있는지 빨리 찾으려고 모든 트랜잭션에 1초 락 타임아웃을 걸었다.
   • Slack 웹훅이 들어오면 데이터베이스 쿼리 없이 바로 PubSub 로 넘겨 Slack 이벤트를 비동기로 처리하게 바꿨다.
   • ngrok/sqlmw 패키지로 미들웨어를 만들고, trackUsage 메서드로 작업마다 데이터베이스 커넥션을 쥔 시간을 세어 로그와 트레이스에서 거를 수 있게 했다.
   • Slack 모달 제출 대부분에서 필요 없던 트랜잭션을 없애고, 트랜잭션 보장이 필요한 코드 경로에만 명시적으로 넣었다.

   교훈

   한 번에 모든 것이 풀리는 결정적인 발견은 없었다. 대신 그 과정에서 이런 문제를 진단할 준비가 훨씬 잘 됐고, 실제 성능 개선도 함께 이뤄졌다. 원인은 눈에 띄게 느린 것 하나가 아니라 짧은 트랜잭션 여러 개가 합쳐진 것이었다. 애플리케이션의 부분마다 다른 데이터베이스를 썼다면 아마 더 빨리 찾았을 것이다. 하지만 그러면 분산 트랜잭션을 고민해야 하고 개발 환경도 덜 편해지므로, 팀은 지금의 선택을 유지한다.

   사례 보기
4. IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

   Stripe2019

   증상

   2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

   오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

   촉발

   16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩

   감지

   첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

   조치

   • 17:00 UTC 에 데이터베이스 클러스터의 모든 노드를 재시작해 새 primary 선출을 성공시켰다. 17:02 에 Stripe API 가 완전히 복구됐다.
   • 22:34 UTC 에 운영 설정을 고쳐 새로 배포하고 데이터베이스 클러스터의 노드를 재시작해 영향받은 shard 를 되살렸다.
   • 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸다. 22:47 UTC 에 완전히 복구됐다.

   후속 조치

   • 노드가 복제 지연 지표를 보내지 않으면 알리는 모니터링을 더했다.
   • shard 가 데이터베이스 장애 조치 시스템의 이 선출 결함을 일으킬 수 있는 상태에 들어가면 알리는 모니터링을 더했다.
   • 이 결함을 고치는 수정을 데이터베이스 메인테이너와 함께 만든다.
   • 특정 클러스터로 가는 작업이 실패하면 끊어 내는 서킷 브레이커를 더 넣는다. 이번 사고의 클러스터도 대상이다.
   • shard 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기

원인별1