쿠버네티스 HPA 완벽 가이드: 단순한 복제본 증설을 넘어 안정적인 스케일링으로

HPA의 작동 원리부터 VPA와의 충돌 방지, 그리고 프로덕션 환경에서 흔히 발생하는 '데스 스파이럴' 해결책까지

제가 운영 현장에서 목격한 가장 위험한 상황 중 하나는 VPA와 HPA를 동일한 리소스 메트릭으로 동시에 실행하는 경우였습니다. 이 설정은 서로의 계산식을 망가뜨려 리소스가 계속 줄어들다가 결국 서비스가 붕괴되는 이른바 ‘데스 스파이럴(Death Spiral)’ 피드백 루프에 빠질 수 있습니다 [3]. 자동화라는 이름 아래 무심코 설정한 옵션이 어떻게 시스템의 자멸을 초래하는지 지켜보는 것은 엔지니어로서 매우 뼈아픈 경험이었습니다.

HPA는 무상태 서비스의 트래픽 대응에 최적이지만, 정확한 리소스 요청(Requests) 설정과 메트릭 선택이 뒷받침되지 않으면 오히려 서비스 불안정성을 초래하는 양날의 검이 됩니다.

HPA(Horizontal Pod Autoscaler)란 무엇인가?

HPA는 메트릭을 기반으로 Pod의 복제본(Replica) 수를 자동으로 조정하는 컨트롤러입니다. 기본적으로 Kubernetes Metrics Server나 Prometheus 같은 외부 시스템을 통해 데이터를 수집하며, 현재 사용량을 설정된 타겟 값과 비교하여 Pod 수를 결정합니다 [1].

특히 HPA는 웹 서버나 API 서버처럼 상태를 가지지 않는 무상태(Stateless) 서비스에 가장 적합합니다.

“HPA is ideal for stateless services (like web or API servers) where increased traffic can be met by simply adding more pods” [1]

(HPA는 트래픽 증가 시 단순히 Pod를 추가하는 것만으로 대응이 가능한 웹이나 API 서버 같은 무상태 서비스에 이상적입니다.)

즉, HPA는 Pod의 수를 변경하여 서비스를 수평적으로 확장하며, Metrics Server를 통해 현재 사용량을 타겟 값과 비교해 작동합니다 [1].

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: my-app-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-app
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 60

성공적인 HPA 운영을 위한 핵심 설정 전략

단순히 HPA를 적용했다고 해서 안정성이 보장되지는 않습니다. 프로덕션 수준의 안정성을 확보하기 위해서는 다음과 같은 전략적 접근이 필요합니다.

리소스 요청(Requests)의 중요성

가장 먼저 짚어야 할 점은 Pod 스펙에 명확한 CPU 및 메모리 요청(Requests)과 제한(Limits)을 설정하는 것이 베스트 프랙티스라는 사실입니다 [1]. HPA는 ‘요청량 대비 사용량’의 퍼센트로 계산하기 때문에, Requests 설정이 부정확하면 스케일링 계산 자체가 왜곡됩니다.

변동성 제어와 메트릭 선택

트래픽의 일시적인 튀어오름(Spike)으로 인해 Pod가 급격히 늘었다 줄었다 하는 ‘Thrashing’ 현상을 방지해야 합니다. 이를 위해 다운스케일 안정화 윈도우(Downscale Stabilization Window)를 활용합니다. 기본값인 5분 설정을 통해 메트릭의 급격한 변동 영향을 완화하고 점진적으로 축소할 수 있습니다 [5].

또한, CPU 사용량만으로는 비즈니스 요구사항을 모두 충족할 수 없습니다. 애플리케이션의 특성에 맞는 커스텀 메트릭 도입을 고려하고, 임계값(Threshold)을 설정한 후 지속적인 모니터링과 튜닝을 병행해야 합니다.

spec:
 behavior:
 scaleDown:
 stabilizationWindowSeconds: 300 # 5분 동안 관찰 후 다운스케일 결정
 policies:
 - type: Percent
 value: 100
 periodSeconds: 15

HPA vs VPA: 어떤 것을 선택해야 하는가?

많은 엔지니어가 HPA와 VPA(Vertical Pod Autoscaler) 사이에서 고민합니다. 두 도구는 서로 다른 축(Axis)에서 작동하므로 목적에 따라 구분해서 사용해야 합니다.

• HPA (Horizontal): ‘복제본 수’를 늘리거나 줄이는 Out/In 확장 방식입니다 [2].
• VPA (Vertical): ‘개별 Pod의 리소스 크기(CPU/Memory Requests)’를 조정하는 Up/Down 확장 방식이며, 리소스 최적화(Right-sizing)를 수행합니다 [1, 2].

VPA는 예측 불가능한 리소스 요구량을 가진 상태 저장(Stateful) 앱이나 배치 작업, 혹은 단일 복제본으로 운영되어야 하는 워크로드에 유리합니다 [1]. 다만, VPA를 바로 적용하기보다는 ‘추천 모드(Recommendation-only)’를 통해 먼저 적정 사이즈를 파악하는 과정이 권장됩니다 [1].

주의: HPA 운영 시 빠지기 쉬운 함정과 안티패턴

실제 운영 환경에서 가장 위험한 안티패턴은 동일한 리소스 메트릭으로 HPA와 VPA를 동시에 사용하는 것입니다.

데스 스파이럴(Death Spiral)의 공포

VPA가 과거 사용량을 기반으로 요청량(Requests)을 낮추면, HPA 입장에서는 동일한 절대 사용량이라도 ‘요청량 대비 사용률(%)’이 올라간 것으로 인식합니다. 그러면 HPA는 Pod를 더 많이 띄우게 되고, 부하가 분산되면서 개별 Pod의 사용량은 다시 낮아집니다. 이를 본 VPA는 다시 요청량을 더 낮추는 악순환이 반복되며, 결국 서비스가 붕괴되는 ‘데스 스파이럴’이 발생합니다 [3].

