쿠버네티스 클러스터 오토스케일링 전략: HPA, VPA, CA를 활용한 리소스 효율화

쿠버네티스 클러스터에서 겪는 리소스 낭비 문제를 해결하고 싶으신가요? HPA, VPA, CA를 활용한 오토스케일링 전략으로 비용 효율적인 클라우드 인프라를 구축하는 실질적인 방법을 소개합니다.

쿠버네티스 환경을 운영하면서 리소스 낭비나 갑작스러운 트래픽 증가로 인한 서비스 장애 문제를 겪고 계신가요? 클라우드 비용은 예측하기 어렵게 늘어나고, 반대로 서비스는 느려지거나 멈추는 상황은 많은 개발자와 운영자들에게 큰 골칫거리입니다. 이러한 문제의 핵심은 애플리케이션의 리소스 요구사항이 시간에 따라 끊임없이 변한다는 점입니다. 고정된 리소스 할당으로는 유연하게 대처하기 어렵습니다.

다행히 쿠버네티스는 이러한 동적인 환경에 대응할 수 있는 강력한 오토스케일링(Autoscaling) 기능을 제공합니다. 이 글에서는 쿠버네티스 클러스터의 리소스 효율성을 극대화하고 안정적인 서비스 운영을 돕는 세 가지 핵심 오토스케일링 도구인 HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler), 그리고 CA(Cluster Autoscaler)에 대해 심층적으로 다루고자 합니다. 각 도구의 원리와 활용법을 이해하고, 이들을 효과적으로 조합하여 클라우드 인프라 비용을 최적화하고 서비스 품질을 향상시키는 실질적인 방법을 제시합니다.

---

📑 목차

• HPA(Horizontal Pod Autoscaler) 이해와 활용: Pod 수평 확장 전략
• HPA의 작동 원리 및 주요 지표
• HPA 설정 예시
• VPA(Vertical Pod Autoscaler) 이해와 활용: Pod 리소스 최적화 전략
• VPA의 필요성과 작동 방식
• VPA 모드와 설정 예시
• CA(Cluster Autoscaler) 이해와 활용: 클러스터 노드 확장 전략
• CA의 역할과 작동 방식
• CA 설정 고려사항
• HPA, VPA, CA 조합 전략 및 상호작용
• 각 오토스케일러 역할 비교
• 시나리오별 조합 전략
• 오토스케일링 구현 시 고려할 점 및 모범 사례
• 1. 정교한 모니터링 시스템 구축
• 2. 애플리케이션 설계 최적화
• 3. 안전한 배포 전략과 PDB(Pod Disruption Budget) 활용
• 4. 스케일링 정책 튜닝
• 5. 비용 최적화 고려
• 결론

Image by Niko_Shogol on Pixabay

HPA(Horizontal Pod Autoscaler) 이해와 활용: Pod 수평 확장 전략

HPA(Horizontal Pod Autoscaler)는 이름 그대로 Pod의 수를 수평적으로 조절하여 애플리케이션의 부하에 대응하는 쿠버네티스 컨트롤러입니다. 특정 지표(예: CPU 사용률, 메모리 사용률, 커스텀 메트릭)가 설정한 임계값을 초과하거나 미달할 때, Pod의 복제본(replica) 수를 자동으로 늘리거나 줄여줍니다. 이를 통해 트래픽 변동이 심한 웹 서비스나 Stateless 애플리케이션의 안정성을 확보하고 리소스 효율성을 높일 수 있습니다.

HPA의 작동 원리 및 주요 지표

HPA는 주로 CPU 사용률 또는 메모리 사용률을 기반으로 작동합니다. 예를 들어, 웹 서비스의 CPU 사용률이 50%를 초과하면 Pod 수를 늘리고, 20% 미만으로 떨어지면 Pod 수를 줄이는 식입니다. HPA는 대상 워크로드(Deployment, ReplicaSet 등)의 메트릭을 주기적으로 모니터링하고, 설정된 목표 값과 비교하여 필요한 Pod 수를 계산합니다. 계산된 Pod 수가 현재 Pod 수와 다르면, 해당 워크로드의 스케일(scale)을 업데이트하여 Pod 수를 조절합니다.

