사례3건

3건 중 1~3번째

1. IL-0354 Fly.io 일부 머신의 사설 네트워크 6PN 이 끊겼고 다음 날 잠깐 다시 끊겼다

   Fly.io2026

   증상

   9월 23일 일부 머신의 사설 네트워크인 6PN 이 끊겼다. 다음 날에도 같은 문제가 잠깐 다시 일어났다.

   네트워크 도달 불가요청 오라우팅

   촉발

   에지가 static 이 아닌 피어의 게이트웨이 역할도 하도록 바꾸면서, 모든 에지에 게이트웨이처럼 netid 마다 /80 접두사 전체를 그 호스트로 보내는 라우팅 규칙이 들어갔다.

   원인

   배포 결함

   구성 요소

   호스트 라우팅 규칙네트워크 컨트롤 플레인

   기여 요인

   미검증 가정자동 테스트 공백

   조치

   • 영향을 받은 모든 호스트의 라우팅 테이블에서 잘못된 /80 경로를 지웠다.
   • 6PN 경로를 관리하는 데몬 s6pnforwarderd 의 변경을 롤백했다.
   • interactive 피어를 /128 로만 넣도록 고쳐 배포했다. 이 수정은 근본 원인을 고치지 못해 다음 날 잠깐 같은 문제가 다시 났다.
   • 호스트가 워커로 알려져 있는지와 상관없이 그 호스트의 ID 를 가진 머신이 있는지부터 찾도록 고쳐 근본 원인을 일단 막았다.

   후속 조치

   • 6PN 문제를 시험하고 알림을 내는 데 쓰는 머신에 당분간 로컬이 아닌 6PN 주소를 배정한다.
   • 중장기적으로 6PN 주소의 host ID 가 경로 결정에 아무 역할도 하지 않게 한다. 머신은 지금도 대체로 그렇지만 게이트웨이 피어는 아직 그렇지 않다.
   • 기존 게이트웨이 피어를 살리려고 둔 지금의 임시 방식을 끝내고, 새 피어와 머신 전체를 더 나은 모델로 옮긴다.

   교훈

   Fly.io 는 워커의 host ID 가 워커가 아닌 호스트에 다시 쓰일 수 있다는 점이 문서로 잘 남아 있지 않아 처음에 모두가 떠올린 것은 아니었다고 봤다. 게이트웨이를 오래 손대지 않았기 때문에 에지를 게이트웨이로 쓰기 전까지 문제가 드러나지 않았다. 더 깊은 문제는 6PN 라우팅의 알림과 자동 테스트였다. 기존 점검은 모두 원래 호스트에 있는 머신을 써서 host ID 재사용으로 생기는 충돌이나 고정 6PN 주소 구현과 얽힌 문제를 잡을 수 없었다. Fly.io 는 알림이나 큰 장애로 이어지지 않은 문제가 더 있었을 수 있다고 했다. 6PN 주소의 host ID 가 경로 결정에 아무 역할도 하지 않아야 이런 장애가 되풀이되지 않는다고 결론지었다.

   사례 보기
2. 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 수가 민감하게 반응한 지표였다.

   사례 보기
3. IL-0396 새로 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, 네트워크 로드 밸런서가 2시간 8분 동안 공인 IP 주소로 연결되지 않았다

   Google Cloud2017

   증상

   2017년 1월 30일 새로 만든 GCE 인스턴스에 네트워크 연결이 되지 않았다. 라이브 마이그레이션 중인 인스턴스, 새로 만든 Cloud VPN 터널과 GCE 네트워크 로드 밸런서도 공인 IP 주소로 닿을 수 없었다. 이미 만들어져 있고 라이브 마이그레이션을 겪지 않은 인스턴스, 로드 밸런서, VPN 터널은 영향이 없었다.

   네트워크 도달 불가프로브 실패

   촉발

   드물게 쓰는 로드 밸런싱 구성에 대량의 변경이 들어갔다. 이 변경이 비효율적인 코드 경로를 타면서 canary 배포가 타임아웃됐다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서네트워크 컨트롤 플레인

   기여 요인

   과도한 영향 범위자동 테스트 공백

   조치

   • 네트워크 로드 밸런서에 변경을 반영하는 작업을 재시작했다. 재시작 뒤 문제의 변경이 한 묶음으로 처리되면서 비효율적인 코드 경로를 타지 않았고, 변경이 다시 처리됐다.
   • 이 조치를 11:36 부터 12:42 까지 존마다 차례로 적용했다.

   후속 조치

   • canary 타임아웃을 늘려, 비효율적인 코드 경로를 타는 변경이 네트워크 변경을 완전히 멈추지 않고 늦추기만 하게 한다.
   • 비효율적인 코드 경로를 개선한다.
   • 더 넓은 범위의 구성에서 동작을 확인하는 테스트를 새로 쓴다.
   • 주소 구성을 전 세계로 퍼뜨리는 방식을 분산 라우팅으로 바꾸는 작업을 앞당겨, 이 계층의 문제가 전 세계에 영향을 주지 않게 한다.
   • 이런 문제를 더 빨리 알아보고 더 빨리 해결할 수 있도록 지표와 알림을 더 만든다.

   사례 보기

원인별2