사례4건

4건 중 1~4번째

1. IL-0235 Azure OpenAI Service 의 GPT-5.2 모델 요청이 일곱 개 리전에서 HTTP 400 과 HTTP 429 오류로 실패했다

   Microsoft Azure2026

   증상

   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 였다.

   오류율 상승부하 불균형

   촉발

   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월에 마칠 예정이다.

   사례 보기
2. IL-0367 Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다

   Microsoft Azure2024

   증상

   Central US 리전에서 VM 가용성이 떨어졌고, 그 VM 에 기대는 여러 Azure 서비스에서 연결 실패와 서비스 관리 작업 실패가 났다. 서비스 모니터링은 7월 18일 22:06 UTC 에 VM 가용성 하락을 잡았고, 22:14 UTC 에 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

   스토리지 연결 끊김서비스 중단오류율 상승장애 조치 실패오래된 엔드포인트 라우팅

   촉발

   일상적인 VM 호스트 변경에 맞춰 스토리지 허용 목록을 새로 만들 때, 목록을 만드는 서버가 네트워크 설정이 바뀐 인프라 파일 서버 일부에 접근하지 못했다. 그래서 VM 호스트 주소 범위 일부가 빠진 목록이 Central US 의 모든 스토리지 스케일 유닛에 배포됐다.

   원인

   설정 변경

   구성 요소

   클라우드 블록 스토리지데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위모니터링 사각지대

   감지

   허용 목록이 Central US 에 배포되는 동안 서비스 모니터링이 VM 가용성 하락을 잡았고, 엔지니어링 팀이 투입됐다. VM 가용성 하락을 잡은 시각은 22:06 UTC 로, 고객 영향이 시작되고 26분 뒤였다. SQL 모니터링은 SQL 을 쓸 수 없게 된 지 1분 안에 비정상 노드와 로그인 실패를 잡았고, 22:14 UTC 에는 모니터링이 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

   조치

   • 원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈췄다.
   • 23:27 UTC 에 Central US 리전의 모든 배포를 멈췄다.
   • 23:35 UTC 에 모든 리전의 컴퓨트 증설 배포를 멈췄다.
   • Central US 리전의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다.
   • 장애 1시간 안에 자동 장애 조치 정책이 있는 SQL 데이터베이스의 장애 조치를 시작했다. geo-secondary 를 새 프라이머리로 올리고 장애 조치 그룹 엔드포인트가 새 프라이머리를 가리키게 했다.
   • SQL 게이트웨이 노드를 재시작해 캐시를 새로 고치고, 연결이 올바른 노드로 가게 했다.
   • 끝나지 않은 SQL 장애 조치를 강제로 완료했다.
   • 영향이 시작된 직후, Central US 에 쓰기 리전이 있는 다중 리전 액티브-패시브 계정을 위해 Cosmos DB 컨트롤 플레인의 장애 조치를 시작했다. 이어 고객 계정을 다른 리전으로 장애 조치했다.
   • 일부 계정에서는 고객이 Azure 포털에서 시작한 "graceful switch region" 작업이 Microsoft 가 시작한 서비스 관리 장애 조치를 막고 있었다. 이런 계정에서는 그 작업을 취소했다.
   • 일부 계정은 오래 도는 컨트롤 작업이 서비스 메타데이터에 잠금을 잡고 있어 장애 조치가 끝나지 않았다. 이런 계정은 그 잠금을 지워 장애 조치를 강제로 완료했다.
   • 장애 조치와 함께, 비정상으로 표시된 Cosmos DB 파티션을 고치는 작업을 따로 진행했다. 이 작업으로 Central US 단일 리전 계정의 가용성을 09:41 UTC 까지 99.9% 넘게 되살렸고, 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했다.
   • 08:51 UTC 부터는 백엔드 노드 수리가 진행되는 대로, Microsoft 가 장애 조치했던 Cosmos DB 계정을 Central US 로 되돌렸다. Central US 를 먼저 읽기 리전으로 추가했고, 쓰기 리전을 다시 Central US 로 옮길지는 고객이 정하게 했다.

   후속 조치

   • 허용 목록을 만드는 워크플로가 원본 정보가 빠진 것을 알아채면 멈추게 고친다.
   • 스토리지 요청이 허용 목록 검사에서 거부되면 알림을 보낸다.
   • 허용 목록 배포를 가용 영역과 스토리지 종류에 따라 차례로 진행하고, 배포 기간을 24시간으로 늘린다.
   • 허용 목록 배포 워크플로에 VM 상태 확인을 더하고, 이상이 보이면 배포를 자동으로 멈춘다.
   • Microsoft 가 SQL 장애 조치 그룹의 장애 조치를 시작하는 정책을 다시 검토하고, 고객이 장애 조치를 직접 관리하라는 권고를 다시 알린다.
   • Cosmos DB 페일백 워크플로를 고친다. 이 워크플로 때문에 MongoDB API 계정 일부에서 특정 버전의 MongoDB 드라이버가 모든 리전에 연결하지 못했다.
   • 프라이빗 엔드포인트가 있는 Cosmos DB 계정이 페일백 뒤 Central US 에 연결하지 못하던 문제를 고쳐, Microsoft 가 페일백을 다시 하지 않아도 되게 한다.
   • 스토리지 데이터 플레인 방화벽이 잘못된 허용 목록 배포를 알아채고 마지막으로 정상이던 상태를 계속 쓰게 한다.
   • Azure NetApp Files 의 여러 모니터 로직을 고쳐 영향을 주는 이벤트를 제때 잡고 알맞게 분류하게 한다.
   • Azure NetApp Files 의 여러 서비스 지표를 더 모니터링해 비슷한 문제를 잡고 관련 이벤트를 더 빨리 서로 연결해 보게 한다.
   • SQL 이 쓰는 Service Fabric 클러스터 위치 변경 알림 메커니즘이 부하가 클 때도 믿을 만하게 동작하게 한다.
   • SQL 지역 장애 조치 워크플로를 견고하게 만들어 장애 조치가 끝까지 완료되게 한다.
   • Cosmos DB 장애 조치의 5%를 늦춘 문제를 없앤다.
   • Azure DevOps 의 모든 고객 메타데이터를 알맞은 지리 영역으로 옮겨, 한 장애가 여러 지리 영역에 걸쳐 영향을 주지 않게 한다.
   • Azure NetApp Files 의 리전 사이 읽기와 쓰기를 분리해, 이런 종류의 문제가 한 리전 안에서 끝나게 한다.
   • Azure NetApp Files 가 저장소에 둔 사용률 데이터에 덜 기대도록 캐시를 쓰는 방안을 검토한다.
   • Cosmos DB 다중 리전 액티브-패시브 계정에 파티션 단위 자동 장애 조치를 넣어, 영향받은 파티션을 자동으로 처리하게 한다.
   • SQL 과 Cosmos DB 를 위해 Azure Virtual Machines 가 Resilient Ephemeral OS disk 개선을 진행해, 스토리지 장애에도 VM 이 더 잘 버티게 한다.

   사례 보기
