korean-docs
Wave Flow
개요

Wave Flow 개요

Wave Flow는 Wave의 우선순위 기반 트래픽 보호 시스템입니다. 고부하 상황에서 덜 중요한 트래픽을 지능적으로 차단해 핵심 서비스를 보호합니다. 서비스 메시에 WebAssembly(WASM) 모듈 형태로 직접 배포되므로, 추가 Sidecar나 인프라 오버헤드 없이 세밀하고 저지연의 트래픽 보호를 제공합니다.

Wave Flow란?

Wave Flow는 우선순위 기반 트래픽 보호를 구현합니다. 이는 들어오는 요청을 우선순위 등급(CRITICAL, IMPORTANT, MODERATE, BULK)으로 분류하고, 서비스에 부하가 걸리면 우선순위가 낮은 트래픽을 자동으로 차단하는 전략입니다. 이를 통해 인프라 용량이 제한된 상황에서도 가장 중요한 비즈니스 기능은 계속 사용할 수 있습니다.

모든 트래픽을 동일하게 취급하는 기존의 rate limiting이나 circuit breaker와 달리, Wave Flow는 얼마나 많은 요청을 허용할지가 아니라 어떤 요청을 처리할지를 비즈니스 우선순위에 따라 지능적으로 결정합니다.

주요 이점

  • 매출에 직결되는 트래픽 보호: 트래픽 급증 시에도 체크아웃, 결제, 인증 흐름이 계속 동작하도록 보장합니다
  • 인프라 오버헤드 제로: 기존 서비스 메시 프록시에 WASM 모듈로 직접 배포됩니다 (신규 Pod, 신규 Sidecar 불필요)
  • 밀리초 미만의 지연 시간: 네이티브 WASM 실행이므로 외부 rate limiter 대비 오버헤드가 거의 없습니다
  • 세밀한 제어: HTTP 헤더, 경로, 메서드를 기준으로 매치 규칙을 설정해 정교하게 트래픽을 분류합니다
  • 서비스 메시 네이티브: Istio, Linkerd, Kuma, Consul 및 주요 API Gateway(Kong, NGINX, Envoy, APISIX)와 함께 동작합니다
  • 동적 설정: 서비스를 재배포하거나 프록시를 재시작하지 않고도 트래픽 규칙을 업데이트할 수 있습니다
  • 실시간 지표: Wave 대시보드에서 차단 결정과 보호된 트래픽을 모니터링합니다

동작 방식

아키텍처 개요

⚠️

사전 요구사항: Wave Flow는 Proxy-WASM을 지원하는 프록시 또는 서비스 메시가 필요합니다. 지원되는 옵션은 다음과 같습니다.

  • Istio (Ingress Gateway, Sidecar 또는 Ambient Waypoint)
  • Linkerd, Kuma, Consul (서비스 메시)
  • Kong Gateway, NGINX Ingress, Envoy Gateway, APISIX (API 게이트웨이)

Wave Flow는 이 프록시들 내부에서 실행되며 트래픽을 가로채고 제어하는 WebAssembly(WASM) 모듈로 배포됩니다.

Wave Flow Architecture Diagram

요청 흐름

요청 도착

클라이언트가 Ingress Gateway나 서비스 메시 프록시로 HTTP 요청을 보냅니다

WASM 필터 가로채기

라우팅되기 전에 Wave Flow WASM 모듈이 요청을 가로챕니다

우선순위 분류

