쿠버네티스에서 도는 내부 로드 밸런서 일부가 헬스 체크 실패로 한꺼번에 내려가고 남은 인스턴스가 연결 폭증으로 무너졌다

증상

2024년 8월 27일 14:20 UTC부터 15:16 UTC까지 일부 HubSpot 고객이 계정에 로그인하지 못했고 콘텐츠에 접근하거나 도구를 쓰지 못했다. 모니터링은 플랫폼 전반에서 성능이 크게 떨어진 것을 잡았다.

14:08 UTC에 로드 밸런서의 자동 헬스 체크가 느려지기 시작했다. 14:18 UTC에 장애 인스턴스를 자동으로 찾아내는 기능이 헬스 체크 실패를 보고 로드 밸런서 인스턴스 일부를 다운으로 잘못 표시했고, 이 인스턴스들을 트래픽 처리에서 차례로 빼기 시작했다.

14:19 UTC에 남은 로드 밸런서 인스턴스로 연결이 몰렸다. 연결 수는 수십만에서 수백만으로 치솟아 평소 최대 트래픽의 11배가 됐고, 사용자는 성능 저하와 지연을 겪었다.

14:23 UTC에 자동 시스템이 메모리 과부하를 줄이려고 연결 제한을 걸었다. 로드 밸런서는 넘치는 연결을 거부했고, 그 결과 응답 시간이 늘고 요청이 실패했다.

증상 프로브 실패지연 시간 증가오류율 상승

원인

촉발

트래픽 관리 시스템의 핵심 구성 요소를 평소대로 운영하던 중 로드 밸런서 스택이 경로 처리 설정을 갱신했다. 외부 문서에는 알려져 있었지만 HubSpot 은 몰랐던 문제 때문에 이 갱신이 헬스 체크 응답을 잠시 막았다.

감지

HubSpot 은 14:20 UTC에 내부에서 문제를 확인했다. 14:23 UTC에는 모니터링 시스템이 플랫폼 전반의 성능 저하를 잡았고 장애 대응 팀이 소집됐다.

조치

• 14:59 UTC에 팀이 남은 로드 밸런서 인스턴스의 용량을 늘리는 작업에 들어갔다.
• 15:04 UTC에 새 로드 밸런서 인스턴스가 올라와 시스템의 부하를 덜었고 트래픽이 안정되기 시작했다. 15:16 UTC에 시스템이 완전히 복구됐다.

후속 조치

• 헬스 체크가 잘못 타임아웃되지 않도록 설정을 고쳤다.
• 설정 갱신 같은 작업 중에도 헬스 체크가 끊기지 않고 먼저 처리되도록 헬스 체크 시스템을 다시 설계한다.
• 갑작스러운 트래픽 급증 때 더 많은 트래픽을 받을 수 있도록 로드 밸런서 용량을 늘렸다.
• 트래픽 급증을 더 일찍 감지하고 실시간으로 부하를 나눠 특정 인스턴스 묶음에 부하가 몰리지 않도록 로드 밸런싱 구조를 고친다.
• 대규모 장애 때 상태 페이지가 자동으로 갱신되도록 했다.
• 상태 갱신이 더 빠르고 정확해지도록 모니터링 시스템을 소통 도구와 더 긴밀하게 연결한다.
• 트래픽이 많은 상황을 재현하는 부하 테스트를 넓혀 약한 곳을 미리 찾는다.
• 장애 상황을 일부러 만들어 플랫폼의 복원력을 정기적으로 시험하는 카오스 엔지니어링을 도입한다.
• 최대 허용 연결 수 대비 현재 연결 수의 비율을 포함해 트래픽 흐름을 자세히 보는 새 지표를 넣었다.
• 트래픽 흐름에 맞춰 자원 용량을 자동으로 조절하는 오토스케일링을 구현한다.

교훈

핵심 문제는 설정 갱신 중에 헬스 체크가 잠시 막혀 로드 밸런서 여러 대가 비정상으로 잘못 판정된 것이었다. 여러 인스턴스가 동시에 내려가자 남은 인스턴스에 부하가 몰려 연쇄 장애가 됐다. 넘치는 연결을 거부하는 보호 장치가 있었지만 트래픽 급증이 너무 빠르고 커서 감당하지 못했다. 모니터링은 장애를 빨리 잡았지만, HubSpot 은 비정상적인 트래픽 급증을 더 일찍 알아챘다면 연쇄 장애를 막을 수 있었다고 봤다. 상태 페이지 갱신이 늦어 고객에게 오래되거나 불완전한 정보가 갔다.

출처

• https://product.hubspot.com/blog/hubspot-incident-aug27 · blog · 보관본

관련 사례

• IL-0053 Ingress NGINX Controller의 어드미션 웹훅이 인증 없이 열려 있어, 조작한 Ingress 객체로 NGINX 설정을 주입해 원격 코드를 실행하고 클러스터의 모든 Secret을 읽을 수 있었다Wiz · 2025

  같은 원인 · 공통 인그레스 컨트롤러

• IL-0081 ingress-nginx 의 enable-serial-reloads 옵션이 NGINX 리로드 중에 엔드포인트 동적 갱신을 막아, 배포 중 트래픽이 이미 없는 파드로 가면서 API 요청이 타임아웃됐다.Cresta · 2025

  같은 원인 · 공통 인그레스 컨트롤러

• IL-0106 잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다DFDS · 2021

  같은 원인 · 공통 인그레스 컨트롤러

• IL-0062 GKE Ingress 뒤의 파드가 SIGTERM 을 받자마자 새 연결을 받지 않고 정상 종료해서 API 에 가끔 502 오류가 났다Ravelin · 2019

  같은 원인 · 공통 인그레스 컨트롤러

• IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다Skyscanner · 2019

  같은 원인 · 공통 인그레스 컨트롤러

• IL-0072 etcd 쓰기 지연으로 API 서버가 오래된 데이터를 읽어 클러스터 상태가 두 가지로 번갈아 보였고, 주 운영 클러스터 전체가 약 4시간 멈췄다Nordstrom · 2017

  같은 원인 · 공통 인그레스 컨트롤러

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

AI 도구와 스크립트용

• 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0495
• 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0495/similar
• MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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