Workload CPU Utilization Analysis

Workload CPU Utilization Analysis는 모든 워크로드를 실제 CPU 사용 강도에 따라 네 단계로 정렬합니다. 그래서 Grafana를 파고들지 않고도 클러스터 전체에서 어떤 서비스가 CPU 부족에 시달리고 있고, 어떤 서비스가 비용을 내고 있는 코어를 낭비하고 있는지 볼 수 있습니다.

사이드바에서 Wave Diagnosis 아래 CPU Utilization을 여세요. 클러스터 선택기와 날짜 범위 선택기(기본값 최근 7일)가 화면 범위를 정하고, 발견 배너는 limit 근처에 계속 머무른 워크로드와 거의 유휴 상태였던 워크로드 수를 세어 "CPU가 부족하거나 낭비되는 워크로드가 있는가?"에 답합니다.

네 가지 사용률 단계

모든 워크로드는 CPU request 대비 CPU 사용량 비율을 기준으로 네 단계 중 하나에 속합니다.

단계	CPU 사용률	의미	조치
Normal	40% 미만	여유가 충분하거나 과다 프로비저닝된, 건강한 상태	여유는 남기되 비용을 위해 다운사이징
Medium	40~60%	대부분의 서비스에 적당한 범위	조치 불필요, High로 이동하는지만 관찰
High	60~80%	limit에 근접해 성능 위험이 있는 상태	수평 또는 수직 스케일링 계획
Severe	80% 이상	CPU 병목이며, 사용자 영향 가능성이 높음	지금 바로 스케일링하거나 최적화

CPU Utilization 페이지

CPU Utilization page with the finding banner, the four-level breakdown cards, and the per-workload table

CPU Utilization Level Breakdown. 네 개의 카드가 선택한 범위에 대해 클러스터 전체를 합산해서 보여줍니다. 각 카드는 Event Count(어떤 워크로드든 그 단계에 진입한 횟수)와 Average Duration within an Hour(그 상태가 지속된 시간)를 초록(Normal)에서 빨강(Severe)까지 색으로 구분해 보여줘서, 클러스터 전체의 CPU 상태를 한 줄로 읽을 수 있습니다.

워크로드 테이블

카드 아래에는 워크로드마다 한 행씩, 심각도 순으로 정렬되어 있어 가장 심각한 워크로드가 위에 옵니다.

컬럼	표시 내용
Order	심각도 순위. 우선순위가 가장 높은 워크로드가 맨 위에 옵니다
Namespace	워크로드가 실행 중인 namespace
Workload Name	Deployment, StatefulSet, DaemonSet 이름
Workload Type	Kubernetes 종류(kind)
CPU Usage (Min/Avg/Max)	사용된 CPU 코어 수의 최솟값, 평균, 최댓값
Normal / Medium / High / Severe	단계별 컬럼 하나씩, 아래에서 설명

각 단계 셀은 X events, Ym avg (min to max) 형식으로 읽습니다: 워크로드가 그 단계에 진입한 횟수, 한 번 머문 평균 시간, 그 범위입니다. Severe 컬럼에 이벤트 대부분이 몰린 워크로드는 지속적인 병목이고, 잠깐씩만 튀는 워크로드는 간헐적이라 대체로 문제없는 경우가 많습니다.

Filter Groups

Filter Group 드롭다운(기본값 All (No Filter))은 분석 대상을 워크로드 일부로 좁혀주고, 옆의 톱니바퀴 아이콘은 Filter Group 관리 화면을 엽니다. Kubernetes 라벨 조건(Equals, In, Exists 같은 연산자를 AND나 OR로 조합)으로 그룹을 정의해서 팀, 환경, 애플리케이션 티어별로 나눌 수 있습니다. 그룹을 선택하면 해당 라벨과 일치하는 워크로드가 한 행으로 합산되어, 워크로드별이 아니라 논리적 그룹별로 CPU 동작을 읽을 수 있습니다.

CPU는 하나의 지표일 뿐입니다

⚠️

CPU 사용률이 높다고 항상 문제인 것은 아닙니다. 배치 작업, ML 학습, 비디오 인코딩은 원래 100%에 가깝게 돌아가도록 설계된 워크로드이며, 이는 병목이 아니라 효율적인 상태입니다. 사용자 영향을 보여주는 진짜 신호는 CPU가 아니라 지연 시간(latency)과 에러율입니다. 이 분석은 어떤 워크로드를 먼저 살펴볼지 우선순위를 정하는 데 쓰고, 스케일링하기 전에 애플리케이션 지표로 반드시 확인하세요.

활용 사례

성능 트러블슈팅

Severe와 High로 필터링하면 대시보드를 일일이 훑는 대신 몇 초 만에 CPU 병목 서비스를 찾을 수 있고, 그다음 지연 시간과 에러율로 확인하면 됩니다. 원인을 찾는 시간이 몇 시간에서 몇 분으로 줄어듭니다.

수평 스케일링 결정

Severe나 High에 머물러 있는 stateless 워크로드는 Autopilot에 맡기거나(또는 수동으로 replica를 추가해서) Medium이나 Normal로 안정화되는지 지켜보세요. 분류 결과가 어떤 워크로드에 필요한지 알려주므로, 추측이 아니라 근거를 가지고 스케일링할 수 있습니다.

수직 적정 사이징

Smart Sizing과 함께 사용하세요. Severe와 High 워크로드는 CPU request를 올리고, Normal(과다 프로비저닝된) 워크로드는 낮추면 됩니다. CPU Utilization이 우선순위 목록을 주고, Smart Sizing이 정확한 수치를 제공합니다.

용량 계획

시간에 따른 단계 비율 변화를 추적하세요. Severe와 High 워크로드 수가 늘어난다면 Node 추가를 계획해야 하고, Normal이 대다수인 클러스터는 프로비저닝이 잘 돼 있는 상태입니다. 이 추세가 언제 용량 한계와 만나는지는 Cluster Resource Forecast로 교차 확인하세요.