Incident Library

IL-0351 Heroku · 2017-06-03networking

EU 와 US 에서 Heroku 라우팅 계층을 지나는 요청이 느려지거나 실패했다

your-app.herokuapp.com 꼴의 DNS 레코드는 DNS 라운드 로빈으로 트래픽을 Heroku 서버 전체에 나누도록 설계돼 있었다. 조회할 때마다 서버 가운데 무작위로 고른 일부의 주소가 응답에 담겨 트래픽이 고르게 퍼지는 구조였다. 그런데 Heroku 의 DNS 공급자는 이 사용 방식에서 여러 주소가 아니라 주소 하나만 응답했고, Heroku 는 이 구성 오류를 모르고 있었다. 캐싱 DNS 리졸버 한 대를 함께 쓰는 많은 HTTP 클라이언트 같은 트래픽 패턴에서는 요청이 라우팅 계층의 서버 한 대로 몰려 그 서버가 감당하지 못했다. 그 결과 2017-06-03 부터 06-07 사이 EU 와 US 에서 요청이 느려지거나 실패했다.

DNS 공급자는 이 동작을 옛 방식으로 보고, 새 DNS 레코드에는 여러 주소를 응답하도록 시스템을 바꿨다. Heroku 는 지연이 늘 때마다 트래픽이 많은 출처를 찾아 그 애플리케이션 소유자와 함께 요청을 더 고르게 나눴고, 옛 DNS 레코드를 새로 고친 레코드로 바꿔 들어오는 트래픽이 고르게 나뉘게 했다. 조사 중에는 캐싱 Add-on 공급자에 영향을 주는 DNS 구성 문제도 더 찾았다.

심각도
–
영향 범위
Requests through the Heroku Routing Layer were slow or failed during periods between 3 and 7 June 2017
영향 사용자
All customers in the EU and US, at various times
지역
EU and US
감지까지
–
복구까지
–

증상

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

트래픽이 라우팅 계층의 개별 서버로 고르지 않게 몰려 그 서버들이 감당하지 못했다. 캐싱 DNS 리졸버 한 대를 함께 쓰는 많은 HTTP 클라이언트처럼 특정한 트래픽 패턴에서는 많은 요청이 서버 한 대로만 갔다.

2017-06-07 20:50 UTC 부터는 US Common Runtime 에서 non-SSL/SNI 엔드포인트를 쓰는 앱의 라우팅 지연이 늘었다. Heroku 는 이 영향이 https://status.heroku.com/incidents/1180 에 기록된 것과 같다고 적었다.

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

원인

촉발
–

감지

–

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

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

AI 도구와 스크립트용

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