{"id":"IL-0495","org":"HubSpot","date":"2024-08-27","docs":[],"title":{"en":"HubSpot's internal load balancers on Kubernetes were falsely marked unhealthy and the rest collapsed under the traffic","ko":"쿠버네티스에서 도는 내부 로드 밸런서 일부가 헬스 체크 실패로 한꺼번에 내려가고 남은 인스턴스가 연결 폭증으로 무너졌다"},"domain":["kubernetes","networking"],"impact":{"scope":"Logging in, reaching content and using HubSpot tools","users":"some HubSpot customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"HubSpot concluded that earlier detection of the abnormal traffic surge could have prevented the cascading failure, and that health checks have to keep running during operations such as configuration updates so that working load balancers are not removed together. The late status page update caused confusion for customers.","ko":"핵심 문제는 설정 갱신 중에 헬스 체크가 잠시 막혀 로드 밸런서 여러 대가 비정상으로 잘못 판정된 것이었다. 여러 인스턴스가 동시에 내려가자 남은 인스턴스에 부하가 몰려 연쇄 장애가 됐다. 넘치는 연결을 거부하는 보호 장치가 있었지만 트래픽 급증이 너무 빠르고 커서 감당하지 못했다. 모니터링은 장애를 빨리 잡았지만, HubSpot 은 비정상적인 트래픽 급증을 더 일찍 알아챘다면 연쇄 장애를 막을 수 있었다고 봤다. 상태 페이지 갱신이 늦어 고객에게 오래되거나 불완전한 정보가 갔다."},"related":[],"sources":[{"url":"https://product.hubspot.com/blog/hubspot-incident-aug27","kind":"blog","archived":"https://web.archive.org/web/20260208211051/https://product.hubspot.com/blog/hubspot-incident-aug27"}],"summary":{"en":"HubSpot's platform sends customer traffic through several layers of security and routing systems. One of these layers is a set of internal load balancers deployed on Kubernetes that distribute traffic across the backend services. On 27 August 2024 a routine operation of the traffic management system ran into an issue in the load balancer stack that HubSpot had not known about, although it had been documented outside HubSpot: path handling updates temporarily blocked the responses to health checks. The health checks, which decide whether a load balancer instance is working and ready for traffic, did not complete in time, and the system read those instances as unhealthy.\n\nSeveral load balancer instances were falsely marked as failed and shut down at the same time. The remaining instances took a sudden surge of connections, 11x the normal peak, and went into congestive collapse. Built-in protections rejected excess connections, but performance for the affected customers was heavily degraded. At 14:59 UTC the team tried to increase the capacity of the remaining instances, at 15:04 UTC new load balancer instances came online and took the pressure off, and by 15:16 UTC the system had fully recovered and traffic was back to normal levels.","ko":"HubSpot 의 트래픽은 여러 층의 보안 시스템과 라우팅 시스템을 거쳐 나뉜다. 그 가운데 내부 로드 밸런서는 쿠버네티스에 배포돼 있고 백엔드 서비스로 트래픽을 나눈다. 2024년 8월 27일 로드 밸런서 스택의 경로 처리 갱신이 헬스 체크 응답을 잠시 막았다. 헬스 체크가 제시간에 끝나지 못하자 시스템은 로드 밸런서 인스턴스 일부를 비정상으로 잘못 판단했고, 이 인스턴스들이 동시에 내려가기 시작했다.\n\n남은 인스턴스에는 평소 최대치의 11배인 수백만 연결이 몰렸고, 로드 밸런서는 혼잡으로 무너졌다. 내장된 보호 장치가 넘치는 연결을 거부했지만, 영향을 받은 고객의 응답 시간은 늘고 요청은 실패했다. HubSpot 은 14:20 UTC에 내부에서 문제를 확인했지만 상태 페이지는 14:44 UTC에야 갱신했고, 이 지연 때문에 고객이 혼란을 겪었다.\n\n14:59 UTC에 팀이 남은 인스턴스의 용량을 늘리는 작업에 들어갔고, 15:04 UTC에 새 로드 밸런서 인스턴스가 올라오면서 부하가 줄었다. 15:16 UTC에 시스템이 완전히 복구됐고 트래픽이 평소 수준으로 돌아왔다."},"trigger":{"en":"Routine operation of a critical component of HubSpot's traffic management system, from about 14:08 UTC, ran path handling updates in the load balancer stack, and an issue in that stack made those updates block health check responses.","ko":"트래픽 관리 시스템의 핵심 구성 요소를 평소대로 운영하던 중 로드 밸런서 스택이 경로 처리 설정을 갱신했다. 외부 문서에는 알려져 있었지만 HubSpot 은 몰랐던 문제 때문에 이 갱신이 헬스 체크 응답을 잠시 막았다."},"severity":"unknown","symptoms":["readiness-probe-failures","high-latency","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":"56m"},"date_kind":"incident","detection":{"en":"Monitoring detected widespread performance degradation across the platform at 14:23 UTC and the incident response team was mobilised. HubSpot says it had identified the issue internally by 14:20 UTC. The status page was not updated until 14:44 UTC, which left customers with outdated information.","ko":"HubSpot 은 14:20 UTC에 내부에서 문제를 확인했다. 14:23 UTC에는 모니터링 시스템이 플랫폼 전반의 성능 저하를 잡았고 장애 대응 팀이 소집됐다."},"components":["ingress","health-probe"],"root_cause":"software-bug","remediation":[{"text":{"en":"Tried to increase the capacity of the remaining load balancer instances","ko":"14:59 UTC에 팀이 남은 로드 밸런서 인스턴스의 용량을 늘리는 작업에 들어갔다."}},{"text":{"en":"Brought new load balancer instances online, which relieved the pressure and let traffic return to normal","ko":"15:04 UTC에 새 로드 밸런서 인스턴스가 올라와 시스템의 부하를 덜었고 트래픽이 안정되기 시작했다. 15:16 UTC에 시스템이 완전히 복구됐다."}}],"action_items":[{"text":{"en":"Change the health check configuration so health checks do not time out falsely","ko":"헬스 체크가 잘못 타임아웃되지 않도록 설정을 고쳤다."}},{"text":{"en":"Redesign the health check system so health checks get priority and keep running during operations such as configuration updates","ko":"설정 갱신 같은 작업 중에도 헬스 체크가 끊기지 않고 먼저 처리되도록 헬스 체크 시스템을 다시 설계한다."}},{"text":{"en":"Increase the capacity of the load balancers for sudden traffic spikes","ko":"갑작스러운 트래픽 급증 때 더 많은 트래픽을 받을 수 있도록 로드 밸런서 용량을 늘렸다."}},{"text":{"en":"Change the load balancing architecture to detect traffic surges earlier and distribute load dynamically in real time","ko":"트래픽 급증을 더 일찍 감지하고 실시간으로 부하를 나눠 특정 인스턴스 묶음에 부하가 몰리지 않도록 로드 밸런싱 구조를 고친다."}},{"text":{"en":"Update the status page automatically for large-scale outages","ko":"대규모 장애 때 상태 페이지가 자동으로 갱신되도록 했다."}},{"text":{"en":"Integrate the monitoring systems more tightly with the communication tools","ko":"상태 갱신이 더 빠르고 정확해지도록 모니터링 시스템을 소통 도구와 더 긴밀하게 연결한다."}},{"text":{"en":"Expand load testing to simulate high-traffic scenarios","ko":"트래픽이 많은 상황을 재현하는 부하 테스트를 넓혀 약한 곳을 미리 찾는다."}},{"text":{"en":"Introduce chaos engineering to test platform resilience regularly","ko":"장애 상황을 일부러 만들어 플랫폼의 복원력을 정기적으로 시험하는 카오스 엔지니어링을 도입한다."}},{"text":{"en":"Add traffic pattern metrics, including the ratio of current connections to the maximum allowed","ko":"최대 허용 연결 수 대비 현재 연결 수의 비율을 포함해 트래픽 흐름을 자세히 보는 새 지표를 넣었다."}},{"text":{"en":"Add auto-scaling that adjusts resource capacity to traffic patterns","ko":"트래픽 흐름에 맞춰 자원 용량을 자동으로 조절하는 오토스케일링을 구현한다."}}],"contributing":["automation-amplified","no-spare-capacity"],"recurrence_of":null,"symptoms_text":{"en":"Between 14:20 and 15:16 UTC on 27 August 2024, some HubSpot customers could not log in to their accounts, reach their content or use HubSpot tools. Requests were slow or failed because HubSpot's internal load balancers, which run on Kubernetes and spread traffic across the backend services, were overloaded.\n\nThe first sign came at 14:08 UTC, when automated health checks on the load balancer instances started to slow down during routine operation. At 14:18 UTC the automatic detection of impaired instances marked a subset of the load balancer instances down because their health checks were failing, and began to take them out of traffic. Those instances were not broken: path handling updates in the load balancer stack were blocking the health check responses, so the checks could not finish in time.\n\nAt 14:19 UTC the remaining load balancer instances received a massive surge in connections, 11x the normal peak, going from hundreds of thousands to several million connections. At 14:23 UTC automated systems applied connection limits to reduce memory overload, which brought longer response times and failed requests, and monitoring detected widespread performance degradation across the platform. The public status page was updated only at 14:44 UTC.","ko":"2024년 8월 27일 14:20 UTC부터 15:16 UTC까지 일부 HubSpot 고객이 계정에 로그인하지 못했고 콘텐츠에 접근하거나 도구를 쓰지 못했다. 모니터링은 플랫폼 전반에서 성능이 크게 떨어진 것을 잡았다.\n\n14:08 UTC에 로드 밸런서의 자동 헬스 체크가 느려지기 시작했다. 14:18 UTC에 장애 인스턴스를 자동으로 찾아내는 기능이 헬스 체크 실패를 보고 로드 밸런서 인스턴스 일부를 다운으로 잘못 표시했고, 이 인스턴스들을 트래픽 처리에서 차례로 빼기 시작했다.\n\n14:19 UTC에 남은 로드 밸런서 인스턴스로 연결이 몰렸다. 연결 수는 수십만에서 수백만으로 치솟아 평소 최대 트래픽의 11배가 됐고, 사용자는 성능 저하와 지연을 겪었다.\n\n14:23 UTC에 자동 시스템이 메모리 과부하를 줄이려고 연결 제한을 걸었다. 로드 밸런서는 넘치는 연결을 거부했고, 그 결과 응답 시간이 늘고 요청이 실패했다."},"updated_at":"2026-11-14T12:34:13.999947Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0495","org_slug":"hubspot"}