사례8건

8건 중 1~5번째

1. IL-0136 Sweden Central 리전에서 내부 서비스 배포가 캐시를 비워 메타데이터 백엔드에 평소 20배의 트래픽이 몰렸고, 데이터베이스 연결에 기대는 헬스 체크가 인스턴스를 계속 재시작시켜 Azure OpenAI 요청이 6시간 가까이 실패했다

   Microsoft Azure2026

   증상

   2026년 9월 29일 10시 03분 UTC 부터 15시 58분 UTC 까지 Sweden Central 리전의 Azure OpenAI Service, Foundry Agent Service, Foundry Models, Azure AI services 에서 요청이 간헐적으로 실패했다. 고객은 이 리전에 올라간 모델과 데이터 플레인 API 에 요청을 보낼 때 지연 증가, HTTP 500 오류, HTTP 503 오류를 겪었다.

   오류율 상승지연 시간 증가간헐적 연결 실패간헐적 타임아웃프로브 실패아웃바운드 연결 고갈

   촉발

   09시 38분 UTC 에 Sweden Central 에서 내부 서비스 하나의 계획된 배포가 시작됐다. 이 배포가 그 서비스의 캐시를 비웠고, 배포 시점이 리전의 트래픽 정점과 겹쳤다.

   원인

   배포 결함

   구성 요소

   인메모리 캐시애플리케이션 데이터베이스

   기여 요인

   피크 시간 변경재시도 폭주자동화 증폭모니터링 사각지대런북 부재의존성에 묶인 헬스 체크

   감지

   10시 17분 UTC 서비스 모니터링이 리전의 Azure OpenAI Service 요청 실패율 상승을 감지해 엔지니어링 팀에 경보를 보냈다. 고객 영향이 시작되고 14분 뒤였다. 10시 28분 엔지니어가 투입돼 조사를 시작했다.

   조치

   • 15시 40분 UTC 백엔드 서비스의 자동 헬스 체크가 원격 연결에 의존하지 않도록 구성을 바꿔 재시작 루프를 멈췄다.

   후속 조치

   • 백엔드 서비스의 자동 헬스 체크가 데이터베이스 계층 연결에 의존하지 않도록 바꿔, 의존 서비스에 문제가 생겨도 인스턴스가 불필요하게 재시작되지 않게 했다.
   • 백엔드 서비스가 쓰는 캐시 계층의 부하와 지연에 모니터링과 경보를 더했다.
   • 이런 연결 고갈 상황에 맞춰 문제 해결 가이드와 절차를 고쳐 온콜 엔지니어가 비슷한 상황을 수습할 수 있게 했다.
   • 트래픽이 갑자기 늘어도 백엔드 서비스가 버티도록 스로틀링과 요청 속도 제한을 더한다. 완료 목표는 2026년 10월이다.
   • 여러 리전에서 백엔드 서비스가 쓰는 캐시 계층의 용량을 늘린다. 완료 목표는 2026년 10월이다.
   • 진단 지표와 자동 탐지를 개선해 이런 문제를 더 빨리 찾게 한다. 완료 목표는 2026년 10월이다.
   • 장기적으로 백엔드 서비스가 쓰는 캐시 계층을 파티션으로 나눠 처리량을 높인다. 완료 목표는 2026년 12월이다.

   교훈

   헬스 체크가 원격 의존성 연결에 기대면, 의존성 쪽 문제가 인스턴스를 계속 재시작시키는 루프로 번진다. 이번 장애는 트래픽 급증 자체보다 이 재시작 루프 때문에 6시간 가까이 이어졌다. 캐시를 비우는 배포를 트래픽 정점에 내보내면 캐시 미스가 뒤쪽 서비스로 한꺼번에 몰린다. 연결 고갈은 기존 네트워크 지표에 잘 드러나지 않았고, 그 사이 규모 조정과 자원 증설처럼 원인과 맞지 않는 조치에 시간을 썼다. Microsoft 는 고객에게 지수 백오프를 쓰는 재시도 패턴과 Microsoft Foundry 의 비즈니스 연속성 지침을 검토하라고 권했다.

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

   OpenAI2026

   증상

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

   오류율 상승지연 시간 증가

   촉발

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

   원인

   소프트웨어 결함

   구성 요소

   자동 용량 관리 시스템

   기여 요인

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기
3. 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 메트릭을 봐야 찾을 수 있었다. 글쓴이는 대규모 트래픽에 미리 대비한 경험이 부족했다고 돌아보고, 트래픽 패턴이 바뀔 때의 대비와 리소스 설정을 더 고민하기로 했다.

   사례 보기
