사례2건

2건 중 1~2번째

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-0353 미국 서부 에지의 fly-proxy 가 과부하에 빠져 요청이 수백 밀리초에서 몇 초씩 밀렸다

   Fly.io2026

   증상

   미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 반복해서 흔들렸다. 로그와 지표에서는 fly-proxy 가 처리 중인 요청에 필요한 항목만 읽어 오는 lazy loader 의 지연이 500 ms 에서 몇 초까지 높게 나왔다. 새 요청도 그만큼 더 기다린 뒤에야 처리됐다.

   지연 시간 증가

   원인

   용량 한계

   구성 요소

   CDN 과 엣지 네트워크서비스 디스커버리

   기여 요인

   용량 계획 부재한계 미인지장애 중첩

   감지

   Fly.io 는 미국 서부 리전에서, 처음에는 주로 SJC 에서 에지가 흔들리는 것을 알아챘다. 로그와 지표에서 lazy loader 지연이 500 ms 에서 몇 초까지 높게 나왔다.

   조치

   • Corrosion 에 상태가 아주 큰 앱을 원인으로 보고 임시 완화책을 넣은 뒤 SJC 에 프록시를 배포했다. 잠시 나아졌지만 새 프로세스가 워밍업을 마치자 지연이 다시 치솟았다.
   • 서버 몇 대가 빠져 용량이 모자란 SJC 에서 Anycast 트래픽을 LAX 로 옮겼다. 처음에는 나아졌지만 얼마 뒤 LAX 도 버거워했다.
   • Airtime 의 대역폭 한도를 낮췄다. softirq CPU 사용률과 호스트 load average 는 내려갔지만 lazy loader 질의는 계속 느렸다.
   • 프록시를 재시작하면서 종료를 기다리던 프록시 프로세스를 모두 강제로 죽여 lazy loader 문제를 풀었다. 이것으로 첫 고비가 끝났다.

   후속 조치

   • 앞으로 몇 주에서 몇 달 사이에 에지 용량을 크게 늘린다.
   • 프록시 인스턴스가 여럿 함께 떠 있게 만든 버그를 고쳤다.
   • Airtime 이 돌고 있는 프록시가 기대한 활성 인스턴스가 아닐 때는 당분간 훨씬 엄격한 한도를 쓰도록 바꿨다.
   • lazy loader 의 로드 셰딩 동작을 고쳐 요청 처리 지연의 최대값에 합리적인 상한이 생기게 했다.
   • 프록시 메모리 안 서비스 카탈로그를 샤드로 나누고 더 잘게 나눈 락으로 바꾼다. 이 전환이 장애를 더 내지 않도록 Antithesis 같은 테스트를 함께 쓴다.
   • Airtime 이 프록시만이 아니라 시스템 전체 부하에 맞춰 반응하도록 다시 만든다. 프록시 프로세스가 여럿 떠 있거나 같은 호스트의 다른 프로세스가 대역폭 여유를 쓸 때도 안전장치가 되게 한다.
   • 프록시가 기대한 구성으로 돌지 않을 때를 더 잘 감시하는 방법을 찾는다.

   사례 보기

원인별2