사례3건

3건 중 1~3번째

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-0543 Twingate 의 인증과 관리 서비스 전반이 29분 동안 오류를 내며 멈췄다

   Twingate2025

   증상

   2025년 5월 28일 20:45 UTC 부터 Twingate 의 여러 핵심 서비스에서 API 요청이 넓게 실패하고 오류율이 올라갔다. 장애는 3분 뒤인 20:48 UTC 에 감지됐다.

   요청 오라우팅부하 불균형오류율 상승

   촉발

   글로벌 로드 밸런서의 라우팅 규칙을 바꾸는 롤아웃에서 새 라우팅 규칙이 의도치 않게 높은 우선순위를 받았다.

   원인

   설정 변경

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   스테이징 불일치순환 의존

   감지

   장애가 시작되고 3분 뒤인 20:48 UTC 에 감지됐고, 엔지니어들이 원인 파악과 초기 대응을 시작했다.

   조치

   • 20:52 UTC 에 라우팅 변경의 롤백을 시작했지만, 복구에 쓰는 인프라가 영향을 받은 구성 요소에 기대고 있어서 21:05 UTC 에 자동 롤백 과정이 지연됐다.
   • 21:09 UTC 에 엔지니어들이 로컬 도구로 직접 고쳤고, 21:14 UTC 에 서비스가 모두 복구됐다.

   후속 조치

   • 라우팅 규칙을 바로잡았다.
   • 하위 환경에서 백엔드 트래픽 이상을 감지하는 알림을 더했다.
   • 리소스 스케일링 임계값을 조정했다.
   • 복구 수단을 더 빨리 쓸 수 있도록 인프라 도구가 서비스에 기대지 않게 떼어 낸다.
   • 백엔드 샤딩을 도입해 고객 워크로드를 서로 격리하고 장애의 영향을 줄인다.

   사례 보기
3. IL-0351 EU 와 US 에서 Heroku 라우팅 계층을 지나는 요청이 느려지거나 실패했다

   Heroku2017

   증상

   2017-06-03 부터 06-07 사이 여러 차례, EU 와 US 의 고객 모두가 때때로 높은 지연을 겪었다. 일부 요청은 실패했고, 일부는 Heroku Routing Layer 를 지나는 데 지나치게 오래 걸렸다.

   지연 시간 증가오류율 상승부하 불균형

   원인

   DNS·네트워크 장애

   구성 요소

   DNS 서버와 레코드클라우드 로드 밸런서

   기여 요인

   미검증 가정

   조치

   • 트래픽이 많은 출처를 찾아 그 애플리케이션 소유자와 함께 요청을 더 고르게 나눴다.
   • 옛 DNS 레코드를 새로 고친 DNS 레코드로 바꿔 들어오는 트래픽이 고르게 나뉘게 했다.

   후속 조치

   • 트래픽이 고르지 않게 나뉘면 엔지니어에게 더 빨리 알림이 가도록 모니터링을 고친다.
   • 트래픽이 많거나 갑자기 몰릴 때의 영향을 줄이도록 DNS 와 로드 밸런서를 구성하는 방법을 내부 조사로 찾는다.
   • 조사 중에 찾은 DNS 구성 문제가 캐싱 Add-on 공급자에 영향을 주므로, 그 공급자들과 함께 부하가 고르게 나뉘도록 작업한다.

   사례 보기

원인별3