IL-0304 Intercom · 2026-01-09database
Intercom US 리전에서 Vitess 의 라우팅 설정 VSchema 가 빈 값으로 덮여 서비스 전체가 71분 동안 멈췄다
Intercom 은 Vitess 위에 만든 PlanetScale 을 핵심 데이터베이스 계층으로 쓴다. 2026년 1월 9일 18:56 UTC 에 데이터베이스 관리 파이프라인의 한 설정 때문에 'branch unfreeze' 동작이 다음 주로 잡혀 있던 v22 버전 업그레이드를 진행하라는 신호로 해석되었다. Intercom 은 이 동작이 의도한 것이 아니었다고 밝혔다. 19:00 UTC 에 버그가 있는 Vitess v22 업그레이드가 배포되기 시작했다.
19:30 UTC 에 테스트용으로 테이블을 옮기는 MoveTables workflow 를 만들었고, 제공업체 Kubernetes 클러스터의 일시적인 네트워크 문제로 이 명령이 실패했다. MoveTables 가 실패하면 Vitess 는 상태를 되돌리려 한다. 샤딩되지 않은 keyspace 에서는 이전 VSchema 를 메모리에 담아 두지만, 샤딩된 keyspace 에서는 이 작업 중에 VSchema 가 바뀔 일이 없다고 보고 이전 상태를 남기지 않는다. 그런데 Vitess Pull Request #17401 로 v22 에 들어간 회귀 버그 때문에, 샤딩된 keyspace 에서도 이전 VSchema 를 다시 적용해야 한다는 조건이 참으로 판정되었다. 저장해 둔 적 없는 이전 VSchema 를 다시 적용하면서 운영 keyspace 토폴로지에 빈 값이 들어갔다.
19:39 UTC 에 PlanetScale 컨트롤 플레인이 빈 VSchema 를 데이터베이스 프록시 계층인 VTGate 들에 전파했고, VTGate 들은 곧바로 모든 라우팅 경로를 버렸다. 쿼리를 올바른 샤드로 보내지 못해 US 리전의 Intercom 서비스 전체가 멈췄다. 20:50 UTC 에 PlanetScale 엔지니어가 장애 한 시간 전의 VSchema 스냅샷을 다시 적용하고 실패한 workflow 의 잔여물을 지웠다. 올바른 설정이 컨트롤 플레인을 거쳐 VTGate 들에 퍼지자 VTGate 들이 내부 라우팅 테이블을 다시 만들었고 서비스가 돌아왔다. 장애는 19:39 UTC 부터 20:50 UTC 까지 71분이었고, 고객 데이터가 사라지거나 손상된 증거는 없었다. 21:00 UTC 이후 Vitess 를 v21 로 롤백했다.
- 심각도
- –
- 영향 범위
- All Intercom services in the US region were unavailable for 71 minutes
- 영향 사용자
- Intercom customers hosted in the US region
- 지역
- US
- 감지까지
- 1m
- 복구까지
- 1h 11m
증상
2026년 1월 9일 19:40 UTC 에 US 리전의 Inbox Heartbeat Anomaly 알람이 울려 장애가 선언되었다. US 리전에 호스팅된 고객은 Intercom 서비스를 전혀 쓸 수 없었다.
데이터베이스 프록시 계층인 VTGate 들이 빈 VSchema 를 받아들이자마자 모든 라우팅 경로를 버렸다. VSchema 는 샤딩된 데이터의 라우팅 정보를 담은 설정이고, VTGate 는 이 설정을 보고 쿼리를 올바른 샤드로 보낸다. 쿼리가 샤드에 닿지 못해 Intercom 애플리케이션과 데이터 계층 사이의 연결이 모두 끊겼다. 쿼리를 라우팅하고 실행하지 못했을 뿐, 저장된 데이터는 바뀌지 않았다.
빈 VSchema 는 몇 단계를 거쳐 퍼졌다. 19:00 UTC 에 버그가 있는 Vitess v22 업그레이드가 배포되기 시작했다. 19:30 UTC 에 만든 MoveTables workflow 가 실패했고, v22 버그 때문에 이 실패를 처리하는 과정에서 빈 VSchema 가 토폴로지에 적용되었다. 19:39 UTC 에 PlanetScale 컨트롤 플레인이 빈 VSchema 를 읽어 VTGate 들에 전파하면서 운영 영향이 시작되었다.
19:41 UTC 에 엔지니어들과 인시던트 커맨더가 장애를 확인하고 조사를 시작했고, 19:48 UTC 부터 PlanetScale 과 함께 조사했다.
증상 서비스 중단
원인
- 촉발
- 테스트용으로 테이블을 옮기는 MoveTables 명령이 제공업체 Kubernetes 클러스터의 일시적인 네트워크 문제로 실패했다. 이 실패를 처리하는 과정에서 Vitess v22 의 롤백 로직 버그 때문에 운영 데이터베이스에 빈 VSchema 가 적용되었다.
감지
19:40 UTC 에 US 리전의 Inbox Heartbeat Anomaly 알람이 울려 장애가 선언되었다. 19:41 UTC 에 엔지니어들과 인시던트 커맨더가 장애를 확인하고 조사를 시작했다.
조치
- PlanetScale 엔지니어가 장애 한 시간 전에 찍어 둔 VSchema 스냅샷을 다시 적용해 라우팅 토폴로지를 되살렸다.
- PlanetScale 엔지니어가 실패한 MoveTables workflow 가 남긴 잔여물을 지웠다.
- 21:00 UTC 이후 Vitess 를 v21 로 롤백하기 시작했고, 그 뒤 몇 시간에 걸쳐 끝냈다.
후속 조치
- PlanetScale 이 회귀를 일으킨 코드 경로를 찾았고 수정을 배포한다.
- Vitess 수정 패치가 충분히 검증될 때까지 Intercom 인프라의 추가 데이터베이스 업그레이드를 멈춘다.
- PlanetScale 이 장애 시작 때 Kubernetes 네트워크에서 패킷이 드롭된 원인을 찾는다.
- 잘못된 토폴로지 갱신이 애플리케이션에 닿지 않게 막을 안전장치를 PlanetScale 과 함께 더 찾는다.
- 데이터베이스 'branch unfreeze' 가 대기 중이던 버전 업그레이드를 자동으로 시작하게 만든 파이프라인 설정을 PlanetScale 과 함께 검토한다.
- 의도하지 않은 배포가 일어나지 않도록 유지보수 작업과 버전 업그레이드를 더 엄격하게 나눈다.
교훈
–
출처
관련 사례
IL-0316밀린 배포가 한꺼번에 몰린 Control Plane 에서 새 버전 PgBouncer 가 CPU 와 메모리를 비정상적으로 많이 써 데이터베이스 연결이 타임아웃됐다Railway · 2025같은 원인 · 공통 데이터베이스 프록시와 커넥션 풀러, 데이터베이스
같은 원인 · 공통 데이터베이스 프록시와 커넥션 풀러, 데이터베이스
IL-0308RevenueCat 이 Aurora PostgreSQL 10 에서 14 새 클러스터로 넘어간 직후 쿼리가 극도로 느려져 대시보드와 SDK 엔드포인트가 세 시간 넘게 실패했다RevenueCat · 2022같은 원인 · 공통 데이터베이스 프록시와 커넥션 풀러, 데이터베이스
IL-0572Merpay 회계 이벤트 처리 시스템에서 Cloud Pub/Sub 메시지 1000만 건이 밀려 새 회계 데이터가 하루 넘게 Cloud Spanner에 들어가지 못했다Mercari · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0444Aurora MySQL 에서 ALTER TABLE 을 실행할 때마다 그 테이블을 reader 로 읽던 커넥션이 끊겨 애플리케이션 오류가 쏟아졌다Repro · 2024같은 원인 · 공통 데이터베이스
IL-0117인그레스 업그레이드가 네트워크 컨트롤 플레인 회귀를 일으켜 데이터 플레인이 잠깐 끊겼고, 한꺼번에 재시작한 서비스들이 백엔드 저장소에 과부하를 일으켜 OpenAI API 오류가 늘었다OpenAI · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0304
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0304/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.