IL-0305 Intercom · 2026-01-27database
Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다
Intercom 은 Vitess 위에 만든 PlanetScale 을 핵심 데이터베이스 계층으로 쓰고, 규모가 큰 데이터 대부분을 여러 데이터베이스 클러스터에 샤딩해 둔다. 2026년 1월 27일 한 샤드에 부하가 큰 작업 두 가지가 겹쳤다. 고객 워크스페이스를 지우는 내부 앱 삭제 작업이 속도 제한 없이 앱마다 평소보다 많은 삭제 단계를 동시에 돌렸고, 같은 때에 ETL 파이프라인이 분석과 보고에 쓸 데이터를 동기화하려고 같은 샤드를 읽었다. 두 작업의 부하가 복제본의 용량을 넘어 이 샤드를 맡은 복제본 두 대가 모두 CPU 100% 에 닿았다. 복제본은 주 데이터베이스의 변경 스트림을 따라가지 못했고, 복제 지연이 최대 2.2시간까지 늘었다.
17:03 UTC 부터 복제 지연이 쌓였고, 17:25 UTC 에 메시지 백로그 알람이 울려 장애가 자동으로 선언되었다. 18:25 UTC 에 이 샤드의 부하를 줄이려고 ETL 처리를 껐고, 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다. 지표가 안정된 것을 본 뒤 ETL 을 조심스럽게 다시 켰다. 22:09 UTC 에 모든 복제본의 CPU 가 정상으로 돌아오고 복제 지연이 사라졌다. 영향은 Intercom 고객 1% 미만에 그쳤다. 쓰기는 내내 정상이었고, 고객 데이터가 사라지거나 손상된 증거는 없었다.
- 심각도
- –
- 영향 범위
- Inbox reads for customers on one shard were slow and returned data up to 2.2 hours old; writes kept working
- 영향 사용자
- fewer than 1% of Intercom customers
- 지역
- US
- 감지까지
- 22m
- 복구까지
- 5h 6m
증상
2026년 1월 27일 17:25 UTC 에 메시지 백로그가 지나치게 쌓였다는 워커 알람이 울려 장애가 자동으로 선언되었다. 일부 고객의 받은편지함에서 지연이 들쭉날쭉했고 오래된 데이터가 보였다.
고객 쪽에서는 대화를 만들어도 받은편지함에 바로 나타나지 않았다. 메시지가 보내지지 않은 것처럼 보였지만, 실제로는 제대로 저장되었다. 설정이나 데이터를 바꿔도 적용되지 않은 것처럼 보였다. 쓰기는 장애 내내 정상이었고, 영향은 읽기에서 오래된 데이터가 나오는 것에 그쳤다.
데이터베이스 쪽에서는 17:03 UTC 부터 한 샤드의 복제본 CPU 가 오르며 복제 지연이 쌓이기 시작했다. 이 샤드를 맡은 복제본 두 대가 모두 CPU 100% 에 닿았고, 주 데이터베이스에서 오는 변경 스트림을 따라가지 못해 백로그가 쌓였다. 복제 지연은 꾸준히 늘어 최대 2.2시간까지 갔다.
원인
- 촉발
- 내부 앱 삭제 작업과 ETL 파이프라인이 한 샤드에 겹쳤다. 앱 삭제 작업은 속도 제한 없이 평소보다 많은 삭제 단계를 동시에 돌렸고, ETL 파이프라인은 분석과 보고에 쓸 데이터를 같은 샤드에서 읽고 있었다.
감지
17:25 UTC 에 워커에서 메시지 백로그가 지나치게 쌓였다는 알람이 울렸고, 이 알람으로 장애가 자동으로 선언되었다.
조치
- 18:25 UTC 에 영향받은 샤드의 부하를 줄이려고 ETL 처리를 껐다.
- 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다.
- 모니터링에서 지표가 안정된 것을 확인한 뒤 ETL 을 조심스럽게 다시 켰다.
후속 조치
- 예상하지 못한 부하 급증에 대비할 여유를 두려고 샤드 용량을 미리 늘렸다.
- 앱 삭제 작업에 속도 제한과 자원 통제를 넣어 데이터베이스 인프라를 짓누르지 못하게 했다. 이제 워커는 용량 한도를 지키고, 데이터베이스 부하가 높으면 처리 속도를 늦춘다.
- ETL 과 유지보수 작업 같은 백그라운드 작업이 운영 데이터베이스 용량과 어떻게 얽히는지 검토한다. 이런 작업이 고객이 쓰는 기능과 핵심 자원을 다투지 못하게 하는 것이 목표다.
- 복제 지연을 더 일찍 잡고 특정 작업과 연결해 볼 수 있도록 알림을 보강한다.
- 영향 범위가 좁은 장애에서도 영향받은 고객에게 먼저 연락하도록 절차를 고친다. 상태 페이지 전체에 올릴 일이 아니어도 영향받은 고객은 제때 소식을 받게 한다.
교훈
Intercom 은 이 장애가 샤딩한 데이터베이스 구조의 가치를 보여 줬다고 밝혔다. 데이터를 서로 독립된 여러 샤드에 나눠 두었기 때문에, 플랫폼 전체의 성능 저하가 될 수 있었던 일이 고객 1% 미만에 그쳤다.
출처
관련 사례
같은 원인 · 공통 데이터베이스, 데이터베이스 복제
IL-0288CDN77 의 ClickHouse 데이터 파이프라인에서 이중화된 인스턴스 세 곳의 ZooKeeperWait 가 수천 초로 치솟아 복제가 한 시간 넘게 느려졌다CDN77 · 2026같은 원인 · 공통 데이터베이스, 데이터베이스 복제
IL-0443Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다Repro · 2019같은 원인 · 공통 데이터베이스, 데이터베이스 복제
IL-0334RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다Instapaper · 2017같은 원인 · 공통 데이터베이스, 데이터베이스 복제
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0390PostHog US Cloud 의 Persons Postgres 데이터베이스 쓰기가 크게 느려져 이벤트와 persons 수집이 최대 2일 지연됐다PostHog · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0287Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다MongoDB · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0298Wikimedia sessionstore 의 Cassandra 노드가 디스크가 가득 차 잇따라 죽고 쿼럼을 잃어 편집이 실패했다Wikimedia Foundation · 2025같은 원인 · 공통 데이터베이스
IL-0312max_connections 를 올리려고 재시작한 주 PostgreSQL 데이터베이스가 다시 올라오지 않아 Gadget 의 모든 앱 요청이 멈췄다Gadget · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0110Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0202갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1같은 원인 · 공통 데이터베이스
IL-0386Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다incident.io · 2023같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0206GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0496전역 복제 Cassandra 클러스터에서 모든 리전의 인스턴스 CPU 가 100% 로 치솟아 쿼리가 타임아웃됐고, 같은 부하가 이틀 저녁 더 찾아왔다Ably · 2020같은 원인 · 공통 데이터베이스
IL-0037imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0211Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다Mailchimp · 2019같은 원인 · 공통 데이터베이스
IL-0064CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0333사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다Buildkite · 2016같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스 복제
IL-0282US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다Amazon Web Services · 2015같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0305
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0305/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.