Incident Library

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 에 엔지니어들과 인시던트 커맨더가 장애를 확인하고 조사를 시작했다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 프록시와 커넥션 풀러. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.