사례2건

2건 중 1~2번째

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-0530 us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다

   Google Cloud2023

   증상

   us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.

   패킷 손실네트워크 도달 불가OOMKilled오래된 엔드포인트 라우팅클러스터·노드 생성 정체

   촉발

   관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.

   원인

   배포 결함

   구성 요소

   네트워크 컨트롤 플레인클라우드 로드 밸런서

   기여 요인

   과도한 영향 범위한계 경보 부재

   감지

   엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.

   조치

   • 컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다.
   • 08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다.
   • 업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다.

   후속 조치

   • 메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다.
   • 엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다.
   • API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다.
   • 관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다.
   • 리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
   • 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.

   사례 보기

원인별1