사례3건

3건 중 1~3번째

1. IL-0058 Argo CD 에서 여러 앱이 함께 선언한 네임스페이스가 force 동기화로 지워져 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   Argo CD users2026

   증상

   application-controller 를 롤링 재시작한 뒤, 여러 앱이 함께 쓰는 네임스페이스가 Terminating 상태가 됐다. 이 네임스페이스를 쓰는 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   리소스 삭제

   촉발

   여러 앱이 같은 네임스페이스를 매니페스트에 선언했고, 네임스페이스의 app.kubernetes.io/instance 레이블은 그중 다른 앱을 가리켰다. application-controller 를 롤링 재시작한 직후, UI 에서 레이블이 가리키지 않는 앱을 force: true 로 수동 동기화했다. Argo CD 가 kubectl replace --force 로 네임스페이스를 지우고 다시 만들었다.

   원인

   소프트웨어 결함

   구성 요소

   Argo CD

   기여 요인

   파괴적 변경 보호 장치 부재미검증 가정수동 조치 악화

   후속 조치

   • 보고자가 이 이슈를 닫고, 재시작과 상관없는 재현 절차와 함께 force 동기화와 tracking-ID 충돌 문제를 다루는 #29739 를 새로 열었다.

   교훈

   argocd.argoproj.io/sync-options: Prune=false 는 prune 경로만 막고, force replace 로 일어나는 삭제는 막지 않는다. 수동 동기화는 자동 동기화와 달리 OutOfSync 검사를 거치지 않으므로 언제든 실행된다. 여러 앱이 같은 클러스터 범위 리소스를 선언하면 tracking-ID 충돌이 생기고, 소유하지 않은 앱을 force 동기화하면 그 리소스가 지워졌다가 다시 만들어질 수 있다. 처음 세운 재시작과 캐시 가설은 코드를 읽어 보니 맞지 않았다.

   사례 보기
2. IL-0124 서킷 브레이커가 풀리자 낡은 상태를 근거로 쌓여 있던 용량 조정이 한꺼번에 실행돼 여러 추론 엔진이 동시에 빠졌고, OpenAI API 의 오류율과 지연 시간이 올랐다.

   OpenAI2026

   증상

   2026년 3월 4일 오후 4시 26분 PST 무렵부터 약 30분 동안 여러 모델의 API 요청에서 오류율과 지연 시간이 올랐다. 영향은 주로 API 트래픽에 나타났고, Codex 트래픽 일부도 영향을 받았다.

   오류율 상승지연 시간 증가

   촉발

   보호용 서킷 브레이커가 일부 스케줄링 작업을 멈춰 둔 사이에 인프라 작업이 큐에 쌓였고, 서킷 브레이커가 풀리자 이 작업이 한꺼번에 실행됐다.

   원인

   소프트웨어 결함

   구성 요소

   자동 용량 관리 시스템

   기여 요인

   자동화 증폭늦게 드러난 변경파괴적 변경 보호 장치 부재모니터링 사각지대

   조치

   • 엔지니어들이 영향을 받은 모델에 인프라 자원을 손으로 다시 배정했다.
   • 추론 엔진을 다시 올리고 모델에 재배정해 서비스를 되살렸다.

   후속 조치

   • 자동 용량 관리 시스템이 실제 상태와 어긋났을 때 이를 더 잘 감지하고 대응하도록 보호 장치를 보강한다.
   • 서킷 브레이커와 스케줄링 시스템의 상태와 그 영향을 쉽게 알아볼 수 있도록 관측성을 높인다.
   • 오래 멈췄다가 풀린 뒤 큐에 쌓인 작업이 대량으로 한꺼번에 실행되지 않도록 보호 장치를 더한다.
   • 용량 조정이 실제 상태와 어긋나는 문제를 잡아내도록 모니터링과 알림을 개선한다.

   교훈

   실행을 멈춘 동안에도 작업을 큐에 쌓는 자동화는 멈춤이 풀리는 순간 낡은 상태를 근거로 한 변경을 한꺼번에 쏟아낼 수 있다. 서킷 브레이커가 무엇을 멈춰 두었는지, 풀릴 때 무엇이 실행될지 눈으로 확인할 수 있어야 한다. 긴 멈춤 뒤에 쌓인 작업이 대량으로 한 번에 실행되지 않게 막아야 한다.

   사례 보기
3. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.

   Grafana Labs2020

   증상

   2020년 3월 16일 11:31 UTC에 SLO 기반 알림이 당직 엔지니어를 호출했다. 런던 리전 Hosted Prometheus 로 들어오는 쓰기의 약 20%가 실패하고 있었다. 문제는 이미 11분 전에 시작된 상태였다.

   오류율 상승간헐적 타임아웃

   촉발

   예약된 쿠버네티스 버전 업그레이드가 etcd 리더가 돌던 노드를 정상 종료 절차 없이 갑자기 종료했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd노드 풀

   기여 요인

   기본 설정 방치파괴적 변경 보호 장치 부재

   감지

   SLO 기반 알림이 11:31 UTC에 당직 엔지니어를 호출했다. 장애가 시작되고 11분이 지난 시점이었다. 오류율이 20% 수준이었기 때문에 이대로 두었다면 월간 SLA 를 넘기기까지 약 18시간이 걸렸을 것이다.

   조치

   • 11:32 UTC에 영향받은 distributor 를 재시작했고, 오류가 멈췄다.

   후속 조치

   • Cortex 의 etcd 클라이언트 설정에 gRPC keepalive 프로브를 켠다. DialKeepAliveTime 은 10초, DialKeepAliveTimeout 은 DialTimeout 의 두 배로 두고 PermitWithoutStream 을 true 로 한다.
   • 쿠버네티스 업그레이드 절차를 고쳐, etcd operator 가 관리하는 etcd 파드까지 포함해 파드와 머신을 정상 종료 절차로 내리게 한다.

   교훈

   노드가 죽으면 TCP 연결이 정상적으로 닫히지 않고 멈춘 채 남을 수 있다. etcd 클라이언트에 keepalive 를 설정하지 않으면 새 리더가 뽑힌 뒤에도 클라이언트는 죽은 연결을 계속 쓴다. 노드를 내리는 업그레이드 스크립트는 operator 가 관리하는 파드까지 정상 종료할 수 있어야 한다. 장애 대응과 복구, 사후 분석 동안 Grafana Loki 로 로그를 빠르게 뒤질 수 있어서 복구 시간이 줄었다.

   사례 보기

원인별1