사례43건

43건 중 8~12번째

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

   OpenAI2026

   증상

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

   오류율 상승지연 시간 증가

   촉발

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

   원인

   소프트웨어 결함

   구성 요소

   자동 용량 관리 시스템

   기여 요인

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기
2. IL-0181 외부 커뮤니티 게시글로 트래픽이 몰려 상품 API 파드가 CPU limit 1코어에서 스로틀링되면서 상품 조회 페이지가 매우 느려졌다

   Kevin2026

   증상

   운영 중인 이커머스 플랫폼의 응답이 갑자기 느려졌다. 상품 조회 페이지가 특히 심했고, 사용자들에게서 "페이지가 안 열린다"는 문의가 들어왔다.

   CPU 스로틀링지연 시간 증가

   촉발

   외부 커뮤니티인 뽐뿌에 플랫폼 링크가 담긴 게시글이 올라와 짧은 시간에 많은 사용자가 몰렸고, 이 사용자들이 상품 조회 API 를 집중적으로 호출했다.

   원인

   용량 한계

   구성 요소

   컨테이너 CPU 한도수평 파드 오토스케일러

   기여 요인

   모니터링 사각지대

   감지

   사용자에게서 "페이지가 안 열린다"는 문의가 들어와 장애를 알았다. 대시보드의 파드 상태는 정상이었고, 네임스페이스 CPU 사용량과 CPU 메트릭을 직접 보고서야 CPU 스로틀링을 확인했다.

   조치

   • HPA 의 minReplicas 를 5에서 10으로 늘렸다.
   • Deployment 의 CPU limit 을 1코어에서 2코어로 올렸다.

   후속 조치

   • CPU limit 을 무작정 높이면 노드 자원을 과하게 차지할 수 있으므로, 모니터링하면서 적정 수준으로 계속 조정한다.

   교훈

   글쓴이는 예측 가능한 이벤트성 트래픽까지는 받아낼 수 있게 설정해 뒀다고 생각했다. 그러나 외부 커뮤니티 게시글 하나로 트래픽이 폭증하자 그동안 문제없던 리소스 설정이 순식간에 병목이 됐다. CPU 스로틀링은 파드 상태와 로그에 드러나지 않아서 파드 목록이 아니라 CPU 메트릭을 봐야 찾을 수 있었다. 글쓴이는 대규모 트래픽에 미리 대비한 경험이 부족했다고 돌아보고, 트래픽 패턴이 바뀔 때의 대비와 리소스 설정을 더 고민하기로 했다.

   사례 보기
3. IL-0188 EKS 롤링 업데이트 때 Kubernetes 는 새 파드가 Ready 가 되자마자 옛 파드를 지웠지만 ALB 는 새 파드를 아직 healthy 로 보지 않아, 배포마다 약 30초 동안 502 가 났다.

   Yonghyun Kim2025

   증상

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지가 왔다. 모든 파드는 Ready 였고 Datadog 도 초록불이었지만, 사용자는 계속 오류 화면을 보고 있었다.

   오류율 상승서비스 중단

   촉발

   롤링 업데이트에서 새 파드가 readinessProbe 를 통과해 Ready 가 되자 Kubernetes 가 곧바로 옛 파드를 지웠다. 그때 ALB 는 새 파드 IP 를 대상 그룹에 막 등록해 initial 상태로 헬스 체크를 하고 있었다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정기본 설정 방치모니터링 사각지대

   감지

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지로 알았다. 파드 상태와 Datadog 대시보드는 모두 정상이었고, 장애는 사용자가 보는 화면에만 나타났다.

   조치

   • 네임스페이스에 elbv2.k8s.aws/pod-readiness-gate-inject=enabled 레이블을 붙였다. AWS Load Balancer Controller 의 웹훅이 파드에 ReadinessGate 를 넣었다. 새 파드는 ALB 대상이 healthy 가 된 뒤에야 Ready 가 됐고, 그제야 옛 파드가 지워졌다.

   교훈

   Kubernetes 의 Ready 와 ALB 의 healthy 는 서로 다른 시점에 정해지므로, 둘을 잇는 장치가 없으면 롤링 업데이트 때 502 가 날 수 있다. 파드 상태와 대시보드가 모두 정상이어도 사용자는 오류를 볼 수 있다. terminationGracePeriodSeconds 를 늘려 시간을 버는 방식은 배포만 느리게 하고 새 파드가 뜰 때의 공백은 막지 못한다. ReadinessGate 는 ALB 대상 유형이 ip 일 때만 의미가 있고, instance 모드에서는 노드가 대상이라 쓸 수 없다. ReadinessGate 를 쓰면 파드가 Ready 가 되기까지 30초에서 40초가 더 걸리므로 급한 스케일 아웃에 대비해 레플리카나 HPA 를 넉넉히 잡는다. 웹훅의 failurePolicy 를 Ignore 로 두면 컨트롤러가 죽어도 배포가 막히지 않는다.

   사례 보기
