Kubernetes 이벤트 기반 오토스케일링, KEDA로 트래픽과 비용을 동시에 최적화하기

 

Kubernetes 운영을 하다 보면 스케일링의 기준을 CPU/메모리 사용률이 아닌, 비즈니스 이벤트로 잡아야 하는 순간이 옵니다.

메시지 큐의 잔량, API 호출 급증, 배치 Job 트리거 등 실제 서비스 부하의 원인을 기준으로 파드를 조정하고 싶다면, KEDA가 훌륭한 선택지가 됩니다.

---

1. KEDA란? — Event-Driven Autoscaling의 등장 배경

Kubernetes 기본 오토스케일링인 **HPA(Horizontal Pod Autoscaler)**는 CPU/메모리 기반 스케일링엔 최적이지만,

다음과 같은 한계가 있습니다.

• 지표가 실제 서비스 부하 원인과 간접적
• 비동기/배치 워크로드에서는 Scale-to-Zero 적용 어려움
• 외부 이벤트 소스(메시지 큐, 스트림 등)를 스케일링 기준으로 삼기 복잡

이런 문제를 해결하기 위해 등장한 것이 바로 KEDA 입니다.

KEDA는 Kafka, RabbitMQ, SQS, Azure Queue, Prometheus Metric, Cron Schedule, HTTP 요청 등 수십 가지 이벤트 소스를 직접 스케일링 트리거로 사용할 수 있습니다.

즉,

“파드가 얼마나 바쁜가?”가 아니라 → **“왜 바쁜가?”(이벤트 원인)**을 기준으로 스케일링합니다.

또한, 이벤트가 없을 경우 **레플리카 0개로 축소(Scale-to-Zero)**가 가능해 서버리스風 Kubernetes 운영이 가능해집니다.

---

2. 동작 구조 — 핵심 컴포넌트와 흐름 이해

KEDA는 Kubernetes 클러스터에 경량(Operator + Metric Adapter) 컴포넌트로 설치되어 아래 흐름으로 동작합니다.

1. ScaledObject 또는 ScaledJob CRD로 "어떤 워크로드를 어떤 이벤트 기준으로 스케일링할지" 선언
2. KEDA Scaler가 외부 이벤트 소스를 지속 감시
3. Metric Adapter가 수집 지표를 External Metric으로 변환
4. KEDA Operator가 자동으로 HPA 리소스를 생성 및 관리
5. HPA가 이벤트 지표를 기준으로 Pod Replica 수 조정

지원되는 스케일링 대상

• Deployment
• StatefulSet
• Job (event-driven batch job)
• Cron 기반 ScaledJob
• Queue 기반 소비자 파드

주요 Scalability 지표 예시

 

Scaler	측정 기준
AWS SQS	대기 메시지 수 (queue length)
Kafka	Consumer lag / Topic 메시지 수
Prometheus	사용자 정의 Metric
HTTP(HTTP Add-on)	초당 요청 수
Cron	스케줄 기반 Job 트리거

이처럼 이벤트 소스와 워크로드를 직접 이어주는 스케일링 레이어를 제공하는 것이 KEDA의 핵심 가치입니다.

---

3. 장점 — 안정성, 비용, 대응성을 한 번에

3-1. 실전 장애 완화

• 메모리 피크 기반 스케일링으로 OOM 감소
• 과도한 CPU Limit로 발생하는 Throttling 예방
• 큐 기반 부하 분산으로 지연 시간 안정화

3-2. FinOps 관점 비용 절감

• 이벤트가 없을 때 파드 0개 → 유휴 리소스 제거
• 실제 부하 원인을 기준으로 필요 이상 확장 방지
• 클러스터 효율 증가 → 동일 노드에서 더 많은 파드 수용 가능

3-3. 운영 설득이 쉬워지는 근거 확보

KEDA는 다음과 같은 대화의 근거를 제공합니다.

• “설정값이 너무 큰 거 아니야?”
• “지금 노드 늘려야 진짜 괜찮아?”
• “pod request를 왜 이렇게 잡았어?”

