사례2건

2건 중 1~2번째

1. IL-0352 Router 2.0 을 쓰는 앱에서 HTTP 요청이 web dyno 에 고르지 않게 나뉘어 지연과 타임아웃이 늘었다

   Heroku2025

   증상

   Heroku Common Runtime 에서 Router 2.0 을 쓰는 일부 앱의 HTTP 요청이 web dyno 사이에 고르게 나뉘지 않았다. 요청이 몰린 dyno 가 과부하에 빠지면서 HTTP 요청 지연과 타임아웃이 늘었다.

   부하 불균형지연 시간 증가간헐적 타임아웃

   촉발

   2025-07-18 22:00 UTC 무렵부터 Router 2.0 인스턴스가 어떤 코드 조건에 닿기 시작했다. 이 조건에 닿으면 부하 분산용 엔트로피 메타데이터와 그 로직이 dyno 선택의 폭을 줄였다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   모니터링 사각지대스테이징 불일치

   감지

   07-20 16:46 UTC 에 Heroku Support 가 요청이 dyno 에 고르지 않게 가서 지연과 타임아웃이 늘었다는 첫 고객 신고를 받았다. 스테이징 부하 테스트에도 같은 불균형이 있었지만, 알림은 라우팅 가용성과 HTTP 요청 지연만 보고 요청 분배는 보지 않아 울리지 않았다.

   조치

   • 지원 팀이 영향을 받은 고객에게 Router 2.0 을 끄고 legacy router 로 돌아가라고 안내했다.
   • 운영 라우터 인스턴스를 차례로 새로 띄워 영향을 받은 앱의 부하 분산을 나아지게 했다.
   • 부하 분산을 고친 라우터 코드를 스테이징에 먼저 배포한 뒤 운영에 단계적으로 배포해 07-23 00:12 UTC 에 마지막 파티션까지 마쳤다.

   후속 조치

   • 부하 분산 동작이 다시 망가지지 않도록 막는 게이트와 알림을 넣었다.
   • 자동 이전을 다시 시작하기 전에, 아직 legacy router 를 쓰는 앱의 고객에게 일정과 안내를 꾸준히 알린다.

   사례 보기
2. IL-0493 Google Cloud TCP 로드 밸런서의 백엔드 노드가 상태 검사에 모두 실패해 Netlify 전체 트래픽의 약 5%가 처리되지 않았다

   Netlify2021

   증상

   2021-03-25 14:39 UTC에 모니터가 로드 밸런서 상태 검사 실패를 알렸다. 고정 IP로 A 레코드를 거는 고객이 쓰는 Google Cloud TCP 로드 밸런서에서 전체 트래픽의 약 5%가 처리되지 않았고, 18:46 UTC까지 이어졌다.

   프로브 실패오류율 상승

   촉발

   OS의 자동 업데이트가 백엔드 노드의 systemd-networkd 유닛을 재시작해 로컬 라우팅 테이블에 넣어 둔 로드 밸런서 IP 항목을 지웠다. google-guest-agent는 systemd-networkd 재시작을 감시하지 않아 그 IP를 다시 넣지 않았다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서systemd-networkd

   기여 요인

   모니터링 사각지대장애 중첩

   감지

   14:39 UTC에 모니터가 로드 밸런서 상태 검사 실패를 알렸다. 백엔드에 직접 붙는 노드 단위 상태 검사는 장애 내내 정상이라고 했고, 로드 밸런서의 백엔드 상태 검사는 알림에 들어 있지 않아 노드가 하나씩 빠지던 몇 시간 동안 알림이 없었다.

   조치

   • 15:30 UTC까지 엔터프라이즈 네트워크 트래픽을 받을 IP 대역을 따로 마련하고, 영향을 받은 고객에게 연락하기 시작했다.
   • 15:55 UTC에 Global Accelerator를 앞에 둔 AWS 네트워크 로드 밸런서를 프로비저닝하기 시작했고, 16:46 UTC에 이 엔드포인트의 새 IP를 상태 페이지와 지원 페이지에 올렸다.
   • 18:46 UTC에 영향을 받은 모든 노드에서 GCP 네트워킹 데몬을 재시작해 Google 로드 밸런서로 가는 트래픽을 되살렸다.

   후속 조치

   • 모든 GCP CDN 노드의 guest-agent systemd 설정을 손으로 고쳐 systemd-networkd 재시작을 감지하게 했다.
   • 이 버그를 Google에 알리고 google-guest agent 저장소에 이슈를 열었다. 글을 쓸 때 공식 수정 PR이 열려 있었다.
   • 로드 밸런서의 백엔드 상태 검사를 알림에 넣어 로드 밸런서 모니터링을 넓힌다.
   • 업데이트 시험을 개선하고 며칠 동안 문제를 지켜볼 수 있도록 백엔드에 카나리 노드를 더한다.
   • 트래픽 등급을 나누고 여러 리전으로 옮겨, 등급마다 따로 규모를 늘리고 리전 장애에 더 잘 견디게 했다.
   • 고객이 apex 도메인을 Netlify 사이트로 보내는 방법을 넓힌다. 많은 DNS 사업자가 apex 도메인에 지원하는 ALIAS와 ANAME 레코드로 가용성을 높이는 방법을 찾는다.
   • 엔터프라이즈 트래픽 라우팅을 전용 IP로 나눠, 엔터프라이즈 고객과 나머지 고객의 용량과 설정 변경을 따로 다룬다.

   교훈

   Netlify는 자사 같은 서비스를 쓸 때 IP 기반 A 레코드에 기대지 말라고 권하지만, 많은 DNS 사업자에서는 A 레코드가 유일한 방법이다. 노드 단위 상태 검사는 백엔드의 자체 IP로 붙었기 때문에 로드 밸런서 IP가 빠진 것을 잡지 못했고, 로드 밸런서의 백엔드 상태 검사를 알림으로 받았다면 장애 전에 진단할 시간을 더 벌었을 것이다.

   사례 보기

원인별1