사례4건

4건 중 1~4번째

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

   Microsoft Azure2026

   증상

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

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

   촉발

   Microsoft 365 가 쓰는 상위 API 계층의 변경으로, 용량 부족 실패가 재시도할 수 있는 일시적 서버 실패로 상위 계층에 전달되기 시작했다. 이 변경은 Australia East 에 먼저 배포되고 뒤에 Sweden Central 로 넓어졌다.

   원인

   배포 결함

   구성 요소

   모델 요청 라우팅

   기여 요인

   재시도 폭주과도한 영향 범위미검증 가정

   감지

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

   조치

   • 16:30 UTC 에 불어난 재시도 트래픽의 출처를 찾아, 문제를 일으킨 내부 작업을 전용 인프라로 떼어 냈다.
   • 상위 서비스가 장애를 일으킨 변경을 롤백하기 시작했고, 재시도로 불어난 트래픽을 줄이는 조치를 더 했다.
   • 격리와 롤백이 끝나고 밀린 요청이 모두 처리된 뒤, 17:05 UTC 에 고객 영향이 끝났다고 확인했다.

   후속 조치

   • Microsoft 자체의 큰 생성형 AI 작업을 전용 라우팅 인프라로 옮겨, 여러 테넌트의 트래픽과 같은 추론 부하 분산 인프라를 함께 쓰지 않게 한다. 완료 예정은 2026년 6월이다.
   • 빠르게 번지는 장애에서 엔지니어가 부차적인 크래시 증상과 과부하의 실제 출처를 더 빨리 구별하도록 진단 안내, 런북, 알림을 고친다. 완료 예정은 2026년 6월이다.
   • 상위 서비스 팀과 함께 재시도 정책 설계, 의존 관계 계약, 텔레메트리를 고쳐 재시도 증폭을 더 일찍 잡고 공유 인프라로 번지지 않게 한다. 완료 예정은 2026년 7월이다.
   • 과부하 방지와 작업 단위 스로틀링을 강화해, 어떤 내부 작업 하나의 과도한 재시도 트래픽도 공유 구성 요소를 무너뜨리지 못하게 한다. 완료 예정은 2026년 7월이다.
   • 추론 라우팅 계층의 단일 장애점을 찾아 없애고 복원력을 높이는 일을 계속한다.

   교훈

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

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

   사례 보기
3. 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월에 마칠 예정이다.

   사례 보기
4. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.

   Microsoft Azure2023

   증상

   2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

   지연 시간 증가간헐적 타임아웃간헐적 연결 실패패킷 손실네트워크 도달 불가

   촉발

   07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

   원인

   설정 변경

   구성 요소

   백본망내부 라우팅BGP 라우팅

   기여 요인

   설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화

   감지

   모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

   조치

   • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.

   후속 조치

   • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
   • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
   • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
   • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.

   사례 보기

원인별2