사례4건

4건 중 1~4번째

1. IL-0379 Azure West Europe 의 InfluxDB Cloud 에서 9월 27일부터 30일까지 쿼리가 느려지고 타임아웃됐다

   InfluxData2026

   증상

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울렸다. Azure West Europe 리전 고객의 쿼리가 느려지고 타임아웃됐다. 쓰기는 계속 받았지만 일부 파티션에서는 새 데이터를 바로 조회할 수 없었다.

   지연 시간 증가간헐적 타임아웃복제 지연프로브 실패

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제라이브니스·레디니스 프로브파드 스케줄링과 배치

   기여 요인

   모니터링 사각지대자동화 증폭

   감지

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다.

   조치

   • 쿼리 계층 용량을 두 배로 늘렸다.
   • 9월 28일 아침에 멈춘 스토리지 파드를 하나씩 재시작했다.
   • 9월 29일 08:58 UTC 에 readiness 검사 타임아웃을 올려 전체에 배포했다.
   • 재시작 뒤 복구 동시성을 두 배로 늘렸다.
   • 9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올려 안전장치가 일으키던 강제 재시작을 멈췄다.
   • 스토리지 파드마다 자원 요청을 올려 호스트에 올라가는 파드 수를 줄였고, 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐다.

   후속 조치

   • 페이지 폴트 비율, 캐시 커버리지, 스토리지 볼륨의 디스크 읽기, 쿼리 중단 비율에 경고 알림을 더했다. 알림은 캐시 압박이 고객에게 보이기 전에 울리도록 만들었다.
   • 런북에 major page fault 를 스토리지 성능 저하의 선행 지표로 적고, 조정할 수 있는 완화 설정을 자세히 적었다.
   • 스토리지 엔진의 참조 누수를 계속 추적한다.
   • 디스크 검사를 상태 검사 경로에서 뺀다.

   교훈

   캐시가 모자란 상태는 메모리 지표에 드러나지 않았다. 스토리지 프로세스가 메모리를 적게 쓰고 나머지를 페이지 캐시가 차지하기 때문이다. InfluxData 는 major page fault 를 스토리지 성능 저하의 선행 지표로 본다. InfluxData 는 스토리지 엔진의 참조 누수와 상태 검사 경로의 디스크 검사가 이런 장애를 일으키는 위험 요인은 아니며, 진단과 복구 중에 눈에 띄어 조사할 만한 현상이라고 밝혔다.

   사례 보기
2. IL-0288 CDN77 의 ClickHouse 데이터 파이프라인에서 이중화된 인스턴스 세 곳의 ZooKeeperWait 가 수천 초로 치솟아 복제가 한 시간 넘게 느려졌다

   CDN772026

   증상

   13:30 UTC 에 ZooKeeperWait 지표가 갑자기 오른다는 알림이 왔다. 이 클러스터의 알림 기준은 낮은 쪽 10초, 높은 쪽 20초인데 값은 수천 초였다. 값은 대칭으로 이중화된 인스턴스 세 곳에서 똑같이 올랐다.

   복제 지연처리량 저하

   촉발

   몇 달 동안 네트워크에서 떨어져 있던 클라이언트 머신 두 대가 다시 연결되면서, 그동안 쌓인 몇 달 치 헬스 체크 데이터를 아주 작은 배치로 빠르게 보냈다.

   원인

   용량 한계

   구성 요소

   데이터베이스코디네이션 키-값 저장소데이터베이스 복제텔레메트리 에이전트

   기여 요인

   모니터링 사각지대기본 설정 방치초기 신호 무시

   감지

   13:30 UTC 에 팀은 ZooKeeperWait 지표가 갑자기 오른다는 알림을 받았다. 이 클러스터 크기에 맞춘 알림 기준은 낮은 쪽 10초, 높은 쪽 20초였다.

   조치

   • 쌓인 파트를 끝내 정리하지 못한 5분 단위 파티션 테이블을 장애 뒤 DROP-CREATE 로 다시 만들어 정상으로 되돌렸다.
   • 그 테이블의 파티션 단위를 분에서 시간으로 넓혔다.

   후속 조치

   • 루트 MaterializedView 테이블에서 범위를 벗어난 타임스탬프를 거부하도록 구현했다.
   • 두 번째 MaterializedView 가 거부된 데이터의 통계를 기록한다.
   • 거부 범위는 과거 데이터 백필을 위해 일부러 넓게 잡았고, 거부되는 데이터를 모아 가며 범위를 다듬는다.
   • 타임스탬프가 며칠이나 몇 달에 걸친 insert 쿼리 하나로 이번 상황을 재현하는 최소 시험 시나리오를 만들었다.
   • 관측 기능을 여러 가지 개선한다.

   교훈

   이 파이프라인은 주로 데이터 양을 다루지만, 어긋난 타임스탬프도 카디널리티 변화만큼 파이프라인을 흔들 수 있었다. 이상한 지표를 바로 설명하지 못했다고 치워 두면 안 된다. 이번에도 원인으로 이끈 것은 처음에 무시한 insert 크기 감소였다. 중앙값과 평균은 각자 쓸모가 있고, 이번에는 평균이 실마리였다. 파티션이 너무 적으면 파트가 커지고 mutation 이 느려지며 TTL 이 너무 비싸지거나 아예 동작하지 않는다. 반대로 너무 많으면 열 스캔과 집계 쿼리가 느려지고 Keeper 가 과부하된다. Keeper 작업은 파트 수에 따라 선형보다 훨씬 빠르게 늘었다.

   사례 보기
