사례3건

3건 중 1~3번째

1. IL-0121 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 잘못된 코드가 배포되어, 그 클러스터가 함께 관리하던 운영 추론 워크로드가 망가졌다

   OpenAI2025

   증상

   2025-07-09 오후 2:10 PDT 부터 gpt-4.1-mini 모델의 API 성공률이 떨어지고 ChatGPT 검색의 오류율이 크게 올랐다.

   오류율 상승

   촉발

   잘못된 코드 변경이 주로 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 배포되었다.

   원인

   배포 결함

   구성 요소

   –

   기여 요인

   과도한 영향 범위파괴적 변경 보호 장치 부재

   조치

   • 잘못된 코드 변경을 롤백했다.

   후속 조치

   • 운영 추론 워크로드가 이 컨트롤 플레인 클러스터에서 관리되지 않도록 막는 안전장치를 더했다.
   • 영향이 큰 컨트롤 플레인 변경을 배포할 때 쓰는 테스트를 강화했다.
   • 기존 운영 추론 워크로드를 모두 운영용 컨트롤 플레인 클러스터가 관리하도록 옮긴다.
   • 의도하지 않은 대규모 변경이 서비스에 일어나지 않게 막는 서킷 브레이커를 만든다.

   사례 보기
2. IL-0086 테스트 Kubernetes 클러스터용 배포가 운영 클러스터의 Traefik 과 Calico 리소스까지 지워 CircleCI UI 와 runner.circleci.com 이 1시간 54분 동안 내려갔다.

   CircleCI2021

   증상

   2021년 3월 11일 15:35 EST 에 CircleCI UI 에 접속할 수 없게 됐다. API 는 별도 인그레스로 들어오기 때문에 계속 응답했고 빌드도 계속 돌았다.

   서비스 중단리소스 삭제

   촉발

   테스트 Kubernetes 클러스터를 대상으로 한 배포가 테스트 클러스터와 운영 클러스터 양쪽에서 Traefik 과 Calico 리소스를 지웠다.

   원인

   배포 결함

   구성 요소

   인그레스 컨트롤러Calico

   기여 요인

   과도한 영향 범위런북 부재모니터링 사각지대

   감지

   알림을 받은 엔지니어들이 조사를 시작했다. 상태 페이지에는 20:45 UTC 에 첫 공지가 올라왔다.

   조치

   • 지워진 Traefik 을 복구했다.
   • Calico 를 복구해 운영 클러스터의 파드가 다시 고객 요청을 처리하게 했다.

   후속 조치

   • Kubernetes 네트워크의 여러 계층을 모두 다루도록 네트워크 수준 문서와 런북을 보강한다.
   • 네트워크 인프라 쪽 모니터링과 알림을 개선했다.
   • 운영 클러스터와 스테이징 클러스터가 서로 간섭하지 않도록 둘을 더 확실히 떼어 놓는 안전장치를 추가한다.

   교훈

   테스트 클러스터용 배포가 운영 클러스터의 리소스를 건드릴 수 있으면 스테이징 작업이 곧 운영 장애가 된다. 스테이징 배포가 운영에 영향을 줬다는 사실이 바로 보이지 않아 조사가 DNS 와 AWS 에서 시작됐다. Traefik 만 되살려서는 복구되지 않았고 Calico 와 Traefik 의 관계까지 알아야 했다. CircleCI 는 Kubernetes 네트워크의 모든 계층을 담은 문서와 런북이 필요하다고 정리했다.

   사례 보기
3. IL-0034 메트릭 에이전트 사이드카가 업그레이드 중 크래시하자 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다

   Airbnb2019

   증상

   쿠버네티스의 메트릭 에이전트를 업그레이드하는 작업이 예정되어 있다는 공지가 나갔다. 공지에는 몇 분 동안 서비스가 메트릭을 쓰지 못할 수 있다고 적혀 있었다. 몇 분 뒤 한 서비스 담당자가 자기 쿠버네티스 서비스가 지금 모두 내려간 것 같다는 메시지를 보냈다.

   프로브 실패서비스 중단

   촉발

   예정된 작업으로 쿠버네티스의 메트릭 에이전트를 업그레이드하던 중, 파드마다 들어 있던 메트릭 에이전트 사이드카 컨테이너가 크래시했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트서비스 디스커버리

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   작업 공지가 나가고 몇 분 뒤 서비스 담당자가 자기 쿠버네티스 서비스가 모두 내려간 것 같다는 메시지를 보내와서 알았다.

   후속 조치

   • 로깅, 트레이싱, 메트릭 에이전트처럼 파드 준비 상태 판단에 넣지 않을 컨테이너를 중요하지 않은 컨테이너로 표시하고, 서비스 메시 로직이 파드 준비 상태를 판단할 때 이 컨테이너들을 건너뛰게 했다. 발표자는 이것을 임시 해결책이라고 했고 다른 방법도 검토했다고 했다.

   교훈

   헬스 체크는 컨테이너마다 걸리므로 파드 안의 각 컨테이너가 파드 전체의 준비 상태에 어떻게 영향을 주는지 따져서 설정해야 한다. 프로브를 설정하지 않은 사이드카도 크래시하면 준비되지 않은 상태가 된다.

   사례 보기

원인별1