lander.log

KEDA (Kubernetes Event-Driven Autoscaling)

6 min read

KEDA (Kubernetes Event-Driven Autoscaling)

정의 (Definition)

KEDA는 Kubernetes의 기본 HPA(Horizontal Pod Autoscaler) 를 확장하여, CPU/Memory 같은 리소스 메트릭이 아닌 외부 이벤트 소스(Kafka, RabbitMQ, SQS, Prometheus 등)의 상태를 기준으로 워크로드를 0에서 N까지(Scale-to-Zero) 자동 조정하는 이벤트 기반 오토스케일러입니다.

문제가 되는 배경 (Problem Context)

기본 HPA는 파드의 리소스 사용률(CPU/Memory)에 반응합니다. 그러나 비동기 워커 패턴이나 이벤트 드리븐 아키텍처에서는 다음과 같은 한계가 발생합니다.

  1. 반응 지연: 메시지 큐(Lag)는 쌓이는데, 워커의 CPU 사용률은 아직 낮아 스케일링이 트리거되지 않는 경우.
  2. 리소스 낭비: 할 일이 없는(이벤트가 없는) 새벽 시간에도 HPA의 minReplicas 제약 때문에 최소 1개의 파드가 계속 떠 있어야 함.
  3. 외부 메트릭 연동 복잡성: Prometheus Adapter 등을 직접 구성해야 외부 지표를 HPA에서 쓸 수 있어 운영 오버헤드가 큼.

핵심 메커니즘 (How it Works)

KEDA는 크게 Operator(Agent) 와 Metrics Server 두 가지 역할을 수행합니다.

  1. ScaledObject: 사용자가 정의하는 CRD로, 어떤 이벤트 소스(Trigger)를 보고 어떤 배포(Deployment)를 조정할지 정의합니다.
  2. 0 ↔ 1 스케일링 (Activation): KEDA Operator가 이벤트 소스를 직접 모니터링하다가, 이벤트가 없으면 파드를 0으로 줄이고, 이벤트가 발생하면 1로 늘립니다.
  3. 1 ↔ N 스케일링 (HPA): 파드가 1개 이상일 때는 KEDA Metrics Server가 외부 메트릭을 HPA가 이해할 수 있는 형태(External Metrics API)로 변환하여 제공하고, 실제 확장은 HPA에게 위임합니다.

아키텍처 다이어그램

graph LR
    Event["Event Source (Kafka/SQS)"] -->|Monitoring| KEDA[KEDA Operator]
    KEDA -->|0 <-> 1| Dep[Deployment]
    
    KEDA_Metric[KEDA Metrics Server] -->|Serve Metrics| HPA[Native HPA]
    HPA -->|1 <-> N| Dep

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 책임 분리: 0에서 1로 깨우는 것은 KEDA Operator의 책임이며, 1에서 N으로 늘리는 것은 KEDA가 생성한 HPA의 책임입니다.
  • Scale-to-Zero: minReplicaCount: 0 설정 시, 이벤트가 없으면 파드는 반드시 0으로 종료됩니다(비용 절감 보장).
  • 비보장: 이벤트가 폭증해도, 클러스터의 물리적 자원(Node Capacity)이나 HPA maxReplicaCount를 초과하여 확장될 수는 없습니다.

비유 (Analogy)

  • HPA (CPU 기반): “식당 손님이 꽉 차서 직원들이 바빠 보이면(CPU High) 알바생을 더 부르는 점장님.” (손님이 줄 서 있어도 직원들이 안 바쁘면 안 부름)
  • KEDA (이벤트 기반): “대기 명단(Queue Lag)을 보고 손님이 5팀 이상 기다리면 즉시 알바생을 부르는 점장님.” (직원들이 놀고 있어도 대기 줄이 길면 인력을 투입함)
  • Scale-to-Zero: “손님이 아예 없으면 가게 문을 닫고 퇴근했다가(0), 벨이 울리면 다시 출근하는(1) 방식.”

실무적 함의 (Operational Implications)

  • 비용 효율성: 개발/스테이징 환경이나 배치성 워크로드에서 Scale-to-Zero를 적용하면 유휴 비용을 획기적으로 줄일 수 있습니다.
  • 메트릭 선택의 중요성: Kafka Consumer의 경우, 단순히 “Lag가 있다”가 아니라 “Consumer Group당 처리 가능한 Lag 임계값”을 잘 설정해야 플래핑(Flapping)을 막을 수 있습니다.
  • Polling Interval: KEDA는 주기적으로(기본 30초) 외부 소스를 폴링합니다. 따라서 이벤트 발생 후 파드 기동까지 최소 폴링 주기 + Cold Start 시간만큼의 지연이 발생함을 고려해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • “HPA를 대체한다?”: KEDA는 HPA를 대체하는 게 아니라, HPA를 생성하고 관리하는 상위 추상화 계층입니다. kubectl get hpa를 하면 KEDA가 만든 HPA가 보입니다.
  • “실시간 반응?”: KEDA는 폴링 기반이므로 밀리초 단위의 실시간 반응이 필요한 초저지연 시스템에는 적합하지 않을 수 있습니다.

References

Recent Posts