3. IL-0305 Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다

   Intercom2026

   증상

   2026년 1월 27일 17:25 UTC 에 메시지 백로그가 지나치게 쌓였다는 워커 알람이 울려 장애가 자동으로 선언되었다. 일부 고객의 받은편지함에서 지연이 들쭉날쭉했고 오래된 데이터가 보였다.

   복제 지연데이터베이스 과부하지연 시간 증가

   촉발

   내부 앱 삭제 작업과 ETL 파이프라인이 한 샤드에 겹쳤다. 앱 삭제 작업은 속도 제한 없이 평소보다 많은 삭제 단계를 동시에 돌렸고, ETL 파이프라인은 분석과 보고에 쓸 데이터를 같은 샤드에서 읽고 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   여유 용량 부재

   감지

   17:25 UTC 에 워커에서 메시지 백로그가 지나치게 쌓였다는 알람이 울렸고, 이 알람으로 장애가 자동으로 선언되었다.

   조치

   • 18:25 UTC 에 영향받은 샤드의 부하를 줄이려고 ETL 처리를 껐다.
   • 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다.
   • 모니터링에서 지표가 안정된 것을 확인한 뒤 ETL 을 조심스럽게 다시 켰다.

   후속 조치

   • 예상하지 못한 부하 급증에 대비할 여유를 두려고 샤드 용량을 미리 늘렸다.
   • 앱 삭제 작업에 속도 제한과 자원 통제를 넣어 데이터베이스 인프라를 짓누르지 못하게 했다. 이제 워커는 용량 한도를 지키고, 데이터베이스 부하가 높으면 처리 속도를 늦춘다.
   • ETL 과 유지보수 작업 같은 백그라운드 작업이 운영 데이터베이스 용량과 어떻게 얽히는지 검토한다. 이런 작업이 고객이 쓰는 기능과 핵심 자원을 다투지 못하게 하는 것이 목표다.
   • 복제 지연을 더 일찍 잡고 특정 작업과 연결해 볼 수 있도록 알림을 보강한다.
   • 영향 범위가 좁은 장애에서도 영향받은 고객에게 먼저 연락하도록 절차를 고친다. 상태 페이지 전체에 올릴 일이 아니어도 영향받은 고객은 제때 소식을 받게 한다.

   교훈

   Intercom 은 이 장애가 샤딩한 데이터베이스 구조의 가치를 보여 줬다고 밝혔다. 데이터를 서로 독립된 여러 샤드에 나눠 두었기 때문에, 플랫폼 전체의 성능 저하가 될 수 있었던 일이 고객 1% 미만에 그쳤다.

   사례 보기
4. IL-0443 Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다

   Repro2019

   증상

   Aurora MySQL 의 reader 가 이유를 알 수 없이 재시작했다. 그 직후부터 writer 의 insert latency 가 7배쯤 오르는 등 writer 성능이 크게 떨어진 상태가 오래 이어졌다. 같은 일이 2019년 11월 두 주 사이에 두 번 일어났다.

   지연 시간 증가복제 지연처리량 저하

   촉발

   reader 에서 오래 도는 쿼리 때문에 롤백 세그먼트가 계속 커진 끝에 reader 가 재시작했다. 글쓴이는 그 쿼리가 Redash 에서 reader 로 보낸 것이었다고 기억한다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   모니터링 사각지대

   조치

   • 팀은 writer 성능이 원래대로 돌아올 때까지 지켜보기만 했다.

   후속 조치

   • 롤백 세그먼트 길이를 Datadog 의 mysql.innodb.history_list_length 로 감시하는 모니터를 더했다.
   • reader 가 재시작할 만큼 오래 도는 쿼리를 찾으면 바로 kill 하게 했다.
   • 모니터 알림이 거의 매주 울리게 되자 사내에 알린 뒤 max_execution_time 을 설정해, 일정 시간이 지난 쿼리를 강제로 끝내게 했다.

   교훈

   롤백 세그먼트가 커지지 않도록 트랜잭션을 작게 해야 한다. 롤백 세그먼트는 클러스터 전체가 함께 쓰므로, 한번 커지면 인스턴스를 바꿔도 해제가 끝나기를 기다리는 수밖에 없다. 롤백 세그먼트 길이는 show engine innodb status 의 "History list length" 값으로 볼 수 있다.

   사례 보기

원인별1