[K8s] 트래픽 폭주에 대비하는 K8s 자동 확장 전략: HPA와 KEDA

728x90

이번 글에서는 K8s가 제공하는 자동 확장(Auto-Scaling) 메커니즘인 HPA(Horizontal Pod Autoscaler)와, 그 한계를 넘어선 이벤트 기반 확장 프레임워크 KEDA를 비교합니다.

1. HPA: CPU/메모리 기반의 기본 자동 확장

HPA는 K8s에 기본 내장된 오토스케일러입니다. 동작 원리는 직관적입니다.

metrics-server가 각 Pod의 CPU/메모리 사용량을 주기적으로 수집
HPA 컨트롤러가 목표치(target)와 비교 (예: "CPU 평균 50% 유지")
목표치를 초과하면 Pod를 늘리고(Scale-Out), 밑돌면 줄입니다(Scale-In)

# HPA 설정 예시
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50   # CPU 평균 50% 유지

HPA의 한계

리액티브(Reactive) 방식: 이미 CPU가 올라간 후에야 반응합니다. 트래픽 스파이크에 대한 대응이 늦을 수 있습니다.
메트릭 제한: 기본적으로 CPU와 메모리만 기준으로 삼습니다. "카프카 큐에 메시지가 1만 개 쌓였으니 컨슈머를 늘려라"는 판단이 불가능합니다.
0→1 스케일링 불가: 최소 1개의 Pod가 항상 떠 있어야 합니다. 트래픽이 없는 야간에도 리소스를 소비합니다.

2. KEDA: 이벤트 기반의 차세대 오토스케일러

KEDA(Kubernetes-based Event Driven Autoscaler)는 HPA의 한계를 극복하기 위해 등장한 CNCF 프로젝트입니다. 핵심 차이는 "무엇을 기준으로 스케일링하는가"입니다.

기준	HPA	KEDA
스케일링 트리거	CPU, 메모리 (내부 메트릭)	Kafka 큐 깊이, HTTP 요청률, Cron, AWS SQS, Redis 등 60+ 외부 이벤트
Zero-to-One	❌ 최소 1개 Pod 필수	✅ 트래픽 없으면 0개까지 축소, 이벤트 발생 시 1개부터 기동
동작 방식	리액티브 (이미 올라간 후)	프로액티브 (외부 신호 기반 선제 대응)

# KEDA ScaledObject 예시: Kafka 큐 깊이 기반 스케일링
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-consumer-scaler
spec:
  scaleTargetRef:
    name: order-consumer
  minReplicaCount: 0          # 트래픽 없으면 0개까지!
  maxReplicaCount: 30
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: order-group
        topic: orders
        lagThreshold: "100"   # 미처리 메시지 100개 이상이면 스케일 아웃

3. 요약: 실무에서의 선택 기준

시나리오	추천	이유
REST API 서버 (Spring Boot)	HPA	CPU 기반 스케일링으로 충분, K8s 기본 기능
Kafka 컨슈머 / 배치 워커	KEDA	큐 깊이 기반 스케일링, 0→1 지원으로 비용 절감
크론 기반 선제 스케일링	KEDA	Cron 트리거로 "매일 오전 9시에 미리 5개로 확장" 가능
복합 (API + 비동기 워커)	HPA + KEDA 혼용	각 워크로드 특성에 맞는 전략 적용

K8s 자동 확장의 핵심은 "인프라를 트래픽에 반응하는 탄력적 자원으로 전환"하는 것입니다. HPA가 기본기를 제공하고, KEDA가 이벤트 기반 마이크로서비스 아키텍처에 최적화된 고급 확장을 담당합니다.

728x90

1. HPA: CPU/메모리 기반의 기본 자동 확장

HPA의 한계

2. KEDA: 이벤트 기반의 차세대 오토스케일러

3. 요약: 실무에서의 선택 기준

티스토리툴바