확장성

확장성 (Extensibility)

Istio는 두 가지 주요 확장 메커니즘을 제공해요. 아래 설명하는 Envoy 확장과 Extension Providers예요.

출처: Istio 문서

본문

Envoy 프록시 확장하기 (Extending Envoy Proxies)

Istio는 Envoy 기반 프록시를 확장하는 두 가지 메커니즘을 제공해요. WebAssembly(Wasm)와 Lua예요. 둘 다 TrafficExtension API로 구성되는데, 이 API는 일관된 대상 지정과 단계/우선순위 순서로 워크로드에 확장을 부착하는 통일된 방식을 제공해요.

필터 유형 선택하기 (Choosing a filter type)

WebAssembly Lua
언어 (Languages) C++, Rust, Go, AssemblyScript, 그 외 Lua만
배포 (Distribution) OCI 레지스트리, HTTP URL, 로컬 파일에서 가져옴 리소스에 직접 인라인
메모리 (Memory) 더 높음 — 각 플러그인이 자체 샌드박스에서 실행 WebAssembly보다 약 10배 낮음
격리 (Isolation) 전체 VM 샌드박스 — 크래시가 플러그인에 국한됨 인프로세스 실행 — 크래시가 워커 스레드를 죽일 수 있음
실패 정책 (Failure policy) 구성 가능 — 기본적으로 fail-closed fail-open만 — 구성 옵션 없음
SDLC 전체 생태계: 단위 테스트, CI, 버전 관리 릴리스 제한적 — 스크립트가 리소스 자체에 있음
가장 적합한 용도 (Best for) 복잡한 로직, 재사용 가능한 플러그인, 운영 확장 간단한 일회성 변환, 임시 해결책

일반적으로 테스트, 버전 관리, 재사용이 필요한 운영 확장에는 WebAssembly를 선호하세요. 인라인 코드의 단순함이 도구 부족보다 중요한 가볍고 국소적인 변경에는 Lua를 선호하세요.

WebAssembly 플러그인 (WebAssembly Plugins)

WebAssembly는 더 복잡한 확장을 위한 샌드박싱 기술이에요. Proxy-Wasm 샌드박스 API는 Istio의 기본 확장 메커니즘으로 Mixer를 대체해요.

WebAssembly 샌드박스 목표:

  • 효율성 (Efficiency) - 확장이 낮은 지연 시간, CPU, 메모리 오버헤드를 추가해요.
  • 기능 (Function) - 확장이 정책을 적용하고, 텔레메트리를 수집하고, 페이로드 변형을 수행할 수 있어요.
  • 격리 (Isolation) - 한 플러그인의 프로그래밍 오류나 크래시가 다른 플러그인에 영향을 주지 않아요.
  • 구성 (Configuration) - 플러그인은 다른 Istio API와 일관된 API로 구성돼요. 확장은 동적으로 구성될 수 있어요.
  • 운영 (Operator) - 확장은 카나리 배포되고 log-only, fail-open 또는 fail-close로 배포될 수 있어요.
  • 확장 개발자 (Extension developer) - 플러그인은 여러 프로그래밍 언어로 작성될 수 있어요.

이 비디오 강연은 WebAssembly 통합 아키텍처에 대한 소개예요.

고수준 아키텍처 (High-level architecture)

Istio 확장(Proxy-Wasm 플러그인)에는 여러 컴포넌트가 있어요:

  • 필터용 Proxy-Wasm 플러그인을 구축하기 위한 Filter Service Provider Interface (SPI).
  • Envoy에 내장된 Sandbox V8 Wasm 런타임.
  • 헤더, 트레일러, 메타데이터용 Host APIs.
  • gRPC 및 HTTP 호출용 Call out APIs.
  • 메트릭과 모니터링용 Stats and Logging APIs.

예제 (Example)

필터용 C++ Proxy-Wasm 플러그인의 예제는 여기에서 찾을 수 있어요. 이 가이드를 따라 C++로 Wasm 확장을 구현할 수 있어요.

생태계 (Ecosystem)

Lua 스크립트 (Lua Scripts)

Lua 필터는 간단한 요청·응답 변환을 위한 가볍고 인라인된 스크립팅 접근 방식을 제공해요. Lua 코드는 TrafficExtension 리소스에 직접 인라인되고 Envoy 프록시 안에서 실행되며, 모듈 배포가 필요 없어요. Lua 필터는 간단한 헤더 조작, 로깅, 조건부 로직에 가장 적합해요. 더 복잡한 처리는 WebAssembly 필터를 권장해요.

Lua의 메모리 사용량은 WebAssembly보다 훨씬 작아요. 벤치마크는 동시성과 관계없이 Lua가 대략 20–26 MiB를 소비하는 반면, WebAssembly는 낮은 동시성에서 ~110 MiB에서 높은 동시성에서 ~290 MiB까지 변함을 보여줘요:

동시성 (Concurrency) Lua (MiB) Wasm (MiB)
1 19.79 117.7
2 23.07 132.5
4 22.63 152.0
8 23.97 190.9
16 25.66 291.8

더 알아보기 (Learn more)