Incident Library
적용된 필터 원인배포 결함기여 요인과도한 영향 범위조직Microsoft Azure모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례1건

1건 중 1~1번째

  1. 증상

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

    촉발

    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 작업에는 여러 지역에 걸친 복원 전략을 고려하고, 클라이언트 재시도에 알맞은 백오프와 지터를 쓰며, 의존 서비스에 문제가 생겨도 애플리케이션이 기능을 줄여 버티도록 하라고 권했다.

내 클러스터에도 있는지 확인하기

이 사례에서 가장 많이 나오는 구성 요소: 모델 요청 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1