이런 질문에 Kubernetes 메트릭이 아니라 ‘이벤트 원인 지표’로 설계한 근거를 제시할 수 있습니다.

팀 문화가 단순 장애 대응에서 → 이벤트 근거 기반 운영으로 전환됩니다.

---

4. 도입이 적합한 규모 — 언제 Goldilocks처럼 ROI가 커질까?

KEDA 도입 ROI는 **클러스터 크기보다 "이벤트 스케일링이 필요한 워크로드 개수"**에 더 직접적으로 비례합니다.

✅ KEDA가 제 역할을 하는 조직 규모

• 파드 30~50개 이상
• 워크로드(Deployment/Job 등) 3~5개 이상
• 스케일링 기준이 Queue/Stream/API Request
• 트래픽 피크 편차가 큰 경우
• 노드 3대 이상 ~ 20대 미만 구간에서 효과 ↑
• (대규모 DAU 서비스는 노드 스케일레이어와 함께 설계 필요)

⭐ 시너지가 극대화되는 경우

• KEDA + Karpenter(노드 오토스케일) 필요
• Scaler 지표 + Warm-up 전략 설계
• GitOps 기반 배포 환경이거나, IaC 기반 운영조직

△ 과도할 수 있는 경우

• 워크로드 1~2개, 파드 <10개, 이벤트 부하 X
• (수동 설정 or HPA로 충분)

핵심: Scale-to-Zero, 큐 기반 부하 분산, 요청 수 기반 스케일링이 필요한 시점부터 KEDA를 도입하세요.

---

5. 실전 고려사항 — 다 같이 도입할 때 놓치지 말아야 할 부분

5-1. 이벤트 피크 워밍업 시간 (Cold Start 허용 범위)

Scale-to-Zero로 내려가는 경우 다시 확장하면서 **초기 지연(Cold Start Latency)**가 발생할 수 있습니다.

이 경우:

• 앱 초기 부팅 시간 최적화
• 최소 레플리카 유지 or 웜 파드 1개 유지 옵션
• 트래픽 급증 대비 큐 소비 파드 Burst 허용 설계

가 필요합니다.

---

5-2. 노드 스케일링 레이어 함께 설계

KEDA는 파드 수를 늘려주지만, 노드 부족이 발생하면 Pod는 Pending 상태에 머물 수 있습니다.

따라서 **파드 스케일아웃을 보조하는 노드 오토스케일러(Karpenter, CA, Node Pool 등)**와 조합을 권장합니다.

---

5-3. 요청 스톰 (Queue Storm) 대비

이벤트 급증 시 너무 빠른 scale-out으로 클러스터가 순간적으로 흔들릴 수 있으므로:

• stabilizationWindowSeconds(HPA 안정화)
• VPA의 리소스 피크 반영
• Node capacity 고려
• cooldown 옵션 설계
• 적정 Polling interval 조율

을 함께 구성하세요.

---

6. 결론 — 오토스케일링의 기준을 ‘근거’로 디자인하자

KEDA는 Kubernetes 스케일링의 기준을 CPU/Memory가 아닌 ‘Event Cause’의 정확 지표로 전환해줍니다.

특히:

• 비동기 큐 기반 워크로드
• 트래픽 급등 API 서비스
• 배치 Job 트리거
• 메시지 스트림 소비자 파드

와 같이 동작 원인이 명확한 시스템에서 안정성과 비용절감 효과가 극대화 됩니다.

“스케일링은 리소스를 늘리는 기술이 아니라, 부하의 원인을 이해하고 유휴자원을 회수하는 기술이어야 합니다.”

KEDA를 도입하면 더 이상 리소스를 감으로 크게 주지 않아도, 트리거 기준으로 딱 맞는, 설득 가능한 스케일링 설계가 가능해집니다.

---

7. 다음 글에서 다룰 수 있는 확장 주제 

• KEDA 설치 (Helm/Terraform)
• Kafka ConsumerLag 기반 ScaledObject YAML 작성
• AWS SQS 기반 Scaler 구성 실전 예
• HTTP Add-on을 통한 Request-기반 스케일링 실전
• KEDA + Karpenter + Istio GitOps 운영 예시