사례21건

21건 중 9~13번째

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

   Storj2025

   증상

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

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

   촉발

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

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

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

   조치

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

   후속 조치

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

   사례 보기
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-0556 수동 데이터베이스 유지 보수 중 열어 둔 트랜잭션이 잠금을 쥐어 Storj US1 satellite 의 업로드와 다운로드가 실패했다

   Storj2024

   증상

   2024년 5월 20일 14시 56분 UTC쯤 Storj US1 satellite 에서 쓰기 작업이 실패하기 시작했다. 14시 59분에 당번 팀이 호출을 받고 조사를 시작했다.

   잠금 경합과 교착서비스 중단

   촉발

   14시 55분에 US1 satellite 에서 정기 수동 데이터베이스 유지 보수를 시작했고, 다른 작업을 하는 사이 트랜잭션 하나가 실수로 열린 채 남았다.

   원인

   운영 실수

   구성 요소

   데이터베이스

   기여 요인

   –

   감지

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

   조치

   • 15시 22분에 열려 있던 트랜잭션을 찾아 닫고 복구를 시작했다. 15시 23분에 서비스가 돌아왔다.

   후속 조치

   • 다른 작업으로 넘어가기 전에 모든 트랜잭션을 제대로 닫도록 데이터베이스 유지 보수 절차와 교육을 다시 살펴 고친다.
   • 정해 둔 시간보다 오래 열려 있는 트랜잭션을 찾아 팀에 알리는 모니터링과 알림을 더한다.
   • 사고 분석으로 절차와 시스템에서 더 고칠 점을 찾고, 수동 유지 보수를 줄이거나 없애는 도구를 만든다.

   사례 보기
4. IL-0217 스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다

   Honeycomb2023

   증상

   2023년 7월 24일 밤 저장소와 쿼리 엔진인 Retriever 의 클러스터를 바꾼 지 몇 시간 뒤 수집 서비스 Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되기 시작했다. 엔지니어들은 소진이 느리고 들쭉날쭉하며 뚜렷한 설명이 없어서 아침에 조사해도 되는 작은 문제라고 판단했다.

   지연 시간 증가데이터베이스 과부하잠금 경합과 교착서비스 중단

   촉발

   7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터 두 개 사이를 전환했다. 전환 뒤 Retriever 가 마지막 쓰기 시각 기록을 데이터베이스에 쓰지 않았고, 그 뒤 쓰기만 되돌리려고 기능 플래그를 바꾸자 남은 쓰기마저 완전히 멈췄다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스인메모리 캐시

   기여 요인

   데워진 캐시에 기댄 구조초기 신호 무시수동 조치 악화미검증 가정

   감지

   Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되는 것을 엔지니어들이 봤지만 작은 문제로 판단해 아침으로 미뤘다. 아침에 Retriever 의 데이터베이스 호출이 끊긴 차트를 찾아 성능 문제의 원인을 알았다.

   조치

   • 클러스터의 쓰기에 문제가 있다고 보고 자주 쓰던 기능 플래그를 바꿔 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다.
   • 데이터베이스를 보호하려고 서킷 브레이커를 걸어 모든 Shepherd 트래픽을 5xx 오류로 거부했다.
   • 데이터베이스 호스트가 완전히 잠겨 살릴 수 없자 복제본으로 페일오버했고, 데이터베이스와 그에 기대는 서비스들이 돌아왔다.
   • 데이터베이스가 살아난 뒤 캐시에 데이터를 채우려고 Retriever 호스트를 모두 재시작했다.
   • 지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 손으로 바꿔 스키마 저장소가 캐시를 모두 다시 읽게 했다.
   • 서킷 브레이커를 풀어 수집을 완전히 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다.

   후속 조치

   • 클러스터 이전을 마쳤고, 캐시 뒤의 쓰기를 끌 수 있는 코드를 모두 지웠다.
   • 캐시를 더 튼튼하게 하는 방법을 찾는다.
   • 새 스키마로 갱신이 몰릴 때 데이터베이스에 거는 경합을 줄이는 방법을 찾는다.
   • 시스템 안 일부 작업의 성능 비용이 들쭉날쭉하지 않게 한다.
   • 이런 드문 경우를 더 잘 찾고 다루기 위한 계측과 실험 방법을 검토한다.

   교훈

   Honeycomb 은 기능 플래그, 잦은 배포, 장애 중 배포 중단, 지난 아차 사고에서 배운 것처럼 시스템을 안전하게 만드는 가장 믿는 관행들이 함께 이번 장애의 원인이 됐다고 봤다. 저마다 합리적인 결정들이 간접 의존 관계를 따라 예상하지 못하게 얽혔고, 환경 한쪽의 문제가 다른 쪽 서비스를 망가뜨렸다. 최근 여러 장애와 아차 사고에서 미묘한 버그를 피하려던 조치가 더 큰 예상 밖 장애로 이어진 일이 자주 있었다. 이런 드문 데이터베이스 잠김에는 페일오버가 가장 빠른 복구 방법이라는 것도 배웠다.

   사례 보기
5. IL-0483 PostgreSQL 커넥션이 바닥나 Replicate 웹사이트와 API가 두 시간 가까이 느린 응답과 HTTP 500을 냈다

   Replicate2023

   증상

   5월 11일 05:45 UTC쯤 데이터베이스 커넥션 풀이 가득 찼고, 모니터링이 이를 곧바로 감지해 05:46 UTC에 엔지니어를 호출했다. 많은 고객이 replicate.com 웹사이트와 API에서 느린 응답이나 HTTP 500 오류를 받았고, 예측 작업을 제대로 실행하지 못했다.

   오류율 상승지연 시간 증가잠금 경합과 교착

   촉발

   5월 9일과 10일에 기능 플래그로 넓게 켠 비동기 예측 상태 업데이트 기능이 같은 예측 ID로 INSERT 쿼리를 동시에 보내기 시작했다. 5월 11일 05:00 UTC가 조금 지나 평소 수준의 트래픽 변동이 이 불안정한 상태를 무너뜨렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   늦게 드러난 변경

   감지

   05:45 UTC쯤 데이터베이스 커넥션 풀이 가득 차자 모니터링 시스템이 거의 곧바로 이를 감지해 05:46 UTC에 엔지니어를 호출했다.

   조치

   • 07:31 UTC에 기능 플래그로 비동기 예측 업데이트 기능을 모두 껐다. 몇 분 안에 데이터베이스가 회복했고 서비스가 정상으로 돌아왔다.

   후속 조치

   • 비동기 예측 업데이트 기능을 꺼 둔 채로, 같은 예측 ID에 INSERT가 쌓이지 않도록 다시 설계한다.
   • 방치하면 비슷한 문제를 일으킬 수 있는 잠금 경합과 그 밖의 데이터베이스 부하 집중 지점을 점검한다.
   • 큰 장애가 나면 무슨 일이 있었고 무엇을 고치는지 담은 자세한 보고서를 공개한다.

   교훈

   Replicate는 이 장애에 복잡한 시스템 장애의 전형적인 특징이 있다고 보았다. 시스템은 성능이 떨어진 채로도 겉으로는 잘 돌다가 어느 순간 크게 무너졌다. 장애를 촉발한 방어 장치가 같은 장애를 일부 막아 주기도 했다. 변경은 새 위험을 만들지만 위험을 없애는 것도 변경이다. 한 가지를 빠르게 만든 성능 개선이 다른 곳을 훨씬 나쁘게 만들 수 있다.

   사례 보기

원인별8