Kubernetes 자동 스케일링 대결: HPA vs. VPA vs. Karpenter vs. KEDA

Source: Dev.to

두 단계의 스케일링

특정 도구를 분석하기 전에, 쿠버네티스 스케일링이 두 개의 별도 레이어에서 이루어진다는 점을 이해하는 것이 중요합니다.

• Pod 스케일링 (애플리케이션 레이어): Pod 복제본 수나 개별 Pod의 크기를 조정합니다. 이는 애플리케이션 용량과 관련됩니다.
• Node 스케일링 (인프라 레이어): 클러스터 내 가상 머신(노드) 수를 조정해 Pod를 수용합니다. 이는 컴퓨팅 용량과 관련됩니다.

Pod를 스케일링했지만 배치할 노드가 없으면 스케일링이 실패합니다(Pending Pod). 반대로 노드를 스케일링했지만 Pod가 이를 활용하지 못하면 비용만 낭비하게 됩니다. 스케일링의 핵심은 이 두 레이어를 동기화하는 데 있습니다.

레이어 1: Pod‑레벨 스케일링

1. Horizontal Pod Autoscaler (HPA)

작동 방식
HPA는 메트릭 서버(또는 커스텀 메트릭 API)에게 정해진 간격(기본 15 초)으로 질의합니다. 현재 메트릭 값(예: CPU 사용률)을 HorizontalPodAutoscaler 리소스에 정의된 목표값과 비교합니다. 현재 사용량이 목표치를 초과하면 HPA는 필요한 복제본 수를 계산하고 Deployment 또는 StatefulSet의 scale 서브리소스를 업데이트합니다.

수식

강점

• 네이티브 & 간단: 기본 CPU/Memory 스케일링에 외부 CRD가 필요 없습니다.
• 복원력: 트래픽 급증 시 더 많은 인스턴스로 부하를 분산해 처리합니다.
• 무중단: 스케일 아웃 시 기존 Pod를 재시작할 필요가 없습니다.

약점

• 콜드 스타트: HPA는 반응형입니다. 애플리케이션 부팅에 ~60 초가 걸리는 경우(JVM 등), 급격한 트래픽 급증 시 스케일 아웃이 늦어질 수 있습니다.
• 스래싱: stabilizationWindowSeconds 설정이 없으면 HPA가 빠르게 상하 스케일링을 반복해 불안정해질 수 있습니다.
• 노드 용량 제한: HPA는 Pod만 스케일링합니다. 클러스터가 포화 상태이면 Pending Pod이 생성되고 스케일링이 멈춥니다.

추천 대상
상태 비저장 마이크로서비스, 웹 서버, 부하가 고르게 분산되는 애플리케이션.

2. Vertical Pod Autoscaler (VPA)

작동 방식
VPA는 Pod의 실제 사용량에 맞춰 CPU와 메모리 요청/제한을 자동으로 조정합니다. 세 가지 구성 요소로 이루어집니다.

• Recommender: 과거 리소스 사용량을 모니터링합니다.
• Updater: 새로운 리소스 제한이 필요한 Pod를 퇴출시킵니다.
• Admission Controller: Pod 생성 시 올바른 리소스 요청을 주입합니다.

VPA 모드

강점

• 정확한 사이징: 인간의 실수를 보정합니다. 개발자는 흔히 “RAM 2 GB 줘”처럼 추측하지만 VPA는 실제 사용량에 기반해 교정합니다.
• 레거시 앱: 수평 확장이 어려운 모놀리식 애플리케이션에 적합합니다(수평 스케일링 불가).

약점

• 중단: Pod 리소스를 변경하려면 재시작이 필요하므로, Pod Disruption Budget(PDB)과 고가용성을 충분히 갖추지 않으면 다운타임이 발생합니다.
• HPA와 충돌: 동일한 메트릭(CPU/Memory)에 대해 HPA와 VPA를 동시에 사용할 수 없습니다. HPA는 Pod를 추가하고 VPA는 Pod 제한을 늘리려 하기 때문에 서로 경쟁합니다.

추천 대상
Stateful 워크로드, 모놀리식 애플리케이션, “골디락스” 분석(리포트 작성을 위해 Off 모드로 VPA 사용).

3. KEDA (Kubernetes Event‑Driven Autoscaling)

작동 방식
KEDA는 컨트롤러와 오퍼레이터를 설치해 HPA용 “Metrics Server” 역할을 수행합니다. ScaledObject에 트리거(예: Kafka 토픽 지연, SQS 큐 깊이, Prometheus 쿼리)를 지정하면 KEDA가 해당 이벤트 소스를 모니터링합니다.

• 0 → 1 스케일링: 이벤트가 없으면 배포를 0으로 스케일 다운해 비용을 절감합니다. 이벤트가 발생하면 1로 스케일 업합니다.
• 1 → N 스케일링: Pod가 실행 중일 때 KEDA는 이벤트 메트릭을 HPA에 전달해 1에서 N으로 스케일링합니다.

강점

• Scale‑to‑Zero: 개발 환경이나 간헐적인 배치 처리에 큰 비용 절감 효과.
• 사전 스케일링: CPU 급증 전에 큐 길이 기반으로 스케일링합니다.
• 풍부한 에코시스템: 50개 이상의 스케일러 지원(Azure Service Bus, Redis, Postgres, AWS SQS 등).

약점

• 복잡성: 추가 CRD와 컨트롤러가 필요합니다.
• 지연: 0 → 1 스케일링 시 Pod가 스케줄되고 부팅되는 콜드 스타트 패널티가 발생합니다.

추천 대상
이벤트‑드리븐 아키텍처, 큐 기반 워커, 쿠버네티스 위 서버리스 스타일 워크로드.

레이어 2: Node‑레벨 스케일링

4. Cluster Autoscaler (CA)

작동 방식
Cluster Autoscaler는 클라우드 제공자의 자동 스케일링 그룹(AWS ASG, Azure VMSS 등)과 연동하는 제어 루프입니다. 두 가지 상황을 확인합니다.

• Scale Up: 리소스 부족으로 Pending 상태인 Pod가 있나요? 있으면 클라우드 제공자에 노드 추가를 요청합니다.
• Scale Down: 활용도가 낮은 노드가 있나요? 있으면 Pod를 다른 노드로 이동시키고 빈 노드를 종료합니다.

강점

• 성숙하고 안정적: 수년간 프로덕션에서 검증된 솔루션.
• 클라우드 중립적: AWS, GCP, Azure 등 대부분의 클라우드에서 최소 설정만으로 동작합니다.

약점

• 느림: 클라우드 제공자의 노드 그룹에 의존합니다. 노드 부팅은 클라우드 API 호출, EC2 인스턴스 생성, 클러스터 등록, 이미지 풀링 등을 포함해 2–5 분 정도 소요될 수 있습니다.
• 경직성: 미리 정의된 “Node Group” 기반으로만 스케일링합니다. 예를 들어 GPU 노드가 필요하지만 일반 노드 그룹만 있으면, 별도로 GPU 전용 그룹을 사전에 구성하지 않는 한 CA가 GPU 노드를 프로비저닝하지 못합니다.
• 비용 비효율: 가장 비용 효율적인 인스턴스 타입을 자동으로 탐색하지 않으며, 기존 그룹 내에서만 노드를 추가·제거합니다.

(기사에서 Karpenter에 대한 논의는 일부만 포함되어 있어 여기서는 생략했습니다.)