Incident Library

IL-0248 Microsoft Azure · 2026-05-29azureai-infra

Azure OpenAI Service 의 추론 요청이 여러 지역에서 느려지고 타임아웃과 HTTP 5XX 오류로 실패했다

Azure OpenAI 는 내부 라우팅·부하 분산 계층으로 추론 요청을 여러 지역과 모델 용량에 나눠 보낸다. Microsoft 365 는 Copilot 관련 기능을 포함한 일부 요청 처리에 Azure OpenAI 를 쓴다. 그런데 Microsoft 365 가 쓰는 상위 API 계층이 용량 관련 실패를 상위 계층에 전달하는 방식을 바꿨다. 이전에는 용량이나 자원이 바닥나 실패하면 설계대로 재시도했고, 그래도 실패가 이어지면 여러 상위 계층이 다시 재시도하지 않는 형태의 응답을 냈다. 변경 뒤에는 같은 상황이 일시적 서버 실패로 나타났다. 호출 경로의 여러 계층이 이를 재시도할 수 있는 응답으로 보고, 충분한 백오프나 지터 없이 곧바로 거듭 재시도했다. 실패한 요청 하나가 재시도를 최대 48번 더 부르기도 했다. 실제 고객 수요는 크게 변하지 않았는데도 내부 트래픽이 크게 불어나, 공유 추론 로드 밸런서 구성 요소가 과부하에 걸렸다. 이 내부 작업의 트래픽은 많은 외부 트래픽에 적용하는 속도 제한과 과부하 제어를 받지 않았다. 일부는 일반 외부 트래픽보다 더 직접적인 경로로 내부 라우팅 계층에 닿았다.

고객 영향은 09:20 UTC 에 Australia East 배포와 함께 시작됐고, 09:39 에 자동 모니터링이 요청 성공률 하락을 잡았다. 초기 크래시 진단을 근거로 12:17 에 오류 처리와 관련된 구성 요소를 껐다. 12:40 에 Australia East 의 트래픽이 평소 사용 패턴대로 줄면서 상태가 나아졌고, 조치가 통한 것처럼 보였다. 14:20 에 상위 배포가 Sweden Central 로 넓어지자 14:40 에 더 큰 규모로 장애가 다시 났다. 추론 라우팅 계층의 자원이 바닥나 여러 인스턴스가 메모리 부족으로 죽었다. 몇몇 지역에서는 교체할 가상 머신 SKU 의 컴퓨팅 할당량이 모자라 스케일 아웃이 막혔다. 16:20 에 팀은 앞선 조치가 부차적인 증상만 다뤘다는 것을 알았고, 16:27 에 불어난 트래픽이 Microsoft 자체 내부 작업에서 온다는 것을 확인했다. 16:30 에 그 작업을 전용 인프라로 떼어 냈고, 상위 서비스는 장애를 일으킨 변경을 롤백하고 재시도 트래픽을 줄였다. 격리와 롤백이 끝나고 밀린 요청이 모두 처리된 17:05 에 고객 영향이 끝났다고 확인했다.

심각도
–
영향 범위
Azure OpenAI Service inference requests: higher latency, intermittent failures, timeouts and HTTP 5XX errors
영향 사용자
–
지역
Multiple regions, most in Europe and Australia East (Australia East and Sweden Central named)
감지까지
19m
복구까지
7h 45m

증상

2026년 5월 29일 Azure OpenAI Service 고객의 추론 요청이 느려지고, 간헐적으로 실패하거나 타임아웃이 나거나 HTTP 5XX 오류를 받았다. 09:39 UTC 에 자동 모니터링이 요청 성공률이 떨어진 것을 잡았다. 영향은 가장 많은 트래픽을 처리하던 유럽 지역과 Australia East 에서 더 컸다.

10:10 UTC 에는 서비스 불안정이 넓게 퍼져 있었고, 여러 지역과 여러 모델에서 실패가 함께 나타났다. 늘어난 재시도 트래픽이 추론 라우팅 계층의 자원을 바닥내기 시작했다.

Australia East 에서 일어난 첫 번째 장애 때는 초기 크래시 시그니처가 오류 처리와 관련된 내부 기능을 가리켰다. 12:17 UTC 에 그 구성 요소를 껐다. 12:40 에 Australia East 의 트래픽이 평소 사용 패턴대로 줄면서 서비스 상태가 나아졌고, 조치가 통한 것처럼 보였다. 실제로는 그 기능이 원인이 아니었고 재시도 증폭은 그대로 남아 있었다.

14:20 UTC 에 상위 배포가 Sweden Central 로 넓어지자 14:40 에 같은 양상의 장애가 훨씬 큰 규모로 다시 나타났다. Sweden Central 은 유럽의 주요 처리 거점이라 트래픽이 많아 재시도 증폭이 더 강했다. 추론 라우팅 계층이 자원을 다 써 버렸고, 여러 인스턴스가 메모리 부족으로 죽었다. 해당 구성 요소를 스케일 아웃했지만 재시도 증폭을 감당하지 못했다. 몇몇 지역에서는 교체할 가상 머신 SKU 의 컴퓨팅 할당량이 모자라 스케일 아웃도 막혔다. 16:20 에 팀은 앞선 조치가 부차적인 증상만 다뤘다는 것을 알고, 상위 계층의 재시도 동작으로 조사 방향을 바꿨다.

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

원인

원인 배포 결함

구성 요소 모델 요청 라우팅
기여 요인 재시도 폭주과도한 영향 범위미검증 가정
촉발
Microsoft 365 가 쓰는 상위 API 계층의 변경으로, 용량 부족 실패가 재시도할 수 있는 일시적 서버 실패로 상위 계층에 전달되기 시작했다. 이 변경은 Australia East 에 먼저 배포되고 뒤에 Sweden Central 로 넓어졌다.

감지

09:39 UTC 에 자동 모니터링이 요청 성공률이 떨어진 것을 잡아 장애 조사를 시작했다.

조치

후속 조치

교훈

Australia East 에서 일어난 첫 번째 장애는 그럴듯하지만 불완전한 설명으로 이어졌다. 의심한 기능을 끈 뒤 트래픽이 줄어 회복한 것처럼 보였고, 그 때문에 실제 원인이 가려졌다. Sweden Central 에서 더 큰 규모로 다시 나고서야 재시도 증폭과 상위 API 계층의 변경을 원인으로 짚을 수 있었다. 이 장애는 내부 작업이 외부 트래픽만큼 보호받지 못한다는 빈틈도 드러냈다. 내부 작업의 트래픽은 같은 속도 제한과 과부하 제어를 받지 않아, 불어난 재시도가 공유 인프라에 닿기 전에 걸러지지 않았다. Microsoft 는 고객에게 중요한 AI 작업에는 여러 지역에 걸친 복원 전략을 고려하고, 클라이언트 재시도에 알맞은 백오프와 지터를 쓰며, 의존 서비스에 문제가 생겨도 애플리케이션이 기능을 줄여 버티도록 하라고 권했다.

출처

참고 문서

관련 사례

–

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 모델 요청 라우팅. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.