🧠 “서비스 상태 기반 SLA 중심 자동 스케일링: KEDA + Prometheus + 슬랙 경보형 HPA 확장 전략”

🎯 문제 인식: 단순 CPU 기반 오토스케일링의 한계

기존 Kubernetes HPA(Horizontal Pod Autoscaler)는 CPU나 메모리 사용률만 기반으로 오토스케일링을 수행합니다.
하지만, 실제 운영에서는 다음과 같은 문제가 발생합니다:
• 사용자 응답 시간 증가에도 CPU 사용률은 낮은 경우
• 특정 API에서만 오류율이 급증하는데 스케일링이 되지 않음
• 특정 지표를 기준으로 경보가 발생했지만, 스케일 조치 없이 알람만 전송됨

→ 이제는 단순한 리소스 사용률이 아니라 **서비스 상태(SLO/SLA 기준)**에 따라 정책 기반으로 자동 스케일링할 수 있어야 합니다.

⸻

🔧 해결 전략: KEDA + Prometheus + SLA 알람 기반 확장

“애플리케이션 상태나 SLA 지표가 일정 기준을 초과하면 자동 확장하고, 알림도 함께 전송되도록 구성합니다.”

주요 구성 요소

구성 요소 역할
KEDA 외부 지표 기반 Kubernetes 스케일러
Prometheus SLA 지표 수집 및 질의
Alertmanager SLA 위반 알림 처리
Slack API 연동 SLA 알림 자동 전파
Custom Metrics (e.g., 응답시간, 오류율) 스케일링 트리거 지표로 활용


⸻

⚙️ KEDA 스케일링 정의 예시

KEDA는 Prometheus에서 SLA 위반 지표를 쿼리하여, 해당 조건이 일정 시간 이상 지속되면 Pod 수를 확장합니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-response-scaler
spec:
  scaleTargetRef:
    name: my-api-deployment
  minReplicaCount: 2
  maxReplicaCount: 10
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: |
          rate(http_server_response_time_seconds_bucket{le="0.5"}[2m]) < 0.85
        threshold: "1"
        activationThreshold: "0.9"


⸻

🧪 SLA 알림 + Slack 자동화 예시 (Alertmanager)

receivers:
  - name: 'slack-sla-alert'
    slack_configs:
      - channel: '#sre-alerts'
        send_resolved: true
        text: |
          :fire: SLA 위반 감지: 응답률이 85% 이하입니다. 자동 스케일링이 시작됩니다.

위 예시는 SLA 지표가 기준 이하로 떨어지면 Slack에 자동 알림을 전송하고,
동시에 KEDA가 해당 지표에 따라 스케일링을 수행합니다.

⸻

🔄 실전 운영 시나리오
1. API 응답 성공률이 90% 아래로 하락
2. Prometheus + Alertmanager가 SLA 위반 감지
3. Slack 채널에 자동 SLA 위반 경고 전송
4. KEDA가 http_server_response_time_seconds_bucket 기준으로 스케일링 트리거
5. Pod 2개에서 6개로 자동 확장
6. 응답률 회복 → 알람 종료 + 리소스 정상화

⸻

🧠 실전 Tip
• SLA 기반 스케일링은 비동기 지표에 강함 → Kafka lag, API latency 등 활용 가능
• SLA 기준이 명확하지 않다면 SLO 문서화를 먼저 수행
• SLA 기준 초과 시, 배포 중단 or Canary Rollback 트리거도 함께 구성 가능

⸻

✅ 기대 효과

항목 기존 HPA SLA 기반 KEDA
트리거 지표 CPU, 메모리 응답률, 오류율, 큐 적체
SLA 연계 불가능 가능 (SLO 직접 반영)
운영 대응성 수동 개입 필요 자동 Slack 알림 + 확장
확장 민감도 리소스 중심 고객 영향 중심


⸻

📌 결론

“리소스 기반 오토스케일링은 지표를 무시하고, 고객 경험 기반 스케일링은 지표를 살핀다.”

KEDA를 활용한 SLA 기반 스케일링 구조는 SRE 관점에서 서비스 품질을 실시간으로 유지할 수 있는 핵심 자동화 전략입니다.
앞으로는 CPU보다 사용자 중심 SLA 지표를 기반으로 한 운영 전략이 DevOps 팀의 차별점이 될 것입니다.