Incident Library

IL-0225 Microsoft Azure · 2023-01-25azurenetworking

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

2023-01-25 07:08 UTC 에 한 네트워크 엔지니어가 마드리드에서 Microsoft 의 전 세계 WAN 에 용량을 더하는 작업을 했다. 이 작업에는 새 라우터마다 IP 주소를 바꾸고 IGP 와 BGP 라우팅 도메인에 넣는 단계가 들어 있었다. 이런 작업의 표준 운영 절차는 Open Network Emulator 환경에서의 시험, 랩 시험, 두 시험과 롤아웃·롤백 계획을 문서로 남기는 Safe-Fly Review, 한 번에 장비 하나만 접근하게 하는 Safe-Deployment 의 네 단계다. 이번에는 앞선 실행에서 생긴 문제를 고치려고 작업 전에 절차를 바꿨다. 하지만 바꾼 절차를 다시 시험하지 않았고 사후 점검도 넣지 않았다. 바뀐 절차에는 IGP 데이터베이스를 비우는 명령이 들어 있었다. 두 제조사의 라우터는 이 명령을 로컬 라우터에서만 실행하지만, 세 번째 제조사의 라우터는 IGP 로 이어진 모든 라우터에 토폴로지 데이터베이스를 다시 계산하라고 지시한다. 라우터마다 모든 명령을 승인하는 실시간 AAA 시스템과, 전역 영향을 주는 명령의 차단 목록이 있었다. 하지만 이 라우터 모델에서 이 명령이 기본으로 전역에 영향을 준다는 사실은 고위험 명령을 평가할 때 드러나지 않았고, 그래서 이 명령은 차단 목록에 없었다.

엔지니어는 라우터 한 대에만 접근했지만 그 라우터가 IGP 로 WAN 전체와 이어져 있었다. 그래서 전 세계 라우터가 내부 네트워크 전체의 IP 연결을 다시 계산했고, 이어 BGP 라우터가 인터넷에서 받은 prefix 를 다시 광고하고 검증했다. 모든 prefix 의 연결이 돌아오기까지 약 1시간 40분이 걸렸다. 모니터링은 5분 안에 당직 엔지니어에게 알렸다. 하지만 변경하던 엔지니어는 바뀐 절차 때문에 이를 전달받지 못했고, 33분 뒤 두 번째 마드리드 라우터에 같은 작업을 해 두 번째 장애를 일으켰다.

팀은 08:20 UTC 에 문제의 명령을 찾았다. 09:05 UTC 에 거의 모든 네트워크 장비와 대부분의 리전, 서비스가 회복했고, 09:25 UTC 에 마지막 장비가 회복했다. 사고 동안 비정상 장비를 찾아 빼는 시스템과 트래픽 엔지니어링 시스템 같은 WAN 상태 관리 자동화가 멈춰 있어, 일부 경로가 최적화되지 않은 채 패킷 손실이 이어졌다. 이 시스템들을 손으로 다시 시작해 12:43 UTC 에 복구를 마쳤다.

심각도
–
영향 범위
Network connectivity to Azure regions and to other Microsoft services including Microsoft 365 and Power Platform, internet, inter-region and ExpressRoute or VPN/vWAN traffic, and Azure Government services that depend on the public cloud
영향 사용자
–
지역
global
감지까지
3m
복구까지
5h 35m

증상

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

라우팅 불안정은 인터넷을 오가는 트래픽, 리전 사이 트래픽, ExpressRoute 나 VPN/vWAN 을 거친 온프레미스 연결, Azure 공용 클라우드에 기대는 US Gov Cloud 서비스에 모두 나타났다. 라우팅이 자동으로 수렴하는 동안 고객이 겪는 영향은 계속 바뀌었다. 어떤 고객은 연결이 끊겼다 이어지기를 반복했고, 어떤 고객은 연결 타임아웃을 겪었고, 다른 고객은 지연이 길어지거나 연결이 완전히 끊겼다.

장애는 두 차례에 걸쳐 일어났다. 변경하던 엔지니어는 알림을 전달받지 못했고, 첫 변경 33분 뒤 마드리드의 두 번째 라우터에 같은 작업을 다시 했다. 네트워크 규모 때문에 모든 prefix 의 연결이 돌아오기까지 약 1시간 40분이 걸렸다.

대부분의 리전과 서비스는 09:05 UTC 까지 회복했고 마지막 네트워크 장비는 09:25 UTC 에 회복했다. 그 뒤에도 네트워크 일부 구간에서 평소보다 높은 패킷 손실이 이어졌고, 자동으로 회복하지 못한 라우터 두 대 때문에 일부 고객은 간헐적인 연결 문제를 계속 겪었다. 인도 리전과 북미 일부를 지나는 트래픽이 가장 늦게 회복했다.

팀은 최근 변경을 모두 살피는 것으로 조사를 시작했고, 자동 회복이 진행되던 08:20 UTC 에 장애를 일으킨 명령을 찾았다.

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

원인

원인 설정 변경

구성 요소 백본망내부 라우팅BGP 라우팅
기여 요인 설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화
촉발
07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

감지

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

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 백본망, 내부 라우팅, BGP 라우팅. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.