Priority-Based Traffic Protection

우선순위 기반 트래픽 보호는 부하 상황에서 핵심 서비스를 지키는 Wave Flow의 핵심 메커니즘입니다. 모든 트래픽을 동일하게 취급하는 대신, Wave Flow는 각 요청을 네 가지 우선순위 등급 중 하나로 분류하고, 어떤 요청을 처리하고 어떤 요청을 shed(차단)할지 지능적으로 판단합니다.

The Four Priority Classes

Wave Flow는 높은 순위부터 낮은 순위까지 고정된 네 가지 우선순위 클래스 체계를 사용합니다.

1. CRITICAL - 차단 안 함

목적: 시스템 부하와 무관하게 절대 차단되어서는 안 되는, 미션 크리티컬한 트래픽을 보호합니다.

사용 시점:

• 직접적인 매출 관련 작업(checkout, 결제 처리)
• 핵심 쓰기 작업(주문 제출, 계정 생성)
• 인증 및 인가 흐름
• 실패 시 연쇄 장애를 일으킬 수 있는 다운스트림 서비스 의존성

차단 동작: 항상 Disabled로 설정(절대 차단하지 않음)

예시:

• POST /checkout/submit - 최종 checkout 제출
• POST /api/v1/payments - 결제 처리
• POST /api/v1/auth/login - 사용자 인증
• POST /api/v1/orders - 주문 생성

2. IMPORTANT - 극단적 부하에서만 차단

목적: 중요하지만 극심한 과부하 상황에서는 드물게 실패해도 괜찮은, 가치가 높은 트래픽을 보호합니다.

사용 시점:

• 유료/프리미엄 사용자 트래픽
• 실시간 대시보드 및 모니터링
• 핵심 읽기 작업(주문 상태, 계좌 잔액)
• 비핵심 쓰기 작업(프로필 수정, 환경설정)

차단 동작: Auto로 설정(필요할 때만 차단)

예시:

• X-User-Tier: enterprise 헤더(엔터프라이즈 고객)
• GET /api/v1/orders/{id} - 주문 상태 조회
• POST /api/v1/support/tickets - 지원 티켓 생성
• GET /api/v1/dashboard - 사용자 대시보드

IMPORTANT 트래픽이 차단되는 경우:

• 시스템이 이미 MODERATE, BULK 트래픽을 차단하고 있는 경우
• 백엔드 서비스 용량이 95%를 초과한 경우
• 응답 지연이 감당할 수 없는 수준으로 치솟는 경우
• 차단하지 않으면 시스템이 완전히 장애 상태에 이를 수 있는 경우

3. MODERATE - 선제적으로 차단

목적: 가치는 있지만, 상위 우선순위 클래스를 보호하기 위해 성능을 낮출 수 있는 범용 트래픽입니다.

사용 시점:

• 상품 탐색 및 카탈로그 조회
• 검색 및 필터링 작업
• 무료 요금제 / 비유료 사용자 트래픽
• 덜 중요한 읽기 작업

차단 동작: Auto로 설정(IMPORTANT 트래픽에 영향이 가기 전에 차단)

예시:

• GET /products - 상품 목록
• GET /search?q=shoes - 상품 검색
• GET /api/v1/recommendations - 추천(중간 정도로 중요한 경우)
• X-User-Tier: free 헤더(무료 요금제 사용자)

MODERATE 트래픽이 차단되는 경우:

• 시스템 용량이 80~90%인 경우
• 응답 지연이 증가하고 있는 경우
• BULK 트래픽이 이미 대량으로 차단되고 있는 경우
• CRITICAL/IMPORTANT 트래픽을 처리할 여유 용량이 필요한 경우

4. BULK - 적극적으로 차단

목적: 있으면 좋은 부가 기능을 제공하지만, 용량 보호를 위해 자유롭게 차단해도 되는 낮은 우선순위 트래픽입니다.

사용 시점:

• 머신러닝 추천 및 개인화
• 분석 및 트래킹
• Prefetch 및 캐싱
• 필수적이지 않은 백그라운드 작업
• 내부 테스트 트래픽

차단 동작: Auto로 설정(가장 먼저, 가장 적극적으로 차단)

예시:

