사례1건

1건 중 1~1번째

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

   Buttondown2026

   증상

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

   커넥션 풀 고갈서비스 중단

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

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

   감지

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기

원인별1