사례7건

7건 중 1~5번째

1. IL-0099 메모리 상한 없이 8GB 만 보장한 프로필 때문에 워크숍 중 사용자 파드가 서로를 축출해 서버 시작이 15분을 넘고 커널이 죽었다.

   2i2c2025

   증상

   2025년 5월 12일 20:15 EEST 에 Freshdesk 지원 티켓이 들어왔다. 워크숍 중 사용자 서버가 시작하는 데 15분 넘게 걸리고 커널이 죽는다는 내용이었다. 같은 허브를 다른 용도로 쓰던 강사들도 영향을 받았다.

   파드 축출

   촉발

   워크숍 사용자들이 메모리 상한이 없는 프로필로 보장량 8GB 보다 많은 메모리를 꾸준히 썼다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도노드 풀

   기여 요인

   리소스 요청과 한도 미설정

   감지

   커뮤니티가 Freshdesk 지원 티켓으로 알렸다. 티켓은 20:15 에 열렸고 20:49 에 #support-freshdesk 슬랙 채널로 팀에 전달됐으며, 20:57 에 첫 엔지니어가 확인했다.

   조치

   • 5월 12일 21:05 에 helm 롤아웃과 허브 재배포를 했고 상황이 일부 나아졌다.
   • 5월 13일 15:51 에 medium 프로필을 열었고, 그 메모리 보장량을 올려 오버커밋을 줄였다.
   • 17:15 에 30명 워크숍을 위해 노드 15개를 미리 띄웠다.
   • 5월 14일 워크숍 전에 작은 노드용 프로필의 메모리 보장량과 상한을 같게 맞춰 명시적인 메모리 상한을 두는 변경을 배포했다.

   후속 조치

   • 장애 보고서를 쓴다.
   • 내부 회고를 열어 이번 장애에서 배울 점을 정리한다.

   교훈

   메모리 상한 없이 보장량만 둔 프로필에서는 노드를 나눠 쓰는 사용자끼리 서로를 축출할 수 있다. 메모리 보장량과 상한을 같게 두면 한 사용자의 메모리 급증이 같은 노드의 다른 사용자에게 번지지 않는다. 이번에는 로그에 뚜렷한 오류가 없었고 원인은 프로필 설정에 있었다. 워크숍 직전에는 프로필 구조를 바꾸지 않고 노드를 미리 띄우는 쪽으로 대응했다.

   사례 보기
2. 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. IL-0175 JVM 파드의 CPU requests 를 1코어로 줄이자 JVM 이 노드의 CPU 36개를 인식해 Reactor Netty 스레드가 늘고 메모리 사용량이 경보 기준을 넘었다

   Hyperconnect2022

   증상

   DevOps 팀이 아직 운영 트래픽을 받지 않는 notification-preferences 마이크로서비스의 `resources.requests.cpu` 를 2에서 1로 줄였다. 작업을 마치고 몇 분 뒤 메모리 사용량이 90% 를 넘었다는 경보가 왔다. 메모리 할당량이나 JVM 의 GC 관련 인자는 건드리지 않은 상태였다.

   메모리 압박

   촉발

   리소스 최적화 작업 중 notification-preferences 디플로이먼트의 `resources.requests.cpu` 를 2에서 1로 줄였다. CPU limit 은 설정하지 않은 상태였다.

   원인

   소프트웨어 결함

   구성 요소

   언어 런타임 설정컨테이너 CPU 한도

   기여 요인

   리소스 요청과 한도 미설정

   감지

   CPU requests 를 줄이고 몇 분 뒤 메모리 사용량이 90% 를 넘었다는 경보가 울렸다.

   조치

   • JVM 옵션에 `-XX:ActiveProcessorCount=1` 을 넣어 JVM 이 쓸 CPU 수를 강제로 지정했다. 자원을 다시 늘리거나, CPU limit 을 걸거나, requests 를 1001m 이나 999m 으로 두는 방법은 각각 문제가 있어 고르지 않았다.

   후속 조치

   • 이 문제를 사내 공지로 알렸다.

   교훈

   cgroup v1 환경에서 JVM 은 `cpu.shares` 값이 정확히 1024 일 때 이를 설정 없음으로 보고 노드의 CPU 수를 쓴다. CPU limit 없이 requests 만 1로 준 JVM 파드는 노드가 클수록 스레드를 많이 띄우고 메모리를 더 쓴다. 이 문제는 쓸 수 있는 CPU 수로 스레드 수를 정하는 WebFlux 같은 프레임워크에서 특히 크게 드러난다. 이런 설정이라면 `-XX:ActiveProcessorCount` 나 CPU limit 으로 CPU 수를 명시해야 한다. Hyperconnect 는 원래 운영 JVM 애플리케이션에 CPU requests 를 2 이상 주었고, 마이크로서비스가 늘어 자원을 아끼려다 이 문제를 만났다.

   사례 보기
4. IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.

   2i2c2020

   증상

   WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   서비스 중단노드 CPU 고부하

   촉발

   WER 학생들의 사용량이 늘어 사용자 파드와 코어 파드가 함께 도는 노드의 CPU 와 메모리를 다 썼다.

   원인

   용량 한계

   구성 요소

   노드 풀컨테이너 메모리 한도

   기여 요인

   리소스 요청과 한도 미설정미검증 가정과도한 영향 범위

   감지

   08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   조치

   • 09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다.
   • 09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다.

   후속 조치

   • 사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다.
   • prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다.
   • 메모리 오버커밋 비율을 검토하고 문서로 남긴다.
   • 자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다.
   • 다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다.

   교훈

   코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.

   사례 보기
5. IL-0176 시계열 급증으로 호스트 메모리가 바닥나자 oom_score_adj 999 를 받은 Prometheus 컨테이너가 커널 OOM Killer 에게 먼저 죽어 CrashLoopBackOff 에 빠졌다.

   LINE2020

   증상

   어느 월요일 아침, 엔지니어가 쿠버네티스 클러스터 경고를 보려고 Prometheus 대시보드를 열었는데 접속되지 않았다. Prometheus 서버 파드는 CrashLoopBackOff 상태였다.

   컨테이너 재시작 반복OOMKilled모니터링 중단프로브 실패

   촉발

   Prometheus 가 시작한 지 5분 만에 시계열 수가 2,162,256 까지 급증해 메모리 8GB 호스트의 메모리를 거의 다 썼다.

   원인

   용량 한계

   구성 요소

   Prometheuskubelet리눅스 커널

   기여 요인

   리소스 요청과 한도 미설정용량 계획 부재

   감지

   월요일 아침 엔지니어가 클러스터 경고를 확인하려고 Prometheus 대시보드를 열었다가 접속되지 않는 것을 보고 알았다.

   조치

   • Prometheus configMap 에서 불필요한 설정 대부분을 지워 컨테이너가 더 이상 비정상 종료되지 않게 했다.

   후속 조치

   • Prometheus 파드의 requests 와 limits 를 알맞게 고친다. 지금 문제를 완전히 풀지는 못해도 비슷한 문제를 막아 해결 시간을 줄인다.
   • 불필요한 수집 지표를 줄이도록 수집 대상이나 수집 간격을 조정한다.
   • Prometheus 에 필요한 메모리를 예측해 새 호스트를 마련하고 deploy-topology: Prometheus 같은 노드 레이블을 붙인 뒤, 매니페스트에 nodeSelector 를 넣어 Prometheus 파드가 그 호스트에만 배치되게 한다.

   교훈

   원인은 둘이었다. 첫째, Prometheus 파드의 requests 와 limits 를 잘못 잡아 Prometheus 서버 컨테이너가 높은 oom_score_adj 를 받았다. 둘째, 대규모 클러스터에서 Prometheus 가 쓸 메모리를 미리 예측하지 않았다. 쿠버네티스에서 파드의 QoS 클래스는 메모리가 모자랄 때 어느 컨테이너가 먼저 죽는지에 영향을 준다. 커널의 OOM Killer 는 메모리 사용량과 oom_score_adj 로 점수를 매기고, kubelet 은 QoS 클래스에 따라 oom_score_adj 를 정한다.

   사례 보기

원인별3