사례3건
3건 중 1~3번째
- 증상
2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.
- 촉발
2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.
- 조치
- node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
- AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
- SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.
- 후속 조치
- Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.
- 교훈
gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.
- 증상
2022년 3월 8일 18:12 UTC 부터 여러 클라이언트 앱에서 사용자가 로그아웃됐다는 신고가 올라오기 시작했다. Spotify 앱에서 로그아웃된 사용자는 다시 로그인할 수 없었고, 장애는 전 세계에 걸쳤다.
- 촉발
2022년 3월 8일 Spotify 의 일부 서비스가 서비스 디스커버리에 쓰는 Google Cloud Traffic Director 에 장애가 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
18:12 UTC 에 여러 클라이언트 앱에서 사용자가 로그아웃됐다는 신고가 올라오면서 알게 됐다.
- 조치
- 영향받은 시스템이 DNS 기반 서비스 디스커버리를 다시 쓰도록 설정 변경을 배포했다.
- 후속 조치
- Google Cloud 와 함께 Traffic Director 의 문제가 어떻게 Spotify 사용자에게 큰 장애로 번졌는지 알아본다.
- 비슷한 서비스 디스커버리 문제를 더 일찍 잡도록 모니터링과 알림을 더한다.
- 모니터링, 오류 자동 감지, 자동 복구 쪽으로 안전장치를 더 찾아 넣는다.
- 증상
2022년 1월 13일 07:28 UTC 직후 크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다. 전 세계 사용자의 Firefox 가 2시간 가까이 웹 콘텐츠를 불러오지 못하고 쓸 수 없는 상태가 됐다.
- 촉발
2022년 1월 13일 07:28 UTC 에 GCP 가 예고 없이 로드 밸런서의 HTTP/3 를 기본으로 켰다. Mozilla 의 로드 밸런서는 "Automatic (default)" 설정이어서 Firefox 가 Telemetry 서비스로 여는 연결 일부가 HTTP/2 대신 HTTP/3 를 쓰게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다.
- 조치
- 09:12 UTC 에 GCP 에서 HTTP/3 를 명시적으로 껐다.
- 후속 조치
- GCP 와 함께 예고 없는 기본값 변경 문제를 개선한다.
- 비슷한 실수를 막으려고 모든 서비스의 설정을 다시 검토한다.
- HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌린다.
- 이런 문제에 브라우저가 더 잘 견디고 사고 대응이 더 빨라지도록 할 조치를 찾는다.
- 교훈
문제는 처음 보기보다 훨씬 복잡했고 여러 요인이 함께 작용했다. GCP 가 HTTP/3 기본값 변경을 예고했다면 사고를 완전히 막지는 못했어도 스테이징 환경 같은 곳에서 더 통제된 실험과 배포를 할 수 있었을 것이다. 로드 밸런서를 명시적인 값 대신 "Automatic (default)" 로 둔 탓에 변경이 저절로 적용됐다. Firefox Desktop 에서 HTTP/3 와 viaduct 를 함께 쓰는 조합은 CI 가 시험하지 않았다. 모든 조합을 시험할 수는 없어도 HTTP 버전 선택이나 viaduct 같은 추가 네트워크 계층은 시험했어야 했다. HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌렸다면 이 문제를 찾았을 것이다.
이 3건에서 가장 많이 나오는 구성 요소: HTTP·RPC 클라이언트 라이브러리, Cilium. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.