✅ SLA 기반 KEDA AutoScaler 설계 with 비용 최적화 정책

1. 왜 KEDA인가?

Kubernetes HPA(Horizontal Pod Autoscaler)는 기본적으로 CPU/Memory 사용률만을 기준으로 스케일링합니다.

그러나:
• API SLA는 응답 시간, 처리량, 에러율, Queue 길이 등 다양한 지표로 결정됨
• 트래픽은 비정형적으로 몰리며, 지연 발생은 CPU 사용량과 일치하지 않음
• SLA 위반을 막기 위해, 보다 정밀한 트리거가 필요

→ 이를 해결하는 것이 KEDA (Kubernetes-based Event Driven Autoscaler)

⸻

2. 구조 개요

graph LR
A[Prometheus / Custom Metrics] --> B[KEDA ScaledObject]
B --> C[Deployment or Job]
C --> D[Pod Scaling based on SLA targets]


⸻

3. 주요 트리거 유형 (SLA 기반)

트리거 유형 지표 설명
Prometheus API 응답 시간 (95p latency) 평균 응답 시간 > 1.5s 시 스케일 업
Kafka 메시지 대기열 길이 대기 메시지 > 1000건 시 consumer pod 증가
Redis 작업 큐 길이 처리 대기 job 건수 기준 스케일
HTTP SLA API 응답 기반 SLA Endpoint에서 반환된 상태 기반 스케일


⸻

4. KEDA ScaledObject 예시 (Prometheus 기반)

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-latency-scaler
spec:
  scaleTargetRef:
    name: api-deployment
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: |
          histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1.5
        threshold: "1"

→ 응답 시간의 95퍼센타일이 1.5초를 초과하면 pod 스케일 업
→ 과도한 스케일 방지를 위해 cooldownPeriod 적용

⸻

5. 비용 최적화 정책

전략 설명
스케일 업 속도 제한 급격한 pod 증가는 비용 급증 초래 → 단계적 증가
야간/비업무시간 스케일 제한 시간대 기반 minReplica 설정
maxReplicaCount 조정 고객 SLA 등급에 따라 최대 리소스 제한
QoS Class 설정 낮은 우선순위 workload는 BestEffort로 스케일


⸻

6. 고급 트리거: 복합 SLA 조건

KEDA + OpenFaaS + Prometheus 예시

triggers:
  - type: prometheus
    metadata:
      query: |
        sum(increase(http_5xx_errors_total[1m])) > 10
      threshold: "1"
  - type: prometheus
    metadata:
      query: |
        histogram_quantile(0.95, rate(http_latency_seconds_bucket[1m])) > 2
      threshold: "1"

→ 오류율 + 응답시간 동시 초과 시 스케일
→ 둘 다 만족해야 확장 → 비용 방어

⸻

7. 운영 지표 및 대시보드

대시보드 항목 설명
SLA 지표별 스케일 이벤트 추이 latency, error rate → scale decision 확인
스케일 이벤트 vs 비용 pod 수와 클라우드 비용 간 상관관계 시각화
비업무 시간대 scale 여부 불필요한 리소스 낭비 방지 분석


⸻

8. 조직별 적용 전략

조직 유형 적용 방식
B2B SaaS 고객 요금제 등급 → maxReplicaCount 제한
마이크로서비스 아키텍처 서비스 단위 스케일 구성 → 독립 확장성
대규모 Kafka 기반 consumer group 단위 큐 길이 기반 스케일


⸻

✅ 결론

SLA 위반을 사전에 방지하려면,
• 단순 CPU 기반 스케일링에서 벗어나,
• 실제 품질 지표 기반의 스케일링 트리거를 도입해야 합니다.

KEDA는 SLA + 비용 + 운영 탄력성을 동시에 만족시키는 현실적 해법이며,
기존 Prometheus, Kafka, Redis, HTTP SLA 지표와 유연하게 연동 가능합니다.