KEDA 필요성, HPA 와의 차이점

Kubernetes를 운영하면서 가장 큰 장점 중 하나는 트래픽에 따라 파드(Pod)의 수를 자동으로 조절하는 Autoscaling 기능입니다. 우리는 보통 HPA(Horizontal Pod Autoscaler) 를 통해 이를 구현합니다. 하지만, CPU나 메모리 사용량은 낮은데 처리해야 할 작업(이벤트)이 쌓여 서비스가 지연되는 경험을 해보신 적이 있나요? 이번 글에서는 HPA의 한계를 짚어보고, 이를 보완하기 위해 등장한 KEDA(Kubernetes Event-driven Autoscaling)가 왜 필요한지, 그리고 둘의 차이점은 무엇인지 알아보겠습니다.

---

HPA 란? 

HPA는 쿠버네티스의 기본 리소스 오토스케일러입니다.

• 작동 원리: 주로 CPU 사용량이나 메모리 사용량 같은 리소스 메트릭을 주기적으로 확인하여 스케일링을 결정합니다.
• 장점: 설정이 간편하고, 일반적인 웹 서버와 같이 리소스 사용량이 트래픽과 비례하는 애플리케이션에 적합합니다.

---

리소스 기반 스케일링의 한계

HPA는 훌륭하지만, 이벤트 기반 아키텍처(Event-Driven Architecture)에서는 한계가 있습니다.

1. 반응 속도의 지연 (Lag): 메시지 큐(Kafka, RabbitMQ 등)에 메시지가 1만 개가 쌓여도, 파드가 이를 처리하느라 CPU를 본격적으로 쓰기 전까지는 스케일링이 일어나지 않습니다.
2. 외부 메트릭 연동의 복잡함: 기본 HPA로 특정 큐의 길이(Lag)나 외부 API 수치를 기반으로 스케일링하려면, 별도의 Metrics Adapter를 구축해야 하는 등 설정이 매우 복잡해집니다.
3. Scale to Zero 불가: HPA는 기본적으로 최소 1개의 파드를 유지해야 합니다. 작업이 없을 때 아예 0개로 줄여 비용을 절감하는 것이 불가능합니다.

---

KEDA (Kubernetes Event-driven Autoscaling)

KEDA는 이름 그대로 "이벤트 기반"의 오토스케일링을 가능하게 해줍니다.

• 다양한 Scaler 지원: Kafka, AWS SQS, Prometheus, Redis 등 60개 이상의 외부 이벤트 소스를 기본적으로 지원합니다.
• Scale to Zero: 처리할 이벤트가 없으면 파드 수를 0으로 줄였다가, 이벤트가 발생하면 즉시 파드를 생성합니다. (비용 절감 효과)
• HPA와의 공존: KEDA는 HPA를 대체하는 것이 아니라, HPA에게 "언제 스케일링해야 하는지"에 대한 외부 메트릭을 제공하는 역할을 합니다. (실제 스케일링은 HPA가 수행)

 

ScaledObject(사용자 선언)
   ↓ (KEDA Operator)
HPA(자동 생성/관리)
   ↓ (HPA가 질의)
KEDA Metrics Server(external.metrics API)
   ↓ (KEDA Scaler가 이벤트 소스 조회)
Event Source(Kafka/RabbitMQ/Prometheus/CloudWatch/…)

 

 

KEDA는 다양한 이벤트 소스에 대응하는 scaler (공식문서 링크)를 제공하고, 각 scaler가 이벤트 기반 활성화 여부 판단과 메트릭 제공을 담당해 HPA가 이를 기반으로 스케일링하도록 연결합니다.

---

 

비교 항목	HPA (기본)	KEDA
스케일링 기준	CPU, Memory (리소스 중심)	Queue Length, Lag, Stream 등 (이벤트 중심)
반응성	리소스 사용량이 증가해야 반응 (Reactive)	이벤트 발생 즉시 반응 (Proactive)
Scale to Zero	불가능 (최소 1개 유지)	가능 (0개로 축소 가능)
외부 연동	복잡함 (Custom Metrics Adapter 필요)	간편함 (다양한 내장 Scaler 제공)
주요 사용처	일반적인 웹 애플리케이션	백그라운드 워커, 데이터 프로세싱, 큐 처리

---