Incident Library

IL-0227 Heroku · 2025-06-10networking

의도하지 않은 자동 OS 업데이트가 호스트 네트워킹을 다시 시작해 Heroku dyno 의 외부 연결이 끊기고 많은 고객이 최대 24시간 서비스 중단을 겪었다.

2025-06-10 06:00 UTC 부터 Heroku 고객이 서비스 중단을 겪었고, 많은 고객에게 중단은 최대 24시간 이어졌다. 보안 사고가 아니었고 고객 데이터도 잃지 않았다. 세 가지 문제가 겹쳤다. 꺼져 있어야 할 자동 운영체제 업데이트가 운영 인프라에서 돌아 호스트의 네트워킹 서비스를 다시 시작했다. 네트워킹 서비스는 올바른 라우팅 규칙을 첫 부팅 때만 적용하는 오래된 스크립트에 기대고 있었다. 그래서 재시작 뒤 경로가 다시 적용되지 않았고, 그 호스트에 있는 모든 dyno 의 외부 연결이 끊겼다. Heroku 의 내부 도구와 Heroku Status Page 가 같은 인프라에서 돌아, 애플리케이션이 망가지는 동안 대응과 고객 소통도 함께 막혔다.

06:00 부터 간헐적 로그인 문제와 dyno 네트워킹 오류가 나타났고, 08:26 에 Private Spaces 의 dyno 대부분이 외부 HTTP 요청을 보내지 못한다는 것이 확인됐다. 팀은 정상 호스트와 비정상 호스트를 비교해 11:54 에 빠진 네트워크 경로를 찾았고, 13:11 에 예상하지 못한 네트워크 서비스 재시작을 알았으며, 13:42 에 시스템 패키지 자동 업그레이드를 촉발 원인으로 짚었다.

원인 조사와 함께 12:56 부터 내부 인스턴스를 돌아가며 다시 시작했고, 13:58 에 X 의 @herokustatus 계정으로 공지를 올리기 시작했다. 업스트림 벤더를 통해 자동 업데이트에 쓰는 토큰을 무효화해 19:18 에 더는 다른 호스트가 영향받지 않게 했다. Heroku Dashboard 는 20:59 에 완전히 복구됐고, 22:01 에 남은 서비스를 안정시키려고 전체 dyno recycle 을 시작했다. 그 뒤 Private Spaces 복구와 밀린 작업 처리가 길게 이어졌고, 6월 11일 05:50 에 사고가 해결로 선언됐다.

심각도
–
영향 범위
Heroku applications: most dynos in Private Spaces without outbound connectivity, intermittent logins, application failures, the Heroku Dashboard and the Heroku Status Page
영향 사용자
many customers, with up to 24 hours of downtime
지역
–
감지까지
–
복구까지
23h 50m

증상

2025-06-10 06:00 UTC 부터 Heroku 서비스의 성능이 크게 떨어졌다. 고객은 로그인이 됐다 안 됐다 한다고 알렸고, 모니터링은 dyno 네트워킹에서 넓은 범위의 오류를 잡았다.

Heroku 의 내부 도구와 Heroku Status Page 도 같은 인프라에서 돌아 함께 영향을 받았다. 고객은 정확한 상태 정보를 볼 수 없었고, Heroku 팀이 고객에게 상황을 알리는 일도 크게 늦어졌다. 팀은 13:58 에야 X 의 @herokustatus 계정으로 공지를 올리는 우회 방법을 찾았다.

08:26 에 Private Spaces 의 dyno 대부분이 외부로 HTTP 요청을 보내지 못한다는 것이 핵심 문제로 확인됐다. 이 문제 때문에 로그인이 간헐적으로 실패했고, 애플리케이션이 실패했으며, Heroku 팀의 공지가 늦어졌다.

팀은 영향이 dyno 네트워킹에 한정된 것을 보고 영향받은 호스트를 분석했다. 업스트림 제공자 문제가 아니라 Heroku 인프라 안의 문제라고 판단했다. 이어 정상 호스트와 비정상 호스트를 비교해 11:54 에 네트워크 경로가 빠져 있는 것을 찾았다. 13:11 에 네트워크 서비스가 예상하지 못하게 다시 시작된 것을 알았고, 13:42 에 시스템 패키지의 자동 업그레이드를 촉발 원인으로 짚었다. 많은 고객이 최대 24시간 동안 서비스 중단을 겪었다.

서비스가 돌아온 뒤에도 밀린 일이 오래 남았다. 사고 초기에 보낸 상태 이메일이 뒤늦게 전달됐고, Heroku Connect 동기화가 따라잡아야 했으며, Heroku release phase 는 밀린 작업을 처리하는 데 몇 시간이 걸렸다. 사고는 6월 11일 05:50 에 해결로 선언됐다.

증상 네트워크 도달 불가서비스 중단오류율 상승

원인

원인 업그레이드로 깨진 호환성

구성 요소 호스트 라우팅 규칙
기여 요인 버전 미고정순환 의존디버그 접근 제한
촉발
꺼져 있어야 할 자동 운영체제 업데이트가 운영 인프라에서 돌아 호스트의 네트워킹 서비스를 다시 시작했다. 올바른 라우팅 규칙은 첫 부팅 때만 도는 오래된 스크립트가 넣은 것이었다. 그래서 서비스가 다시 시작된 뒤 경로가 다시 적용되지 않았고, 그 호스트에 있는 모든 dyno 의 외부 네트워크 연결이 끊겼다.

감지

06:00 UTC 부터 서비스 성능이 크게 떨어지자 고객이 간헐적인 로그인 문제를 알렸고, 모니터링이 dyno 네트워킹에서 넓은 범위의 오류를 잡았다. Heroku 의 자체 도구와 Heroku Status Page 도 함께 영향을 받았다.

조치

후속 조치

교훈

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

출처

관련 사례

–

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 호스트 라우팅 규칙. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.