{"id":"IL-0492","org":"Hosted Graphite","date":"2018-03-01","docs":[],"title":{"en":"Hosted Graphite's self-hosted load balancers hit their connection limit in an AWS outage, timing out its site and APIs","ko":"AWS 연결 문제로 느려진 연결이 연결 한도를 다 차지해 AWS 밖에 있는 Hosted Graphite 로드 밸런서에 새 연결이 붙지 못했다"},"domain":["networking","aws"],"impact":{"scope":"Hosted Graphite website, graph rendering API and HTTP ingestion API intermittently unavailable from all locations; ingestion from AWS us-east1 and us-west2 reduced; some internal services timed out","users":"unknown","region":"global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"An outage at a provider that did not host the service's website still made the service unavailable, here because slow clients in the affected regions used up the connection limit of the load balancers that served everyone.","ko":"분산 시스템에서는 한 서비스의 장애가 다른 서비스에 어떻게 영향을 줄지 알기 어렵다. 이번에는 직접으로도 간접으로도 쓰지 않는 사업자의 장애가 AWS 밖에 있는 서비스를 멈췄다. 연결을 끊지는 않고 느리게 만드는 네트워크 문제만으로도 느린 클라이언트가 로드 밸런서의 연결 한도를 다 차지해 다른 모든 클라이언트를 막을 수 있다. 로드 밸런서 로그를 충분히 남겨 두었기 때문에 활성 연결 수와 ISP별 요청 시간을 시각화해 원인을 밝힐 수 있었다."},"related":[],"sources":[{"url":"https://blog.hostedgraphite.com/blog/spooky-action-at-a-distance-how-an-aws-outage-ate-our-load-balancer","kind":"blog","archived":"https://web.archive.org/web/20260420195654/https://blog.hostedgraphite.com/blog/spooky-action-at-a-distance-how-an-aws-outage-ate-our-load-balancer"}],"summary":{"en":"Hosted Graphite runs its own load balancers outside AWS and uses AWS Route53 health checks to keep only healthy load balancers in the DNS results of hostedgraphite.com. Many Hosted Graphite users are hosted in AWS themselves. During an AWS connectivity problem in us-east1 and us-west2, connections from AWS hosts in those regions became very slow without breaking: a heatmap built from the load balancer logs showed AWS hosts, mainly EC2 instances, taking up to 5 seconds to send a full HTTP request, while other ISPs were largely unaffected. The number of active connections to the load balancers rose sharply and then flatlined for exactly the period of the incident, even though the number of requests had fallen.\n\nThe slow AWS clients held every available connection until the load balancers reached their connection limit. New connections from everywhere else were queued and could time out before they were processed, which explained the slow SSL handshakes and the failures of the website, the render API and the HTTP API from every location. Traffic started to recover slowly when AWS resolved its incident at 01:46 UTC. Afterwards Hosted Graphite enforced stricter client timeouts and raised the load balancers' connection limits.","ko":"Hosted Graphite는 웹사이트와 HTTP 프런트엔드를 AWS 밖에서 자체 로드 밸런서로 운영하고, 로드 밸런서의 상태 확인에만 AWS Route53 상태 검사를 써서 상태가 나쁜 로드 밸런서를 hostedgraphite.com의 DNS 응답에서 뺀다. 금요일 밤 23:28 UTC에 웹사이트와 그래프 렌더링 API의 주기 검사가 타임아웃되기 시작했고, 모든 수집 프로토콜에서 트래픽이 줄었다. 수집은 us-east1과 us-west2 같은 AWS 리전에서 영향을 받았지만 HTTP API 수집은 어디서든 영향을 받았고, S3에 의존하는 내부 서비스도 타임아웃됐다.\n\n팀은 AWS 연결 문제를 단서로 따라갔지만 AWS에 있지 않은 웹사이트가 왜 응답하지 않는지 설명하지 못했다. Route53 상태 검사를 잠시 꺼도 소용없었고, 로드 밸런서 로그에서 AWS 밖의 IP 주소들이 SSL 핸드셰이크를 끝내지 못하는 것을 찾았다. 01:46 UTC에 AWS 장애가 해결되자 트래픽이 천천히 돌아왔다.\n\n나중에 로드 밸런서 로그로 그래프 두 개를 만들어 원인을 밝혔다. 로드 밸런서의 활성 연결 수는 장애 기간에 급히 늘어 한도에 닿은 채 평평하게 이어졌고, 한도에 이르면 새 연결은 대기열에 쌓여 처리되기 전에 타임아웃될 수 있었다. 받은 요청 수는 오히려 줄었다. ISP별로 전체 HTTP 요청을 보내는 데 걸린 평균 시간을 그린 히트맵을 보니, 장애 중 AWS 호스트가 요청 하나를 보내는 데 최대 5초가 걸렸다. 이 호스트는 주로 EC2 인스턴스였다. 영향을 받은 리전의 AWS 호스트가 느린 연결로 가용 연결을 모두 차지해 로드 밸런서의 연결 한도에 이르렀고, 다른 위치의 호스트는 새 연결을 맺지 못했다."},"trigger":{"en":"An AWS connectivity problem in us-east1 and us-west2 slowed down connections from AWS hosts in those regions to Hosted Graphite's load balancers without breaking them.","ko":"AWS의 us-east1과 us-west2 리전에서 연결 문제가 생겨, 그 리전의 AWS 호스트가 Hosted Graphite 로드 밸런서에 맺은 연결이 끊기지는 않은 채 크게 느려졌다."},"severity":"unknown","symptoms":["intermittent-timeouts","intermittent-connection-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Monitoring reported the website intermittently unavailable at 23:28 UTC, when periodic checks of the website and the graph rendering API started timing out.","ko":"23:28 UTC에 웹사이트와 그래프 렌더링 API를 주기적으로 확인하는 모니터링 검사가 타임아웃되며 알렸다. 내부와 외부 카나리로 영향받은 수집 경로를 가렸다."},"components":["on-premises-load-balancer"],"root_cause":"capacity","remediation":[],"action_items":[{"text":{"en":"Enforce stricter client timeouts","ko":"클라이언트 타임아웃을 더 엄격하게 적용한다."}},{"text":{"en":"Raise the load balancers' connection limits","ko":"로드 밸런서의 연결 한도를 높인다."}},{"text":{"en":"Use the new visualizations built from load balancer logs when troubleshooting the load balancing layer","ko":"로드 밸런서 로그로 만든 활성 연결 수와 ISP별 요청 시간 히트맵을 SRE 팀과 지원 팀이 로드 밸런싱 계층 문제를 살필 때 늘 쓰는 도구로 삼았다."}}],"contributing":["circular-dependency"],"recurrence_of":null,"symptoms_text":{"en":"On a Friday night at 23:28 UTC, Hosted Graphite's monitoring showed its website intermittently becoming unavailable: periodic checks of the website and of the graph rendering API were timing out. Traffic dropped across all ingestion protocols at the same time.\n\nInternal and external canaries showed ingestion affected from some AWS regions, us-east1 and us-west2 in particular, while ingestion through the HTTP API was affected from every location. Some internal services that are not user-facing also reported timeouts. The internal services in trouble relied on S3, integrations with AWS dependencies such as Heroku were badly affected, and the AWS status page confirmed connectivity issues in us-east1 and us-west2. That did not explain why the website, which is neither hosted in AWS nor near those regions, was failing.\n\nThe team then suspected the Route53 health checks that remove an unhealthy self-hosted load balancer from the DNS results of hostedgraphite.com, since the health check logs reported failures from many locations. The SRE chatbot that would normally disable them depended on Slack's IRC gateway, which the AWS outage had also affected, so the health checks were disabled by hand. That did not fix anything.\n\nThe load balancer logs then showed failures to complete SSL handshakes for IP addresses outside the normal AWS ranges, and tests from several locations confirmed that SSL handshakes took unacceptably long wherever they came from.","ko":"금요일 밤 23:28 UTC에 모니터링이 웹사이트가 간헐적으로 응답하지 않는다고 알렸다. 웹사이트와 그래프 렌더링 API를 주기적으로 확인하는 검사가 타임아웃됐다.\n\n모든 수집 프로토콜에서 트래픽이 전체적으로 줄었다. 내부와 외부 카나리를 보니 수집은 특정 AWS 리전, 특히 us-east1과 us-west2에서 영향을 받았지만, HTTP API를 통한 수집은 위치와 상관없이 영향을 받았다.\n\n사용자에게 보이지 않는 내부 서비스 일부도 타임아웃을 보고하기 시작했다. 이 서비스들은 S3에 의존했고, Heroku처럼 AWS에 의존하는 연동도 크게 영향을 받았다. AWS 상태 페이지도 나중에 us-east1과 us-west2의 연결 문제를 알렸다.\n\n로드 밸런서 로그에는 평소 보던 AWS 대역 밖의 IP 주소에서 SSL 핸드셰이크를 끝내지 못한 실패가 찍혔다. 여러 위치에서 시험해 보니 어디서든 SSL 핸드셰이크가 받아들일 수 없을 만큼 오래 걸렸다.\n\n처음에는 AWS 연결 문제가 가장 유력한 단서였지만, 웹사이트는 AWS에 있지도 않고 영향을 받은 리전 가까이에 있지도 않아 설명이 되지 않았다. HTTP 프런트엔드에서 AWS에 있는 유일한 부분인 Route53 상태 검사가 여러 위치에서 실패하고 있어, 원인인지 증상인지 가리려고 잠시 껐지만 문제는 풀리지 않았다. 평소에는 SRE 챗봇으로 Slack에서 끄면 되는 일이었지만, AWS 장애가 챗봇이 쓰는 Slack의 IRC 게이트웨이에도 영향을 줘 손으로 바꿔야 했다."},"updated_at":"2026-11-14T12:34:13.713805Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0492","org_slug":"hosted-graphite"}