사례2건
2건 중 1~2번째
- 증상
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 를 쓰는 앱의 고객에게 일정과 안내를 꾸준히 알린다.
- 증상
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 고객에게 내보낸다.
이 2건에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.