[Kubernetes] VPA vs HPA: 리소스 오토스케일링 최적화 전략 비교

Kubernetes VPA HPA를 처음 비교할 때 가장 헷갈리는 지점이 바로 “뭘 늘리는 거지?”였습니다. Replica(레플리카, Pod 개수)를 늘리는 건지, 아니면 Pod 하나가 먹는 CPU/Memory(메모리) 요청값을 바꾸는 건지요. 저도 처음엔 HPA(Horizontal Pod Autoscaler, 수평 Pod 오토스케일링)만 걸어두고 끝난 줄 알았는데, 실제로 운영해보니 Pod 수는 늘어나도 개별 Pod 요청값이 너무 작아서 계속 Throttling(스로틀링, CPU 제한으로 인한 성능 저하)이 나는 경우가 있더라고요. 반대로 VPA(Vertical Pod Autoscaler, 수직 Pod 오토스케일링)를 무턱대고 적용했다가 재시작 타이밍 때문에 서비스가 흔들리는 경험도 있었습니다.

그래서 이번 글에서는 Kubernetes VPA HPA를 비교 중심으로 정리해보겠습니다. 단순 개념 비교가 아니라, 오토스케일링 비교 관점에서 어떤 워크로드에 무엇이 맞는지, 그리고 리소스 최적화와 Pod 스케일링을 어떻게 나눠서 생각해야 하는지 실제 운영자 시선으로 풀어보겠습니다. 혹시 지금 클러스터에서 CPU는 남는데 응답 속도는 들쭉날쭉하고, 어떤 서비스는 OOMKilled(메모리 부족 종료)까지 난다면 이 주제가 꽤 중요하실 거예요.

HPA는 Pod 개수를, VPA는 Pod 자원 요청값을 조정한다는 차이를 한눈에 보여주는 개요 이미지입니다.

1. 왜 Kubernetes VPA HPA 비교가 중요한가

쉽게 말해 HPA는 옆으로 늘리는 방식이고, VPA는 위로 키우는 방식이에요. 둘 다 오토스케일링이긴 한데 해결하는 문제가 달라요. 여기서 중요한 포인트가 있어요. 트래픽이 몰릴 때 모든 문제가 Pod 개수 부족 때문에 생기는 건 아니거든요. 어떤 앱은 싱글 Pod당 메모리를 더 줘야 안정적이고, 어떤 앱은 그냥 복제본을 여러 개 띄우는 게 훨씬 낫다니까요.

• HPA: 평균 CPU 사용률이나 메모리, 혹은 Custom Metric(커스텀 메트릭), External Metric(외부 메트릭)을 기준으로 Replica 수를 조절해요.
• VPA: Pod의 requests/limits 같은 리소스 설정을 추천하거나 자동 조정합니다.
• 핵심 차이: HPA는 분산 처리에 강하고, VPA는 개별 Pod의 자원 부족 문제를 다루는 데 유리해요.

제가 직접 해보니 웹 애플리케이션처럼 상태가 거의 없고 수평 확장이 쉬운 경우에는 HPA가 훨씬 직관적이었어요. 반면 배치 작업이나 메모리 사용량이 시간이 지나면서 조금씩 커지는 워크로드는 VPA의 추천값이 꽤 도움이 됐습니다. 이거 진짜 편하더라고요. 다만 자동 적용은 신중해야 했어요.

2. 개념 정리: VPA vs HPA를 쉽게 말해보면

2-1. HPA는 언제 쓰나

HPA는 요청이 갑자기 몰리는 서비스에 잘 맞아요. 예를 들어 API 서버, 프론트엔드 백엔드, 이벤트 소비자를 여러 개 띄워 병렬 처리할 수 있는 구조라면 HPA가 기본 선택지가 되거든요. Metrics Server(메트릭 서버)나 Prometheus Adapter(프로메테우스 어댑터)와 함께 쓰는 경우가 많습니다.

• 장점: 빠르게 Replica를 늘려 트래픽을 분산할 수 있어요.
• 장점: 무상태(Stateless, 상태 비저장) 서비스에 특히 잘 맞습니다.
• 주의: 시작 시간이 긴 앱은 스케일 아웃이 늦게 체감될 수 있어요.

2-2. VPA는 언제 쓰나

VPA는 “이 Pod에 CPU 100m만 준 게 애초에 잘못된 거 아닌가?” 같은 상황에서 정말 빛을 봐요. 실제 사용량을 보고 requests를 추천해주기 때문에, 운영자가 감으로 자원값을 넣던 습관에서 벗어나는 데 정말 도움이 돼요. 처음엔 이게 뭔가 싶었는데 추천 모드부터 보기 시작하면 생각보다 실용적이더라고요.

• 장점: 과소 설정된 requests/limits를 바로잡는 데 좋아요.
• 장점: 장기적으로 노드 자원 낭비를 줄이는 리소스 최적화에 유리해요.
• 주의: 자원값 변경을 적용하는 과정에서 Pod 재시작이 개입될 수 있습니다.

