사례3건

3건 중 1~3번째

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-0122 여러 핵심 서비스가 함께 읽는 설정에 잘못된 값이 들어가 ChatGPT 파드가 크래시 루프에 빠졌다

   OpenAI2025

   증상

   2025-07-15 오후 7:43 PDT 부터 일부 사용자의 ChatGPT 대화에서 오류율이 올라갔다. 상태 페이지는 이 장애를 성능 저하로 표시했다.

   컨테이너 재시작 반복오류율 상승

   촉발

   내부 엔지니어가 잘못된 값이 든 설정 변경을 적용했다.

   원인

   설정 변경

   구성 요소

   –

   기여 요인

   과도한 영향 범위단계적 배포 부재

   조치

   • 잘못된 설정 값을 올바른 값으로 되돌렸다.
   • 영향받은 파드를 롤링 재시작해 곧바로 다시 동기화되게 했다.

   후속 조치

   • 중요한 설정 변경에 더 강한 안전장치를 둔다. 앞으로 이 서비스의 중요한 설정 변경은 클러스터 하나에 먼저 배포하고, 가용성이 떨어지면 자동 헬스 가드가 다음 배포를 멈춘다.
   • 여러 서비스가 함께 쓰는 설정을 서비스별 설정 값으로 나눠 서비스 사이의 의존 위험을 줄인다.
   • 배포 안전장치를 강화한다.

   사례 보기
3. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.

   DFDS2024

   증상

   2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

   노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단

   촉발

   Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도애플리케이션 데이터베이스

   기여 요인

   과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대

   감지

   10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

   조치

   • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
   • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
   • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
   • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
   • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
   • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.

   후속 조치

   • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
   • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
   • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
   • grafana-agent 의 메모리 사용량을 조사한다.
   • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
   • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
   • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.

   교훈

   포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

   사례 보기

원인별3