필요한 이유

- Istio 서비스 메시에서 트래픽은 Envoy SideCar를 거침

- 기본 제공되는 설정(VirtualService, DestinationRule 등)으로 대부분 커버 됨

- 하지만 "커스텀 로직"이 필요한 경우가 존재.

- 이때 Envoy의 "필터 체인에 직접 코드를 넣는 수단"이 "Lua와 Wasm"

적용 우선순위

- "Istio 기본 CRD로 해결 -> EnvoyFilter(내장 필터) -> Lua -> Wasm" 순서로 복잡도가 올라감

- 가능한 앞 쪽에서 해결하는 게 운영상 편함

Lua

- 경량 스크립팅 방식

- EnvoyFilter yaml 안에 코드를 인라인으로 넣으면 "바로 적용, 별도 빌드 과정 필요 없음"

- 헤더 가공, 조건부 403 리턴, 간단한 로깅 태깅 같은 "가벼운 작업에 적합"

Wasm(와즘, WebAssembly)

- Wasm 자체는 바이너리 실행 포맷이고, proxy-wasm은 프록시와 wasm 모듈 간의 인터페이스 스펙

- Rust, Go 등으로 필터를 작성하고 ".wasm"으로 컴파일한 뒤 OCI 레지스트리에 푸시해서 배포

- Istio에서는 "WasmPlugin" CRD를 적용

- 요청 바디피싱, 외부 서비스 연동, 복잡한 인증/인가 등 "무거운 작업에 적합"

위험도

- Istio에서는 "EnvyFilter 리소스로 Envoy 내부 설정을 직접 조작하는 행위"를 위험도가 높다고
	말함
	
- Envoy의 필터 체인 구조, 리스너 설정, 클러스터 설정 같은 내부 구현을 직접 패치하는 거라서,
	"Istio 버전이 바뀌면 그 내부 구조도 변경되어 설정이 깨짐"
	
- Lua는 위험도가 EnvoyFilter 설정과 동일함, Lua는 EnvoyFilter 리소스를 통해서만 적용할 수
	있기 때문.
	=> 즉, EnvoyFilter yaml 안에 코드가 "직접" 들어감

- Wasm은 "WasmPlugin CRD를 쓰면 위험가 낮아짐", EnvoyFilter처럼 Envoy 내부 설정을 직접
	건드리는 게 아니라, Istio가 알아서 올바른 위치에 wasm 모듈을 "주입"
	=> 즉, OCI 레지스트리에 올려두고, WasmPlugin CRD에서 "이거 가져다가 써"라고 참조만 함.
	=> 정확히 위험도를 낮추는건 "Istio 업그레이드 때 yaml이 깨지는" 대표적인 위험을 줄여주는것

실무 판단 기준

[ Lua ]
- 헤더 조작 수준의 단순한 로직, 빠르게 적용해야 하는 임시 대응, Wasm 빌드 파이프라인 구축할
	여유가 없음
	
[ Wasm ]
- 로직이 점점 복잡해질 조짐이 보일 때, 장기적으로 운영할 필터일 때, Istio 업데이트를
	자주하는 환경일 때