2-3. 한눈에 보는 오토스케일링 비교

정리하면 HPA는 트래픽 대응, VPA는 자원 설정 보정에 가깝습니다. 둘 중 하나만 정답이라기보다 워크로드 성격에 따라 고르는 문제예요.

3. 실전 구현: HPA부터 적용해보겠습니다

실제로 써보니까 대부분 팀은 HPA부터 시작하는 편이 안정적이었어요. 이유가 간단해요. 애플리케이션을 재시작하지 않고도 Replica 수 조절로 대응 가능한 경우가 많기 때문입니다.

3-1. 전제 조건 확인

1. 클러스터에 Metrics Server가 있어야 해요.
2. Deployment에 requests 값이 어느 정도 합리적으로 들어가 있어야 합니다.
3. readinessProbe(레디니스 프로브)와 livenessProbe(라이브니스 프로브)가 정리되어 있으면 더 좋아요.

여기서 requests가 엉망이면 HPA 기준도 같이 흔들려버려요. 이 부분을 무시하고 들어가면 나중에 “왜 평균 CPU가 이상하지?” 하면서 삽질 좀 했습니다 ㅎㅎ

3-2. 샘플 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: demo-api
          image: nginx:stable
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          ports:
            - containerPort: 80

3-3. HPA 리소스 생성

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

kubectl apply -f deployment.yaml
kubectl apply -f hpa.yaml
kubectl get hpa
kubectl describe hpa demo-api-hpa

이 상태에서 부하 테스트를 걸면 평균 CPU 사용률을 기준으로 Replica가 늘어나요. 물론 바로 늘지 않는다고 당황하실 필요는 없습니다. 메트릭 수집 주기와 안정화 구간 때문에 약간의 시간차가 생기거든요.

Metrics Server에서 수집한 지표를 바탕으로 HPA가 Deployment Replica 수를 조정하는 구성 예시입니다.

4. 실전 구현: VPA는 추천 모드부터 시작하는 게 안전합니다

VPA는 개인적으로 처음부터 Auto 모드로 넣기보다 Recommendation(추천) 확인부터 시작하는 걸 권장해요. 저도 초반에는 자동 조정이 멋져 보여서 바로 적용하고 싶었는데, 운영 중 Pod 교체 타이밍을 무시하면 생각보다 거칠게 느껴질 수 있더라고요.

4-1. VPA 샘플 리소스

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: demo-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-api
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: demo-api
        controlledResources: ["cpu", "memory"]

kubectl apply -f vpa.yaml
kubectl describe vpa demo-api-vpa

updateMode: "Off"로 두면 자동 반영은 하지 않고 추천값 위주로 볼 수 있어요. 운영 초반에는 이 방식이 훨씬 덜 위험합니다.

4-2. 추천값을 어떻게 읽나

보통 운영자가 보는 포인트는 이렇습니다.

• 현재 requests가 실제 사용량보다 너무 작은가
• 메모리 사용 패턴이 일정한가, 피크가 큰가
• 권장값을 적용했을 때 노드 밀도(Node Density, 노드당 수용량)가 나빠지지 않는가

제가 직접 해보니 CPU는 HPA가 어느 정도 흡수해주는데, 메모리는 오히려 VPA 추천이 더 실무적으로 도움이 되는 경우가 많았어요. 특히 Java 계열이나 캐시가 붙은 워크로드는 순간 피크보다 장기 패턴을 보는 게 중요하더라고요.

5. 같이 쓰면 안 되는 건가요? 조합 전략이 핵심입니다

이 질문 정말 많이 나와요. 결론부터 말하면 무조건 같이 쓰면 안 된다는 아니에요. 다만 같은 CPU/메모리 지표를 기준으로 HPA와 VPA가 동시에 서로를 흔드는 구조는 피하는 게 좋습니다. 이건 운영해보면 왜 위험한지 금방 느껴져요.

즉, Pod 스케일링은 HPA가 맡고, VPA는 추천과 보정 역할로 두는 식이 현실적입니다. 특히 트래픽 기반 서비스라면 HPA를 메인으로 두고, VPA는 운영 관찰 도구처럼 활용하는 접근이 꽤 괜찮았어요.

HPA와 VPA를 함께 사용할 때 역할을 분리하는 권장 패턴과 충돌 위험 구간을 시각화한 이미지입니다.

6. ⚠️ 실제 운영에서 자주 만난 문제와 해결법

6-1. HPA가 안 늘어나는 문제

• 원인: Metrics Server 미설치 또는 메트릭 수집 실패
• 원인: requests 값이 비현실적이라 CPU 사용률 계산이 왜곡돼요
• 해결: kubectl top pod, kubectl describe hpa로 먼저 메트릭 상태 확인

kubectl top pod
kubectl describe hpa demo-api-hpa
kubectl get apiservices

저도 처음엔 애플리케이션 성능 문제인 줄 알고 로그만 뒤졌는데, 알고 보니 메트릭 자체가 비어 있던 적이 있었어요. 이런 건 진짜 허무합니다.

