사례2건

2건 중 1~2번째

1. IL-0136 Sweden Central 리전에서 내부 서비스 배포가 캐시를 비워 메타데이터 백엔드에 평소 20배의 트래픽이 몰렸고, 데이터베이스 연결에 기대는 헬스 체크가 인스턴스를 계속 재시작시켜 Azure OpenAI 요청이 6시간 가까이 실패했다

   Microsoft Azure2026

   증상

   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 오류를 겪었다.

   오류율 상승지연 시간 증가간헐적 연결 실패간헐적 타임아웃프로브 실패아웃바운드 연결 고갈

   촉발

   09시 38분 UTC 에 Sweden Central 에서 내부 서비스 하나의 계획된 배포가 시작됐다. 이 배포가 그 서비스의 캐시를 비웠고, 배포 시점이 리전의 트래픽 정점과 겹쳤다.

   원인

   배포 결함

   구성 요소

   인메모리 캐시애플리케이션 데이터베이스

   기여 요인

   피크 시간 변경재시도 폭주자동화 증폭모니터링 사각지대런북 부재의존성에 묶인 헬스 체크

   감지

   10시 17분 UTC 서비스 모니터링이 리전의 Azure OpenAI Service 요청 실패율 상승을 감지해 엔지니어링 팀에 경보를 보냈다. 고객 영향이 시작되고 14분 뒤였다. 10시 28분 엔지니어가 투입돼 조사를 시작했다.

   조치

   • 15시 40분 UTC 백엔드 서비스의 자동 헬스 체크가 원격 연결에 의존하지 않도록 구성을 바꿔 재시작 루프를 멈췄다.

   후속 조치

   • 백엔드 서비스의 자동 헬스 체크가 데이터베이스 계층 연결에 의존하지 않도록 바꿔, 의존 서비스에 문제가 생겨도 인스턴스가 불필요하게 재시작되지 않게 했다.
   • 백엔드 서비스가 쓰는 캐시 계층의 부하와 지연에 모니터링과 경보를 더했다.
   • 이런 연결 고갈 상황에 맞춰 문제 해결 가이드와 절차를 고쳐 온콜 엔지니어가 비슷한 상황을 수습할 수 있게 했다.
   • 트래픽이 갑자기 늘어도 백엔드 서비스가 버티도록 스로틀링과 요청 속도 제한을 더한다. 완료 목표는 2026년 10월이다.
   • 여러 리전에서 백엔드 서비스가 쓰는 캐시 계층의 용량을 늘린다. 완료 목표는 2026년 10월이다.
   • 진단 지표와 자동 탐지를 개선해 이런 문제를 더 빨리 찾게 한다. 완료 목표는 2026년 10월이다.
   • 장기적으로 백엔드 서비스가 쓰는 캐시 계층을 파티션으로 나눠 처리량을 높인다. 완료 목표는 2026년 12월이다.

   교훈

   헬스 체크가 원격 의존성 연결에 기대면, 의존성 쪽 문제가 인스턴스를 계속 재시작시키는 루프로 번진다. 이번 장애는 트래픽 급증 자체보다 이 재시작 루프 때문에 6시간 가까이 이어졌다. 캐시를 비우는 배포를 트래픽 정점에 내보내면 캐시 미스가 뒤쪽 서비스로 한꺼번에 몰린다. 연결 고갈은 기존 네트워크 지표에 잘 드러나지 않았고, 그 사이 규모 조정과 자원 증설처럼 원인과 맞지 않는 조치에 시간을 썼다. Microsoft 는 고객에게 지수 백오프를 쓰는 재시도 패턴과 Microsoft Foundry 의 비즈니스 연속성 지침을 검토하라고 권했다.

   사례 보기