3. IL-0407 정리 자동화가 Azure OpenAI 의 GPU VM 과 모델 엔드포인트를 지워 28개 지역 중 14곳에서 5xx 오류가 났다

   Microsoft Azure2024

   증상

   2024년 7월 13일 00:00 UTC 부터 Azure OpenAI 엔드포인트를 호출하는 일부 고객이 5xx 오류를 비롯한 문제를 겪었다. 00:05 UTC 에 서비스 모니터링이 실패율이 정해 둔 기준을 넘었다고 엔지니어에게 알렸다.

   오류율 상승리소스 삭제

   촉발

   Microsoft 는 쓰지 않는 리소스를 정리하는 작업의 하나로, 쓰지 않는다고 본 리소스 그룹 14개를 전역 설정 파일에서 뺐다. 이 변경은 커밋 직후 적용됐고, 그 리소스 그룹 안의 리소스가 짧은 시간에 모두 지워졌다.

   원인

   설정 변경

   구성 요소

   모델 추론 서버자동 용량 관리 시스템

   기여 요인

   단계적 배포 부재파괴적 변경 보호 장치 부재미검증 가정

   감지

   서비스 내부 모니터링이 2024년 7월 13일 00:05 UTC 에 실패율이 정해 둔 기준을 넘었다고 엔지니어에게 알렸다. 영향이 시작되고 5분 뒤였다.

   조치

   • 자동 정리 작업이 리소스를 지우는 것을 확인하고, 정리를 실행하던 자동화부터 멈췄다.
   • ARM 과 자동화 양쪽에서 리소스 잠금을 걸고 삭제 요청을 막아 더 지워지지 않게 했다.
   • 지워진 리소스를 다시 만들기 시작했고, 14개 지역의 모델 풀을 병렬로 다시 세웠다.
   • GPT-4o 가 쓰는 REDIS 와 Private Link 를 Azure REDIS 팀, Azure Networking 팀과 함께 손으로 다시 설정했다.
   • DALL-E 프론트엔드와 백엔드 사이의 Managed Identity 를 허용 목록에 추가해 DALL-E 를 복구했다.
   • 모든 것이 복구되고 안정된 7월 15일에 자동화를 다시 켰고, 이와 함께 fine-tuning 배포 기능이 돌아왔다.

   후속 조치

   • 안전 배포 절차에 따라 이후의 모든 설정 업데이트가 지역 단위로 나가도록 설정 정책을 바꿨다. 문제가 있는 변경이 한 지역에 머물게 하려는 것이다.
   • 자동화가 관리하면 안 되는 리소스에 붙은 잘못된 메타데이터 태그를 지우고, 자동화 설정에서 그 리소스를 빼서 중요한 리소스를 실수로 지우지 않게 했다.
   • 워크로드마다 걸치는 지역 수를 줄여, 비슷한 실수로 리소스가 지워져도 피해가 넓게 퍼지지 않게 했다.
   • 장애 대응 인력을 더 빨리 불러 모으도록 장애 대응 호출 자동화를 고쳤다.
   • 운영 환경의 모든 변경이 단계마다 확인을 거쳐 나가는 안전 배포 절차를 따르도록 변경 관리 통제를 더 넣는 방안을 검토한다. 완료 예정은 2024년 8월이다.
   • 영향받은 고객의 범위를 정하기 어려운 상황에서도 더 빨리 알릴 수 있도록 공지 도구에 Azure OpenAI 관련 데이터를 넣는다. 완료 예정은 2024년 9월이다.
   • 앞으로의 설정 업데이트 위험을 줄이려고 테스트 범위와 검증 절차를 더 늘리는 방안을 검토한다. 완료 예정은 2024년 9월이다.
   • 고객 트래픽에 기대지 않고 시스템 상태를 확인할 수 있도록 모델 계열마다 능동 모니터링을 더 만든다. 완료 예정은 2024년 9월이다.
   • 복구 시간을 줄이려고 모델 풀을 세우는 작업의 병렬도를 높인다. 완료 예정은 2024년 12월이다.

   교훈

   Microsoft 는 이 장애의 가장 큰 빈틈이 변경 관리 절차에 있었다고 밝혔다. 설정 변경이 전역 범위의 콘텐츠 업데이트로 나가서, 변경이 지역 하나씩 차례로 적용되게 통제하는 안전 배포 절차를 거치지 않았다. 그래서 한 번에 여러 지역이 무너졌다. 자동화가 관리하는 리소스와 모르는 리소스가 같은 리소스 그룹에 섞이면서 설정 파일과 실제 구독의 상태가 어긋났고, 이 어긋남 때문에 필요한 리소스까지 지워졌다. 고객에게는 주 지역이 내려갈 때를 대비해 여러 지역에 엔드포인트를 두라고 권했다.

   사례 보기