또한, HPA는 Prometheus와 같은 모니터링 시스템과 연동하여 QPS(초당 쿼리 수), Latency(응답 지연 시간) 등 커스텀 메트릭(Custom Metrics)이나 외부 메트릭(External Metrics)을 기반으로 스케일링할 수도 있습니다. 이는 더욱 정교하고 애플리케이션 특화된 오토스케일링을 가능하게 합니다.

HPA 설정 예시

아래는 CPU 사용률을 기준으로 Pod 수를 조절하는 HPA 설정 예시입니다. 이 설정은 `nginx-deployment`라는 이름의 Deployment에 대해 CPU 사용률이 50%를 초과하면 Pod를 최대 10개까지 늘리고, 50% 미만으로 떨어지면 최소 1개까지 줄이도록 합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

이 외에도 `periodSeconds`, `stabilizationWindowSeconds`와 같은 스케일링 정책(Policy)을 설정하여 너무 잦은 스케일링을 방지하고 안정성을 높일 수 있습니다. 예를 들어, `stabilizationWindowSeconds`를 설정하면 스케일 다운 결정을 내리기 전에 일정 시간 동안 메트릭이 낮은 상태를 유지해야만 실제로 스케일 다운이 발생합니다.

---

VPA(Vertical Pod Autoscaler) 이해와 활용: Pod 리소스 최적화 전략

VPA(Vertical Pod Autoscaler)는 Pod의 리소스(CPU, Memory) 요청(requests)과 제한(limits)을 수직적으로 자동으로 조절하여 리소스 낭비를 줄이고 애플리케이션 성능을 최적화하는 도구입니다. HPA가 Pod의 수를 조절한다면, VPA는 개별 Pod가 사용하는 리소스 양을 조절하여 "알맞은 옷"을 입혀주는 역할을 합니다.

VPA의 필요성과 작동 방식

애플리케이션 개발 단계에서 Pod에 할당할 최적의 CPU와 메모리 값을 정확히 예측하기란 매우 어렵습니다. 너무 적게 할당하면 OOMKilled(Out Of Memory Killed)와 같은 문제로 서비스 장애가 발생할 수 있고, 너무 많이 할당하면 클라우드 비용 낭비로 이어집니다. VPA는 이러한 문제를 해결하기 위해 Pod의 과거 및 현재 리소스 사용량 데이터를 분석하여 최적의 리소스 권장 값을 제시하거나, 심지어 자동으로 적용합니다.

VPA는 크게 세 가지 구성 요소로 이루어집니다:

• Recommender: Pod의 과거 리소스 사용량 데이터를 수집하고 분석하여 최적의 `requests` 및 `limits` 값을 계산합니다.
• Updater: Recommender가 계산한 값을 바탕으로 Pod의 리소스 설정을 업데이트합니다. 이 과정에서 Pod가 재시작될 수 있습니다.
• Admission Controller: 새로운 Pod가 생성될 때 Recommender의 권장 값을 기반으로 리소스 설정을 주입합니다.

VPA 모드와 설정 예시

VPA는 다양한 업데이트 모드를 제공하여 유연하게 사용할 수 있습니다:

• Off: VPA는 리소스를 추천만 하고, Pod에 적용하지 않습니다. 모니터링 및 분석 목적으로 유용합니다.
• Recommender: Pod의 리소스를 자동으로 업데이트하지 않고, VPA 오브젝트의 상태(status) 필드에 권장 값을 표시합니다. 관리자가 수동으로 적용할 수 있습니다.
• Initial: Pod가 처음 생성될 때만 권장 값을 적용합니다. 이후에는 업데이트하지 않습니다.
• Auto: Pod가 생성될 때 권장 값을 적용하고, 실행 중에도 필요에 따라 Pod를 재시작하여 리소스 설정을 업데이트합니다. 가장 적극적인 모드입니다.

아래는 `my-app-deployment`에 대해 VPA를 `Auto` 모드로 설정하는 예시입니다.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-app-deployment
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 2
          memory: 4Gi
        controlledResources: ["cpu", "memory"]

