{"id":"IL-0351","org":"Heroku","date":"2017-06-03","docs":["https://devcenter.heroku.com/articles/http-routing"],"title":{"en":"Heroku apps in the EU and US had slow and failed requests as DNS round-robin sent traffic to single router hosts","ko":"EU 와 US 에서 Heroku 라우팅 계층을 지나는 요청이 느려지거나 실패했다"},"domain":["networking"],"impact":{"scope":"Requests through the Heroku Routing Layer were slow or failed during periods between 3 and 7 June 2017","users":"All customers in the EU and US, at various times","region":"EU and US"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.heroku.com/incidents/1182","kind":"official-status","archived":"https://web.archive.org/web/20251114131024/https://status.heroku.com/incidents/1182"}],"summary":{"en":"The DNS records for your-app.herokuapp.com are meant to spread traffic over Heroku's routing fleet: each lookup should return a random subset of router addresses. Heroku expected its DNS provider to return several addresses, but for Heroku's specific use case the provider returned only one, a behaviour the provider calls legacy. For traffic patterns such as many HTTP clients sharing one caching DNS resolver, a large number of requests therefore went to a single router host, which was overwhelmed, and requests became slow or failed. During the latency periods Heroku engineers found the sources of high-volume traffic and worked with the owners of those apps to distribute their requests better. The provider has since changed its systems to return multiple addresses for new records, and Heroku replaced its legacy DNS records with new ones, after which incoming traffic was spread more evenly. While investigating, Heroku also found DNS configuration issues that affect its caching Add-on providers.","ko":"your-app.herokuapp.com 꼴의 DNS 레코드는 DNS 라운드 로빈으로 트래픽을 Heroku 서버 전체에 나누도록 설계돼 있었다. 조회할 때마다 서버 가운데 무작위로 고른 일부의 주소가 응답에 담겨 트래픽이 고르게 퍼지는 구조였다. 그런데 Heroku 의 DNS 공급자는 이 사용 방식에서 여러 주소가 아니라 주소 하나만 응답했고, Heroku 는 이 구성 오류를 모르고 있었다. 캐싱 DNS 리졸버 한 대를 함께 쓰는 많은 HTTP 클라이언트 같은 트래픽 패턴에서는 요청이 라우팅 계층의 서버 한 대로 몰려 그 서버가 감당하지 못했다. 그 결과 2017-06-03 부터 06-07 사이 EU 와 US 에서 요청이 느려지거나 실패했다.\n\nDNS 공급자는 이 동작을 옛 방식으로 보고, 새 DNS 레코드에는 여러 주소를 응답하도록 시스템을 바꿨다. Heroku 는 지연이 늘 때마다 트래픽이 많은 출처를 찾아 그 애플리케이션 소유자와 함께 요청을 더 고르게 나눴고, 옛 DNS 레코드를 새로 고친 레코드로 바꿔 들어오는 트래픽이 고르게 나뉘게 했다. 조사 중에는 캐싱 Add-on 공급자에 영향을 주는 DNS 구성 문제도 더 찾았다."},"trigger":null,"severity":"unknown","symptoms":["high-latency","high-error-rate","uneven-load"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["dns-server","cloud-load-balancer"],"root_cause":"dns-network","remediation":[{"text":{"en":"Found the sources of high-volume traffic and worked with those apps' owners to distribute their requests better","ko":"트래픽이 많은 출처를 찾아 그 애플리케이션 소유자와 함께 요청을 더 고르게 나눴다."}},{"text":{"en":"Replaced the legacy DNS records with new, corrected DNS records","ko":"옛 DNS 레코드를 새로 고친 DNS 레코드로 바꿔 들어오는 트래픽이 고르게 나뉘게 했다."}}],"action_items":[{"text":{"en":"Make monitoring alert engineers sooner to unevenly distributed traffic","ko":"트래픽이 고르지 않게 나뉘면 엔지니어에게 더 빨리 알림이 가도록 모니터링을 고친다."}},{"text":{"en":"Investigate how to configure DNS and load balancers to reduce the effect of high-volume and bursting traffic","ko":"트래픽이 많거나 갑자기 몰릴 때의 영향을 줄이도록 DNS 와 로드 밸런서를 구성하는 방법을 내부 조사로 찾는다."}},{"text":{"en":"Work with caching Add-on partners on the DNS configuration issues that affect them, to achieve proper load balancing","ko":"조사 중에 찾은 DNS 구성 문제가 캐싱 Add-on 공급자에 영향을 주므로, 그 공급자들과 함께 부하가 고르게 나뉘도록 작업한다."}}],"contributing":["assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"Between 3 and 7 June 2017, Heroku customers in both the EU and US regions had periods of high latency: some requests failed and others took an excessive time to pass through the Heroku Routing Layer. All customers in the EU and US were affected at various times.\n\nThe slowness came from hot-spotting. A disproportionate share of traffic reached individual servers in the Routing Layer and overwhelmed them, for example when a large group of HTTP clients used a single caching DNS resolver and a large number of requests went to a single host.\n\nThe status page entry itself records one window on 7 June: from 20:50 UTC (16:50 EDT), apps in the US Common Runtime using non-SSL/SNI endpoints had increased routing latency, with the same impact as Heroku incident 1180, and the entry was resolved at 21:50 UTC.","ko":"2017-06-03 부터 06-07 사이 여러 차례, EU 와 US 의 고객 모두가 때때로 높은 지연을 겪었다. 일부 요청은 실패했고, 일부는 Heroku Routing Layer 를 지나는 데 지나치게 오래 걸렸다.\n\n트래픽이 라우팅 계층의 개별 서버로 고르지 않게 몰려 그 서버들이 감당하지 못했다. 캐싱 DNS 리졸버 한 대를 함께 쓰는 많은 HTTP 클라이언트처럼 특정한 트래픽 패턴에서는 많은 요청이 서버 한 대로만 갔다.\n\n2017-06-07 20:50 UTC 부터는 US Common Runtime 에서 non-SSL/SNI 엔드포인트를 쓰는 앱의 라우팅 지연이 늘었다. Heroku 는 이 영향이 https://status.heroku.com/incidents/1180 에 기록된 것과 같다고 적었다."},"updated_at":"2026-11-14T12:34:00.547128Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0351","org_slug":"heroku"}