IL-0181 Kevin · 2026-02-19 (게시일)kubernetes
이번 장애는 코드 버그나 인프라 결함에서 시작되지 않았다. 뽐뿌에 플랫폼 링크가 담긴 게시글이 올라오면서 짧은 시간에 사용자가 몰렸고, 상품 조회 API 호출이 상품 관련 파드에 집중됐다. 컨테이너가 CPU limit 인 1코어에 닿자 Linux 의 CFS 스케줄러가 CPU 사용을 강제로 제한했다. 파드는 Running 상태로 남은 채 요청을 제때 처리하지 못했다.
글쓴이는 먼저 HPA 의 minReplicas 를 5에서 10으로 늘렸다. 같은 트래픽이 10개 파드로 나뉘면서 파드당 CPU 사용률이 크게 내려갔고, 이 조치만으로 응답 속도가 정상으로 돌아왔다. HPA 의 maxReplicas 는 20, CPU 평균 사용률 목표는 70% 였다.
파드를 늘려도 파드당 CPU limit 이 낮으면 같은 문제가 되풀이될 수 있어서, Deployment 의 CPU limit 을 1코어에서 2코어로 올렸다. requests 는 cpu 500m, memory 1Gi 그대로였다.
운영 중인 이커머스 플랫폼의 응답이 갑자기 느려졌다. 상품 조회 페이지가 특히 심했고, 사용자들에게서 "페이지가 안 열린다"는 문의가 들어왔다.
쿠버네티스 대시보드에서는 모든 파드가 Running 이었고 재시작도 없었다. 그런데 문제 서비스의 네임스페이스 CPU 사용량은 100% 에 이르렀다.
CPU 스로틀링이 일어나도 파드는 Running 으로 남고 OOMKill 처럼 재시작되지도 않는다. 로그에도 뚜렷한 오류가 남지 않고 응답만 느려진다. 그래서 대시보드에서 파드 목록만 볼 때는 원인을 전혀 짐작하지 못했고, CPU 사용량 메트릭을 직접 보고서야 스로틀링을 확인했다.
원인 ? 용량 한계
사용자에게서 "페이지가 안 열린다"는 문의가 들어와 장애를 알았다. 대시보드의 파드 상태는 정상이었고, 네임스페이스 CPU 사용량과 CPU 메트릭을 직접 보고서야 CPU 스로틀링을 확인했다.
글쓴이는 예측 가능한 이벤트성 트래픽까지는 받아낼 수 있게 설정해 뒀다고 생각했다. 그러나 외부 커뮤니티 게시글 하나로 트래픽이 폭증하자 그동안 문제없던 리소스 설정이 순식간에 병목이 됐다. CPU 스로틀링은 파드 상태와 로그에 드러나지 않아서 파드 목록이 아니라 CPU 메트릭을 봐야 찾을 수 있었다. 글쓴이는 대규모 트래픽에 미리 대비한 경험이 부족했다고 돌아보고, 트래픽 패턴이 바뀔 때의 대비와 리소스 설정을 더 고민하기로 했다.
같은 원인 · 공통 수평 파드 오토스케일러
같은 원인 · 공통 수평 파드 오토스케일러
같은 원인 · 공통 컨테이너 CPU 한도