장애 탐지 & 알림 설계 — RED·USE 지표와 모니터링 4계층

장애를 빠르게 탐지하지 못하면 사용자가 먼저 알게 됩니다. 목표는 사용자보다 먼저 장애를 감지하고, 즉시 행동 가능한 알림을 받는 것입니다.

모니터링 4계층 구조

장애는 단일 지표가 아닌 여러 계층의 신호가 복합적으로 나타납니다.

[사용자 경험]     → 합성 모니터링, 실사용자 모니터링(RUM)
      ↓
[API / 서비스]    → 에러율, 응답 시간, 처리량 (RED 지표)
      ↓
[애플리케이션]    → 예외, 로그, 트레이스
      ↓
[인프라]          → CPU, 메모리, 디스크, 네트워크 (USE 지표)

위에서부터 탐지할수록 사용자 영향을 기준으로 경보를 울립니다. 아래 계층은 원인 분석(RCA)에 활용합니다.

RED 지표: 서비스 건강 상태 핵심 3종

지표	의미	임계치 예시
Rate	초당 요청 수	평소 대비 50% 이상 급감/급증
Errors	에러율	> 1% 경고, > 5% 위험
Duration	응답 시간(p95)	> 500ms 경고, > 2s 위험

# Prometheus 규칙 예시
groups:
  - name: service-health
    rules:
      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "에러율 5% 초과 (현재: {{ $value | humanizePercentage }})"

      - alert: SlowResponseTime
        expr: |
          histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 2
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "p95 응답 시간 2초 초과"

USE 지표: 인프라 포화도 확인

지표	의미
Utilization	리소스 사용률 (CPU, 메모리 %)
Saturation	대기열·백로그 (큐 길이, 스레드 대기)
Errors	하드웨어·커널 오류 횟수

합성 모니터링 (Synthetic Monitoring)

실제 사용자 흐름을 주기적으로 시뮬레이션해서 외부에서 서비스 가용성을 검증합니다.

# Playwright 기반 합성 테스트 예시
async def check_checkout_flow():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page()

        await page.goto("https://shop.example.com")
        await page.click("[data-testid=add-to-cart]")
        await page.click("[data-testid=checkout]")

        # 결제 페이지 도달 여부 확인 (5초 이내)
        await page.wait_for_selector("[data-testid=payment-form]", timeout=5000)

        elapsed = page.evaluate("performance.now()")
        assert elapsed < 3000, f"체크아웃 흐름 {elapsed}ms 초과"

실행 주기: 1분마다 (글로벌 리전 3곳 이상)
실패 기준: 연속 2회 실패 시 P1 알림

알림 품질 관리: 노이즈 줄이기

경보가 많을수록 온콜 담당자는 무감각해집니다.

알림 피로 진단 체크리스트:

지난 1주간 알림 중 실제 조치가 필요했던 비율이 50% 이상인가?
같은 알림이 반복적으로 울려 수동으로 끄고 있지 않은가?
알림 발생 후 3분 안에 무엇을 해야 하는지 명확한가?

# AlertManager: 유사 알림 그룹화로 폭풍 방지
route:
  group_by: ['alertname', 'service', 'env']
  group_wait: 30s          # 첫 알림 전 30초 대기 (묶기 위해)
  group_interval: 5m       # 그룹 갱신 주기
  repeat_interval: 2h      # 동일 알림 재전송 간격

inhibit_rules:
  # 서비스 전체 다운 알림이 있으면 개별 에러 알림 억제
  - source_match:
      alertname: ServiceDown
    target_match:
      severity: warning
    equal: ['service']

다음 단계

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →