005-cpu stress

Tag

Experiments

CPU Stress — CPU 부하 주입 및 알람 구축

목적: 모든 podinfo Pod에 CPU 부하를 주입했을 때의 서비스 영향과 HPA scale-out 동작을 관찰하고, CPU 관련 alert를 구축해 검증한다.

1. 개요

Chaos Mesh의 StressChaos로 podinfo의 모든 Pod에 CPU 부하를 주입하고, k6로 동일한 부하를 주며 서비스 영향을 관찰했다. 이 실험은 다음 두 단계로 진행했다.

단계	내용
1차 (개선 전)	CPU Stress 주입, k6/Grafana 지표만으로 관찰
2차 (개선 후)	CPU usage, CPU throttling, HPA max replica 감지를 위한 Alertmanager 규칙 추가 후 재실험

Pod Failure와 마찬가지로 이번 개선의 목적은 서비스 지표를 직접 개선하는 것이 아니라, CPU 관련 장애 상황을 자동으로 감지할 수 있는 체계를 마련하는 것이다.

2. 실험 환경

•

대상 서비스: podinfo (http://podinfo.chaos-lab.local)

•

부하 도구: k6 (Rate 15 req/s, Duration 10m, 2분 baseline → 5분 chaos 주입 → 3분 안정화)

•

장애 주입: Chaos Mesh (StressChaos)

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: podinfo-cpu-stress
  namespace: chaos-mesh
spec:
  mode: all
  duration: "5m"
  selector:
    namespaces:
      - podinfo
    labelSelectors:
      app.kubernetes.io/name: podinfo
  stressors:
    cpu:
      workers: 2
      load: 80
YAML
복사

workers: 2, load: 80 설정으로 각 대상 Pod에 CPU stress worker 2개를 실행하고, 5분 동안 높은 CPU 부하를 주입했다. 대시보드에서 Pod의 CPU 사용률 합산이 400~500%까지 치솟고 CFS Throttling이 100%에 도달하는 것이 관찰되었으며, HPA가 이를 감지해 replica를 3에서 6(max)까지 scale-out했다.

•

모니터링: Prometheus + Grafana + Alertmanager(Discord 연동)

3. 1차 실험 (개선 전)

결과

지표	값
총 요청 수	8,985 건
실패율	0.28% (25건)
p50 latency	4.12ms
p90 latency	39.15ms
p95 latency	50.47ms
p99 latency	83.15ms
max latency	214ms
checks 통과율	99.86%

Grafana 대시보드

1차 — Overview / Pod Health / Traffic & Latency

CPU 부하가 주입되자 CFS Throttling이 100%에 근접했고, HPA가 CPU 사용률 급등을 감지해 replica를 3에서 6(max)까지 scale-out했다. 새 Pod가 추가되면서 부하가 분산되어 latency는 어느 정도 흡수되었고, fail rate도 baseline과 동일한 수준을 유지했다. 그러나 이 시점에는 CPU 이상을 자동으로 감지하는 alert가 없어, 대시보드를 직접 보고 있어야만 상황을 파악할 수 있었다.

4. 관측성 개선 — Alertmanager 규칙 추가

CPU 사용률 급등, CPU throttling, HPA max replica 도달을 자동으로 감지할 수 있도록 세 가지 alert 규칙을 추가했다.

Alert	조건	for	의미
PodinfoHighCPUUsage	CPU 사용률 > request 대비 80%	1m	CPU 과부하 또는 HPA 미반응 상태 감지
PodinfoHpaMaxReplicasReached	HPA current replicas ≥ max replicas	1m	scale-out 한계 도달, 추가 용량 필요 여부 확인
PodinfoCPUThrottlingHigh	CFS throttled 비율 > 20%	2m	CPU limit 대비 요청이 과다한 상태 감지

- alert: PodinfoHighCPUUsage
  expr: |
    sum by (pod) (
      rate(container_cpu_usage_seconds_total{namespace="podinfo", pod=~"podinfo-.*", container="podinfo"}[2m])
    )
    /
    sum by (pod) (
      kube_pod_container_resource_requests{namespace="podinfo", pod=~"podinfo-.*", container="podinfo", resource="cpu"}
    ) > 0.8
  for: 1m
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo CPU usage is high"
    description: "podinfo CPU usage is above 80% of the requested CPU for more than 1 minute. Check CPU Stress or HPA behavior, or application load."

- alert: PodinfoHpaMaxReplicasReached
  expr: |
    kube_horizontalpodautoscaler_status_current_replicas{namespace="podinfo", horizontalpodautoscaler="podinfo"}
    >= on(namespace, horizontalpodautoscaler)
    kube_horizontalpodautoscaler_spec_max_replicas{namespace="podinfo", horizontalpodautoscaler="podinfo"}
  for: 1m
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo HPA max replicas reached"
    description: "podinfo HPA reached the configured max replica count. Check whether additional capacity or HPA maxReplicas tuning is required."

- alert: PodinfoCPUThrottlingHigh
  expr: |
    sum by (pod) (
      rate(container_cpu_cfs_throttled_periods_total{namespace="podinfo", pod=~"podinfo-.*", container="podinfo"}[2m])
    )
    /
    sum by (pod) (
      rate(container_cpu_cfs_periods_total{namespace="podinfo", pod=~"podinfo-.*", container="podinfo"}[2m])
    ) > 0.2
  for: 2m
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo CPU throttling is high"
    description: "podinfo CPU throttling ratio is above 20% for more than 2 minutes. Check CPU limits, resource requests, and HPA scaling behavior."
YAML
복사

5. 2차 실험 (개선 후 — Alert 동작 검증)

결과

지표	1차 (개선 전)	2차 (개선 후)	비교
실패율	0.28% (25건)	0.28% (25건)	동일
p50 latency	4.12ms	5.74ms	소폭 증가
p90 latency	39.15ms	48.00ms	증가
p95 latency	50.47ms	71.47ms	증가
p99 latency	83.15ms	168.67ms	증가
max latency	214ms	889ms	증가
checks 통과율	99.86%	99.86%	동일

fail count와 checks rate는 두 실험이 완전히 동일하다. latency는 2차가 전반적으로 높게 나타났으나, 이는 alert 도입의 효과가 아니라 실행 시점의 부하 편차로 해석한다. alert rule은 Prometheus 평가와 Alertmanager 알림 경로에만 영향을 주며, request path에 직접 개입하지 않기 때문에 애플리케이션 latency를 개선하거나 악화시키는 요인으로 보기는 어렵다.

Grafana 대시보드

2차 — Overview / Pod Health / Traffic & Latency

2차 실험에서도 CPU 사용률 500%대, CFS Throttling 100%, HPA 3→6 scale-out이 동일하게 관찰되었다. 이번에는 세 가지 alert가 모두 Discord로 정상 수신되었고, chaos 종료 후 Resolved로 전환되었다.

알람 동작 확인

Firing — PodinfoCPUThrottlingHigh (3개 Pod 동시)

Firing — PodinfoHighCPUUsage (3개 Pod 동시)

chaos 주입 시각(12:39:57 UTC)을 기준으로 Discord 알림 수신 시각을 비교하면 다음과 같다.

Alert	Discord 수신 시각 (UTC)	Discord 수신 기준 MTTD
PodinfoHighCPUUsage	12:42:06.749	약 2분 9초
PodinfoHpaMaxReplicasReached	12:42:06.753	약 2분 9초
PodinfoCPUThrottlingHigh	12:43:06.851	약 3분 9초

PodinfoHighCPUUsage와 PodinfoHpaMaxReplicasReached가 거의 동시에 Firing된 것은 두 alert 모두 for: 1m으로 설정되어 있어, CPU 급등과 함께 HPA가 즉시 max replica에 도달했기 때문이다. PodinfoCPUThrottlingHigh는 for: 2m으로 설정되어 약 1분 늦게 Firing되었다.

Resolved 시각도 주목할 만하다. PodinfoHighCPUUsage와 PodinfoCPUThrottlingHigh는 CPU Stress 종료 후 약 2분 뒤인 12:47경 Resolved되었다. 반면 PodinfoHpaMaxReplicasReached는 12:52:06까지 Resolved되지 않았다. 이는 CPU 부하가 해소된 뒤에도 HPA scale-down이 즉시 발생하지 않고, 일정 시간 동안 replica 수가 max 상태로 유지되었기 때문이다.

6. 결론 및 학습 내용

결론

CPU Stress 상황에서 HPA가 scale-out으로 응답해 fail rate와 checks rate는 baseline 수준을 유지했다. 그러나 alert 구축 전에는 이 모든 과정이 대시보드를 직접 보고 있어야만 파악 가능했다. alert 구축 후에는 CPU 과부하, HPA max replica 도달, throttling 급등이 각각 약 2분 9초~3분 9초 내에 Discord로 수신되는 것을 실측으로 확인했다. Pod Failure와 마찬가지로, 감지 시간이라는 지표 자체가 처음으로 측정 가능해진 것이 이번 실험의 핵심 성과다.

학습 내용

•

HPA는 CPU 과부하에 대해 scale-out으로 응답하지만, max replica에 도달한 이후에는 추가 확장이 불가능하다. PodinfoHpaMaxReplicasReached alert는 현재 HPA가 설정된 확장 한계에 도달했음을 보여준다. 이번 실험에서는 Chaos Mesh가 의도적으로 모든 Pod에 CPU 부하를 주입했기 때문에 maxReplicas를 즉시 조정해야 한다는 결론으로 보지는 않았다. 다만 실제 운영 트래픽에서도 동일한 alert가 반복된다면 maxReplicas, resource requests/limits, 노드 여유 용량을 함께 검토해야 한다.

•

CPU throttling(CFS)과 CPU usage는 별개의 현상을 나타낸다. usage가 request 대비 80%를 초과하는 것은 요청한 CPU를 거의 다 쓰고 있다는 의미이고, throttling이 높다는 것은 limit에 걸려 실제로 처리해야 할 연산이 지연되고 있다는 의미다. 두 alert를 분리한 것은 이 둘이 동시에 발생하는지, 아니면 throttling만 높은 상태(limit 설정 문제)인지를 구분하기 위함이다.

•

PodinfoHpaMaxReplicasReached의 Resolved가 다른 두 alert보다 약 5분 늦었던 것은 HPA scale-down cooldown 때문이다. 이는 예상 범위 내의 동작이지만, 장애 대응 관점에서는 alert가 Resolved되었다고 해서 시스템이 즉시 정상 상태로 복귀한 것이 아님을 인식해야 한다. 다만 alert resolved 시각은 Prometheus scrape/evaluation 및 Alertmanager 전달 지연을 포함하므로, 실제 replica 변화 시점과 몇 초~수십 초 차이가 날 수 있다.

부록. Alertmanager 규칙

항목	내용
알람명	PodinfoHighCPUUsage
조건	Pod별 CPU 사용률 > request 대비 80%
메트릭	container_cpu_usage_seconds_total, kube_pod_container_resource_requests
for	1m
심각도	warning

항목	내용
알람명	PodinfoHpaMaxReplicasReached
조건	HPA current replicas ≥ max replicas
메트릭	kube_horizontalpodautoscaler_status_current_replicas, kube_horizontalpodautoscaler_spec_max_replicas
for	1m
심각도	warning

항목	내용
알람명	PodinfoCPUThrottlingHigh
조건	CFS throttled 비율 > 20%
메트릭	container_cpu_cfs_throttled_periods_total, container_cpu_cfs_periods_total
for	2m
심각도	warning