KEDA — 이벤트 기반 오토스케일링과 스케일 투 제로

쿠버네티스의 기본 오토스케일러는 오랫동안 CPU와 메모리만 바라봤다. 그런데 현실의 부하는 CPU로 다 설명되지 않는다. 큐에 쌓인 메시지, 스트림의 밀린 오프셋, 예약된 시각 같은 신호가 진짜 원인일 때가 많다. KEDA(Kubernetes Event-driven Autoscaling)는 바로 이 이벤트 신호를 기준으로 파드를 늘리고 줄이는 오토스케일러다.

나는 배치성 워크로드를 운영하며 답답한 순간이 많았다. 큐에 작업이 산더미인데 CPU 사용률은 낮아서 스케일아웃이 안 되던 상황 말이다. 반대로 아무 일도 없는데 파드는 최소 개수만큼 계속 떠서 돈을 태웠다. KEDA는 이 어긋남을 정면으로 푼다.

기본 오토스케일링의 사각지대

쿠버네티스의 수평 파드 오토스케일러(HPA)는 훌륭하지만, 태생적으로 자원 사용률 중심이다. 웹 서버처럼 요청이 곧 CPU로 이어지는 워크로드에는 잘 맞는다. 문제는 비동기 처리다. 메시지 큐를 소비하는 워커, 스트림을 읽는 파이프라인, 특정 시간에만 몰리는 배치는 부하와 CPU가 나란히 움직이지 않는다.

또 하나, 기본 HPA는 파드를 0으로 줄이지 못한다. 최소 한 개는 늘 떠 있어야 한다. 하루에 몇 번만 도는 작업을 위해 파드를 종일 켜두는 건 클라우드 비용 관점에서 낭비다.

결국 문제의 뿌리는 "무엇을 부하로 볼 것인가"에 있다. 웹 서버에게는 CPU가 곧 부하지만, 큐 소비자에게 부하는 큐에 밀린 메시지의 수다. 스트림 처리기에게는 아직 읽지 못한 오프셋의 격차가 부하다. 이 진짜 신호를 오토스케일러가 보지 못하면, 반응이 늘 한 박자 늦거나 엉뚱하게 움직인다. KEDA는 바로 이 "진짜 신호"를 스케일링의 기준으로 끌어올린다.

KEDA가 일하는 방식

스케일러(scaler)

KEDA의 매력은 다양한 외부 신호를 읽는 스케일러 모음에 있다. 메시지 큐의 대기 길이, 스트림의 소비 지연, 데이터베이스 쿼리 결과, 심지어 크론 스케줄까지 스케일 기준으로 삼을 수 있다. "큐에 메시지가 100개 쌓이면 파드를 늘려라" 같은 규칙을 그대로 표현한다.

스케일 투 제로(scale to zero)

내가 가장 아끼는 기능이다. 처리할 이벤트가 없으면 파드를 완전히 0개로 내린다. 그러다 이벤트가 들어오면 KEDA가 감지해 다시 파드를 띄운다. 간헐적으로만 도는 워크로드라면 유휴 시간 비용이 사실상 사라진다. 서버리스에 가까운 경제성을 표준 쿠버네티스 위에서 얻는 셈이다.

도입 전에 짚을 점

KEDA는 기본 HPA를 대체하는 게 아니라 확장한다. 내부적으로 HPA를 그대로 활용하되, 스케일 기준으로 삼을 외부 지표를 공급하는 역할이다. 그래서 기존 쿠버네티스 지식이 대부분 그대로 쓰인다. 학습 곡선이 급하지 않다는 뜻이다.

다만 스케일 투 제로에는 대가가 있다. 파드가 0이면 첫 이벤트가 들어왔을 때 파드를 새로 띄우는 만큼 지연(콜드 스타트)이 생긴다. 즉각 응답이 생명인 온라인 서비스보다는 약간의 지연을 감수할 수 있는 배치·비동기 워크로드에 더 잘 맞는다. 워크로드 성격을 먼저 가려야 한다.

자주 묻는 질문

KEDA는 기본 HPA를 대체하나요?

대체가 아니라 확장이다. KEDA는 내부적으로 HPA를 활용하면서 이벤트 기반 지표를 더해준다. 기존 CPU 기반 스케일링과 함께 쓸 수 있다.

어떤 워크로드에 잘 맞나요?

메시지 큐 소비자, 스트림 처리, 배치 작업처럼 부하가 CPU가 아니라 대기 중인 일의 양으로 표현되는 워크로드에 특히 잘 맞는다. 간헐적으로만 도는 작업이라면 스케일 투 제로의 이득이 크다.

콜드 스타트 지연은 어떻게 다루나요?

즉시성이 중요한 서비스라면 최소 파드 수를 1 이상으로 두어 0으로 내려가지 않게 설정할 수 있다. 지연을 감수할 수 있는 워크로드에만 스케일 투 제로를 적용하는 것이 안전하다.

여러 신호를 동시에 쓸 수 있나요?

가능하다. 하나의 워크로드에 여러 스케일러를 걸어, 큐 길이와 시간대 등 복합 조건으로 스케일링을 구성할 수 있다.