⚠️ Prometheus + KEDA로 실시간 장애 탐지와 자동 트래픽 컷오프 + Slack 경고 파이프라인 만들기

아래는 고급 DevOps 자동화 주제로, 실시간 이상 징후 탐지와 대응을 위한 Prometheus + KEDA 기반 장애 감지 → Slack 자동 알림 + 트래픽 컷오프 파이프라인 구축법에 관한 상세 가이드입니다. 이 시나리오는 단순 모니터링을 넘어 실제 인프라 스케일링 제어 및 알림 연동까지 완결된 사고 대응 자동화 흐름을 목표로 설계되었습니다.

⸻

⸻

✅ 개요

대규모 SaaS 또는 API 서비스에서 다음과 같은 문제가 발생할 수 있습니다:
• 특정 서비스의 응답시간 증가
• 특정 엔드포인트의 5xx 오류율 급증
• 인증 서버 지연 → 전체 로그인 실패

이러한 문제를 실시간 탐지하고, 트래픽을 자동으로 제한하거나 유입을 차단하며, 동시에 Slack 등으로 즉시 알림을 전송하여 대응 속도를 획기적으로 개선할 수 있습니다.

⸻

🔧 아키텍처 구성

        +-------------+
        |   Users     |
        +-------------+
               │
        ┌──────▼──────┐
        │ API Gateway │
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │   Services  │
        └──────┬──────┘
               ▼
        +-------------+
        | Prometheus  |
        +-------------+
               │
        ┌──────▼──────┐
        │   KEDA      │
        └──────┬──────┘
               │
       ┌───────▼─────────┐
       │  HorizontalPod  │
       │    Autoscaler   │
       └──────┬──────────┘
               │
      ┌────────▼─────────┐
      │ Alertmanager     │─────▶ Slack
      └──────────────────┘


⸻

🎯 목표 시나리오
• 5xx 오류율 > 5% → Prometheus 알림 발생
• KEDA가 에러 지표 기반으로 replicaCount = 0 처리
• Alertmanager가 Slack에 실시간 알림 발송

⸻

📈 Prometheus 지표 예시

rate(http_requests_total{job="checkout", status=~"5.."}[1m])
/
rate(http_requests_total{job="checkout"}[1m])

→ 1분간의 5xx 오류율이 5% 이상일 경우 탐지

⸻

📄 ScaledObject 정의 (에러율 기반 스케일 다운)

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: checkout-error-autoscaler
spec:
  scaleTargetRef:
    name: checkout-service
  minReplicaCount: 0
  maxReplicaCount: 10
  cooldownPeriod: 300
  pollingInterval: 30
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: error_rate
        query: |
          sum(rate(http_requests_total{job="checkout",status=~"5.."}[1m]))
          /
          sum(rate(http_requests_total{job="checkout"}[1m]))
        threshold: "0.05"

5% 이상 오류율이면 해당 서비스 자동 정지 또는 최소 스케일 유지

⸻

📣 Slack 경고 설정 (Alertmanager)

groups:
  - name: checkout-alerts
    rules:
      - alert: High5xxErrorRate
        expr: |
          (sum(rate(http_requests_total{job="checkout",status=~"5.."}[1m])) /
           sum(rate(http_requests_total{job="checkout"}[1m]))) > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Checkout 서비스 5xx 오류율 5% 초과"
          description: "자동 스케일 다운 & 운영팀 Slack 알림 발송됨"

Slack 연동은 Alertmanager에서 Webhook 형태로 구성 가능

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - channel: '#devops-alerts'
        send_resolved: true
        username: 'prometheus-bot'


⸻

🧠 고급 응용 전략

항목 설명
Rate Limit 설정 Istio/L7 프록시에서 오류 요청에 Rate Limit 적용
자동 복구 재시도 오류율 안정화 후, Replica 재가동 조건 추가
지표 복합 조건 응답 지연율 + 5xx 오류율 동시 조건 사용
배포 차단 Argo Rollouts와 연결하여 고장 서비스에 대해 배포 차단


⸻

🧪 테스트 시나리오
1. hey, wrk, k6 등으로 5xx 오류 유발
2. Prometheus → 경고 감지 → KEDA 스케일 다운
3. Slack → 운영 채널로 경고 발송 확인
4. 오류 회복 후 자동 스케일 복구

⸻

✅ 결론

이 구조는 단순한 모니터링을 넘어서 다음을 가능케 합니다:
• 장애 발생 → 자동 탐지 → 자가 차단 + 알림의 폐쇄 루프 완성
• 장애 확산 방지 및 초기 응답 속도 단축
• 운영 인력 개입 최소화로 안정성과 신뢰성 향상

다음 주제에서는 이 구조를 GitOps 파이프라인에 통합하거나, 혹은 Sentry/Bugsnag 연계 통한 애플리케이션 레벨 에러기반 스케일링을 다뤄보겠습니다.