사례2건

2건 중 1~2번째

1. IL-0304 Intercom US 리전에서 Vitess 의 라우팅 설정 VSchema 가 빈 값으로 덮여 서비스 전체가 71분 동안 멈췄다

   Intercom2026

   증상

   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 과 함께 검토한다.
   • 의도하지 않은 배포가 일어나지 않도록 유지보수 작업과 버전 업그레이드를 더 엄격하게 나눈다.

   사례 보기
2. IL-0265 HAProxy 패키지 업데이트 뒤 Open Build Service 참조 서버가 약 2시간 동안 내려갔다

   Open Build Service2023

   증상

   업데이트 직후 Open Build Service 참조 서버가 내려갔다. 애플리케이션은 점검 안내 메시지나 HTTP 503 Service Unavailable 오류로 응답했고, 아무도 API 와 웹 화면을 쓸 수 없었다. 팀도 사용자도 이를 알아챘고, 사용자들은 여러 채널로 알려 왔다.

   서비스 중단

   촉발

   참조 서버에서 zypper 업데이트로 haproxy 패키지를 업데이트했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   HAProxy

   기여 요인

   장애 중첩모니터링 사각지대코드로 관리되지 않는 설정

   감지

   팀과 사용자 모두 애플리케이션이 내려간 것을 알아챘다. 사용자들이 여러 소통 채널로 알려 왔다. 문제는 업데이트 직후에 드러났다.

   조치

   • HAProxy 설정 파일을 모두 고쳤다.
   • 다른 서버의 Apache 설정에 남아 있던 점검 모드 플래그를 지웠다.
   • 서버를 재시작했고, 12시 20분 UTC 에 OBS 가 다시 올라왔다.

   후속 조치

   • 점검 모드 설정 블록이 도움이 되는지 문제가 되는지 논의한다.
   • 보조 프록시들의 SSL 인증서 동기화를 다시 살핀다.

   교훈

   "zypper up" 을 실행하면 무엇이 바뀌는지 더 잘 따져 봐야 한다. 업그레이드 중에는 주의가 필요한 것이 있기 때문이다. 보조 서버와 그 설정도 지켜봐야 한다. 평소에는 Salt 로 모든 것을 배포하지만 이번에는 보조 서버의 인증서를 놓쳤다. Apache 를 통해 Passenger 를 시작하면, Apache 에 문제가 있을 때 Passenger 프로세스가 뜨지 않는다. 그러므로 데몬이 문제없이 떠 있어도 Apache 설정 전체를 두 번 확인해야 한다. 긴 휴가 뒤에는 예상하지 못한 일이 생길 것이라고 생각해야 한다.

   사례 보기

원인별1