이 설정은 `my-app-deployment`의 모든 컨테이너에 대해 CPU는 최소 100m, 최대 2코어, 메모리는 최소 50Mi, 최대 4Gi 범위 내에서 자동으로 조절하도록 합니다. `updateMode: "Auto"`는 VPA가 필요에 따라 Pod를 재시작하여 리소스 설정을 업데이트할 수 있음을 의미합니다.

---

CA(Cluster Autoscaler) 이해와 활용: 클러스터 노드 확장 전략

CA(Cluster Autoscaler)는 쿠버네티스 클러스터의 노드(Node) 수를 자동으로 조절하는 도구입니다. HPA와 VPA가 Pod 수준에서 리소스를 관리한다면, CA는 클러스터 전체의 Node 용량을 관리하여 클러스터 인프라 비용을 최적화하고 애플리케이션의 가용성을 보장합니다.

CA의 역할과 작동 방식

클러스터에 Node가 부족하여 새로 스케줄링될 Pod가 "Pending" 상태에 머무르는 경우가 발생할 수 있습니다. 반대로, Node에 할당된 Pod가 적어 Node 리소스가 낭비되는 상황도 있습니다. CA는 이러한 상황을 감지하여 다음과 같이 작동합니다.

• 스케일 업(Scale Up): 스케줄링할 수 있는 Node가 부족하여 Pending 상태인 Pod가 발생하면, CA는 클라우드 공급자(AWS EC2, Google Cloud GKE, Azure AKS 등)의 API를 호출하여 새로운 Node를 프로비저닝하고 클러스터에 추가합니다.
• 스케일 다운(Scale Down): 일정 시간 동안 Node의 리소스 사용률이 매우 낮게 유지되거나, Node의 Pod들을 다른 Node로 안전하게 옮길 수 있는 경우, CA는 해당 Node를 클러스터에서 제거합니다. 이때, Node에 있는 Pod들이 다른 Node로 안전하게 이동할 수 있도록 PDB(Pod Disruption Budget)를 고려합니다.

CA는 각 클라우드 공급자의 오토스케일링 그룹(예: AWS Auto Scaling Group, GKE Node Pool)과 통합되어 작동하며, 미리 설정된 Node 그룹의 최소 및 최대 크기 범위 내에서 Node 수를 조절합니다.

CA 설정 고려사항

CA는 클라우드 공급자에 따라 설치 및 설정 방식이 다를 수 있습니다. 일반적으로 클라우드 인프라에 CA를 배포하고, CA가 관리할 Node 그룹을 지정하며, Node 그룹의 최소/최대 Node 수를 설정합니다.

CA를 효과적으로 사용하기 위한 몇 가지 고려사항은 다음과 같습니다:

• Node 그룹의 최소/최대 크기: 예기치 않은 부하에 대비할 수 있도록 충분한 최대 크기를 설정하고, 비용 효율성을 위해 적절한 최소 크기를 유지합니다.
• Node 종료 시 Pod 처리: CA는 Node를 종료하기 전에 해당 Node의 Pod들을 다른 Node로 이동시키려고 시도합니다. 이때 PDB를 설정하여 필수 Pod들이 한 번에 너무 많이 종료되지 않도록 보호할 수 있습니다.
• Pod의 리소스 요청(requests): CA는 Pod의 `requests` 값을 기반으로 Node의 가용 리소스를 계산합니다. `requests` 값이 실제 사용량과 너무 동떨어져 있으면 비효율적인 스케일링이 발생할 수 있으므로, VPA를 통해 `requests` 값을 최적화하는 것이 중요합니다.

---

Image by peteranta on Pixabay

HPA, VPA, CA 조합 전략 및 상호작용

세 가지 오토스케일링 도구는 각각 다른 계층에서 작동하며, 서로 보완적인 관계를 가집니다. 이들을 조합하여 사용하면 더욱 강력하고 지능적인 오토스케일링 전략을 구축할 수 있습니다.

각 오토스케일러 역할 비교

아래 표는 HPA, VPA, CA의 주요 특징을 비교한 것입니다.

