사례2건

2건 중 1~2번째

1. IL-0235 Azure OpenAI Service 의 GPT-5.2 모델 요청이 일곱 개 리전에서 HTTP 400 과 HTTP 429 오류로 실패했다

   Microsoft Azure2026

   증상

   2026-03-09 23:20 UTC 부터 Azure OpenAI Service 고객의 GPT-5.2 모델 요청이 HTTP 400 과 HTTP 429 오류로 실패했다. 다른 GPT 모델은 영향을 받지 않았다. 영향을 받은 리전은 Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central, UK South 였다.

   오류율 상승부하 불균형

   촉발

   Azure OpenAI 의 GPT-5.2 모델 업데이트에 든 구성 변경이 운영 중인 모델 엔진 코드 버전과 맞지 않았다. 업데이트가 효율과 복원력을 높이려고 일부 기능 설정을 켰는데, 배포된 엔진 버전은 그 설정을 아직 지원하지 않았다.

   원인

   설정 변경

   구성 요소

   모델 추론 서버모델 요청 라우팅

   기여 요인

   스테이징 불일치모니터링 사각지대장애 중첩

   감지

   3월 10일 00:19 UTC 에 서비스 모니터링이 문제를 잡았다. 고객 영향이 시작되고 약 1시간 뒤였다. 모니터링은 클라이언트 쪽 오류만 보고 서비스 쪽 HTTP 400 이상은 보지 않아 초기 감지가 늦었다.

   조치

   • 롤백이 핫픽스보다 빨리 완화할 수 있다고 판단하고 03:18 UTC 에 영향받은 모델의 롤백을 시작했다. 18:00 UTC 에 모든 영향 리전에서 롤백을 마쳤다.
   • 19:30 UTC 에 리전 전체의 용량 정보를 되살려 트래픽 분산을 정상으로 돌렸다.

   후속 조치

   • 비슷한 문제를 더 빨리 완화하도록 엔지니어에게 운영 절차 교육을 더 했다. 교육에는 어떤 상황에서 빠르게 롤백할 수 있는지가 들어갔다.
   • 의존 서비스가 리전 용량의 최신 정보를 주지 못할 때를 대비해, 검증된 트래픽 라우팅 정보를 캐시에 저장해 두게 했다.
   • 서비스 쪽 오류에 임계값을 두어 HTTP 400 오류 모니터링을 개선했다.
   • 평소 임계값에 닿지 않는 비정상 오류율에도 알림이 가도록 HTTP 4xx 오류의 이상 탐지를 개선한다. 2026년 4월에 마칠 예정이다.
   • 배포 시스템에 신호를 더 넣어 문제가 있는 배포를 자동으로 멈추게 한다. 2026년 5월에 마칠 예정이다.
   • Safe Deployment Practices 의 앞 단계에 백엔드 모델 인스턴스가 충분히 있게 해 이런 문제를 더 일찍 잡는다. 2026년 6월에 마칠 예정이다.

   사례 보기
2. IL-0413 Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다

   Microsoft2025

   증상

   Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.

   간헐적 타임아웃오류율 상승지연 시간 증가

   촉발

   몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다.

   원인

   용량 한계

   구성 요소

   모델 추론 서버

   기여 요인

   모니터링 사각지대

   감지

   논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다.

   조치

   • 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켰다.
   • request batching 과 GPU·CPU 레플리카 수를 조정했다.
   • gRPC backoff 와 오류 매핑을 고쳤다.
   • 샘플링 파라미터에 제한을 두고 클라이언트별 throttling 을 걸었다.
   • 오래 걸리는 요청에서 엔진 연결이 타임아웃 나는 문제에는 스트리밍을 켜고, request batching 을 조정하고, 대기 토큰에 상한을 뒀다. 그 결과 HTTP 408 이 줄고 성공률이 높아졌다.
   • 용량 증설, 트래픽 라우팅, 재시작을 주로 추론 엔진 장애를 완화하는 데 썼다.

   후속 조치

   • 오래 걸리는 요청과 높은 샘플링 조건에 맞게 서빙을 최적화해 타임아웃과 자원 고갈을 줄인다.
   • 헬스 프로브 기반 failover 와 GPU 용량 인지 라우팅을 넓혀, 상태가 나빠진 엔드포인트에서 트래픽이 스스로 빠져나가게 한다.
   • 토큰과 처리량 증가를 예측하고 용량 증설 결정을 자동화해, 완화 시간을 늘리는 수동 핫픽스와 수동 증설을 피한다.
   • 적응형 알림을 배포하고 엔진 수준 텔레메트리를 늘려, 트래픽이 적은 엔드포인트에서, 그리고 오류가 모호하게 변환되는 곳에서 생기는 감지 빈틈을 메운다.

   교훈

   논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.

   사례 보기

원인별2