사례2건

2건 중 1~2번째

1. IL-0226 호환되지 않는 설정 메타데이터가 전 세계로 퍼져 Azure Front Door 와 Azure CDN 엣지 서버가 크래시했다.

   Microsoft Azure2025

   증상

   2025-10-29 15:41 UTC 부터 Azure Front Door 와 Azure CDN 을 쓰는 고객과 Microsoft 서비스에서 연결 타임아웃 오류와 DNS 해석 문제가 났다. 15:48 UTC 에 모니터링 알림이 울려 조사가 시작됐다.

   간헐적 타임아웃DNS 조회 실패서비스 중단지연 시간 증가

   촉발

   두 컨트롤 플레인 빌드 버전에 걸쳐 이뤄진 특정 순서의 고객 설정 변경이 호환되지 않는 고객 설정 메타데이터를 만들었다. 15:35 UTC 에 들어간 이 메타데이터가 엣지 사이트 서버에 배포되면서 데이터 플레인의 잠재 버그가 드러났고, 데이터 플레인 서비스가 비동기 처리 중에 크래시했다.

   원인

   소프트웨어 결함

   구성 요소

   CDN 과 엣지 네트워크DNS 서버와 레코드

   기여 요인

   자동 테스트 공백늦게 드러난 변경롤백 무효과도한 영향 범위

   감지

   장애는 15:41 UTC 에 시작됐고 15:48 UTC 에 모니터링 알림이 울려 조사가 시작됐다. 그보다 앞선 15:43 UTC 에 설정 보호 시스템이 넓은 데이터 플레인 문제를 감지해 설정 배포를 자동으로 막았다.

   조치

   • 15:43 UTC 에 설정 보호 시스템이 넓은 데이터 플레인 문제에 반응해 새 설정 변경과 진행 중인 설정 변경의 전 세계 배포를 자동으로 막았다.
   • 최신 LKG 에 문제 메타데이터가 들어 있어 LKG 로도 그 이전 버전으로도 롤백하지 않았다. 대신 17:10 UTC 부터 최신 LKG 에서 문제 고객 설정을 손으로 지웠다.
   • 복구하는 동안 같은 문제가 다시 들어오지 않도록 17:30 UTC 에 모든 고객 설정 변경이 데이터 플레인으로 전파되지 않게 막았다.
   • 17:40 UTC 에 고친 LKG 설정을 전 세계 엣지 서버에 배포하기 시작했다. 엣지 사이트마다 모든 고객 설정을 다시 읽었고, 돌아오는 엣지 사이트가 과부하에 걸리지 않도록 트래픽을 천천히 재분배했다.
   • 17:26 UTC 에 Azure Portal 이 표준 복구 절차에 따라 Azure Front Door 를 거치지 않는 경로로 failover 했다.
   • 18:30 UTC 에 AFD DNS 서버가 회복하자 소수의 정상 엣지 사이트로 트래픽을 손으로 재분배했다. 20:20 UTC 에 충분한 엣지 사이트가 회복하자 자동 트래픽 관리로 바꿨다.
   • 완화 뒤 데이터 플레인을 지키려고 Azure Resource Manager 수준에서 모든 AFD 고객 설정 변경을 임시로 막았다. 2025년 11월 2일부터 고객 설정 큐를 비우기 시작했고, 안전장치를 모두 넣은 뒤 11월 5일에 이 제한을 풀었다.

   후속 조치

   • 원래의 컨트롤 플레인 비호환 문제와 데이터 플레인 버그를 둘 다 고쳤다. 완료됐다.
   • 운영 단계로 넘어가기 전에 고객 설정마다 동기 처리를 끝까지 마치도록 강제한다. 완료됐다.
   • 단계적 설정 롤아웃에 단계를 더 넣고 단계마다 배포 뒤 지켜보는 시간인 bake time 을 늘려 설정 문제를 잡게 했다. 완료됐다.
   • 데이터 플레인 서버의 설정 처리를 트래픽을 받는 인스턴스에서 떼어 별도 워커 프로세스 인스턴스로 옮겨, 설정 결함이 데이터 플레인 처리에 영향을 주지 않게 한다. 2026년 1월에 끝낼 예정이다.
   • 이 설정 파이프라인의 사전 검증이 갖춰지면 전파 시간을 45분에서 약 15분으로 줄인다. 2026년 1월에 끝낼 예정이다.
   • 이전 컨트롤 플레인 빌드 버전에서 만든 설정과의 하위 호환성을 보장하도록 시험과 검증 체계를 강화한다. 2026년 2월에 끝낼 예정이다.
   • Azure Portal, Azure Communication Services, Marketplace, Linux Software Repository for Microsoft Products, 지원 티켓 생성 같은 핵심 자체 인프라를 active-active 구성으로 바꿔, AFD 를 거치지 않는 경로로 옮겨 갈 수 있게 했다. 완료됐다.
   • AFD 데이터 플레인을 'micro cell' 로 나눠 고객 설정과 트래픽 격리를 강화하고, 한 고객의 트래픽이나 설정 문제가 다른 고객에게 영향을 주지 않게 한다. 2026년 6월에 끝낼 예정이다.
   • 로컬 고객 설정 캐시를 더 잘 써서 데이터 플레인 복구 시간을 줄여, 고객 설정을 한 시간 안에 복원하게 했다. 완료됐다.
   • 데이터 플레인 복구 시간을 더 줄여 고객 설정을 약 10분 안에 복원하게 한다. 2026년 3월에 끝낼 예정이다.
   • 리소스 한도를 올려 Azure Service Health 로 영향받은 고객에게 가는 알림이 늦게 전달되던 문제를 해결했다. 완료됐다.
   • Azure Service Health 의 자동 고객 알림 범위를 비슷한 종류의 서비스 저하까지 넓혀 영향받은 고객에게 더 빨리 알린다. 2025년 11월에 끝낼 예정이다.
   • Premier 와 Unified 고객이 지원 요청을 만들지 못하게 한 기술과 인력 문제를 해결하고, 백업 시스템으로 더 빨리 failover 할 수 있게 한다. 2025년 11월에 끝낼 예정이다.

   교훈

   Microsoft 는 라우팅, WAF, 오리진 변경을 전 세계에 빠르게 배포해야 하는 전 세계 CDN 에는 설정 전파 위험이 따른다고 봤다. 이번 사고와 10월 9일의 AFD 사고는 모두 이 위험에서 나왔다. 설정 보호 시스템은 데이터 플레인의 정상 신호를 보고 다음 단계로 넘긴다. 이번에는 크래시가 나중에 도는 비동기 처리에서 늦게 드러나, 문제 메타데이터가 보호 시스템을 통과했다. 앞선 사고에서 얻은 교훈과 개선 항목 일부가 이번 사고에도 들어맞았다. Microsoft 는 고객에게 리전 장애나 네트워크 장애 때도 가용성을 지키는 전 세계 HTTP 진입 계층을 만들라고 권했다. 관리 포털을 쓸 수 없을 때는 REST API 나 PowerShell 로 리소스를 관리하고, 알맞은 사람이 서비스 문제를 알 수 있도록 Azure Service Health 알림을 설정하라고도 권했다.

   사례 보기