특징	HPA (Horizontal Pod Autoscaler)	VPA (Vertical Pod Autoscaler)	CA (Cluster Autoscaler)
대상	Pod의 복제본(replica) 수	개별 Pod의 CPU/Memory 리소스 요청(requests) 및 제한(limits)	클러스터의 Node 수
목적	서비스 부하에 따른 Pod 수평 확장/축소	Pod 리소스 최적화 및 낭비 감소	클러스터 인프라 용량 관리 및 비용 효율화
작동 방식	CPU/Memory 사용률, 커스텀/외부 메트릭 기반 Pod 수 조절	Pod 리소스 사용량 분석, 최적의 requests/limits 권장 또는 자동 적용	Pending Pod 감지 시 Node 추가, 저활용 Node 감지 시 Node 제거
장점	트래픽 급증에 유연하게 대응, 고가용성 유지	정확한 리소스 할당, 비용 낭비 최소화, OOMKilled 방지	클러스터 인프라 비용 절감, 필요한 시점에 Node 자동 공급
단점	Pod 리소스 최적화 불가, Node 부족 시 Pending 발생 가능	Pod 재시작 필요성, HPA와 CPU/Memory 메트릭 충돌 가능성	스케일링 지연, Node 종료 시 Pod 이동 고려 필요, PDB 필요

시나리오별 조합 전략

각 오토스케일러는 서로 다른 문제를 해결하므로, 대부분의 프로덕션 환경에서는 이들을 함께 사용하는 것이 가장 효과적입니다.

• HPA + CA: 가장 일반적인 조합입니다. HPA가 애플리케이션 부하에 따라 Pod 수를 늘리면, 더 많은 Pod를 수용하기 위해 CA가 Node를 추가합니다. 반대로 부하가 줄어 Pod 수가 감소하고 Node가 비효율적으로 사용되면 CA가 Node를 줄여 비용을 절감합니다. 이때 Pod의 `requests` 값이 잘 설정되어야 CA가 올바르게 작동할 수 있습니다.
• VPA + CA: VPA가 Pod의 리소스를 최적화하면, CA는 Node의 가용 리소스를 더욱 효율적으로 사용하여 더 많은 Pod를 Node에 배치하거나, 낭비되는 Node를 줄일 수 있습니다. 이는 특히 리소스 요구사항이 불규칙하고 예측하기 어려운 Stateful 애플리케이션에 유용합니다.
• HPA + VPA + CA: 완벽한 트리플 오토스케일링 조합입니다. VPA는 Pod의 리소스 할당을 최적화하여 Node 활용률을 높이고, HPA는 애플리케이션 부하에 따라 Pod 수를 유연하게 조절합니다. 마지막으로 CA는 이 모든 Pod의 요구사항을 충족시키기 위해 Node 수를 동적으로 관리합니다.
  • 주의사항: VPA와 HPA를 함께 사용할 때, HPA가 CPU/Memory 사용률 기반으로 스케일링하도록 설정되어 있다면 충돌이 발생할 수 있습니다. VPA가 Pod의 CPU/Memory `requests`를 변경하면 HPA의 메트릭 계산에 영향을 줄 수 있기 때문입니다. 이 문제를 해결하려면 HPA는 커스텀 메트릭(예: QPS, Latency)을 기반으로 스케일링하고, VPA는 리소스 `requests`/`limits`를 담당하도록 역할을 분리하는 것이 좋습니다.

---

Image by lil_foot_ on Pixabay

오토스케일링 구현 시 고려할 점 및 모범 사례

쿠버네티스 오토스케일링은 클러스터 운영의 필수 요소이지만, 단순한 설정만으로는 최대의 효과를 얻기 어렵습니다. 다음은 오토스케일링을 성공적으로 구현하기 위한 몇 가지 고려사항과 모범 사례입니다.

1. 정교한 모니터링 시스템 구축

오토스케일링은 정확한 지표를 기반으로 작동합니다. Prometheus, Grafana와 같은 도구를 활용하여 클러스터, Node, Pod, 컨테이너 수준의 CPU, Memory, 네트워크, 디스크 I/O, 애플리케이션별 커스텀 메트릭(QPS, 에러율 등)을 지속적으로 모니터링해야 합니다. 이를 통해 오토스케일링이 의도대로 작동하는지 검증하고, 필요한 경우 설정 값을 튜닝할 수 있습니다.