요청은 설정된 우선순위 클래스 규칙과 매치됩니다.

  • HTTP 헤더 확인 (예: X-User-Type: premium)
  • URL 경로 확인 (예: /checkout/*, /api/v1/payment)
  • HTTP 메서드 확인 (GET, POST, PUT, DELETE)

차단 결정

분류된 우선순위와 현재 시스템 부하에 따라 결정합니다.

  • CRITICAL: 절대 차단하지 않음 (항상 허용)
  • IMPORTANT: 극심한 부하 상황에서만 차단 (auto 모드)
  • MODERATE: 용량이 부족해지면 선제적으로 차단
  • BULK: 상위 우선순위 트래픽을 보호하기 위해 적극적으로 차단

응답

요청 결과:

  • 허용됨: 요청이 백엔드 서비스로 전달됩니다
  • 거부됨: 즉시 HTTP 503 (Service Unavailable)을 반환합니다

배포 모드

Wave Flow는 세 가지 구성으로 배포할 수 있습니다.

Ingress Gateway 모드 (대부분의 경우 권장)

Wave Flow를 Ingress Gateway(Istio, Kong, NGINX, Envoy 등)에 배포하면 클러스터로 들어오는 모든 트래픽을 보호할 수 있습니다. 진입점에서 클러스터 전체의 트래픽을 제어할 수 있어 가장 널리 쓰이는 배포 패턴입니다.

  • 범위: 클러스터로 들어오는 모든 트래픽
  • 활용 사례: 외부 부하로부터 애플리케이션 전체를 보호
  • 구성: Ingress Gateway에 단일 정책 세트 적용
  • 지원 Gateway: Istio Ingress Gateway, Kong Gateway, NGINX Ingress, Envoy Gateway, APISIX

활용 사례

이커머스: 플래시 세일 중 체크아웃 보호

문제: 블랙 프라이데이 플래시 세일 중 체크아웃 API에 과부하가 걸립니다. 사용자는 상품을 둘러볼 수는 있지만 구매를 완료하지 못해 매출 손실로 이어집니다.

해결책: 체크아웃과 결제 흐름을 우선하도록 Wave Flow를 설정합니다.

  • CRITICAL: /checkout/*, /payment/* 경로
  • IMPORTANT: /cart/*, /api/v1/orders
  • MODERATE: /products/*, /search
  • BULK: /recommendations, /similar-items

결과: 구매 의사가 있는 사용자는 체크아웃을 계속 이용할 수 있고, 상품 탐색과 추천 트래픽은 용량 보호를 위해 차단됩니다.

SaaS 플랫폼: 트래픽 급증 시 유료 사용자 보호

문제: 마케팅 캠페인 중 무료 사용자 트래픽이 API를 과도하게 점유해 유료 고객의 서비스 품질이 떨어집니다.

해결책: HTTP 헤더로 트래픽을 분류합니다.

  • CRITICAL: X-User-Tier: enterprise (엔터프라이즈 고객)
  • IMPORTANT: X-User-Tier: pro (Pro 사용자)
  • MODERATE: X-User-Tier: free (무료 사용자)
  • BULK: 인증되지 않은 요청

결과: 유료 고객은 성능 저하를 전혀 겪지 않고, 무료 사용자 트래픽은 용량 보호를 위해 차단됩니다.

금융 서비스: 핵심 거래 처리 보장

문제: 시장 변동성으로 트레이딩 플랫폼에 트래픽이 몰리지만, 실제 거래는 그중 일부에 불과합니다. 대부분은 포트폴리오 조회와 시세 확인 요청입니다.

해결책: 거래 엔드포인트를 우선합니다.

  • CRITICAL: POST /api/v1/trades, POST /api/v1/orders
  • IMPORTANT: GET /api/v1/portfolio, GET /api/v1/balance
  • MODERATE: GET /api/v1/market-data
  • BULK: GET /api/v1/news, GET /api/v1/analytics

결과: 거래 체결은 절대 막히지 않고, 중요하지 않은 데이터 조회는 피크 부하 시 차단됩니다.

헬스케어: 응급 진료 시스템 우선 처리

문제: 근무 교대 시간대에 전자의무기록(EHR) 시스템에 부하가 몰립니다. 응급실 시스템은 계속 응답할 수 있어야 합니다.

해결책: 부서와 긴급도에 따라 분류합니다.

  • CRITICAL: X-Department: emergency, X-Department: icu
  • IMPORTANT: X-Department: surgery, X-Department: cardiology
  • MODERATE: X-Department: outpatient
  • BULK: 행정 및 일정 관리 시스템

결과: 행정 시스템의 트래픽이 차단되는 동안에도 생명과 직결된 시스템은 계속 사용할 수 있습니다.

대안과의 비교

구분Wave Flow기존 Rate LimitingCircuit BreakerAPI Gateway Rate Limit
우선순위 기반✅ 예 (4단계)❌ 아니오 (모든 트래픽 동일 취급)❌ 아니오 (모든 트래픽 동일 취급)⚠️ 제한적 (쿼터 기반)
지연 오버헤드약 0.1ms (WASM)약 1~5ms (Sidecar)약 0.5ms (라이브러리)약 10~50ms (외부 서비스)
인프라 비용없음 (기존 프록시 재사용)높음 (추가 Sidecar)낮음 (라이브러리)높음 (API Gateway)
동적 규칙✅ 실시간⚠️ 배포 필요⚠️ 배포 필요✅ 실시간
서비스 메시 네이티브✅ 멀티 프록시 지원❌ 외부 방식❌ 코드 레벨❌ 외부 방식
세밀한 제어✅ 헤더, 경로, 메서드⚠️ IP 기반❌ 이진 (open/closed)⚠️ API 키 기반
비즈니스 맥락✅ 우선순위 클래스❌ 없음❌ 없음⚠️ 제한적

Wave Flow를 사용해야 할 때

다음과 같은 경우 Wave Flow를 사용하세요:

  • Proxy-WASM을 지원하는 프록시(Istio, Envoy, Kong, NGINX, Linkerd, Kuma, Consul, APISIX)를 사용 중인 경우
  • 트래픽 유형별로 비즈니스 중요도가 다른 경우
  • 장애 상황에서 매출을 발생시키는 흐름을 보호해야 하는 경우
  • 코드 변경 없이 인프라 레벨에서 보호하고 싶은 경우
  • 지연 예산상 밀리초 미만의 오버헤드가 중요한 경우

다음과 같은 경우에는 Wave Flow를 사용하지 마세요:

  • 인프라가 Proxy-WASM을 지원하지 않는 경우 (호환 프록시나 서비스 메시 필요)
  • 모든 트래픽의 중요도가 동일해 우선순위 구분이 필요 없는 경우
  • 코드 레벨의 애플리케이션 rate limiting을 선호하는 경우
  • 고급 쿼터 관리가 필요한 경우 (대신 API Gateway를 사용하세요)

다음 단계

Wave Flow로 핵심 서비스를 보호할 준비가 되셨나요?

  1. 시작하기 가이드 - 단계별 설정과 첫 정책 구성
  2. 우선순위 기반 트래픽 보호 - 트래픽 클래스와 차단 전략에 대한 심화 내용
  3. Autopilot과의 연동 - 수평 스케일링과 결합해 종합적으로 보호

궁금한 점이 있으신가요? Wave Flow는 프로덕션에서 바로 사용할 수 있으며, 트래픽이 많은 애플리케이션을 보호하는 데 실제로 활용되고 있습니다. 아키텍처에 맞는 구체적인 구현 가이드가 필요하면 Wave 문서를 참고하거나 지원팀에 문의하세요.

CRDs시작하기