4. IL-0028 쿠버네티스에서 Temporal History 파드가 CPU 사용률이 60% 아래인데도 CPU 스로틀링을 받아 요청 지연이 불안정했다

   Temporal2023

   증상

   자체 호스팅한 Temporal Server 의 History 서비스에서 요청 지연이 일정하지 않았다. 대시보드에서 history 파드의 CPU 사용률은 60% 아래로 나왔지만 파드는 CPU 스로틀링을 받고 있었다.

   CPU 스로틀링지연 시간 증가

   촉발

   노드는 8코어였고 history 파드의 CPU 한도는 2코어였는데, Go 로 작성된 Temporal Server 는 GOMAXPROCS 기본값대로 노드의 코어 8개를 모두 쓸 수 있다고 보고 동작했다.

   원인

   용량 한계

   구성 요소

   컨테이너 CPU 한도언어 런타임 설정Prometheus

   기여 요인

   기본 설정 방치모니터링 사각지대

   감지

   kube-prometheus 대시보드에서 history 파드의 CPU 사용률은 60% 아래였지만 스로틀링 비율은 0보다 컸다. 15초 이상 간격으로 수집하는 CPU 사용률 지표로는 0.1초 단위로 일어나는 스로틀링이 보이지 않으므로, 스로틀링 지표를 따로 보고서야 문제를 찾았다.

   조치

   • history 파드 배포에 GOMAXPROCS 환경 변수를 CPU 한도와 같은 2로 설정했다.

   후속 조치

   • Temporal 1.21.0 부터는 CPU 한도가 있고 GOMAXPROCS 환경 변수가 따로 설정되지 않았으면 서버가 GOMAXPROCS 를 CPU 한도에 맞춰 자동으로 설정한다.

   교훈

   CPU 사용률이 낮게 나와도 스로틀링은 일어날 수 있으므로 스로틀링 지표를 따로 관찰해야 한다. Go 서비스에서는 GOMAXPROCS 를 CPU 한도의 정수 코어 수에 맞춘다. GOMAXPROCS 는 CPU 요청값으로는 자동 설정되지 않으므로, CPU 한도를 쓰지 않는다면 CPU 요청값과 같거나 조금 큰 값으로 직접 설정한다. 가능하면 CPU 한도를 쓰지 말고 CPU 요청값을 적절히 잡은 뒤 노드 CPU 사용량을 지켜본다. 노드 CPU 가 자주 바닥나면 파드가 요청값을 넘어 자주 버스트한다는 뜻이므로 요청값을 다시 잡는다.

   사례 보기
5. IL-0205 Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다.

   GitLab2021

   증상

   2021-06-21 08:05 UTC 부터 API 의 Apdex 가 나빠지고 Rails 대기열이 늘어나는 추세가 보였다. Apdex 는 목표 시간 안에 끝난 요청의 비율로 사용자 만족도를 나타내는 지표다. 08:43 에 ahmad 가 Slack 에서 장애를 선언했고, 09:01 에 API 디플로이먼트가 비정상 상태이고, 노드를 늘려 파드 용량을 더할 수도 없다는 것을 확인했다.

   노드 증설 실패지연 시간 증가파드 Pending배포 실패

   촉발

   GitLab 이 운영하는 GCP us-east1 리전에서 SSD 재고가 바닥난 상태였는데, 사용자 트래픽이 늘어 API 서비스가 노드를 늘려야 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클러스터 오토스케일러노드 풀

   기여 요인

   모니터링 사각지대디버그 접근 제한장애 중첩

   감지

   로그를 한참 뒤져서 찾았다. 클러스터 오토스케일러 오류는 일부 노드가 백오프 상태라 확장할 수 없다고만 했고, 인스턴스 그룹 수준 오류도 ZONE_RESOURCE_POOL_EXHAUSTED 뿐이어서 어떤 자원이 바닥났는지 알 수 없었다. 결국 GCP 지원팀이 SSD 재고 부족을 알려 주었다. 탐지까지 22시간이 걸렸고, 팀은 자원 가용성 알림이 있었다면 탐지와 진단을 앞당길 수 있었다고 보았다.

   조치

   • 09:55 에 pd-standard 디스크를 쓰는 노드 풀을 하나 더 만들었다.
   • 10:37 에 새 노드 풀이 늘어나지 않자 API 부담을 덜려고 이 노드 풀을 세 존 모두에서 손으로 늘렸다.
   • 13:42 에 배포가 막혀 있고 다른 워크로드도 같은 영향을 받고 있어서 pd-standard 디스크를 쓰는 새 노드 풀들을 올리기로 했다.
   • 18:16 에 canary 시험에서 클러스터 오토스케일러가 새 노드 풀과 함께 동작하지 않자 프로덕션 배포를 막는다고 공지하고, 오토스케일러 문제로 Google 에 지원 케이스를 열었다.
   • 18:26 에 남은 워크로드의 노드 풀과 nodeSelector 를 바꾸는 인프라 작업을 시작했다.
   • pd-standard 노드 풀 위주로 하루 동안 운영하며 문제가 없는 것을 확인한 뒤 SSD 노드 풀을 정리해 없앴다.

   후속 조치

   • 쿠버네티스 서비스를 pd-standard 디스크로 옮겼다.
   • 자원 고갈 오류를 지표로 수집한다.

   교훈

   장애를 수습하는 도중 다른 버그를 만나 대응 전체가 느려졌다. 팀에는 클라우드 자원 가용성을 감시할 수단도, 자원을 미리 예약해 둘 수단도 없었다. 워크로드는 pd-ssd 대신 pd-standard 디스크에서도 문제없이 도는 것으로 보였다.

   사례 보기

원인별5