사례5건

5건 중 1~5번째

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-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 절차를 간소화한다.
   • 복잡한 문제를 훨씬 일찍 잡도록 모니터링을 강화한다.

   교훈

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

   사례 보기
3. IL-0373 EU 리전의 Heroku Postgres Essential 등급 데이터베이스가 메모리가 바닥나 두 번에 걸쳐 연결을 받지 못했다

   Heroku2024

   증상

   EU/Dublin 리전에 있는 Heroku Postgres Essential 등급 고객 일부가 데이터베이스에 연결하지 못했다. 상태 페이지는 영향받은 고객이 데이터베이스에 접근하면 out of memory 오류를 받는다고 알렸다.

   메모리 압박서비스 중단

   촉발

   제3자 업체가 메모리 누수가 있는 모니터링 변경을 배포했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스텔레메트리 에이전트

   기여 요인

   모니터링 사각지대

   감지

   첫 장애는 고객 지원 티켓으로 알았다. Heroku Support 가 7월 28일 07:50 UTC 에 고객 티켓을 받고 기술 팀을 호출했는데, 장애가 시작되고 9시간 19분 뒤였다. 둘째 장애도 Heroku Support 의 에스컬레이션과 고객 지원 티켓으로 알았다.

   조치

   • 첫 장애 때 자원을 더 배정하고 Heroku Postgres 클러스터를 재시작해 7월 28일 14:16 UTC 에 문제를 일시적으로 풀었다.
   • 둘째 장애 때 문제가 없는 제3자 서비스의 이전 버전을 프로비저닝하는 우회책을 적용했다. Postgres 데이터베이스 클러스터를 이전 안정 버전으로 바꾸자 메모리가 회수되어 클러스터가 건강한 상태로 돌아왔다.
   • 제3자 업체가 임시 완화책을 적용했다.

   후속 조치

   • 제3자 모니터링의 지표 수집을 강화했다.
   • 제3자 업체가 메모리 누수를 고친 모니터링 소프트웨어 새 버전을 내면, 기술 팀이 그 버전을 평가하고 괜찮으면 Heroku 고객에게 내보낸다.

   사례 보기
4. IL-0372 Hobby 등급 Heroku Postgres 데이터베이스 약 1%의 연결 문자열이 바뀌어 앱이 17시간 동안 연결하지 못했다

   Heroku2021

   증상

   Heroku 앱이 붙어 있는 Hobby 등급 Postgres 데이터베이스 약 1%에 연결하지 못했다. 상태 페이지는 2021년 2월 25일 03:39 UTC 에 Hobby 등급 데이터베이스의 연결 문제를 조사한다고 알렸다.

   오래된 엔드포인트 라우팅오류율 상승

   촉발

   상위 시스템의 업그레이드 과정에서 공유 데이터베이스 시스템 여러 대의 호스트 이름이 잘못 바뀌었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스서비스 디스커버리

   기여 요인

   –

   조치

   • 문제를 알아챈 직후 업그레이드 과정을 멈춰 영향이 넓어지지 않게 했다.
   • 관련 시스템을 모두 새 호스트 정보로 갱신하고, 영향받은 앱에 새 릴리스를 냈다.
   • 고객에게 `heroku pg:credentials:rotate` 로 데이터베이스 자격 증명을 바꾸는 우회 방법을 안내했다. 자격 증명이 여럿이면 `--all` 플래그를 붙이게 했고, 이렇게 하면 영향받은 데이터베이스가 다시 연결됐다.

   후속 조치

   • 비슷한 장애를 잡을 수 있게 모니터링을 개선한다.
   • 비슷한 장애가 다시 나면 복구 시간을 줄일 수 있도록 도구와 문서를 만들었다.

   사례 보기
5. 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