Kubernetes HPA 메트릭 설계

도입

HPA를 처음 적용할 때 CPU 기준으로 시작하는 경우가 많다. 문제는 사용자 체감 품질은 CPU와 항상 비례하지 않는다는 점이다. 큐 적체, 외부 API 지연, DB connection saturation처럼 CPU로 잡히지 않는 병목이 실제 장애를 만든다.

이 글은 "무엇을 스케일 기준으로 삼을 것인가"를 서비스 관점에서 결정하는 절차를 정리한다.

Kubernetes HPA 메트릭 설계 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

CPU 기반 HPA만 운영할 때 발생하는 대표 문제:

요청량은 늘었는데 I/O wait 중심 병목이라 scale-out이 늦다.
트래픽 급증 시 큐 적체가 먼저 터지지만 CPU는 안정적으로 보여 대응이 지연된다.
scale-out 후에도 p95 latency가 개선되지 않아 과잉 확장만 일어난다.
min/max replica 값을 경험적으로만 정해 비용이 불안정하다.

핵심은 "사용자 영향을 먼저 반영하는 메트릭"을 스케일 트리거로 채택하는 것이다.

핵심 개념

메트릭 타입	예시	적합한 서비스
Resource Metrics	CPU, Memory	단순 stateless API
Custom Metrics	request_per_pod, queue_depth	백그라운드 작업 처리
External Metrics	Kafka lag, SQS depth	이벤트 소비 서비스
SLO-based	p95 latency, error budget burn	사용자 체감 민감 서비스

실무에서는 단일 메트릭보다 "주 메트릭 + 보호 메트릭" 조합이 안전하다. 예: queue depth로 확장하되 error rate 급등 시 승격을 멈춘다.

코드 예시 1: HPA(v2) with custom metric

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 30
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 20
          periodSeconds: 60
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "40"

코드 예시 2: 메트릭 품질 검증 쿼리(PromQL)

# 스케일 기준 후보: pod당 초당 요청
sum(rate(http_server_requests_total{job="api",status!~"5.."}[2m]))
/
count(kube_pod_status_ready{namespace="prod",condition="true",pod=~"api-.*"})

# 보호 메트릭: p95 latency
histogram_quantile(
  0.95,
  sum(rate(http_server_request_duration_seconds_bucket{job="api"}[5m])) by (le)
)

아키텍처 흐름

Mermaid diagram rendering...

트레이드오프

커스텀 메트릭 기반 스케일은 정확도가 높지만 운영 복잡도가 증가한다.
scale-up을 민감하게 두면 급증 대응은 좋지만 비용 변동성이 커진다.
scale-down을 보수적으로 두면 비용은 늘지만 안정성은 높아진다.

정리

HPA는 쿠버네티스 기능이 아니라 서비스 정책이다. CPU만 보지 말고 사용자 영향 지표를 기준으로 삼아야 실제 품질 개선으로 이어진다. 먼저 한 서비스에서 메트릭 품질을 검증한 뒤 표준으로 확장하는 것이 가장 안전하다.

이미지 출처

Cover: source link
License: Public domain / Author: Unknown author Unknown author
Note: Wikimedia Commons 무료 라이선스 이미지를 다운로드 후 1600px 기준 JPG로 최적화했습니다.

도입