IL-0235 Microsoft Azure · 2026-03-09ai-infraazure
Azure OpenAI Service 의 GPT-5.2 모델 요청이 일곱 개 리전에서 HTTP 400 과 HTTP 429 오류로 실패했다
Azure OpenAI Service 는 여러 Azure 리전에 배포된 모델 엔진과 트래픽 라우팅 시스템으로 고객 요청을 처리한다. GPT-5.2 모델 업데이트가 효율과 복원력을 높이려고 일부 기능 설정을 켰지만, 운영 중인 모델 엔진 버전은 이 설정을 지원하지 않았다. 요청이 이 불일치가 있는 엔진으로 가면 서비스가 요청을 제대로 처리하지 못했다. 업데이트는 Safe Deployment Practices 에 따라 리전별로 단계를 나눠 배포되었지만, 앞 단계에는 문제가 드러날 만큼 백엔드 모델 인스턴스가 많지 않았다. 그래서 고객 영향을 알아채기 전에 업데이트가 전체에 배포되었다.
2026-03-09 23:20 UTC 에 고객 영향이 시작되었다. 일곱 개 리전에서 GPT-5.2 요청이 HTTP 400 과 HTTP 429 오류로 실패했다. 모니터링은 클라이언트 쪽 오류만 보고 서비스 쪽 HTTP 400 이상은 보지 않아 초기 감지와 대응이 늦었다. 3월 10일 00:19 UTC 에 서비스 모니터링이 문제를 잡았고, 팀은 조사와 핫픽스 개발을 시작했다. 03:18 UTC 에 팀은 롤백이 더 빠르다고 보고 영향받은 모델을 롤백하기 시작했다.
복구 중에 두 번째 문제가 드러났다. Azure OpenAI 는 내부 텔레메트리로 리전별 실시간 용량을 파악해 트래픽을 보낸다. 그런데 첫 문제와 상관없는 텔레메트리 시스템 문제로 불완전한 용량 정보가 쓰였다. 10:55 UTC 에 팀은 트래픽 경로가 불완전한 데이터로 정해지고 있다는 것을 확인했다. 트래픽이 일부 리전에 몰려 그 리전의 자원이 부족해졌다. 그래서 롤백이 진행되고 다른 리전이 요청을 받을 수 있는데도 일부 고객은 HTTP 429 실패를 간헐적으로 겪었다. 12:40 UTC 에 자원 제약을 찾아 조사했고, 18:00 UTC 에 모든 영향 리전에서 롤백을 마쳤다. 19:30 UTC 에 리전 전체의 용량 정보가 돌아와 트래픽 분산이 정상이 되었고, 19:32 UTC 에 모니터링으로 안정을 확인한 뒤 완전 복구를 선언했다.
- 심각도
- –
- 영향 범위
- Azure OpenAI Service requests to the GPT-5.2 model returned HTTP 400 and HTTP 429 errors; other GPT models were unaffected
- 영향 사용자
- –
- 지역
- Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central and UK South
- 감지까지
- 59m
- 복구까지
- 20h 12m
증상
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 였다.
HTTP 400 은 평소 서비스에서도 나는 응답이어서 처음에는 이상 징후로 잡히지 않았다. 모니터링은 요청 매개변수가 잘못되어 생기는 클라이언트 쪽 오류만 보도록 되어 있었고 서비스 쪽 이상은 보지 않았다. 서비스 모니터링이 문제를 잡은 것은 3월 10일 00:19 UTC 였다.
구성 변경을 롤백하는 동안에도 일부 고객은 HTTP 429 오류로 요청이 간헐적으로 실패했다. 다른 리전이 요청을 받을 수 있었는데도 트래픽이 몇몇 리전에 몰려 그 리전들의 자원이 모자랐다.
팀은 처음에 핫픽스를 만들기 시작했다. 그러다 03:18 UTC 에 롤백이 핫픽스보다 빨리 완화할 수 있다고 판단해 영향받은 모델을 롤백하기 시작했다.
원인
- 촉발
- 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월에 마칠 예정이다.
교훈
–
출처
- https://azure.status.microsoft/en-us/status/history/?trackingId=8GCS-858 · official-status
참고 문서
관련 사례
IL-0407정리 자동화가 Azure OpenAI 의 GPU VM 과 모델 엔드포인트를 지워 28개 지역 중 14곳에서 5xx 오류가 났다Microsoft Azure · 2024같은 원인 · 공통 모델 추론 서버
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0235
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0235/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.