사례5건
5건 중 1~5번째
- 증상
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 를 쓰는 앱의 고객에게 일정과 안내를 꾸준히 알린다.
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 절차를 간소화한다.
- 복잡한 문제를 훨씬 일찍 잡도록 모니터링을 강화한다.
- 교훈
사후 분석은 세 가지 개선 영역을 짚었다. 운영 환경을 함부로 바꾸지 못하게 막는 불변성 통제가 부족해 자동 프로세스가 운영 환경에 계획에 없던 변경을 할 수 있었다. 상태 페이지가 사고의 영향을 받으면서 고객이 가장 필요로 할 때 제때 공지하지 못했다. 도구와 절차의 빈틈 때문에 엔지니어가 문제를 빨리 진단하고 해결하지 못해 복구가 필요 이상으로 오래 걸렸다.
- 증상
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 고객에게 내보낸다.
- 증상
Heroku 앱이 붙어 있는 Hobby 등급 Postgres 데이터베이스 약 1%에 연결하지 못했다. 상태 페이지는 2021년 2월 25일 03:39 UTC 에 Hobby 등급 데이터베이스의 연결 문제를 조사한다고 알렸다.
- 촉발
상위 시스템의 업그레이드 과정에서 공유 데이터베이스 시스템 여러 대의 호스트 이름이 잘못 바뀌었다.
- 원인
- 구성 요소
- 기여 요인
- –
- 조치
- 문제를 알아챈 직후 업그레이드 과정을 멈춰 영향이 넓어지지 않게 했다.
- 관련 시스템을 모두 새 호스트 정보로 갱신하고, 영향받은 앱에 새 릴리스를 냈다.
- 고객에게 `heroku pg:credentials:rotate` 로 데이터베이스 자격 증명을 바꾸는 우회 방법을 안내했다. 자격 증명이 여럿이면 `--all` 플래그를 붙이게 했고, 이렇게 하면 영향받은 데이터베이스가 다시 연결됐다.
- 후속 조치
- 비슷한 장애를 잡을 수 있게 모니터링을 개선한다.
- 비슷한 장애가 다시 나면 복구 시간을 줄일 수 있도록 도구와 문서를 만들었다.
- 증상
2017-06-03 부터 06-07 사이 여러 차례, EU 와 US 의 고객 모두가 때때로 높은 지연을 겪었다. 일부 요청은 실패했고, 일부는 Heroku Routing Layer 를 지나는 데 지나치게 오래 걸렸다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 트래픽이 많은 출처를 찾아 그 애플리케이션 소유자와 함께 요청을 더 고르게 나눴다.
- 옛 DNS 레코드를 새로 고친 DNS 레코드로 바꿔 들어오는 트래픽이 고르게 나뉘게 했다.
- 후속 조치
- 트래픽이 고르지 않게 나뉘면 엔지니어에게 더 빨리 알림이 가도록 모니터링을 고친다.
- 트래픽이 많거나 갑자기 몰릴 때의 영향을 줄이도록 DNS 와 로드 밸런서를 구성하는 방법을 내부 조사로 찾는다.
- 조사 중에 찾은 DNS 구성 문제가 캐싱 Add-on 공급자에 영향을 주므로, 그 공급자들과 함께 부하가 고르게 나뉘도록 작업한다.
이 5건에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.