사례2건

2건 중 1~2번째

1. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

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

   HubSpot2024

   증상

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

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

   촉발

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

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러라이브니스·레디니스 프로브

   기여 요인

   자동화 증폭여유 용량 부재

   감지

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기

원인별2