Wave Flow 시작하기

이 가이드는 우선순위 기반 트래픽 제어로 핵심 서비스를 보호하기 위해 Wave Flow를 설정하는 과정을 안내합니다. 첫 Policy Set을 만들고, 프록시 인프라에 배포하고, 정상 동작을 확인하는 방법을 다룹니다.

💡

참고: 이 가이드는 예시 프록시로 Istio를 사용합니다. 하지만 Wave Flow는 Proxy-WASM을 지원하는 모든 서비스 메시나 API Gateway(Linkerd, Kuma, Consul, Kong, NGINX, Envoy Gateway, APISIX)에서 동작합니다. 개념과 UI 단계는 모든 프록시에서 동일하며, 검증 명령어만 다릅니다.

사전 요구사항

시작하기 전에 다음을 준비하세요.

필요 인프라

프록시 또는 서비스 메시: 다음 중 Proxy-WASM을 지원하는 것 하나
- Istio 1.14 이상 (Ingress Gateway, Sidecar 또는 Ambient Mesh)
- Envoy Gateway, Kong Gateway, NGINX Ingress, APISIX
- Linkerd, Kuma 또는 Consul (서비스 메시)
Wave Agent: 클러스터에 설치되어 연결되어 있어야 함
Kubernetes 접근 권한: Deployment를 조회할 수 있는 kubectl 권한
Wave Console 접근 권한: Wave 웹 콘솔에 대한 접근 권한

1단계: 트래픽 패턴 파악하기

Wave Flow를 설정하기 전에 어떤 트래픽 유형이 비즈니스에서 가장 중요한지 파악합니다.

고려할 질문:

매출을 발생시키는 엔드포인트는? (예: /checkout, /payment, /order)
가장 가치 있는 사용자는? (예: 프리미엄 구독자, 엔터프라이즈 고객)
읽기 전용 작업과 쓰기 작업은 어떻게 구분되는가? (예: GET과 POST 요청)
다운스트림 의존 관계에 있는 서비스는? (예: 인증, 데이터베이스 쓰기)

우선순위 매핑 예시:

트래픽 유형	비즈니스 영향	권장 우선순위 클래스
Checkout API	직접적 매출 손실	CRITICAL
사용자 인증	모든 기능 차단	CRITICAL
결제 처리	직접적 매출 손실	CRITICAL
사용자 대시보드	높은 사용자 영향	IMPORTANT
상품 탐색	중간 수준 사용자 영향	MODERATE
검색 추천	낮은 사용자 영향	BULK
추천 기능	있으면 좋은 정도	BULK

2단계: 첫 Policy Set 만들기

Traffic Rules 페이지 접속

Wave 웹 콘솔에 로그인합니다
왼쪽 사이드바에서 Traffic Rules로 이동합니다
드롭다운에서 대상 클러스터를 선택합니다

새 Policy Set 생성

오른쪽 상단의 "Create" 버튼을 클릭합니다
정책 생성 드로어가 열립니다

기본 설정 구성

Policy Set 이름: 정책을 설명하는 이름을 입력합니다 (예: production-api-priority)

예시:

Name: production-api-priority

우선순위 클래스 구성

각 Policy Set에는 네 가지 우선순위 클래스가 있습니다. 클래스마다 다음을 설정합니다.

차단 전략:

Disabled: 이 우선순위 클래스는 절대 차단하지 않음 (항상 허용)
Auto: 시스템에 부하가 걸리면 자동으로 차단
Force: 이 트래픽을 항상 차단 (테스트나 긴급 트래픽 차단에 유용)

Match Rules (어떤 요청이 이 클래스에 속하는지 정의):

HTTP Headers: 요청 헤더 기준 매치
URL Paths: URL 경로 prefix 기준 매치
HTTP Methods: HTTP 메서드 기준 매치 (GET, POST 등)

설정 예시:

CRITICAL - 절대 차단 안 함

차단 전략: Disabled

Match Rules:

Paths:
- /checkout/* (체크아웃 흐름)
- /payment/* (결제 처리)
- /api/v1/auth/* (인증)
Methods: POST, PUT, DELETE (쓰기 작업)

목적: 매출을 발생시키는 작업과 핵심 쓰기 작업 보호

대상 Deployment 선택

이 정책을 적용할 프록시를 선택합니다.

Target Type:

Ingress Gateway (권장): 클러스터로 들어오는 모든 트래픽에 적용 (Istio, Kong, NGINX, Envoy Gateway 등)
Sidecar: 특정 서비스 Sidecar에 적용 (Istio, Linkerd, Kuma, Consul)
Ambient Waypoint: Istio ambient mesh의 waypoint 프록시에 적용 (Istio 전용 기능)

Select Targets:

클러스터 트리를 펼쳐 사용 가능한 대상을 확인합니다
Ingress Gateway나 대상 프록시 옆의 체크박스를 선택합니다
정책은 선택한 대상에 WASM 모듈로 배포됩니다

Ingress Gateway와 Sidecar 비교

대부분의 경우 정책을 Ingress Gateway에 적용하는 것을 권장합니다.

모든 외부 트래픽을 하나의 지점에서 제어
관리가 쉬움 (정책 하나로 클러스터 전체 커버)
리소스 사용량이 낮음 (여러 개 대신 WASM 모듈 하나)

다음과 같은 경우에는 Sidecar 대상을 사용하세요.

서비스마다 다른 우선순위 규칙이 필요한 경우
ingress와 무관하게 서비스 단위로 제어하고 싶은 경우

활성화 및 저장

"Enabled" 토글을 Yes로 설정합니다 (테스트 목적이면 비활성 상태로 둡니다)
**"Save"**를 클릭해 정책을 배포합니다

정책은 몇 초 안에 선택한 대상에 WASM 모듈로 배포됩니다.

3단계: 배포 확인

저장 후 정책이 활성화되었는지 확인합니다.

Wave Console 확인

Traffic Rules 페이지로 돌아갑니다
테이블에서 새로 만든 정책을 확인할 수 있습니다
Enabled 열에 녹색 "Yes" 배지가 표시됩니다

4단계: 트래픽과 차단 모니터링

실시간 로그 보기

정책의 로그/상세 페이지에 접근하려면 다음과 같이 합니다.

Traffic Rules 테이블에서 해당 정책의 Actions 열에 있는 "Logs" 버튼을 클릭합니다

상세 페이지에서 다음 정보를 확인할 수 있습니다.

우선순위 클래스별 총 요청 수
차단 결정 (허용 대 거부)
각 분류의 타임스탬프
정책 설정 상세 정보

로그 해석하기

로그 테이블은 다음 열로 차단 이벤트를 보여줍니다.

Timestamp: 차단 결정이 내려진 시점
Workload: 정책이 모니터링 중인 워크로드 (namespace/deployment)
CPU Utilization: 해당 시점의 워크로드 CPU 사용량
Shed Status: 현재 차단 중인 우선순위 클래스를 보여주는 배지 (BULK, MODERATE, IMPORTANT, CRITICAL)
Status: 성공/오류 표시와 해당 시 사유

Shed Status 읽는 법:

None: 차단 중인 트래픽 없음 (정상 동작)
BULK 배지: BULK 우선순위 트래픽만 차단 중
MODERATE + BULK 배지: MODERATE와 BULK 트래픽 모두 차단 중
IMPORTANT 배지: 시스템이 심각한 부하 상태 (IMPORTANT 트래픽 차단 중)
CRITICAL 배지: 치명적 장애 상태이며, 올바르게 설정했다면 절대 발생하면 안 됨

정상 동작:

대부분의 로그 항목이 "None"이거나 "BULK"만 차단 중으로 표시됨
CPU 사용량이 안정적으로 유지됨
CRITICAL이나 IMPORTANT 차단 없음

부하 상태:

MODERATE와 BULK 차단 빈도 증가
CPU 사용률 상승
극심한 피크 상황에서는 IMPORTANT도 차단될 수 있음 ("Auto" 전략으로 설정한 경우)

5단계: 부하 테스트 (선택)

Wave Flow가 올바르게 동작하는지 확인하려면 트래픽 부하를 시뮬레이션합니다.

⚠️

먼저 스테이징에서 테스트하세요

부하 시나리오는 항상 프로덕션 전에 스테이징 환경에서 먼저 테스트합니다. 실제 사용자 트래픽을 차단하면 사용자 경험에 영향을 줄 수 있습니다.

부하 생성

부하 테스트 도구로 트래픽을 생성합니다.

# Install hey (HTTP load generator)
go install github.com/rakyll/hey@latest
 
# Generate BULK traffic (recommendations endpoint)
hey -z 60s -c 100 https://your-domain.com/recommendations
 
# Generate CRITICAL traffic (checkout endpoint)
hey -z 60s -c 50 https://your-domain.com/checkout/submit

예상 동작

부하 테스트 중에는 다음과 같이 동작합니다.

CRITICAL 요청은 100% 성공률을 유지해야 함 (HTTP 200)
BULK 요청은 차단되면서 HTTP 503 (Service Unavailable) 응답을 받을 수 있음
전체 시스템 지연 시간은 안정적으로 유지되어야 함 (차단이 과부하를 방지)

자주 발생하는 문제와 트러블슈팅

WASM 모듈이 배포되지 않음

문제: WASM 플러그인 설정이 생성되지 않습니다 (예: Istio의 EnvoyFilter, 다른 프록시의 WasmPlugin).

해결 방법:

프록시가 Proxy-WASM을 지원하는지 확인합니다 (프록시 버전과 WASM 지원 여부 확인)
Wave Agent가 WASM 플러그인 리소스를 생성할 권한이 있는지 확인합니다
Agent 로그를 확인합니다: kubectl logs -n wave-autoscale deployment/wave-autoscale-agent
Istio의 경우 kubectl get envoyfilter -n istio-system으로 EnvoyFilter가 존재하는지 확인합니다

모든 트래픽이 차단됨

문제: CRITICAL 트래픽까지 HTTP 503으로 거부됩니다.

해결 방법:

CRITICAL 클래스의 차단 전략이 **"Disabled"**로 설정되어 있는지 확인합니다
대상이 올바른지 확인합니다 (정책이 올바른 ingress/sidecar에 적용되었는지)
정책이 활성화되어 있는지 확인합니다 (UI 토글)
Match Rules를 확인합니다. CRITICAL 클래스에 매치 규칙이 정의되어 있지 않을 수 있습니다

부하 상황에서 차단이 발생하지 않음

문제: 시스템은 과부하 상태인데 Wave Flow가 트래픽을 전혀 차단하지 않습니다.

해결 방법:

차단 전략이 **"Auto"**로 설정되어 있는지 확인합니다 ("Disabled"가 아닌지)
부하가 실제로 임계값에 도달했는지 확인합니다 (Wave Flow는 필요할 때만 차단함)
Match Rules가 올바른지 확인합니다 (트래픽이 어떤 우선순위 클래스와도 매치되지 않을 수 있음)
Envoy 지표를 확인해 WASM 모듈이 요청을 수신하고 있는지 확인합니다

다음 단계

Wave Flow 설정을 마쳤다면 다음을 살펴보세요.

고급 패턴 학습: 더 깊이 있는 설정 옵션은 우선순위 기반 트래픽 보호를 참고하세요

모범 사례: 보수적으로 시작하기

프로덕션에 Wave Flow를 처음 배포할 때는 다음 순서를 따르세요.

정책을 만들되 비활성화 상태로 유지합니다
1~2주간 트래픽 패턴을 모니터링합니다
실제 트래픽을 기반으로 Match Rules를 다듬습니다
트래픽이 적은 시간대에 정책을 활성화합니다
피크 시간대까지 점진적으로 적용 범위를 확대합니다
처음 며칠간은 지표를 면밀히 모니터링합니다

궁금한 점이 있으신가요? 고급 설정 옵션은 우선순위 기반 트래픽 보호 가이드를 참고하세요. 다른 Wave 기능과의 연동은 통합 패턴을 참고하세요.

개요 우선순위 기반 트래픽 보호