사례3건

3건 중 1~3번째

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

   Buttondown2026

   증상

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

   커넥션 풀 고갈서비스 중단

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

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

   감지

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기
2. IL-0557 같은 객체에 몰린 동시 업로드가 데이터베이스 트랜잭션 경합을 일으켜 Storj US1 satellite 의 업로드와 다운로드 요청이 실패했다

   Storj2025

   증상

   2025년 8월 7일 21시 4분 UTC부터 Storj US1 satellite 에서 데이터베이스 트랜잭션 잠금이 늘었다. 21시 14분에 당번 팀이 호출을 받았고, 21시 25분에 상태 페이지가 US1 의 업로드와 다운로드 실패를 조사 중이라고 알렸다.

   잠금 경합과 교착간헐적 타임아웃커넥션 풀 고갈오류율 상승

   촉발

   같은 객체들을 겨냥한 동시 업로드가 유난히 많이 몰렸다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

   21시 14분에 당번 팀이 호출을 받고 조사를 시작했다.

   조치

   • 커넥션 상태를 주기적으로 초기화해 경합 관련 오류가 연쇄로 불어나지 않게 했다.

   후속 조치

   • 데이터베이스 트랜잭션 사이의 경합 원인을 찾아 코드를 고쳐 없앴다.
   • 데이터베이스 잠금이 늘어나는 것을 찾아 팀에 알리는 모니터링과 알림을 더했다.
   • 사고 분석으로 절차와 시스템에서 더 고칠 점을 찾았다. 수동 유지 보수를 줄이거나 없애는 도구를 만드는 일이 그중 하나다.

   사례 보기
3. IL-0550 Bitbucket Cloud 의 웹사이트와 API 가 6시간 동안 느려지고 Pipelines 빌드가 밀렸다

   Atlassian2024

   증상

   2024년 2월 22일 07:22 UTC 부터 Bitbucket Cloud 의 웹사이트와 API 가 느려졌다. 커넥션 풀이 포화되고 응답 시간이 늘었으며, 완전히 타임아웃 나는 요청이 점점 늘었다.

   지연 시간 증가커넥션 풀 고갈간헐적 타임아웃처리량 저하

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   한계 경보 부재

   조치

   • Bitbucket Pipelines 에 리소스를 더 넣어 쌓인 잡을 처리했고, 17:30 UTC 에 백로그가 모두 처리됐다.

   후속 조치

   • 쓰기가 많은 데이터베이스 테이블의 vacuum 임계값을 다시 설정한다.
   • 이런 동작을 더 일찍 잡아 영향을 줄이도록 알림 임계값을 조정한다.
   • Pipelines 서비스의 오토스케일링과 로드 셰딩 동작을 조정하고 빌드 러너 용량을 늘린다.

   사례 보기

원인별1