4. IL-0533 Azure China 의 핵심 시스템 도메인 chinacloudapp.cn 과 chinacloudsites.cn 의 이름 해석이 실패해 여러 서비스에 연결할 수 없었다

   Microsoft Azure2024

   증상

   Azure China 리전에서 고객이 여러 Azure 서비스에 연결하지 못했다. Azure Portal 인 portal.azure.cn 과 API 로도 리소스를 보거나 관리하기 어려웠다. chinacloudapp.cn 과 chinacloudsites.cn 도메인 안의 FQDN 을 해석하지 못한 것이 원인이었다.

   DNS 조회 실패오류율 상승모니터링 중단

   촉발

   도메인 등록 기관을 거친 설정 변경으로 2024-04-23 03:45 CST 에 chinacloudapp.cn 과 chinacloudsites.cn 의 네임서버가 비활성 서버 묶음으로 바뀌었다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정캐시로 가려진 장애

   감지

   04:37 CST 에 내부 모니터가 Azure China Cloud 의 서비스 저하를 알리고 인시던트를 만들었다. 04:39 CST 에 엔지니어링 팀이 인시던트를 확인했다.

   조치

   • 04:59 CST 에 두 도메인의 네임서버를 이전의 정상 네임서버로 되돌렸고, 05:13 CST 에 되돌리기를 마쳤다.

   후속 조치

   • Azure China 의 관리 도구의 수정이 끝날 때까지 이 도메인 수명 주기 절차의 실행을 모두 멈췄다.
   • 도메인 수명 주기 관리의 검증 절차를 고쳐 모든 클라우드 리전의 신호가 들어가게 한다. 2024년 6월에 마칠 예정이다.
   • 인터넷에서 영역을 직접 조회해 네임서버 정보를 얻는 검증을 더한다. 2024년 7월에 마칠 예정이다.

   사례 보기

원인별1