2. 애플리케이션 설계 최적화

• Stateless 애플리케이션: HPA를 통한 수평 확장에 가장 적합합니다. Pod 추가/제거 시 상태 유실 문제가 발생하지 않도록 설계합니다.
• Graceful Shutdown: Pod가 종료될 때 현재 처리 중인 요청을 완료하고 정상적으로 종료될 수 있도록 애플리케이션을 설계해야 합니다. 이는 특히 스케일 다운 시 서비스 중단을 방지하는 데 중요합니다.
• 리소스 `requests` 및 `limits` 설정: VPA를 사용하지 않더라도, 모든 Pod에 대해 합리적인 `requests`와 `limits`를 설정하는 것이 중요합니다. 이는 쿠버네티스 스케줄러가 Pod를 적절한 Node에 배치하고, Node의 리소스가 과도하게 사용되는 것을 방지하는 데 도움을 줍니다.

3. 안전한 배포 전략과 PDB(Pod Disruption Budget) 활용

오토스케일링은 Pod나 Node의 생성 및 종료를 동반하므로, 서비스 중단이 발생할 수 있습니다. PDB(Pod Disruption Budget)를 설정하여 특정 워크로드의 최소 가용 Pod 수를 보장함으로써, Node 드레인(drain)이나 Pod 축소 시 서비스의 안정성을 확보할 수 있습니다. 또한 Canary, Blue/Green과 같은 배포 전략을 통해 변경 사항이 서비스에 미치는 영향을 최소화해야 합니다.

4. 스케일링 정책 튜닝

HPA의 `stabilizationWindowSeconds`나 CA의 스케일 다운 지연 시간 등 스케일링 정책을 서비스의 특성에 맞게 튜닝해야 합니다. 너무 공격적인 스케일링은 불필요한 비용 증가나 서비스 불안정을 초래할 수 있고, 너무 보수적인 스케일링은 부하 증가에 제때 대응하지 못하게 할 수 있습니다.

5. 비용 최적화 고려

오토스케일링의 궁극적인 목표 중 하나는 비용 최적화입니다. CA를 통해 불필요한 Node를 줄이고, VPA를 통해 Pod의 리소스 낭비를 막는 것은 직접적인 비용 절감으로 이어집니다. 또한, 예측 가능한 워크로드의 경우 Spot Instance와 같은 저렴한 클라우드 리소스를 활용하고, CA가 이를 관리하도록 설정하여 비용을 더욱 절감할 수 있습니다.

---

결론

쿠버네티스 클러스터 운영에서 오토스케일링은 선택이 아닌 필수 요소입니다. HPA, VPA, CA는 각각 Pod의 수평 확장, Pod의 리소스 최적화, 그리고 클러스터 Node의 수직 확장을 담당하며, 이들을 유기적으로 조합할 때 비로소 진정한 리소스 효율화와 서비스 안정성을 달성할 수 있습니다. 동적인 클라우드 환경에서 예측 불가능한 부하에 유연하게 대응하고, 동시에 클라우드 인프라 비용을 효과적으로 관리하는 열쇠는 바로 이 세 가지 오토스케일링 도구의 이해와 적절한 활용에 있습니다.

이 글에서 제시된 전략과 모범 사례들을 바탕으로 여러분의 쿠버네티스 클러스터가 더욱 견고하고 효율적으로 운영되기를 바랍니다. 지속적인 모니터링과 튜닝을 통해 여러분의 서비스에 최적화된 오토스케일링 전략을 찾아나가세요.

여러분은 어떤 오토스케일링 전략을 사용하고 계신가요? HPA, VPA, CA를 활용하면서 겪었던 경험이나 팁이 있다면 댓글로 공유해 주세요!

📌 함께 읽으면 좋은 글

• [클라우드 인프라] EKS AKS GKE 비교 분석: 클라우드 쿠버네티스 서비스 선택 가이드
• [클라우드 인프라] Terraform을 활용한 클라우드 인프라 자동화: AWS VPC 및 EC2 구축 실전 가이드
• [AI 머신러닝] RAG 기반 LLM 애플리케이션 개발: 외부 데이터 연동과 성능 최적화 전략

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.