사례2건

2건 중 1~2번째

1. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다

   Nebius2025

   증상

   2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.

   네트워크 도달 불가

   촉발

   eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.

   원인

   소프트웨어 결함

   구성 요소

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

   기여 요인

   롤백 무효자동 테스트 공백모니터링 사각지대

   조치

   • 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
   • 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.

   후속 조치

   • 버그 자체를 바로잡는다.
   • 경로 수가 어긋나면 울리는 알림을 더한다.
   • 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
   • 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
   • VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
   • Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
   • e2e 테스트를 더 자주 돌린다.
   • 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.

   교훈

   문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.

   사례 보기
2. IL-0339 Azure 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 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.

   원인

   설정 변경

   구성 요소

   CDN 과 엣지 네트워크DDoS 방어 서비스네트워크 컨트롤 플레인데이터센터 전력·냉각

   기여 요인

   장애 중첩과도한 영향 범위모니터링 사각지대

   감지

   장애가 시작되고 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월에 끝낼 예정이다.

   사례 보기

원인별2