사례2건
2건 중 1~2번째
- 증상
2026년 1월 9일 19:40 UTC 에 US 리전의 Inbox Heartbeat Anomaly 알람이 울려 장애가 선언되었다. US 리전에 호스팅된 고객은 Intercom 서비스를 전혀 쓸 수 없었다.
- 촉발
테스트용으로 테이블을 옮기는 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 과 함께 검토한다.
- 의도하지 않은 배포가 일어나지 않도록 유지보수 작업과 버전 업그레이드를 더 엄격하게 나눈다.
- 증상
업데이트 직후 Open Build Service 참조 서버가 내려갔다. 애플리케이션은 점검 안내 메시지나 HTTP 503 Service Unavailable 오류로 응답했고, 아무도 API 와 웹 화면을 쓸 수 없었다. 팀도 사용자도 이를 알아챘고, 사용자들은 여러 채널로 알려 왔다.
- 촉발
참조 서버에서 zypper 업데이트로 haproxy 패키지를 업데이트했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀과 사용자 모두 애플리케이션이 내려간 것을 알아챘다. 사용자들이 여러 소통 채널로 알려 왔다. 문제는 업데이트 직후에 드러났다.
- 조치
- HAProxy 설정 파일을 모두 고쳤다.
- 다른 서버의 Apache 설정에 남아 있던 점검 모드 플래그를 지웠다.
- 서버를 재시작했고, 12시 20분 UTC 에 OBS 가 다시 올라왔다.
- 후속 조치
- 점검 모드 설정 블록이 도움이 되는지 문제가 되는지 논의한다.
- 보조 프록시들의 SSL 인증서 동기화를 다시 살핀다.
- 교훈
"zypper up" 을 실행하면 무엇이 바뀌는지 더 잘 따져 봐야 한다. 업그레이드 중에는 주의가 필요한 것이 있기 때문이다. 보조 서버와 그 설정도 지켜봐야 한다. 평소에는 Salt 로 모든 것을 배포하지만 이번에는 보조 서버의 인증서를 놓쳤다. Apache 를 통해 Passenger 를 시작하면, Apache 에 문제가 있을 때 Passenger 프로세스가 뜨지 않는다. 그러므로 데몬이 문제없이 떠 있어도 Apache 설정 전체를 두 번 확인해야 한다. 긴 휴가 뒤에는 예상하지 못한 일이 생길 것이라고 생각해야 한다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 프록시와 커넥션 풀러. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.