• GET /recommendations - ML 기반 추천
• POST /api/v1/analytics - 분석 이벤트
• GET /similar-items - 관련 상품 추천
• GET /static/prefetch/* - Prefetch 요청

BULK 트래픽이 차단되는 경우:

• 시스템 용량이 70%를 초과한 경우
• 리소스 제약의 조짐이 조금이라도 보이는 경우
• 상위 우선순위를 위한 여유 용량을 선제적으로 확보하는 경우

Match Rules: Traffic Classification

Match Rules는 Wave Flow가 들어오는 요청을 우선순위 클래스로 분류하는 방식을 정의합니다. 각 우선순위 클래스는 여러 개의 match rule을 가질 수 있으며, 일치하는 규칙을 찾을 때까지 순서대로 평가됩니다.

Match Rule 구성 요소

각 match rule은 세 가지 선택적 구성 요소로 이루어지며, 이 중 최소 하나는 반드시 지정해야 합니다.

1. HTTP Headers

요청 헤더의 이름과 값을 기준으로 매칭합니다.

형식:

headers:
  - name: "X-User-Type"
    value: "premium"
  - name: "X-API-Key"
    value: "enterprise-key-12345"

주요 활용 사례:

• 사용자 등급 분류(X-User-Type, X-Subscription-Tier)
• API 클라이언트 식별(X-API-Client, User-Agent)
• 내부 트래픽과 외부 트래픽 구분(X-Internal-Request: true)
• 기능 플래그(X-Beta-Feature: enabled)

매칭 동작:

• 정확한 문자열 일치(대소문자 구분)
• 한 규칙 내 모든 헤더가 일치해야 함(AND 로직)
• OR 로직이 필요하면 별도의 규칙을 사용

2. URL Path Prefixes

URL 경로의 prefix를 기준으로 매칭합니다.

형식:

paths:
  - prefix: "/checkout/"
  - prefix: "/api/v1/payments"
  - prefix: "/admin"

주요 활용 사례:

• 엔드포인트 기반 우선순위(/checkout/*는 CRITICAL, /search/*는 MODERATE)
• API 버전 관리(/api/v1/* 대 /api/v2/*)
• 관리자 트래픽과 사용자 트래픽 구분(/admin/* 대 /app/*)
• 공개 엔드포인트와 인증 필요 엔드포인트 구분

매칭 동작:

• Prefix 일치(정확히 일치하는 것이 아님)
• /checkout/는 /checkout/step1, /checkout/submit 등과 일치
• 순서가 중요합니다. 더 구체적인 prefix를 앞에 배치해야 합니다

3. HTTP Methods

HTTP 메서드를 기준으로 매칭합니다.

형식:

methods:
  - "POST"
  - "PUT"
  - "DELETE"

주요 활용 사례:

• 읽기(GET)보다 쓰기 작업(POST, PUT, DELETE) 보호
• 핵심 변경 작업과 안전한 읽기 작업 구분
• 대량 import 작업

매칭 동작:

• 정확한 문자열 일치(대소문자 구분 안 함)
• 한 규칙에 여러 메서드가 있으면 OR 로직(하나라도 일치하면 성공)

Match Rule 평가 순서

요청이 도착하면 Wave Flow는 다음 순서로 우선순위 클래스를 평가합니다.

1. CRITICAL 클래스 규칙
2. IMPORTANT 클래스 규칙
3. MODERATE 클래스 규칙
4. BULK 클래스 규칙

각 클래스 내에서 규칙은 다음과 같이 평가됩니다.

• 규칙 중 하나라도 일치하면 → 해당 클래스로 분류됩니다
• 일치하는 규칙이 없으면 → 다음 우선순위 클래스로 넘어갑니다
• 어떤 클래스에도 일치하지 않으면 → BULK(최하위 우선순위)로 기본 분류됩니다

Example: E-Commerce Priority Configuration

CRITICAL:
  shed: disabled
  match_rules:
    # Checkout flow
    - paths:
        - prefix: "/checkout/"
      methods: ["POST", "PUT"]
    # Payment processing
    - paths:
        - prefix: "/api/v1/payments"
    # Order submission
    - paths:
        - prefix: "/api/v1/orders"
      methods: ["POST"]
    # Authentication
    - paths:
        - prefix: "/api/v1/auth"
 
IMPORTANT:
  shed: auto
  match_rules:
    # Premium users (all traffic)
    - headers:
        - name: "X-User-Tier"
          value: "premium"
    # Cart operations
    - paths:
        - prefix: "/cart/"
    # Order status checks
    - paths:
        - prefix: "/api/v1/orders"
      methods: ["GET"]
    # User profile
    - paths:
        - prefix: "/api/v1/users/profile"
 
MODERATE:
  shed: auto
  match_rules:
    # Product browsing
    - paths:
        - prefix: "/products/"
    # Search
    - paths:
        - prefix: "/search"
    # Inventory checks
    - paths:
        - prefix: "/api/v1/inventory"
      methods: ["GET"]
 
BULK:
  shed: auto
  match_rules:
    # Recommendations
    - paths:
        - prefix: "/recommendations"
    # Similar products
    - paths:
        - prefix: "/similar-items"
    # Analytics tracking
    - paths:
        - prefix: "/api/v1/analytics"
    # Static assets
    - paths:
        - prefix: "/static/"

트래픽 보호 전략

각 우선순위 클래스에는 트래픽을 언제, 얼마나 적극적으로 차단할지 결정하는 차단 전략이 있습니다.

Disabled - 차단 안 함

동작: 이 클래스의 트래픽은 시스템 부하와 무관하게 절대 차단되지 않습니다.

사용 시점: CRITICAL 클래스 전용(매출에 직결되며 반드시 성공해야 하는 작업)

설정:

shed: disabled

영향:

• 요청의 100%가 통과됩니다
• 자동 보호 장치가 없으므로, 인프라 용량에 전적으로 의존합니다
• 시스템이 장애를 겪으면 CRITICAL 트래픽도 함께 실패합니다

Auto - 부하 기반 차단

동작: 시스템에 부하가 걸리면 트래픽이 자동으로 차단됩니다. 임계값과 차단 강도는 우선순위 클래스에 따라 달라집니다.

• BULK: 적극적으로 차단(가장 먼저 차단되며 차단율도 가장 높음)
• MODERATE: 중간 수준으로 차단(CRITICAL/IMPORTANT 보호)
• IMPORTANT: 보수적으로 차단(극단적 부하에서만)

사용 시점: IMPORTANT, MODERATE, BULK 클래스

설정:

shed: auto

동작 방식:

Wave Flow는 다음과 같은 백엔드 서비스 상태 지표를 모니터링합니다.

• 응답 지연(P95, P99)
• 오류율(5xx 응답)
• 리소스 사용률(CPU, 메모리)
• 동시 요청 수

부하가 증가하면 다음 순서로 진행됩니다.

1. 용량 70~80%: BULK 트래픽 차단 시작
2. 용량 80~90%: BULK 차단 강화, MODERATE 차단 시작
3. 용량 90~95%: BULK 대량 차단, MODERATE 중간 수준 차단
4. 용량 95% 이상: BULK/MODERATE 최대 차단, IMPORTANT 차단 시작

Force - 항상 차단

동작: 이 클래스의 모든 트래픽은 항상 HTTP 503으로 거부됩니다.

사용 시점:

• 긴급 트래픽 차단(장애 대응)
• 차단 동작 테스트(클라이언트가 503을 올바르게 처리하는지 검증)
• 기능 임시 비활성화(예: 장애 중 추천 기능 비활성화)

설정:

shed: force

영향:

• 요청의 100%가 거부됩니다
• 장애 상황에서 비핵심 기능을 빠르게 비활성화할 때 유용합니다
• 서비스를 재배포하지 않고도 전환할 수 있습니다

사용 사례 예시:

블랙프라이데이에 데이터베이스가 과부하 상태에 빠졌다고 가정해봅니다.

1. BULK 클래스를 Force로 설정 → 추천, 분석 트래픽을 즉시 거부
2. MODERATE 클래스를 Force로 설정 → 상품 탐색, 검색 트래픽 거부
3. IMPORTANT/CRITICAL은 Auto로 유지 → checkout과 결제는 계속 동작
4. 데이터베이스 부하가 70% 감소하여 핵심 작업이 정상 처리됨
5. 장애가 해결되면 다시 Auto로 되돌림

Advanced Configuration Patterns

Pattern 1: 점진적 성능 저하(권장)

각 우선순위 클래스마다 서로 다른 임계값으로 Auto 차단을 설정합니다.

CRITICAL:
  shed: disabled  # Never shed
 
IMPORTANT:
  shed: auto      # Shed at 95%+ load
 
MODERATE:
  shed: auto      # Shed at 85%+ load
 
BULK:
  shed: auto      # Shed at 75%+ load

효과:

• 부하가 증가해도 완만하게 성능이 저하됨
• 가장 중요한 기능을 가장 오래 보호
• 사용자는 전체 장애가 아니라 일부 기능 손실만 경험

Pattern 2: 사용자 등급 기반 우선순위

사용자 구독 등급을 기준으로 트래픽을 분류합니다.

CRITICAL:
  shed: disabled
  match_rules:
    - headers:
        - name: "X-User-Tier"
          value: "enterprise"
 
IMPORTANT:
  shed: auto
  match_rules:
    - headers:
        - name: "X-User-Tier"
          value: "premium"
 
MODERATE:
  shed: auto
  match_rules:
    - headers:
        - name: "X-User-Tier"
          value: "basic"
 
BULK:
  shed: auto
  match_rules:
    - headers:
        - name: "X-User-Tier"
          value: "free"

효과:

• 유료 고객이 우선순위를 받음
• 무료 요금제 사용자가 가장 먼저 차단됨
• 업그레이드에 대한 가치 제안이 명확해짐

Pattern 3: 읽기/쓰기 분리

읽기 작업보다 쓰기 작업을 우선 보호합니다.

CRITICAL:
  shed: disabled
  match_rules:
    - methods: ["POST", "PUT", "DELETE", "PATCH"]
 
IMPORTANT:
  shed: auto
  match_rules:
    - methods: ["GET"]
      paths:
        - prefix: "/api/v1/orders"  # Important reads
        - prefix: "/api/v1/account"
 
MODERATE:
  shed: auto
  match_rules:
    - methods: ["GET"]  # All other reads

효과:

• 데이터 변경 작업이 보호됨
• 조회 위주 트래픽(탐색, 검색)이 먼저 차단됨
• 데이터베이스 쓰기 경합을 방지

Pattern 4: 엔드포인트별 우선순위

엔드포인트마다 비즈니스 가치가 다릅니다.

CRITICAL:
  shed: disabled
  match_rules:
    - paths:
        - prefix: "/checkout"    # $100 average order
        - prefix: "/payments"
 
IMPORTANT:
  shed: auto
  match_rules:
    - paths:
        - prefix: "/cart"        # $50 average cart value
        - prefix: "/wishlists"
 
MODERATE:
  shed: auto
  match_rules:
    - paths:
        - prefix: "/products"    # Browsing (low conversion)
        - prefix: "/reviews"
 
BULK:
  shed: auto
  match_rules:
    - paths:
        - prefix: "/recommendations"  # Nice-to-have

효과:

• 비즈니스 지표와 일치
• 보호 조치의 ROI가 명확함(고가치 트랜잭션 보호)

Best Practices

1. 보수적으로 시작하기

초기 설정:

• CRITICAL을 Disabled로 설정
• IMPORTANT를 Auto로 설정(단, 차단이 거의 발생하지 않아야 함)
• MODERATE/BULK를 Auto로 설정(부하 시 차단 발생 예상)

점진적으로 조정하기:

• 1~2주간 차단율을 모니터링합니다
• IMPORTANT가 한 번도 차단되지 않는다면, 정말로 중요한 트래픽이라는 뜻입니다
• MODERATE가 자주 차단되는데도 사용자 불만이 없다면, 분류가 올바르다는 뜻입니다

2. 비즈니스 지표와 정렬하기

우선순위와 매출 매핑:

• CRITICAL: 직접 매출($$$)
• IMPORTANT: 간접 매출($$)
• MODERATE: 사용자 경험($)
• BULK: 있으면 좋은 기능($0)

예시:

• Checkout(평균 주문 $100) → CRITICAL
• 상품 페이지(전환 가치 $5) → MODERATE
• 추천(전환 상승 $0.50) → BULK

3. 차단 동작 테스트하기

프로덕션 적용 전:

1. 스테이징 환경에서 정책을 생성합니다
2. hey, k6, JMeter 같은 도구로 부하를 생성합니다
3. BULK가 먼저 차단되고 CRITICAL은 절대 차단되지 않는지 확인합니다
4. HTTP 503을 받았을 때 클라이언트 동작을 테스트합니다

HTTP 503 응답 처리:

// Example: Retry logic for shedded requests
async function fetchWithRetry(url, options = {}) {
  const maxRetries = 3;
  const retryDelay = 1000; // 1 second
 
  for (let i = 0; i < maxRetries; i++) {
    const response = await fetch(url, options);
 
    if (response.status === 503) {
      // Request was shed — retry after delay
      await new Promise(resolve => setTimeout(resolve, retryDelay));
      continue;
    }
 
    return response;
  }
 
  throw new Error('Max retries exceeded');
}

4. 모니터링 및 알림 설정하기

추적할 핵심 지표:

• CRITICAL 거부율: 항상 0%여야 함(0% 초과 시 알림)
• IMPORTANT 거부율: 1% 미만이어야 함(5% 초과 시 알림)
• MODERATE/BULK 거부율: 허용 가능하지만 추세는 계속 추적

알림 설정:

# Example Prometheus alert
- alert: CriticalTrafficShed
  expr: waveflow_critical_rejected_total > 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "CRITICAL traffic is being shed"
    description: "Wave Flow is rejecting CRITICAL traffic. System is severely overloaded."

5. 우선순위 결정 문서화하기

의사결정 매트릭스 작성:

효과:

• 엔지니어링팀과 비즈니스팀 간 정렬
• 이해관계자에게 우선순위 결정 근거 제시
• 신규 엔지니어 온보딩 용이

Troubleshooting

Issue: 모든 트래픽이 차단되는 경우

증상:

• CRITICAL 트래픽마저 HTTP 503을 반환
• 모든 우선순위 클래스의 거부율이 100%

원인:

1. CRITICAL 클래스가 "Force"로 설정됨: "Disabled"로 변경
2. Match rules가 잘못됨: CRITICAL 클래스에 일치하는 규칙이 없음
3. 시스템이 완전히 과부하 상태: 인프라 부족

해결 방법:

• CRITICAL의 차단 전략이 "Disabled"인지 확인
• match rules가 예상 트래픽 패턴을 모두 포함하는지 확인
• 실제로 과부하 상태라면 인프라를 확장

Issue: 부하가 있어도 차단이 발생하지 않는 경우

증상:

• 시스템이 과부하 상태(높은 지연, 오류 발생)
• Wave Flow의 모든 클래스 거부율이 0%

원인:

1. 모든 클래스가 "Disabled"로 설정됨: 차단이 설정되지 않음
2. 부하가 프록시에 도달하지 않음: 트래픽이 ingress gateway를 우회
3. WASM 모듈이 배포되지 않음: 프록시 필터 설정 누락 또는 오설정

해결 방법:

• MODERATE/BULK를 "Auto"로 설정
• 트래픽이 ingress gateway나 서비스 메시를 통과하는지 확인
• WASM 모듈이 배포되어 있는지 확인:
  • Istio의 경우: kubectl get envoyfilter -n istio-system
  • 다른 프록시의 경우: 프록시의 WASM 플러그인 설정을 확인

Issue: 엉뚱한 트래픽이 차단되는 경우

증상:

• 중요한 사용자 트래픽이 HTTP 503을 받음
• 낮은 우선순위 트래픽은 성공

원인:

1. Match rules가 너무 광범위함: IMPORTANT 클래스가 너무 많이 매칭됨
2. Match rules가 너무 좁음: IMPORTANT 트래픽이 어떤 규칙에도 매칭되지 않음(BULK로 기본 분류됨)
3. Header/path 불일치: 애플리케이션이 예상된 헤더를 보내지 않음

해결 방법:

• match rules를 검토하고 구체성을 조정
• 요청이 어느 클래스에 매칭되는지 확인할 수 있도록 로깅 추가
• 애플리케이션이 예상된 헤더(X-User-Tier 등)를 보내는지 확인

Summary

우선순위 기반 트래픽 보호는 핵심 서비스를 보호하는 강력한 패턴입니다.

• 네 가지 우선순위 클래스: CRITICAL(차단 안 함), IMPORTANT(드물게 차단), MODERATE(선제적 차단), BULK(적극적 차단)
• Match Rules: HTTP 헤더, URL 경로, HTTP 메서드로 분류를 결정
• 차단 전략: Disabled(차단 안 함), Auto(동적 조정), Force(항상 차단)
• 점진적 성능 저하: 낮은 우선순위 트래픽부터 차단하여 핵심 기능을 가장 오래 보호

우선순위 클래스와 match rules를 신중하게 설정하면, 인프라 장애나 예상치 못한 트래픽 급증 상황에서도 가장 중요한 비즈니스 기능을 계속 사용 가능한 상태로 유지할 수 있습니다.

구현 방법은 Getting Started Guide를 참고하세요. 아키텍처 관련 내용은 Overview를 참고하세요.