사례6건
6건 중 1~5번째
- 증상
2025-10-29 15:41 UTC 부터 Azure Front Door 와 Azure CDN 을 쓰는 고객과 Microsoft 서비스에서 연결 타임아웃 오류와 DNS 해석 문제가 났다. 15:48 UTC 에 모니터링 알림이 울려 조사가 시작됐다.
- 촉발
두 컨트롤 플레인 빌드 버전에 걸쳐 이뤄진 특정 순서의 고객 설정 변경이 호환되지 않는 고객 설정 메타데이터를 만들었다. 15:35 UTC 에 들어간 이 메타데이터가 엣지 사이트 서버에 배포되면서 데이터 플레인의 잠재 버그가 드러났고, 데이터 플레인 서비스가 비동기 처리 중에 크래시했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애는 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 알림을 설정하라고도 권했다.
- 증상
2025년 8월 21일 16:27 UTC 부터 AWS us-east-1 에 오리진을 둔 고객과, us-east-1 의 서버를 거쳐 Cloudflare 와 트래픽을 주고받는 사용자에게 높은 지연, 패킷 손실, 오리진 연결 실패가 났다. 16:44 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다.
- 촉발
16:27 UTC 쯤 한 고객이 AWS us-east-1 에서 Cloudflare 캐시에 있는 객체를 대량으로 요청하기 시작했다. 그 응답 트래픽이 Cloudflare 에서 AWS 로 가는 전체 트래픽을 두 배로 늘렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 17분 뒤인 16:44 UTC 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다. 17:45 에는 애시번 IAD 의 고객 영향을 이유로 장애가 선언됐다.
- 조치
- 19:05 UTC 에 트래픽 급증을 일으킨 고객 하나에 속도 제한을 걸어 혼잡을 줄였다.
- 네트워크 팀이 트래픽 엔지니어링 조치를 더 해 19:27 에 혼잡을 완전히 풀었다.
- 19:45 부터 Cloudflare 의 요청에 따라 AWS 가 BGP 광고 철회를 되돌렸고, 20:07 에 IAD PNI 로 Cloudflare 에 보내는 BGP 프리픽스 광고를 정상으로 돌려놓았다.
- 후속 조치
- 한 고객의 트래픽이 다른 고객에게 영향을 줄 만큼 네트워크를 혼잡하게 만들기 시작하면 그 트래픽의 우선순위를 골라서 낮추는 장치를 만든다.
- Data Center Interconnect 증설을 앞당겨 네트워크 용량을 지금보다 크게 늘린다.
- AWS 와 함께 양쪽의 BGP 트래픽 엔지니어링 조치가 앞으로 서로 부딪치지 않게 한다.
- 고객마다 네트워크 자원을 나눠 예산을 정하고, 예산을 넘긴 고객의 트래픽이 다른 고객의 서비스를 떨어뜨리지 못하게 하는 새 트래픽 관리 시스템을 만든다. 이 시스템은 이번에 손으로 한 혼잡 대응 조치 상당수도 자동화한다.
- 교훈
Cloudflare 는 이 사고로 한 고객의 사용 방식이 나머지 생태계를 해치지 못하게 막는 안전장치가 더 필요하다는 것이 드러났다고 했다. 어느 한 고객이 공유 자원을 독차지해 다른 고객의 안정성을 해치지 못하도록 고객 격리를 더 잘 설계해야 하고, 수요를 감당할 만큼 네트워크 인프라 용량을 늘려야 한다는 것을 핵심 교훈으로 꼽았다. 결론에서는 드물게 트래픽이 몰린 상황에서 네트워크 혼잡 관리가 모자라 장애가 났다고 했다.
- 증상
2024년 10월 4일, 16일, 21일에 Sentry 의 이벤트 수집에서 오류가 늘었다. 수집 리전 하나에 밀린 트래픽이 쌓였고, 그 리전에서 빠져나간 트래픽을 받은 다른 리전에도 트래픽이 밀려 쌓이면서 트래픽이 거부됐다.
- 촉발
세 사고는 계기가 각각 달랐지만, 세 번 모두 수집 리전 하나에서 밀린 트래픽이 늘어나면서 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 후속 조치
- 연쇄 장애의 가능성을 줄이려고 엣지 리전을 더 작게 더 많이 만들었다. 남아메리카에 첫 리전을 열고, 북아메리카와 유럽에는 하나씩이던 리전을 둘로 늘려 모두 세 리전을 더했다.
- 오토스케일링 규칙이 원래의 CPU 부하 지표보다 더 강한 신호를 잡도록 바꿨다.
- iowait 때문에 요청이 밀릴 때 축소가 일어나지 않도록 축소 속도를 낮췄다.
- 오토스케일링 규칙과 민감도를 더 다듬을 수 있도록 엣지가 내는 지표를 개선한다.
IL-0339Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다Microsoft Azure2024- 증상
2024년 7월 30일 11시 45분 UTC 부터 Azure Front Door 와 Azure CDN 을 거치는 Microsoft 서비스에 접속하던 일부 고객이 간헐적인 연결 오류, 타임아웃, 지연 급증을 겪었다. 11시 47분에 Azure Portal 팀이 먼저 서비스 성능 저하를 알아챘다.
- 촉발
Azure 네트워크 DDoS 보호 서비스가 TCP SYN flood DDoS 공격을 자동으로 막은 뒤 트래픽을 Azure Front Door 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 2분 뒤인 11시 47분 UTC 에 Azure Portal 팀이 서비스 성능 저하를 알아채고 조사를 시작했다. 12시 10분에 네트워크 모니터링이 이 포털 장애를 유럽의 한 사이트에서 난 네트워크 문제와 연결 지었다.
- 조치
- 12시 55분 UTC 에 국지적인 혼잡을 확인하고, 트래픽 경로 변경을 포함한 혼잡 완화용 표준 플레이북을 실행했다. 13시 58분에 영향 대부분이 사라졌다.
- 16시 58분, 네트워크 컨트롤 플레인이 명령을 다시 내리게 했지만 문제의 장비에는 명령이 닿지 않았다.
- 17시 50분부터 문제의 장비를 네트워크에서 안전하게 빼면서 다른 문제가 없는지 네트워크를 훑었다. 장비는 19시 32분에 다 뺐다.
- 후속 조치
- 한 지역의 DDoS 완화 문제가 다른 지역으로 번지지 않도록, 네트워크 장비에 빠져 있던 설정을 넣었다. 이 일은 끝났다.
- 잘못된 설정을 찾아내도록 Azure 네트워크의 기존 검증과 모니터링을 강화한다. 2024년 11월에 끝낼 예정이다.
- DDoS 보호 서비스가 컨트롤 플레인에서 닿지 않는데도 트래픽을 계속 받는 상황을 잡아내도록 모니터링을 개선한다. 2024년 11월에 끝낼 예정이다.
IL-0491CDN 원본 서버군의 정상 노드가 안전 수준 아래로 줄어 Squarespace 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다Squarespace2019- 증상
2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. static.squarespace.com과 static1.squarespace.com 도메인이 영향을 받아 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다.
- 촉발
2019-02-11 오후 10시 30분 ET에 한 엔지니어가 Squarespace CDN 원본 서버군 전체에 유지보수 작업을 시작했다. 엔지니어는 작업을 멈췄다고 생각했지만 작업은 백그라운드에서 계속 돌았고, 2019-02-12 오전 12시 10분에 CDN 원본 서비스 장애를 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. 알림은 서버군이 핵심 가용성 기준 아래로 떨어진 뒤에야 왔고, 고객 영향이 크다는 것은 나중에야 분명해졌다.
- 조치
- 오전 2시 15분 ET까지 추가 복구 조치로 CDN 원본 서버군 일부를 되살렸고, 2시 20분에 서비스가 정상으로 돌아왔다.
- 후속 조치
- 장애 대응 플레이북을 고쳐 이 서버군에 영향을 주는 문제 대부분을 빨리 해결할 점검과 조치를 넣는다. 첫 점검에서 고객 영향을 판단하고 인시던트 커맨더를 바로 부르게 한다.
- CDN 협력사와 원본 서비스의 문제가 고객에게 주는 영향을 더 빨리 판단할 수 있도록 외부 모니터링을 개선한다.
- 엔지니어가 유지보수 명령을 내리는 방식의 운영 정책을 고치고 안전장치를 더한다. 그런 명령이 작업할 수 있는 서버군의 범위를 제한한다.
- 사람이 직접 하는 유지보수 작업이 필요한 경우를 줄인다.
- 독립된 장애 도메인을 만들고, 상태가 나쁜 부분을 피해 요청을 자동으로 보내도록 해 인프라의 복원력을 높인다.
이 6건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.