6-2. VPA 적용 후 Pod 재시작 때문에 놀라는 문제

• 원인: 자원값 변경을 적용하려면 기존 Pod 교체가 필요할 수 있거든요
• 해결: 먼저 추천 모드로 충분히 관찰하고, PDB(PodDisruptionBudget, Pod 중단 예산)와 롤링 업데이트 전략 점검
• 해결: 단일 Replica 서비스는 특히 조심해야 해요

여기서 중요한 포인트! 단일 Pod 서비스에 VPA 자동 적용은 생각보다 부담이 커요. 실제로 써보니까 “자원은 맞아졌는데 순간 끊김이 생겼네?” 같은 상황이 나올 수 있더라고요.

6-3. HPA와 VPA를 동시에 걸었더니 지표가 이상한 문제

• 원인: VPA가 requests를 바꾸면 HPA의 utilization 계산 기준도 달라질 수 있거든요
• 해결: HPA는 CPU 대신 QPS(Requests Per Second, 초당 요청 수)나 큐 길이 같은 Custom/External Metric 기반으로 분리 검토해요

이 부분은 문서만 읽으면 감이 잘 안 오는데, 운영 그래프를 보면 이해가 돼요. 기준점이 움직이는 상태에서 자동화 둘이 같이 판단하니 안정적이지 않더라고요.

7. 검증과 결과 확인: 무엇을 봐야 제대로 적용한 걸까

오토스케일링 비교는 설정 파일만 보고 끝내면 안 돼요. 검증 항목을 꼭 정해두셔야 합니다.

1. 부하 테스트 전후 평균 응답 시간 변화
2. Replica 증가 시 에러율 변화
3. OOMKilled 발생 여부
4. 노드 자원 사용률과 Bin Packing(빈 패킹, 노드 자원 배치 효율)
5. 스케일 아웃/인 빈도와 안정성

kubectl get hpa -w
kubectl get vpa
kubectl top pod
kubectl top node

제가 홈랩에서 테스트했을 때도, HPA만 걸어둔 서비스는 트래픽 대응은 빨랐지만 requests가 너무 작게 잡힌 컨테이너는 CPU 제한에 자주 걸렸어요. 반대로 VPA 추천을 반영하고 나니 자원 낭비는 줄고 불안정성도 꽤 줄었습니다. 드디어 됐다! 싶은 순간이 오긴 하더라고요. 물론 그 전에 requests 값과 메트릭 파이프라인 때문에 몇 번 헤맸습니다.

HPA와 VPA 적용 이후 Replica 변화, CPU/메모리 추이, 권장 자원값을 검증하는 모니터링 예시입니다.

8. 어떤 워크로드에 무엇이 맞나: 실무 선택 기준

• 웹/API 서버: HPA 우선. 빠른 Pod 스케일링이 중요해요.
• 배치 작업: VPA 추천이 유용할 수 있어요. 작업 특성상 개별 Pod 자원량이 중요하거든요.
• 메모리 민감 애플리케이션: VPA 추천으로 기준값 정리 후 신중히 반영
• 큐 소비자/워커: HPA를 큐 길이나 지연 시간 기반으로 설계하면 좋습니다.
• 단일 인스턴스성 서비스: VPA 자동 적용은 매우 조심해야 해요. 먼저 수동 조정 검토

결국 Kubernetes VPA HPA는 경쟁 관계라기보다 역할이 다른 도구예요. 리소스 최적화가 우선인지, 트래픽 분산이 우선인지부터 정해야 선택이 쉬워집니다.

9. 정리와 FAQ

정리하면, HPA는 서비스 확장성에, VPA는 자원 적정화에 강합니다. 저는 운영 초기에 HPA로 안정적인 Pod 스케일링 구조를 먼저 만들고, 그다음 VPA 추천으로 requests/limits를 보정하는 순서를 권장해요. 이 흐름이 가장 덜 아프고, 실수했을 때 되돌리기도 쉽습니다.

다음 글에서는 Cluster Autoscaler(클러스터 오토스케일러, 노드 수 자동 조절)까지 포함해서 노드 레벨 확장 전략도 다뤄볼 예정입니다. 이전 글에서 다룬 Ingress와 Observability(옵저버빌리티, 관측성) 구성이 되어 있으면 검증이 훨씬 수월해요.

워크로드 유형에 따라 VPA와 HPA를 어떻게 선택할지 빠르게 판단할 수 있는 요약 인포그래픽입니다.

자주 묻는 질문

• Q. 둘 중 하나만 써야 하나요?
  A. 아니에요. 다만 같은 CPU/메모리 기준으로 동시에 자동 제어하는 구성은 주의가 필요합니다.
• Q. 초보자는 무엇부터 시작하면 좋을까요?
  A. HPA부터 시작하고, VPA는 추천 모드로 관찰하는 접근이 가장 무난했어요.
• Q. 리소스 최적화 목적이면 바로 VPA Auto로 가도 되나요?
  A. 운영 중 서비스라면 추천값 검증 후 단계적으로 가는 쪽이 안전합니다.