4. IL-0022 Claude 서빙 인프라의 버그 세 개가 겹쳐 2025년 8월부터 9월 초까지 응답 품질이 간헐적으로 떨어졌다

   Anthropic2025

   증상

   2025년 8월 초부터 일부 사용자가 Claude 의 응답이 나빠졌다고 알리기 시작했다. 처음 들어온 보고는 평소에도 늘 오르내리는 사용자 피드백과 구분하기 어려웠다. 8월 말이 되자 보고가 더 잦아지고 끊이지 않아 조사가 시작됐다.

   응답 품질 저하요청 오라우팅

   촉발

   8월 5일 Sonnet 4 요청 일부를 1M 토큰 컨텍스트 윈도우용 서버로 보내는 라우팅 버그가 들어갔다. 8월 25일과 26일 배포에서 TPU 서버의 잘못된 설정과 토큰 선택 코드 변경이 더해졌다. 8월 29일에는 로드 밸런싱 변경으로 잘못 라우팅되는 트래픽이 늘었다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅TPUXLA 컴파일러

   기여 요인

   장애 중첩모니터링 사각지대디버그 접근 제한초기 신호 무시

   감지

   8월 초부터 사용자 보고가 들어왔지만 평소에도 늘 오르내리는 피드백과 구분되지 않았다. 8월 말 보고가 잦아지고 끊이지 않자 조사를 시작했고, 그 조사에서 버그 세 개가 드러났다. 벤치마크, 안전성 평가, 성능 지표, 소규모 카나리 배포는 이 저하를 잡지 못했다. XLA 버그는 Haiku 3.5 에서 먼저 관찰했고, Opus 3 의 문제는 나중에 이 버그와 맞아떨어지는 사용자 보고가 들어온 뒤에 알았다.

   조치

   • 짧은 컨텍스트 요청과 긴 컨텍스트 요청이 맞는 서버 풀로 가도록 라우팅 로직을 고쳐 9월 4일 배포했다.
   • TPU 서버의 잘못된 설정을 9월 2일 롤백했다.
   • 토큰 선택 코드 변경을 Haiku 3.5 는 9월 4일, Opus 3 는 9월 12일에 롤백했고, Sonnet 4 도 만약을 위해 롤백했다.
   • 근사 top-k 를 정확한 top-k 로 바꾸고 일부 연산을 fp32 정밀도로 통일했다.

   후속 조치

   • 배포 과정에 예상하지 못한 글자 출력을 잡는 테스트를 넣었다.
   • 정상 구현과 망가진 구현을 더 확실히 가려내는 평가를 만들었다.
   • 실제 운영 시스템에서 품질 평가를 계속 돌려 컨텍스트 윈도우 로드 밸런싱 오류 같은 문제를 잡는다.
   • 사용자 개인정보를 해치지 않으면서 커뮤니티 피드백을 디버깅할 수 있는 인프라와 도구를 만든다.
   • XLA:TPU 팀과 함께 컴파일러 버그 수정을 진행한다.

   교훈

   이번 세 버그는 잡음이 많은 평가에 크게 기대는 검증으로는 잡히지 않았다. Claude 가 한 번씩 하는 실수에서는 잘 회복해서 문제가 평가 점수에 드러나지 않았다. 온라인 보고가 늘어도 그 보고를 최근 변경 하나하나와 연결할 방법이 없었다. 겹친 버그가 플랫폼마다 다른 증상을 다른 빈도로 내면 원인 없는 무작위 저하처럼 보인다. 근본 원인을 고쳤다고 믿고 오래된 우회 코드를 지우면 그 코드가 가리던 다른 버그가 드러날 수 있다. 문제를 좁히는 데 결국 도움이 된 것은 사용자가 알려 준 구체적인 변화와 예상 밖 동작의 예시, 그리고 여러 사용 사례에 걸쳐 나타난 패턴이었다.

   사례 보기
5. IL-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.

   Backpackr2025

   증상

   2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.

   서비스 중단

   촉발

   2024년 1월 설날 이벤트로 트래픽이 평소보다 3배 넘게 몰렸다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블인그레스 컨트롤러Istio

   기여 요인

   단일 장애점기본 설정 방치모니터링 사각지대

   감지

   개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.

   조치

   • 서비스 전체가 멈추자 설날 이벤트를 중단했다.

   후속 조치

   • 모든 노드의 nf_conntrack_max 를 올렸다. 일반 노드는 인스턴스 전체 메모리 바이트를 16384 로 나누고 다시 2로 나눈 값, istio 노드는 그 값의 3배를 쓴다. 메모리 16GB 인스턴스라면 net.netfilter.nf_conntrack_max 가 약 50만이 된다. 이 설정은 nodeOptimizer 데몬셋에 넣어 모든 노드에 자동으로 적용했다.
   • VirtualService 의 gateways 에 mesh 를 넣어 사이드카끼리 ingressGateway 를 거치지 않고 직접 통신하게 했다. HTTPS 로 도메인을 호출하면 TLS 오프로딩 때문에 여전히 ingressGateway 나 NLB 를 거쳐야 하므로, 메시 통신은 HTTP 호출에서 쓴다.
   • istio 노드를 12.5Gbps 의 c6.xlarge 에서 최대 25Gbps 대역폭을 내는 n 타입 인스턴스로 바꿨다.
   • 모니터링을 늘렸다. ENA 의 네트워크 대역폭과 패킷 드롭, ingressGateway 와 사이드카 프로세스 상태, CPU 와 메모리 사용률과 포화 상태를 지켜본다.

   교훈

   모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.

   사례 보기

원인별9