사례3건
3건 중 1~3번째
- 증상
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 가 경로 결정에 아무 역할도 하지 않아야 이런 장애가 되풀이되지 않는다고 결론지었다.
- 증상
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 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
- 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.
- 후속 조치
- 버그 자체를 바로잡는다.
- 경로 수가 어긋나면 울리는 알림을 더한다.
- 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
- 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
- VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
- Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
- e2e 테스트를 더 자주 돌린다.
- 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.
- 교훈
문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.
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 타임아웃을 늘려, 비효율적인 코드 경로를 타는 변경이 네트워크 변경을 완전히 멈추지 않고 늦추기만 하게 한다.
- 비효율적인 코드 경로를 개선한다.
- 더 넓은 범위의 구성에서 동작을 확인하는 테스트를 새로 쓴다.
- 주소 구성을 전 세계로 퍼뜨리는 방식을 분산 라우팅으로 바꾸는 작업을 앞당겨, 이 계층의 문제가 전 세계에 영향을 주지 않게 한다.
- 이런 문제를 더 빨리 알아보고 더 빨리 해결할 수 있도록 지표와 알림을 더 만든다.
이 3건에서 가장 많이 나오는 구성 요소: 네트워크 컨트롤 플레인, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.