사례2건

2건 중 1~2번째

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-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 모달 제출 대부분에서 필요 없던 트랜잭션을 없애고, 트랜잭션 보장이 필요한 코드 경로에만 명시적으로 넣었다.

   교훈

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

   사례 보기

원인별1