본문 바로가기
IT & Tech 정보

SLA 기반 리소스 자동 스케일링 시스템: KEDA + Prometheus + Custom Autoscaler의 완전한 설계

by 지식과 지혜의 나무 2025. 5. 28.
반응형



🎯 문제 인식

전통적인 CPU 사용률 기반의 HPA(Horizontal Pod Autoscaler)는 서비스 수준 목표(SLO, SLA)를 만족시키기에 충분하지 않은 경우가 많습니다. 예를 들어:
• 처리량은 낮지만 응답 속도가 느려지는 경우
• 큐 길이는 증가하지만 Pod 수는 그대로인 경우

이러한 시나리오에서 CPU만을 기준으로 한 자동 스케일링은 효과적이지 않습니다.

실리콘밸리의 실전 DevOps 팀은 이러한 문제를 SLA 기반 메트릭에 따라 동적으로 스케일링하는 구조로 해결합니다. 그 중심에는 KEDA, Prometheus, Custom Metrics Adapter가 존재합니다.



⚙️ 아키텍처 구성

!KEDA 아키텍처

이 아키텍처는 다음과 같은 흐름으로 구성됩니다:
1. 애플리케이션에서 메트릭을 Prometheus로 노출
2. KEDA Scaler가 설정된 조건을 만족하는지 확인
3. 조건을 만족하면 Kubernetes HPA를 통해 Pod 수 조정

추가로, SLA 위반 알림은 Slack 또는 Teams로 전송되며, CPU 기반 HPA와 병렬로 적용 가능합니다.



🧱 실전 구성

1. Prometheus 메트릭 기반 Custom 스케일러 정의

queue_latency_seconds 메트릭을 기준으로 스케일링하는 예시입니다:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: app-autoscaler
spec:
  scaleTargetRef:
    name: myapp-deployment
  pollingInterval: 30
  cooldownPeriod: 120
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: queue_latency_seconds
        threshold: '0.2'
        query: |
          avg(rate(queue_latency_seconds[1m]))

이 설정은 평균 대기 시간이 0.2초 이상일 경우 스케일 아웃을 시작합니다.

2. SLA 위반 알림 자동화

Prometheus Alertmanager를 활용하여 SLA 위반 시 Slack으로 알림을 전송할 수 있습니다:

groups:
- name: SLAAlerts
  rules:
  - alert: HighQueueLatency
    expr: avg(rate(queue_latency_seconds[1m])) > 0.3
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Queue latency above SLA threshold"
      description: "Current avg queue latency is above 0.3s"

3. 동적 임계값 조정

고정된 임계값이 아닌, 시간대나 요일에 따라 유동적인 조건을 설정하려면 PromQL의 시간 조건식을 활용하거나 KEDA의 외부 Scaler를 개발하여 적용할 수 있습니다.

4. 다중 트리거 병렬 구성

CPU 사용률과 큐 길이 등 여러 메트릭을 동시에 고려하여 스케일링을 구성할 수 있습니다:

triggers:
  - type: cpu
    metadata:
      type: Utilization
      value: "75"
  - type: prometheus
    metadata:
      metricName: queue_length
      threshold: "50"

이 설정은 두 조건 중 하나라도 만족하면 스케일 아웃을 수행합니다.



✅ 성공 사례 및 활용 팁

기업 적용 방식
GitHub API 요청 지연 시간 기반 HPA를 활용하여 SLA 수준 자동 유지
쿠팡 큐 및 이벤트 기반 비동기 처리 시스템에 KEDA를 적용하여 확장성 확보
MercadoLibre Kafka consumer lag 기반의 KEDA 스케일러를 사용하여 실시간 대응

확장 전략
• Redis, Kafka, RabbitMQ 등 이벤트 기반 시스템에도 스케일링 대상으로 적용 가능
• SLA 기준의 Prometheus Alert를 PagerDuty 또는 Slack과 연동하여 실시간 알림 제공
• Terraform이나 Argo CD를 활용하여 ScaledObject를 코드로 관리 



🚦 체크리스트

항목 점검 여부
메트릭의 실제 SLA 영향도 검증됨 ✔️
동적 트래픽 변동 대응 실험 완료 ✔️
Alertmanager 연동 구성됨 ✔️
CPU 외 메트릭 기반 트리거 정의 ✔️




🔚 결론

단순한 CPU 기반 HPA는 더 이상 프로덕션급 시스템에 충분하지 않습니다. SLA 위반 가능성을 선제적으로 대응하고, Prometheus 메트릭과 KEDA를 활용하여 트래픽 변화에 적응형 인프라를 구성해야 합니다.

이 전략은 단순한 퍼포먼스 튜닝이 아니라, 비즈니스 신뢰성을 유지하기 위한 자동화된 SLA 방어선입니다.

반응형