Scaling Kubernetes pods with KEDA based on Amazon SQS queue depth

왜 CPU 메트릭만으로는 부족한가

이벤트 기반 Kubernetes 아키텍처에서 흔히 발생하는 문제가 있다. 워커 Pod는 CPU 관점에서 완전히 유휴 상태인데, SQS 큐에는 수천 개의 메시지가 쌓여 있는 상황이다. 반대로 트래픽 스파이크가 지나간 뒤에도 Pod는 계속 살아 있어 불필요한 비용을 소모한다. 전통적인 HPA가 CPU/메모리를 기반으로 동작하는 이유는 범용 워크로드에는 충분히 유효하기 때문이지만, 비동기 큐 기반 워크로드에서 실제 시스템 부하의 신호는 인프라 사용률이 아닌 백로그(backlog) 다.

메시지 처리가 지연되면 사용자 경험과 하위 시스템에 즉각적인 영향이 전달된다. 결국 스케일링 트리거를 "얼마나 바쁜가"가 아닌 "얼마나 많이 쌓여 있는가"로 전환하는 것이 이 문제의 핵심 해법이다.

KEDA + SQS 아키텍처 동작 방식

KEDA(Kubernetes Event-Driven Autoscaler)는 외부 이벤트 소스를 기반으로 Kubernetes HPA를 관리하는 컴포넌트다. SQS와의 통합 흐름은 다음과 같다.

프로듀서가 SQS 큐에 메시지를 전송한다.
KEDA가 주기적으로 큐 속성을 폴링해 현재 큐 깊이(queue depth) 를 측정한다.
KEDA가 HPA의 목표 메트릭 값을 업데이트한다.
HPA가 워커 Deployment의 레플리카 수를 조정한다.
큐가 소진되면 레플리카는 다시 축소된다.

AWS 인증은 IRSA(IAM Roles for Service Accounts) 또는 EKS Pod Identity 방식을 사용하며, KEDA가 SQS GetQueueAttributes API를 호출할 수 있는 권한이 필요하다. ScaledObject 리소스 예시는 다음과 같다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-worker-scaler
spec:
  scaleTargetRef:
    name: sqs-worker
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.ap-northeast-2.amazonaws.com/123456789/my-queue
        queueLength: "10"          # 메시지 10개당 Pod 1개
        activationQueueLength: "5" # 스케일 업 시작 임계값
        awsRegion: ap-northeast-2
        identityOwner: operator

queueLength는 Pod 1개가 처리할 목표 메시지 수이며, KEDA는 현재 큐 깊이 / queueLength로 목표 레플리카 수를 계산한다. activationQueueLength는 0 → 1 전환 시점의 임계값으로, 소량의 테스트 메시지에 의한 불필요한 스케일 업을 방지한다.

튜닝과 운영 시 고려사항

KEDA 기반 SQS 스케일링을 실무에 적용할 때 주의해야 할 튜닝 포인트가 몇 가지 있다.

cooldownPeriod: 큐가 비워진 뒤 얼마나 기다렸다가 스케일 다운할지 결정한다. 너무 짧으면 빈번한 스케일 업/다운 플래핑이 발생한다.
pollingInterval: KEDA가 큐 깊이를 확인하는 주기다. 기본값은 30초이며, 버스트가 잦은 워크로드에서는 단축을 검토할 수 있다.
HPA behavior: scaleUp.stabilizationWindowSeconds와 scaleDown.stabilizationWindowSeconds를 조정해 급격한 변동을 완화한다.
minReplicaCount: 0: 비용 최적화를 원한다면 0으로 설정 가능하지만, 첫 메시지 도착 후 Pod 기동 시간만큼 처리 지연이 발생한다는 트레이드오프가 있다.

스케일링 동작을 검증할 때는 kubectl describe scaledobject와 kubectl describe hpa로 KEDA가 계산한 desired replicas를 직접 확인하는 것이 가장 빠른 방법이다. SQS 메시지가 쌓임에도 Pod가 늘지 않는다면 KEDA 오퍼레이터의 IAM 권한 설정이나 ScaledObject의 네임스페이스 불일치를 먼저 점검해야 한다.

정리

CPU/메모리 기반 HPA는 큐 기반 비동기 워크로드의 실제 부하를 반영하지 못하며, SQS 큐 깊이가 더 정확한 스케일링 신호다.
KEDA는 queueLength와 activationQueueLength 설정으로 목표 레플리카 수를 자동 계산하고 HPA를 관리한다.
cooldownPeriod, pollingInterval, HPA behavior를 함께 튜닝해야 안정적인 스케일 업/다운 동작과 비용 효율성을 동시에 확보할 수 있다.