Incident Library
적용된 필터 기여 요인자동화 증폭조직Microsoft Azure모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례2건

2건 중 1~2번째

  1. 증상

    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. 증상

    2022년 8월 30일 06:00 UTC 무렵부터 Ubuntu Unattended-Upgrades 를 켜 둔 Ubuntu 18.04 VM 에서 DNS 이름 해석 오류가 나기 시작했다. AKS 에서는 kubelet 이 컨테이너 레지스트리의 DNS 이름을 해석하지 못해 ImagePullBackoff 같은 파드 생성 오류가 났다.

    촉발

    2022년 8월 30일 06:00 UTC 에 Canonical 이 Ubuntu 보안 업데이트를 공개했고, Unattended-Upgrades 를 켠 Ubuntu 18.04 VM 들이 systemd 237-3ubuntu10.54 를 자동으로 내려받아 설치했다.

    원인
    구성 요소
    기여 요인
    감지

    패키지가 공개된 직후 AKS 와 Azure Container Apps 팀을 포함한 여러 Azure 팀이 운영 알림으로 문제를 알았다. 이어 들어온 고객 지원 문의로 영향이 Ubuntu 18.04 에 한정된다는 것을 확인했다.

    조치
    • Canonical 과 Ubuntu 웹사이트에 이 버그와 수정 방법이 올라왔고, 영향받은 고객에게 읽어 보도록 권했다.
    • 영향받은 VM 은 재부팅하거나, 재부팅할 수 없으면 Azure 가 제공한 템플릿 스크립트를 시험하고 필요한 만큼 고쳐서 돌리도록 권했다.
    • AKS 팀이 AKS 노드의 문제를 자동으로 탐지하고 고치는 장치를 만들어 모든 리전에 배포했다.
    • 나머지 AKS 고객은 지원팀을 거쳐 손으로 완화했다.
    후속 조치
    • 보안 업데이트가 안전 배포 절차를 거치지 않는 지금 방식을 검토해, 이런 장애에서 고객 영향을 줄인다.
    • AKS 데이터 플레인 모니터링을 개선해 오류가 늘면 알림이 오게 했다.
    • AKS 모니터링 알고리즘을 검토해 이번과 비슷한 VM 오류를 탐지하고 알리게 했다.
    • 장애 중 Canonical 로 가는 에스컬레이션 경로를 개선하고 내부 기술 서비스 가이드에 넣었다.
    • AKS 가 지금 Canonical 과 나눠 맡는 보안 패치 체계를 완전히 넘겨받아, 패치를 직접 추가로 시험하고 통제해서 배포한다. 2022년 12월 완료 예정이다.
    • IaaS VM 용으로는 Canonical 과 협의해, Azure 사용자에게 공개되기 전의 후보 패키지에 전용 시험을 돌린다.
    • AKS 가 Canonical 과 절차를 세워 업그레이드 상황의 시험 공백을 메운다. 2023년 3월 완료 예정이다.
    • 안전하다고 판단해 내보내는 패치는 AKS 고객이 유지보수 시간대를 직접 정하고 환경별로 나눠 적용할 수 있게 한다. 2023년 12월 완료 예정이다.
    교훈

    보안 업데이트는 중요도 때문에 안전 배포 절차를 거치지 않았고, 하루 한 번 자동으로 적용되는 업데이트가 모든 리전의 VM 에 퍼졌다. AKS 고객은 자동 노드 이미지 업그레이드를 쓰면 노드를 최신으로 유지하면서 Microsoft 의 공급망만 쓰게 된다. IaaS VM 은 자동 VM 게스트 패치를 쓰면 Ubuntu 패치를 받는 VM 의 범위가 제한되고 업데이트가 조율된 순서로 적용된다. 자동 VM 게스트 패치는 상태 감시도 하며, 사용자는 앱 상태 확장으로 애플리케이션 상태 신호를 줄 수 있다.

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

이 2건에서 가장 많이 나오는 구성 요소: 인메모리 캐시, 애플리케이션 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별2