2. IL-0222 유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.

   Google Cloud2019

   증상

   2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.

   패킷 손실네트워크 도달 불가지연 시간 증가오류율 상승모니터링 중단

   촉발

   US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅백본망

   기여 요인

   과도한 영향 범위순환 의존디버그 접근 제한롤백 무효

   감지

   Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다.

   조치

   • 혼잡을 줄이려고 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다.
   • US/Pacific 13:01 에 근본 원인을 찾고, 유지보수 이벤트를 일으킨 자동화 소프트웨어를 멈췄다.
   • 네트워크 제어 평면과 지원 인프라를 위치마다 다시 스케줄해 켰다.
   • 제어 평면 인스턴스가 모두 내려가면서 사라진 설정 데이터를 여러 위치에 다시 만들어 배포했다. 새 설정은 14:03 부터 나가기 시작했다.
   • Google 안의 여러 팀이 서비스별 완화 조치로 트래픽을 피해 리전 밖으로 돌려 다른 곳에서 계속 서비스했다.
   • us-west2, northamerica-northeast1, southamerica-east1 에서 장애 때문에 fail-safe 상태에 들어간 VPN 제어 평면을 손으로 빼냈다. 이 리전의 VPN 게이트웨이는 16:30 에 회복됐다.

   후속 조치

   • 유지보수 때 작업을 내리는 데이터 센터 자동화 소프트웨어를 즉시 멈췄고, 여러 물리 위치에서 동시에 작업을 내리지 않게 하는 안전장치를 갖춘 뒤에만 다시 켠다.
   • 클러스터 관리 소프트웨어가 요청의 출처와 상관없이 여러 물리 위치의 작업을 한꺼번에 내리는 요청을 거부하도록 강화한다.
   • 네트워크 제어 평면 소프트웨어와 지원 인프라가 이번 사고에 얽힌 유형의 유지보수 요청을 거부하도록 다시 설정한다.
   • 위치마다 네트워크 제어 평면이 설정을 영구 저장하게 바꿔, 모든 작업이 내려가도 설정을 다시 만들고 배포할 필요가 없게 한다. 이렇게 하면 복구 시간이 열 배쯤 줄어든다.
   • 제어 평면을 잃었을 때 네트워크가 fail static 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
   • 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
   • 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.

   사례 보기

원인별1