SLA 기반 자동 스케일링 아키텍처 완전 해부: KEDA + Prometheus + OpenSLO + Slack 연동

⸻

🧭 배경과 문제의식

서비스 확장이 클라우드 시대의 기본 전제가 되면서, “사용자 수에 따라 늘었다 줄었다 하는 자동 스케일링”은 누구나 구현합니다.
그러나 문제는 대부분 **리소스 기반(HPA: CPU/Memory)**으로 제한되고 있으며, 다음과 같은 한계를 갖습니다.
• 리소스 사용률은 “지표”이지 “서비스 품질”이 아님
• CPU 80% 이상이어도 실제 서비스는 정상이거나, 반대로 40%여도 응답 지연이 발생할 수 있음
• 진짜 기준은 “사용자가 체감하는 SLA”여야 함 (예: 평균 응답속도, 에러율, 큐 적체량)

“지표가 아니라 **SLO(SLI 기반 목표)**를 기준으로 스케일링할 수는 없을까?”
→ 이 문제에 정면 대응하는 것이 KEDA + Prometheus + OpenSLO 기반 SLA 중심 스케일링

⸻

⚙️ 아키텍처 구성 요소

구성요소 설명
KEDA 이벤트 기반 자동 스케일러 (Kubernetes 기반)
Prometheus Adapter SLI/SLO 기반 메트릭을 Kubernetes Metric Server에 노출
OpenSLO YAML 정의 SLA 목표(응답시간, 에러율 등)를 선언적 정의
Slack Webhook SLA 이탈·스케일 이벤트 실시간 알림
Kafka/NATS/HTTP Queue 등 트래픽 기반 이벤트 추출 (e.g. 요청 수 증가 감지)


⸻

📐 실제 아키텍처 다이어그램

+--------------+         +-------------------+          +------------------------+
| Prometheus   | <-----> | KEDA ScaledObject | -------> | Kubernetes HPA Adapter |
+--------------+         +-------------------+          +------------------------+
        ^                        |                                 |
        |                        |                                 |
        |                        V                                 V
        |               +----------------+            +------------------------+
        |               | OpenSLO Parser |            | Slack/Alertmanager     |
        |               +----------------+            +------------------------+
        |
        |   ← 수집된 메트릭: latency, error rate, throughput
        |
  [서비스 품질 실시간 분석 & 대응]


⸻

📄 OpenSLO 선언적 SLA 정의 예시

apiVersion: openslo/v1alpha
kind: SLO
metadata:
  name: user-api-latency-slo
spec:
  service: user-api
  indicator:
    metricSource:
      type: prometheus
      spec:
        query: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[1m]))
  objective:
    target: 0.8     # 80% 이상 SLA 유지
    timeWindow: 5m
  alertPolicies:
    - name: scale-up
      condition: below
      threshold: 0.8
      duration: 2m

→ 위 예시에서는 95% 요청이 200ms 이하일 때 목표를 만족.
이를 유지하지 못하면 scale-up 알림이 발생하고 KEDA가 자동으로 스케일링을 트리거합니다.

⸻

🔁 KEDA ScaledObject 예시

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: user-api-scaler
spec:
  scaleTargetRef:
    name: user-api
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 2
  maxReplicaCount: 15
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: slo_violation_rate
      query: |
        1 - (rate(http_request_duration_seconds_bucket{le="0.2"}[5m]) / rate(http_requests_total[5m]))
      threshold: "0.2"

→ SLA 이탈률이 20%를 넘으면 스케일 업 트리거
→ 스케일링 기준이 CPU가 아닌, 서비스 응답속도 SLA 충족률

⸻

🧵 실제 운영 시나리오 흐름
1. 사용자가 급증해 평균 응답속도 상승 (250ms → 320ms)
2. Prometheus는 95th percentile latency 지표를 감지
3. OpenSLO 정책 기준 위반 (SLO: < 300ms, 측정값: 320ms)
4. KEDA가 위반 감지하고 ScaledObject를 통해 레플리카 증가
5. 동시에 Slack 채널에 다음 알림 전송:

🚨 SLO Violation Detected: user-api
📊 Latency 95th percentile: 320ms (SLO: <300ms)
🔁 Scaling action: 4 → 8 pods
🔔 Triggered by: KEDA via Prometheus

6. 응답속도 회복되면 cooldown 이후 다시 scale-in 진행

⸻

📊 SLI 기반 스케일링 지표 예시

지표 유형 Prometheus Query 설명
Latency histogram_quantile(0.95, ...) SLA 충족 비율
Error Rate rate(http_requests_total{status=~"5.."}[1m]) 5xx 비율 증가 시 scale-up
Queue Length queue_length{job="worker"} 백엔드 작업 적체 감지
Request per Second rate(http_requests_total[30s]) 순수 트래픽 기반 트리거


⸻

✅ Best Practice

항목 설명
pollingInterval 튜닝 너무 짧으면 리소스 낭비, 15~30초 적정
cooldown 조절 5분 이상으로 설정해 불필요한 scale-in/out 방지
SLA 이탈 알림 → 자동 PR 생성 GitOps 방식으로 자동 revert or config 조정 가능
사용량 기반 Slack Rate Limiting Prometheus Alertmanager에서 알림 빈도 제한 필요
스테이징과 운영의 스케일 전략 분리 ScaledObject를 환경별로 분리 운영 추천


⸻

🔚 결론

SLA 중심의 자동 스케일링은 단순한 리소스 지표 스케일링보다 한 차원 높은 관점에서 서비스 품질과 사용자 경험을 정량화하고 대응하는 방식입니다.

KEDA, OpenSLO, Prometheus, Slack을 결합하면,
단순 스케일링을 넘어 **“서비스 품질을 수호하는 지능형 인프라”**를 만들 수 있습니다.