{"id":"IL-0136","org":"Microsoft Azure","date":"2026-09-29","docs":["https://aka.ms/air/7QL5-Z50","https://azure.microsoft.com/blog/enterprise-trust-in-azure-openai-service-strengthened-with-data-zones/","https://learn.microsoft.com/azure/foundry/how-to/high-availability-resiliency","https://learn.microsoft.com/azure/architecture/patterns/retry"],"title":{"en":"A deployment that cleared an internal service's caches at peak traffic sent 20 times the normal load to the Azure OpenAI metadata backend in Sweden Central, and health checks that depended on its database restarted instances in a loop for almost six hours","ko":"Sweden Central 리전에서 내부 서비스 배포가 캐시를 비워 메타데이터 백엔드에 평소 20배의 트래픽이 몰렸고, 데이터베이스 연결에 기대는 헬스 체크가 인스턴스를 계속 재시작시켜 Azure OpenAI 요청이 6시간 가까이 실패했다"},"domain":["azure","ai-infra"],"impact":{"scope":"Azure OpenAI Service, Foundry Agent Service, Foundry Models and Azure AI services: intermittent request failures, higher latency, HTTP 500 and 503 errors on models and data plane APIs hosted in the region","users":"unknown","region":"Sweden Central"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A health check that depends on a remote dependency turns a dependency problem into a restart loop: instances that cannot reach the database are killed, the remaining ones take more load and retries, and adding instances or resources does not help until the check itself is changed.\n\nClearing a cache during peak traffic can multiply load on the backend behind it, especially when cache-read defects let lookups bypass the cache. Connection exhaustion was hard to see because the existing network and diagnostic metrics did not show it.","ko":"헬스 체크가 원격 의존성 연결에 기대면, 의존성 쪽 문제가 인스턴스를 계속 재시작시키는 루프로 번진다. 이번 장애는 트래픽 급증 자체보다 이 재시작 루프 때문에 6시간 가까이 이어졌다. 캐시를 비우는 배포를 트래픽 정점에 내보내면 캐시 미스가 뒤쪽 서비스로 한꺼번에 몰린다.\n\n연결 고갈은 기존 네트워크 지표에 잘 드러나지 않았고, 그 사이 규모 조정과 자원 증설처럼 원인과 맞지 않는 조치에 시간을 썼다. Microsoft 는 고객에게 지수 백오프를 쓰는 재시도 패턴과 Microsoft Foundry 의 비즈니스 연속성 지침을 검토하라고 권했다."},"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=7QL5-Z50","kind":"official-status","license":"unknown","archived":null}],"summary":{"en":"Azure OpenAI Service and related Azure AI services look up each calling account's resource metadata and configuration in a regional backend service, which reads from a caching layer and a database layer. Internal services that call this backend keep their own caches of this information to reduce load on it.\n\nA planned deployment of one of those internal services in Sweden Central cleared its caches at peak traffic, which produced a large number of cache misses. Two defects in how the service read from its caches made most lookups bypass the cache and call the backend directly. By about 10:00 UTC the backend received roughly 20 times its normal traffic. Its own requests to the caching layer drove that layer to full utilisation, latency rose, connections stayed open longer, client retries added requests, and the network connection capacity on the infrastructure node instances ran out, so no new outbound connections to the caching or database layers could be made.\n\nThe surge started the incident, but its length came mainly from the backend's health checks, which depended on connecting to the database layer. Instances that could not open new outbound connections failed the check and were restarted by design, which shrank the pool of healthy instances further. Scaling and resource changes did not help. At 15:40 UTC the health check was reconfigured to no longer depend on remote connectivity, the restart loop stopped, and availability recovered by 15:58 UTC. At 16:30 UTC the source of the extra traffic was traced to the internal service deployment.","ko":"Azure OpenAI Service 와 관련 Azure AI 서비스는 요청이 들어오면 리전의 백엔드 서비스에서 요청한 계정의 리소스 메타데이터와 구성 정보를 가져온다. 이 백엔드 서비스는 캐시 계층과 데이터베이스 계층을 읽는다. 백엔드 서비스를 부르는 다른 내부 서비스들은 백엔드 부하를 줄이려고 같은 정보를 자기 캐시에 따로 들고 있다.\n\n09시 38분 UTC 에 이런 내부 서비스 하나의 계획된 배포가 Sweden Central 에서 시작됐다. 배포 과정에서 캐시가 비워졌고, 트래픽 정점 시간과 겹쳐 캐시 미스가 대량으로 났다. 그 서비스가 캐시를 읽는 방식에 있던 결함 두 개가 이를 키워, 대부분의 조회가 캐시를 건너뛰고 백엔드 서비스를 직접 불렀다. 10시 무렵 백엔드 서비스로 가는 트래픽은 평소의 약 20배가 됐다.\n\n이 급증으로 백엔드 서비스가 캐시 계층에 보내는 요청이 크게 늘었고, 캐시 계층이 사용률 한계에 닿아 지연이 커졌다. 지연이 커지자 연결이 더 오래 열려 있었고, 클라이언트 재시도가 요청을 더 얹었다. 결국 인프라 노드 인스턴스의 네트워크 연결 용량이 바닥나 캐시 계층과 데이터베이스 계층으로 새 아웃바운드 연결을 맺을 수 없게 됐다.\n\n트래픽 급증은 시작점이었고, 장애가 길어진 주된 이유는 백엔드 서비스가 인스턴스의 건강 상태를 판단하는 방식이었다. 인스턴스마다 도는 자동 헬스 체크는 데이터베이스 계층에 연결이 되어야 통과했다. 새 아웃바운드 연결을 맺지 못한 인스턴스는 헬스 체크에 실패해 설계대로 자동 재시작됐다. 재시작 루프에 들어간 인스턴스가 늘수록 요청을 받을 정상 인스턴스가 줄었고, 의존 서비스들의 재시도가 남은 인스턴스의 부하를 더 키웠다.\n\n인스턴스 규모 조정과 컴퓨트, 메모리 증설로는 장애가 풀리지 않았다. 15시 40분 자동 헬스 체크가 원격 연결에 의존하지 않도록 구성을 바꾸자 재시작 루프가 멈추고 가용성이 돌아오기 시작했다. 15시 58분 고객 영향이 해소됐고, 16시 30분 트래픽 급증의 출처를 찾아 내부 서비스 배포와 연결 지었다."},"trigger":{"en":"At about 09:38 UTC a planned deployment of an internal service in Sweden Central cleared that service's caches during the region's peak traffic hours.","ko":"09시 38분 UTC 에 Sweden Central 에서 내부 서비스 하나의 계획된 배포가 시작됐다. 이 배포가 그 서비스의 캐시를 비웠고, 배포 시점이 리전의 트래픽 정점과 겹쳤다."},"severity":"unknown","symptoms":["high-error-rate","high-latency","intermittent-connection-failures","intermittent-timeouts","readiness-probe-failures","outbound-connections-exhausted"],"timeline":{"detected_after":"14m","resolved_after":"5h 55m"},"date_kind":"incident","detection":{"en":"Service monitoring detected elevated failure rates for Azure OpenAI Service requests in the region at 10:17 UTC and alerted the engineering teams; engineers were engaged at 10:28 UTC.","ko":"10시 17분 UTC 서비스 모니터링이 리전의 Azure OpenAI Service 요청 실패율 상승을 감지해 엔지니어링 팀에 경보를 보냈다. 고객 영향이 시작되고 14분 뒤였다. 10시 28분 엔지니어가 투입돼 조사를 시작했다."},"components":["cache","database"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"reconfigured the backend service's automated health check so it no longer depended on remote connectivity, which stopped the restart loop","ko":"15시 40분 UTC 백엔드 서비스의 자동 헬스 체크가 원격 연결에 의존하지 않도록 구성을 바꿔 재시작 루프를 멈췄다."}}],"action_items":[{"text":{"en":"Reconfigure the backend service's automated health check so it no longer depends on connectivity to its database layer","ko":"백엔드 서비스의 자동 헬스 체크가 데이터베이스 계층 연결에 의존하지 않도록 바꿔, 의존 서비스에 문제가 생겨도 인스턴스가 불필요하게 재시작되지 않게 했다."}},{"text":{"en":"Add monitoring and alerting on the load and latency of the caching layer used by the backend service","ko":"백엔드 서비스가 쓰는 캐시 계층의 부하와 지연에 모니터링과 경보를 더했다."}},{"text":{"en":"Update troubleshooting and procedural guidance for connection exhaustion scenarios for on-call engineers","ko":"이런 연결 고갈 상황에 맞춰 문제 해결 가이드와 절차를 고쳐 온콜 엔지니어가 비슷한 상황을 수습할 수 있게 했다."}},{"text":{"en":"Add throttling and rate limiting to protect the backend service from sudden traffic increases (estimated October 2026)","ko":"트래픽이 갑자기 늘어도 백엔드 서비스가 버티도록 스로틀링과 요청 속도 제한을 더한다. 완료 목표는 2026년 10월이다."}},{"text":{"en":"Increase the resource capacity of the caching layer used by the backend service across regions (estimated October 2026)","ko":"여러 리전에서 백엔드 서비스가 쓰는 캐시 계층의 용량을 늘린다. 완료 목표는 2026년 10월이다."}},{"text":{"en":"Improve diagnostic metrics and automated detection to identify such issues more quickly (estimated October 2026)","ko":"진단 지표와 자동 탐지를 개선해 이런 문제를 더 빨리 찾게 한다. 완료 목표는 2026년 10월이다."}},{"text":{"en":"Partition the caching layer used by the backend service to increase its throughput (estimated December 2026)","ko":"장기적으로 백엔드 서비스가 쓰는 캐시 계층을 파티션으로 나눠 처리량을 높인다. 완료 목표는 2026년 12월이다."}}],"contributing":["change-in-peak-hours","retry-storm","automation-amplified","monitoring-blind-spot","no-runbook","probe-depends-on-dependency"],"recurrence_of":null,"symptoms_text":{"en":"From 10:03 UTC on 29 September 2026, requests to Azure OpenAI Service, Foundry Agent Service, Foundry Models and Azure AI services in Sweden Central failed intermittently, took longer, or returned HTTP 500 and 503 errors. At 10:17 UTC service monitoring raised an alert on elevated failure rates for Azure OpenAI Service requests in the region.\n\nAt 11:30 UTC engineers found that the service instances on the infrastructure nodes were timing out when they tried to connect to the backend service's caching and database layers. By 13:55 UTC the database layer had been confirmed healthy.\n\nThe backend service's instances were failing their automated health checks, because each check required a new connection to the database layer, and were being restarted automatically. As more instances entered the restart loop, fewer healthy instances were left, and retries from dependent services added more load to them.\n\nThe existing network and diagnostic metrics did not show that outbound connections were exhausted, and correlating the failures with that cause took a long time. Scaling the number of instances to reduce outbound connections, adding compute and memory, raising resource limits and restarting instances did not resolve the incident.","ko":"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 오류를 겪었다.\n\n10시 17분 서비스 모니터링이 이 리전의 Azure OpenAI Service 요청 실패율 상승을 잡아 엔지니어링 팀에 알렸다. 11시 30분에는 인프라 노드의 서비스 인스턴스가 백엔드 서비스의 캐시 계층과 데이터베이스 계층에 연결할 때 타임아웃이 난다는 것을 확인했다.\n\n기존 네트워크 지표와 진단 지표는 이번 연결 고갈을 제대로 보여 주지 못했고, 요청 실패와 연결 고갈의 원인을 연결 짓는 데 오래 걸렸다. 11시 21분에는 다른 엔지니어링 팀까지 불러 Sweden Central 의 Azure OpenAI Service 에 최근 나간 배포 가운데 이번 문제와 맞물리는 것이 있는지 살폈다.\n\n13시 55분 데이터베이스 계층은 정상임을 확인했다. 아웃바운드 연결 수를 줄이려고 서비스 인스턴스 규모를 여러 방식으로 조정했지만 크게 나아지지 않았다. 15시에는 백엔드 서비스의 컴퓨트 자원과 리소스 한도를 더 늘리고, 영향받은 인스턴스의 인프라 상태를 조사하면서 인스턴스를 재시작했지만 이것도 장애를 끝내지 못했다."},"updated_at":"2026-11-10T00:00:35.523105Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0136","org_slug":"microsoft-azure"}