KEDA(Kubernetes Event-Driven Autoscaling)는 큐 길이·토픽 지연·DB 행 수 같은 외부 이벤트 지표를 보고 파드 수를 조절하는 오토스케일러다. 쿠버네티스 기본 HPA가 주로 CPU·메모리를 보는 데 반해, KEDA는 "카프카 토픽에 처리 안 된 메시지가 1만 건 쌓였다" 같은 신호로 스케일한다. 그리고 결정적으로, 일이 없을 땐 파드를 0개까지 줄일 수 있다(scale-to-zero).
배치 워커나 큐 소비자를 CPU 기준으로 스케일해 본 사람은 답답함을 안다. 큐에 일이 산더미인데 워커 CPU는 I/O 대기라 낮게 나오고, HPA는 "여유 있네" 하며 안 늘린다. 정작 봐야 할 건 CPU가 아니라 큐 깊이인데. KEDA는 그 시선을 바로잡는다.
동작 방식 — HPA를 대체하지 않고 먹인다
오해하기 쉬운데, KEDA는 HPA를 버리지 않는다. KEDA는 외부 소스를 폴링해서 지표를 만들고, 그 지표를 HPA에 먹여 주는 어댑터에 가깝다. 실제 스케일 계산은 여전히 HPA가 한다. 다만 KEDA가 앞에 붙어서 두 가지를 더 해 준다. 하나는 다양한 이벤트 소스를 지표로 번역해 주는 것, 다른 하나는 1↔0 구간을 관리해 주는 것이다(HPA 혼자서는 0으로 못 내린다).
ScaledObject — 선언 하나로
ScaledObject에 대상 Deployment와 트리거(scaler)를 적는다. 카프카 컨슈머 예시.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: order-worker }
spec:
scaleTargetRef: { name: order-worker }
minReplicaCount: 0 # 일이 없으면 0으로
maxReplicaCount: 30
cooldownPeriod: 120 # 0으로 내리기 전 대기(초)
triggers:
- type: kafka
metadata:
bootstrapServers: kafka:9092
consumerGroup: orders
topic: orders
lagThreshold: "100" # 파드당 처리할 목표 laglagThreshold: 100의 뜻은 "파드 하나가 대략 100건의 밀린 메시지를 감당하게 하라"이다. lag이 1000이면 대략 10개로 늘린다. 큐가 비면 cooldownPeriod를 지나 0으로 내려간다.
Scale-to-zero의 두 얼굴
0으로 내리는 건 비용 면에서 매력적이다. 야간에 안 도는 배치 워커, 가끔만 쓰는 내부 도구. 안 돌 때 돈을 안 쓴다. 그런데 함정도 있다.
- 콜드 스타트. 0에서 1로 뜨는 데 이미지 풀·부팅 시간이 든다. 첫 이벤트의 지연을 감당할 수 있는 워크로드여야 한다. 사용자 대면 동기 API를 0으로 내렸다가 첫 요청이 몇 초씩 걸려 낭패를 본 적이 있다. 큐 기반 비동기 작업에 어울린다.
- HTTP 워크로드는 별도 애드온. 순수 HTTP 트래픽으로 0↔1을 하려면 요청을 잠깐 버퍼링해 줄 인터셉터가 필요하다. KEDA HTTP add-on 같은 별도 컴포넌트를 쓴다. 기본 ScaledObject만으로 HTTP scale-to-zero가 되는 게 아니다.
- 폴링 주기. KEDA가 소스를 확인하는 간격(
pollingInterval)만큼 반응이 늦다. 너무 촘촘하면 소스에 부하, 너무 성기면 스케일이 굼뜨다.
| 구분 | HPA 단독 | KEDA |
|---|---|---|
| 기준 지표 | 주로 CPU/메모리 | 큐·스트림·DB 등 이벤트 |
| 최소 파드 | 1 이상 | 0 가능 |
| 소스 종류 | 제한적 | Kafka·SQS·Redis·Prometheus 등 다수 |
어디에 먼저 적용하나
개인적으로 KEDA는 큐 뒤에 있는 워커에 먼저 넣는 걸 추천한다. 효과가 즉각적이고 리스크가 낮다. 트래픽이 몰릴 땐 lag 기반으로 쫙 늘었다가, 한가하면 0으로 내려가 비용이 뚝 떨어진다. 반대로 지연에 민감한 동기 API는 minReplicaCount를 1 이상으로 둬서 콜드 스타트를 피하는 게 안전하다. 도구가 좋다고 모든 곳에 0을 적용하려 들면 사용자 경험이 상한다.
자주 묻는 질문
KEDA가 HPA를 대체하나요?
대체가 아니라 확장입니다. KEDA는 외부 이벤트를 지표로 변환해 내부적으로 HPA를 생성·관리하고, HPA 혼자 못 하는 0↔1 전환을 담당합니다. CPU/메모리 기반 스케일이 필요하면 그 부분은 여전히 HPA가 처리합니다.
어떤 이벤트 소스를 지원하나요?
Kafka, RabbitMQ, AWS SQS, Redis Streams/List, NATS, Prometheus 쿼리, 클라우드 모니터링 지표, 크론 스케줄 등 수십 종의 scaler가 있습니다. Prometheus scaler를 쓰면 사실상 임의 지표로 스케일할 수 있어 활용도가 높습니다.
Scale-to-zero는 모든 워크로드에 좋은가요?
아닙니다. 콜드 스타트 지연을 감당할 수 있는 비동기·배치성 워크로드에 적합합니다. 지연에 민감한 동기 API는 최소 파드를 1 이상으로 유지하거나, HTTP add-on으로 요청을 버퍼링하는 구성을 검토해야 합니다.
스케일이 느리게 느껴지면 어디를 봐야 하나요?
pollingInterval(소스 확인 주기)과 HPA의 안정화 윈도우를 봅니다. 폴링이 성기면 반응이 늦고, HPA의 scale-down 안정화 시간이 길면 축소가 굼뜹니다. 소스 부하와 반응성 사이에서 균형점을 찾아 조정하세요.
댓글 0