2. IL-0145 Australia East 의 전압 강하로 냉각기가 멈춰 데이터 홀 장비가 꺼지면서, 영역 중복이 아닌 AKS 작업 큐 데이터베이스가 내려가 두 리전의 AKS 생성, 수정, 삭제 작업이 막혔다

   Microsoft Azure2023

   증상

   2023년 8월 30일 10시 30분 UTC 무렵부터 Australia East 리전에서 Azure, Microsoft 365, Power Platform 서비스에 접근하거나 쓰는 데 문제가 생겼다. AKS 에서는 리소스 공급자를 거치는 생성, 조회, 수정, 삭제 작업과 스케일링이 실패했다.

   컨트롤 플레인 무응답오류율 상승서비스 중단

   촉발

   8월 30일 08시 41분 UTC, Australia East 의 영향받은 가용 영역에서 약 18마일 떨어진 전력 설비에 낙뢰가 떨어져 전압 강하가 일어났다. 이 전압 강하로 여러 데이터센터의 냉각 시스템에 있는 냉각기가 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   AKS 컨트롤 플레인애플리케이션 데이터베이스

   기여 요인

   단일 장애점과도한 영향 범위

   감지

   10시 47분 UTC Cosmos DB 영향이 모니터링에 잡혔고, 10시 48분 첫 자동 공지가 Azure Service Health 로 나갔다. 11시 30분 공개 Azure 상태 페이지에 첫 공지가 올라갔고, 11시 36분 Australia East 의 모든 구독에 포털 공지를 보냈다.

   조치

   • 11시 34분 UTC 냉수 온도를 낮추려고 영향받은 데이터 홀의 남은 네트워크, 컴퓨트, 스토리지 장비를 원격으로 내렸다.
   • 12시 12분 UTC 재시작이 막혔던 냉각기 다섯 대를 손으로 다시 켰다.
   • 데이터 홀 안전 점검을 마친 뒤 장비에 단계적으로 전원을 넣어 15시 10분 UTC 모든 장비의 전원을 복구했다.
   • AKS 작업 큐로 쓰는 SQL Database 가 복구되자 다른 조치 없이도 AKS 작업이 되살아났다.

   후속 조치

   • AKS 팀은 작업 큐로 쓰는 SQL Database 데이터베이스를 모두 영역 중복으로 즉시 전환한다. 완료 목표는 2023년 9월이다.
   • AKS 팀은 리전을 넘나드는 SQL Database 큐 사용을 모두 영역 중복 Service Bus 큐로 바꾼다. 완료 목표는 2023년 9월이다.
   • 가용 영역의 부하가 조금씩 늘면서 냉각기 운전 구성이 냉각기 관리 시스템의 타이밍 결함에 취약해져 있었다. 전압 변동 뒤 재시작에 실패하지 않도록 냉각기 관리 시스템의 제어 타이밍 로직을 바꿨다.
   • 여러 냉각기가 한꺼번에 멈췄을 때 손으로 재시작하는 비상 운영 절차에서, 재시작 순서를 냉각기가 붙어 있는 차례가 아니라 데이터 홀 부하를 기준으로 정하도록 바꿨다. 냉각을 모두 되살리는 동안 모든 데이터 홀이 일부라도 냉각을 받아 열 폭주가 늦춰지게 하려는 것이다.
   • 냉각기 관리 시스템을 바꾸기 전까지의 임시 조치로 데이터센터 기술자 인원을 늘려 수동 재시작 절차를 바로 실행할 수 있게 했다.
   • 스토리지 팀은 대규모 복구 과정을 최적화한다. 장애 중에 빨리 판단할 수 있도록 판단에 쓰는 데이터를 늘리고, 더 빨리 실행할 수 있도록 문제 해결 가이드를 고친다. 완료 목표는 2023년 12월이다.
   • Azure Service Fabric 팀은 SQL Database 테넌트 링 복구의 신뢰성을 높인다. 완료 목표는 2023년 12월이다.
   • SQL Database 팀은 자동 장애 조치 그룹의 발동 기준을 검토해 장애 조치가 기대한 시간 안에 일어나게 한다. 완료 목표는 2023년 10월이다.
   • SQL Database 팀은 데이터베이스를 대량으로 옮길 수 있도록 내부 도구를 개선한다. 완료 목표는 2023년 12월이다.
   • Cosmos DB 팀은 단일 리전 쓰기 계정의 서비스 관리형 장애 조치를 최적화해 복구 시간을 줄인다. 완료 목표는 2023년 11월이다.
   • ARM 팀은 스토리지 계층을 차세대 영역 중복 구조로 옮기는 작업을 마친다. 완료 목표는 2023년 12월이다.
   • 장애 관리 팀은 장비 전원을 내려야 하는 상황에 맞춰 준비 태세, 절차, 플레이북을 강화하는 방법을 찾는다. 완료 목표는 2023년 10월이다.

   교훈

   AKS 컨트롤 플레인의 기반 인프라를 여러 가용 영역에 나눠 두어도, 생성, 조회, 수정, 삭제 작업이 거치는 작업 큐 데이터베이스가 영역 중복이 아니면 한 영역의 장애가 리전 전체의 AKS 작업을 멈춘다. 다른 리전이 같은 데이터베이스에 기대고 있으면 장애가 그 리전까지 번진다. 이미 돌고 있는 워크로드는 영향을 받지 않았을 것으로 Microsoft 는 보았지만, 스케일링처럼 리소스 공급자를 거쳐야 하는 일은 모두 막혔다. 영역 중복 스토리지, 그리고 영역 복원력이나 다중 리전 쓰기를 켠 Cosmos DB 계정은 이번 장애에서도 계속 동작했고, 영역 중복 SQL Database 도 프록시 모드로 연결한 일부 고객을 빼면 중단이 없었다.

   사례 보기

원인별2