사례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-0563 Linode 의 모든 리전에서 서버에 연결할 수 없게 됐고 Amsterdam 데이터센터는 거의 전부 멈췄다

   Linode2025

   증상

   2025년 3월 17일 16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 한꺼번에 울렸다. 같은 때 고객들도 여러 제품에서 문제를 신고하기 시작했다.

   네트워크 도달 불가서비스 중단

   촉발

   Akamai Compute 의 내부 백엔드 API 구성 요소를 릴리스하는 중이었다. 롤아웃이 이어지는 동안 이 API 의 응답이 서로 일치하지 않았다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   부분 배포

   감지

   16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 대거 울렸다. 같은 때 고객들도 여러 제품의 문제를 신고하기 시작했다.

   조치

   • 18:30 UTC 쯤부터 모든 데이터센터의 라우트 서버를 영향이 가장 큰 리전부터 단계적으로 재시작했고, 21:34 UTC 쯤 마쳤다.

   후속 조치

   • 라우트 서버가 받는 경로 데이터가 끊김 없이 이어지게 할 더 나은 방법을 마련할 때까지 백엔드 API 릴리스를 멈춘다.

   사례 보기
3. IL-0530 us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다

   Google Cloud2023

   증상

   us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.

   패킷 손실네트워크 도달 불가OOMKilled오래된 엔드포인트 라우팅클러스터·노드 생성 정체

   촉발

   관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   과도한 영향 범위한계 경보 부재

   감지

   엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.

   조치

   • 컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다.
   • 08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다.
   • 업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다.

   후속 조치

   • 메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다.
   • 엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다.
   • API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다.
   • 관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다.
   • 리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
   • 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.

   사례 보기

원인별1