메모리 메트릭의 함정

메모리를 스케일링 신호로 사용하는 것도 위험합니다. VPA는 메모리 누수와 정상적인 캐시 확장을 구분하지 못하는 ‘컨텍스트 부재’ 문제를 가지고 있기 때문입니다 [3].

“Think of memory as a sizing problem, not a scaling signal.” [4]

(메모리를 스케일링 신호가 아니라 사이징 문제로 생각하십시오.)

메모리는 스케일링 지표가 아니라 ‘사이징’ 문제로 접근해야 합니다. VPA 추천 모드로 적정량을 잡은 뒤, HPA는 CPU나 커스텀 메트릭에 반응하게 설계하는 것이 정석입니다 [4]. 또한, HPA는 반응형(Reactive) 도구이므로 급격한 트래픽 스파이크 시 대응 속도가 느릴 수 있다는 한계를 인지해야 합니다.

짚고 넘어갈 한계와 보완책

일부에서는 VPA가 자동으로 리소스를 최적화해주니 HPA 설정 시 Requests를 대충 잡아도 된다고 생각하지만, 이는 매우 위험합니다. 오히려 HPA의 계산식을 왜곡시켜 불안정한 스케일링을 초래합니다 [3].

또한 HPA가 모든 트래픽 문제를 해결해줄 것이라는 믿음 역시 경계해야 합니다. HPA의 느린 반응 속도를 보완하기 위해 사전 워밍업(Pre-warming)이나 버퍼 Pod 같은 추가적인 보완책이 필요할 수 있습니다 [4].

내가 정리한 Takeaways

• HPA의 핵심은 ‘정확한 Requests’와 ‘적절한 메트릭 선택’에 있다.
• 메모리는 스케일링 지표가 아닌 사이징 지표로 취급하라.
• HPA와 VPA의 동시 사용 시 메트릭 충돌(Death Spiral)을 반드시 경계하라.
• 무상태 서비스는 HPA, 상태 저장/배치 작업은 VPA가 적합하다.
• 자동화 도구에 전적으로 의존하기보다 지속적인 모니터링과 임계값 튜닝이 병행되어야 한다.

단순히 YAML 파일에 HPA 설정을 추가하는 것이 자동화의 끝은 아닙니다. 인프라의 특성과 애플리케이션의 리소스 소비 패턴을 깊이 이해하고 관찰하는 과정이 선행될 때, 비로소 진정한 의미의 ‘탄력적인 인프라’를 구축할 수 있습니다.

---

참고 자료 (References)

1. [ksolves.com] Kubernetes Autoscaling: HPA vs. VPA vs. Cluster Autoscaler — https://www.ksolves.com/blog/devops/kubernetes-autoscaling-hpa-vs-vpa-vs-cluster-autoscaler 2. [gardener.cloud] Shoot Pod Autoscaling Best Practices | Gardener — https://gardener.cloud/docs/guides/applications/shoot-pod-autoscaling-best-practices 3. [scaleops.com] Kubernetes VPA: Architecture, Limitations & Best Practices (2026) — https://scaleops.com/blog/kubernetes-vpa 4. [scaleops.com] Kubernetes HPA: Use Cases, Limitations & Best Practices — https://scaleops.com/blog/kubernetes-hpa 5. [kubernetes.io] Horizontal Pod Autoscaling – Kubernetes — https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/

관련 글 추천

• https://infobuza.com/2026/06/03/20260603-av9d99/
• https://infobuza.com/2026/06/03/20260603-dvj5by/

FAQ

HPA와 VPA의 가장 큰 차이점은 무엇인가요?

HPA(Horizontal Pod Autoscaler)는 Pod의 복제본 수를 늘리거나 줄이는 수평적 확장 방식이며, VPA(Vertical Pod Autoscaler)는 개별 Pod의 리소스 크기(CPU/Memory Requests)를 조정하는 수직적 확장 방식입니다.

HPA를 사용할 때 리소스 요청(Requests) 설정이 왜 중요한가요?

HPA는 '요청량 대비 사용량'의 퍼센트로 스케일링을 계산하기 때문에, Requests 설정이 부정확하면 스케일링 계산 자체가 왜곡되어 서비스 불안정성을 초래할 수 있습니다.

'데스 스파이럴(Death Spiral)' 현상이란 무엇이며 왜 발생하나요?

동일한 리소스 메트릭으로 HPA와 VPA를 동시에 사용할 때 발생하는 악순환입니다. VPA가 요청량을 낮추면 HPA는 사용률이 높아진 것으로 인식해 Pod를 늘리고, 이로 인해 다시 개별 Pod 사용량이 낮아지면 VPA가 요청량을 더 낮추는 과정이 반복되어 결국 서비스가 붕괴됩니다.

메모리를 HPA의 스케일링 지표로 사용하는 것이 위험한 이유는 무엇인가요?

VPA는 메모리 누수와 정상적인 캐시 확장을 구분하지 못하는 컨텍스트 부재 문제가 있기 때문입니다. 따라서 메모리는 스케일링 신호가 아닌 '사이징' 문제로 접근해야 합니다.

트래픽의 일시적인 급증으로 인해 Pod가 빈번하게 생성 및 삭제되는 'Thrashing' 현상을 어떻게 방지하나요?

다운스케일 안정화 윈도우(Downscale Stabilization Window)를 활용하면 됩니다. 예를 들어 기본값인 5분 설정을 통해 메트릭의 급격한 변동 영향을 완화하고 점진적으로 Pod 수를 축소할 수 있습니다.