{"id":"IL-0248","org":"Microsoft Azure","date":"2026-05-29","docs":["https://learn.microsoft.com/azure/ai-services/openai/how-to/business-continuity-disaster-recovery","https://learn.microsoft.com/azure/architecture/patterns/retry"],"title":{"en":"Azure OpenAI inference requests slowed and failed in several regions as a retry storm overloaded the routing layer","ko":"Azure OpenAI Service 의 추론 요청이 여러 지역에서 느려지고 타임아웃과 HTTP 5XX 오류로 실패했다"},"domain":["azure","ai-infra"],"impact":{"scope":"Azure OpenAI Service inference requests: higher latency, intermittent failures, timeouts and HTTP 5XX errors","users":"unknown","region":"Multiple regions, most in Europe and Australia East (Australia East and Sweden Central named)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Internal workloads were not protected the way external traffic was: their traffic skipped some rate limiting and overload controls, so the amplified retries reached shared infrastructure. The apparent recovery after disabling the suspected feature hid the real cause until the problem came back at larger scale in Sweden Central.","ko":"Australia East 에서 일어난 첫 번째 장애는 그럴듯하지만 불완전한 설명으로 이어졌다. 의심한 기능을 끈 뒤 트래픽이 줄어 회복한 것처럼 보였고, 그 때문에 실제 원인이 가려졌다. Sweden Central 에서 더 큰 규모로 다시 나고서야 재시도 증폭과 상위 API 계층의 변경을 원인으로 짚을 수 있었다. 이 장애는 내부 작업이 외부 트래픽만큼 보호받지 못한다는 빈틈도 드러냈다. 내부 작업의 트래픽은 같은 속도 제한과 과부하 제어를 받지 않아, 불어난 재시도가 공유 인프라에 닿기 전에 걸러지지 않았다. Microsoft 는 고객에게 중요한 AI 작업에는 여러 지역에 걸친 복원 전략을 고려하고, 클라이언트 재시도에 알맞은 백오프와 지터를 쓰며, 의존 서비스에 문제가 생겨도 애플리케이션이 기능을 줄여 버티도록 하라고 권했다."},"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=LYXT-C1Z","kind":"official-status","archived":null}],"summary":{"en":"Azure OpenAI uses an internal routing and load balancing layer to send inference requests across regions and model capacity. Microsoft 365 uses Azure OpenAI for some requests, including Copilot experiences. A change in an upstream API layer used by that workload altered how capacity-related failures were passed up the request path: lower-level capacity or resource exhaustion conditions that used to end in a response that did not set off broad retries now surfaced as transient server failures. Several layers of the calling stack treated them as retriable and retried immediately and repeatedly without enough backoff or jitter, up to 48 extra attempts for a single failed request, so internal traffic rose sharply although customer demand had not changed much. This internal traffic was not subject to the rate limiting and overload controls used for many external callers, and part of it reached the routing layer more directly than external traffic.\n\nThe change rolled out first in Australia East, where the retries began exhausting the routing layer at 09:20 UTC. Disabling an internal error-handling feature at 12:17 UTC seemed to work because Australia East traffic fell at the same time. When the rollout expanded to Sweden Central at 14:20 UTC, its larger traffic made the retry storm overload the shared routing path again, with resource exhaustion and out-of-memory crashes. At 16:27 UTC engineers confirmed that the amplified traffic came from an internal first-party workload. They isolated that workload onto dedicated infrastructure, the upstream service began rolling back the triggering change at 16:25 UTC and reduced retry traffic, and after the backlogged requests were cleared the customer impact was declared mitigated at 17:05 UTC.","ko":"Azure OpenAI 는 내부 라우팅·부하 분산 계층으로 추론 요청을 여러 지역과 모델 용량에 나눠 보낸다. Microsoft 365 는 Copilot 관련 기능을 포함한 일부 요청 처리에 Azure OpenAI 를 쓴다. 그런데 Microsoft 365 가 쓰는 상위 API 계층이 용량 관련 실패를 상위 계층에 전달하는 방식을 바꿨다. 이전에는 용량이나 자원이 바닥나 실패하면 설계대로 재시도했고, 그래도 실패가 이어지면 여러 상위 계층이 다시 재시도하지 않는 형태의 응답을 냈다. 변경 뒤에는 같은 상황이 일시적 서버 실패로 나타났다. 호출 경로의 여러 계층이 이를 재시도할 수 있는 응답으로 보고, 충분한 백오프나 지터 없이 곧바로 거듭 재시도했다. 실패한 요청 하나가 재시도를 최대 48번 더 부르기도 했다. 실제 고객 수요는 크게 변하지 않았는데도 내부 트래픽이 크게 불어나, 공유 추론 로드 밸런서 구성 요소가 과부하에 걸렸다. 이 내부 작업의 트래픽은 많은 외부 트래픽에 적용하는 속도 제한과 과부하 제어를 받지 않았다. 일부는 일반 외부 트래픽보다 더 직접적인 경로로 내부 라우팅 계층에 닿았다.\n\n고객 영향은 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 에 고객 영향이 끝났다고 확인했다."},"trigger":{"en":"A change in an upstream API layer used by Microsoft 365 made some capacity-related failures surface as transient server failures that callers retry. It rolled out first in Australia East and later in Sweden Central.","ko":"Microsoft 365 가 쓰는 상위 API 계층의 변경으로, 용량 부족 실패가 재시도할 수 있는 일시적 서버 실패로 상위 계층에 전달되기 시작했다. 이 변경은 Australia East 에 먼저 배포되고 뒤에 Sweden Central 로 넓어졌다."},"severity":"unknown","symptoms":["high-latency","high-error-rate","intermittent-timeouts","oom-killed"],"timeline":{"detected_after":"19m","resolved_after":"7h 45m"},"date_kind":"incident","detection":{"en":"Automated monitoring detected a drop in request success rates at 09:39 UTC and started the incident investigation.","ko":"09:39 UTC 에 자동 모니터링이 요청 성공률이 떨어진 것을 잡아 장애 조사를 시작했다."},"components":["model-routing"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Isolated the internal workload that sent the amplified retries onto dedicated infrastructure","ko":"16:30 UTC 에 불어난 재시도 트래픽의 출처를 찾아, 문제를 일으킨 내부 작업을 전용 인프라로 떼어 냈다."}},{"text":{"en":"Rolled back the triggering change in the upstream service and reduced retry-driven traffic","ko":"상위 서비스가 장애를 일으킨 변경을 롤백하기 시작했고, 재시도로 불어난 트래픽을 줄이는 조치를 더 했다."}},{"text":{"en":"Cleared the backlogged requests","ko":"격리와 롤백이 끝나고 밀린 요청이 모두 처리된 뒤, 17:05 UTC 에 고객 영향이 끝났다고 확인했다."}}],"action_items":[{"text":{"en":"Move large first-party generative AI workloads onto dedicated routing infrastructure instead of the shared inference load balancing stamp","ko":"Microsoft 자체의 큰 생성형 AI 작업을 전용 라우팅 인프라로 옮겨, 여러 테넌트의 트래픽과 같은 추론 부하 분산 인프라를 함께 쓰지 않게 한다. 완료 예정은 2026년 6월이다."}},{"text":{"en":"Improve diagnostic guidance, runbooks and alerting to tell secondary crash symptoms from the real source of overload","ko":"빠르게 번지는 장애에서 엔지니어가 부차적인 크래시 증상과 과부하의 실제 출처를 더 빨리 구별하도록 진단 안내, 런북, 알림을 고친다. 완료 예정은 2026년 6월이다."}},{"text":{"en":"Work with upstream teams on retry policy design, dependency contracts and telemetry to catch retry amplification early","ko":"상위 서비스 팀과 함께 재시도 정책 설계, 의존 관계 계약, 텔레메트리를 고쳐 재시도 증폭을 더 일찍 잡고 공유 인프라로 번지지 않게 한다. 완료 예정은 2026년 7월이다."}},{"text":{"en":"Add stronger overload prevention and throttling so no single internal workload can overwhelm shared components","ko":"과부하 방지와 작업 단위 스로틀링을 강화해, 어떤 내부 작업 하나의 과도한 재시도 트래픽도 공유 구성 요소를 무너뜨리지 못하게 한다. 완료 예정은 2026년 7월이다."}},{"text":{"en":"Find and remove single points of failure in the inference routing layer","ko":"추론 라우팅 계층의 단일 장애점을 찾아 없애고 복원력을 높이는 일을 계속한다."}}],"contributing":["retry-storm","blast-radius-too-wide","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"From 09:39 to 17:05 UTC on 29 May 2026, customers sending inference requests to Azure OpenAI Service saw higher latency, intermittent failures, timeouts and HTTP 5XX errors. Automated monitoring detected falling request success rates at 09:39 UTC, and regions in Europe and Australia East, which processed the most affected traffic, were hit hardest.\n\nThe failure came in two waves. The first began at 09:20 UTC as an upstream change rolled out in Australia East, and by 10:10 UTC instability and correlated failures were seen across regions and models. Early crash signatures pointed to an internal feature related to error handling, and engineers disabled it at 12:17 UTC. Service health improved from 12:40 UTC, but only because traffic in Australia East declined as part of its normal regional usage pattern, so the mitigation looked effective although the feature was not the cause.\n\nWhen the upstream rollout reached Sweden Central at 14:20 UTC, a major European processing hub with much more traffic, the problem came back at 14:40 UTC at greater scale. The inference routing layer ran out of resources and multiple instances crashed with out-of-memory errors. The affected component scaled out, but not enough, and in a few regions scale-out was limited by the compute quota available for replacement virtual machine SKUs. At 16:20 UTC engineers concluded that the earlier mitigation had addressed a secondary symptom and turned to the upstream retry behaviour.","ko":"2026년 5월 29일 Azure OpenAI Service 고객의 추론 요청이 느려지고, 간헐적으로 실패하거나 타임아웃이 나거나 HTTP 5XX 오류를 받았다. 09:39 UTC 에 자동 모니터링이 요청 성공률이 떨어진 것을 잡았다. 영향은 가장 많은 트래픽을 처리하던 유럽 지역과 Australia East 에서 더 컸다.\n\n10:10 UTC 에는 서비스 불안정이 넓게 퍼져 있었고, 여러 지역과 여러 모델에서 실패가 함께 나타났다. 늘어난 재시도 트래픽이 추론 라우팅 계층의 자원을 바닥내기 시작했다.\n\nAustralia East 에서 일어난 첫 번째 장애 때는 초기 크래시 시그니처가 오류 처리와 관련된 내부 기능을 가리켰다. 12:17 UTC 에 그 구성 요소를 껐다. 12:40 에 Australia East 의 트래픽이 평소 사용 패턴대로 줄면서 서비스 상태가 나아졌고, 조치가 통한 것처럼 보였다. 실제로는 그 기능이 원인이 아니었고 재시도 증폭은 그대로 남아 있었다.\n\n14:20 UTC 에 상위 배포가 Sweden Central 로 넓어지자 14:40 에 같은 양상의 장애가 훨씬 큰 규모로 다시 나타났다. Sweden Central 은 유럽의 주요 처리 거점이라 트래픽이 많아 재시도 증폭이 더 강했다. 추론 라우팅 계층이 자원을 다 써 버렸고, 여러 인스턴스가 메모리 부족으로 죽었다. 해당 구성 요소를 스케일 아웃했지만 재시도 증폭을 감당하지 못했다. 몇몇 지역에서는 교체할 가상 머신 SKU 의 컴퓨팅 할당량이 모자라 스케일 아웃도 막혔다. 16:20 에 팀은 앞선 조치가 부차적인 증상만 다뤘다는 것을 알고, 상위 계층의 재시도 동작으로 조사 방향을 바꿨다."},"updated_at":"2026-11-14T12:33:49.617022Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0248","org_slug":"microsoft-azure"}