사례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-0227 의도하지 않은 자동 OS 업데이트가 호스트 네트워킹을 다시 시작해 Heroku dyno 의 외부 연결이 끊기고 많은 고객이 최대 24시간 서비스 중단을 겪었다.

   Heroku2025

   증상

   2025-06-10 06:00 UTC 부터 Heroku 서비스의 성능이 크게 떨어졌다. 고객은 로그인이 됐다 안 됐다 한다고 알렸고, 모니터링은 dyno 네트워킹에서 넓은 범위의 오류를 잡았다.

   네트워크 도달 불가서비스 중단오류율 상승

   촉발

   꺼져 있어야 할 자동 운영체제 업데이트가 운영 인프라에서 돌아 호스트의 네트워킹 서비스를 다시 시작했다. 올바른 라우팅 규칙은 첫 부팅 때만 도는 오래된 스크립트가 넣은 것이었다. 그래서 서비스가 다시 시작된 뒤 경로가 다시 적용되지 않았고, 그 호스트에 있는 모든 dyno 의 외부 네트워크 연결이 끊겼다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   호스트 라우팅 규칙

   기여 요인

   버전 미고정순환 의존디버그 접근 제한

   감지

   06:00 UTC 부터 서비스 성능이 크게 떨어지자 고객이 간헐적인 로그인 문제를 알렸고, 모니터링이 dyno 네트워킹에서 넓은 범위의 오류를 잡았다. Heroku 의 자체 도구와 Heroku Status Page 도 함께 영향을 받았다.

   조치

   • UTC 12:56 부터 내부 인스턴스를 돌아가며 다시 시작해 증상을 어느 정도 덜었다.
   • 업스트림 벤더에 요청해 자동 업데이트에 쓰는 토큰을 무효화했다. 17:30 에 확인됐고 19:18 에 끝나, 더는 다른 호스트가 영향받지 않았다.
   • 사고 중인 6월 10일에 자동 업그레이드 서비스를 껐다.
   • Heroku Dashboard 가 20:59 에 완전히 복구된 뒤, 22:01 에 남은 서비스를 안정시키려고 전체 dyno recycle 을 시작했다.

   후속 조치

   • 다음 주 초에 영구적인 통제 장치를 넣어, 앞으로는 통제된 배포 절차 밖에서 시스템 변경이 일어나지 않게 한다.
   • 모든 베이스 이미지에 비슷한 위험이 있는지 감사한다.
   • 네트워크 서비스가 다시 시작돼도 문제없도록 네트워크 라우팅을 개선한다.
   • 최악의 상황에서도 제때 공지할 수 있도록 운영 인프라와 완전히 독립된 백업 소통 채널을 만든다.
   • 엔지니어가 문제를 더 빨리 진단하고 전체 호스트에 대규모로 질의할 수 있도록 새 도구를 만들고 기존 도구를 개선한다.
   • 비상시 팀이 핵심 시스템에 빨리 접근할 수 있도록 break-glass 절차를 간소화한다.
   • 복잡한 문제를 훨씬 일찍 잡도록 모니터링을 강화한다.

   교훈

   사후 분석은 세 가지 개선 영역을 짚었다. 운영 환경을 함부로 바꾸지 못하게 막는 불변성 통제가 부족해 자동 프로세스가 운영 환경에 계획에 없던 변경을 할 수 있었다. 상태 페이지가 사고의 영향을 받으면서 고객이 가장 필요로 할 때 제때 공지하지 못했다. 도구와 절차의 빈틈 때문에 엔지니어가 문제를 빨리 진단하고 해결하지 못해 복구가 필요 이상으로 오래 걸렸다.

   사례 보기

원인별2