플러그인 개요

이 페이지에서는 플러그인을 Cloud Load Balancing 애플리케이션 부하 분산기 및 미디어 CDN과 통합하는 방법에 대한 개요 정보를 제공합니다.

이 기능은 미디어 CDN의 미리보기 상태입니다.

플러그인은 WebAssembly (Wasm) 형식을 사용하여 빌드되며 Proxy-Wasm API를 사용합니다.

  • Wasm은 호스트가 고객 제공 코드로 Wasm 모듈을 로드하고 실행할 수 있도록 하는 개방형 및 표준화된 바이너리 명령어 형식입니다. Wasm은 보안을 위한 샌드박스, 여러 언어 지원, 이식성, 업계 내 광범위하고 증가하는 지원, JavaScript와 같은 다른 VM 기반 옵션에 비해 향상된 성능 등 고객 코드를 실행하는 데 여러 가지 이점이 있습니다.

  • Proxy-Wasm은 Google에서 시작한 오픈 소스 프로젝트입니다. HTTP 요청 및 응답 처리 중에 실행할 콜백을 구현하여 네트워크 프록시의 동작을 맞춤설정할 수 있는 API를 정의합니다.

플러그인의 작동 방식

애플리케이션 부하 분산기 및 Media CDN에서 Service Extensions를 사용하는 방법은 다음과 같습니다.

  1. 플러그인 코드 준비 방법:

    1. Proxy-Wasm SDK 중 하나를 사용하여 커스텀 코드를 만듭니다.

    2. 코드를 Wasm 모듈로 컴파일합니다.

    3. 컴파일된 플러그인 코드를 Artifact Registry 저장소에 업로드합니다.

  2. 플러그인 만들기 업로드된 플러그인 코드가 포함된 플러그인.

  3. Cloud Load Balancing 확장 프로그램 또는 미디어 CDN 확장 프로그램에서 플러그인을 구성합니다.

플러그인 리소스

Service Extensions를 사용하면 처리 경로에 커스텀 코드를 추가하는 데 도움이 되는 다음과 같은 주요 리소스를 만들 수 있습니다.

  • 플러그인, 배포하려는 커스텀 코드가 포함된

  • 플러그인 버전(Wasm 모듈 버전) 플러그인이 기본 (활성)으로 사용할 Wasm 모듈 버전을 나타낼 수 있습니다.

플러그인의 속성에 액세스

Wasm 플러그인은 Proxy-Wasm ABI의 일부인 proxy_get_property ABI 호출을 사용하여 전달된 속성에 액세스할 수 있습니다. 검색할 수 있는 속성 이름은 속성 이름에 해당합니다.

속성 이름의 경로 표현으로 속성에 액세스할 수 있습니다. 예를 들어 request.host를 검색하려면 {"request", "host"}와 같은 경로 표현을 사용할 수 있습니다.

다음 개념적 Rust 예에서는 HttpContext 구현 내에서 전달된 속성에 액세스하는 방법을 보여줍니다.

use proxy_wasm::traits::{HttpContext, RootContext};
use proxy_wasm::types::Action;

// ... inside your HttpContext implementation ...

fn on_request_headers(&mut self, _num_headers: usize, _end_of_stream: bool) -> Action {
    if let Some(host) = self.get_property(vec!["request", "host"]) {
        // host is a Vec, convert to string
        let host_str = String::from_utf8(host).unwrap_or_default();
        log::info!("Request host: {}", host_str);
    }

    if let Some(region) = self.get_property(vec!["source", "client_region"]) {
        let region_str = String::from_utf8(region).unwrap_or_default();
        log::info!("Client region: {}", region_str);
    }

    Action::Continue
}

제한사항

이 섹션에서는 플러그인의 몇 가지 제한사항을 나열합니다.

리소스 제한사항

플러그인은 사용할 수 있는 리소스 수에 엄격한 제한이 있습니다.

  • 플러그인은 호출당 최대 1밀리초의 정규화된 vCPU를 사용할 수 있습니다. CPU 밀리초는 플랫폼에 따라 다르지만 정규화된 플랫폼은 클록 속도가 4GHz인 프로세서와 거의 같습니다. 호출은 요청 헤더, 요청 본문, 응답 헤더 또는 응답 본문일 수 있는 독립적으로 청구되는 실행 단계입니다.

  • 플러그인은 VM 인스턴스당 최대 16MiB의 메모리를 사용할 수 있습니다. 인스턴스는 최대 1,000개의 동시 요청을 처리할 수 있어야 합니다. 즉, 플러그인은 스트림당 최대 16KiB의 메모리를 보유할 수 있습니다. 총 메모리 사용량에는 전역 상태 및 스택 할당이 포함됩니다.

플러그인 테스터를 사용하여 플러그인의 CPU 및 메모리 특성을 벤치마킹합니다.

API 제한사항

  • 플러그인은 Proxy-Wasm ABI의 하위 집합을 사용할 수 있습니다. 플러그인은 타이머, 커스텀 측정항목, 공유 데이터, 공유 대기열 또는 아웃바운드 네트워크 호출을 지원하지 않습니다.

  • HTTP 트레일러 이벤트는 지원되지 않습니다.

헤더 조작 제한사항

  • 변경사항 (헤더 또는 본문 청크)의 최대 크기는 128KiB입니다.

  • 플러그인은 ext_proc 스트림의 처리 모드를 재정의할 수 없습니다.

  • 일부 헤더에서는 플러그인을 통한 헤더 조작이 지원되지 않습니다. 프로세서가 이러한 헤더의 변경사항을 무시하고 요청 처리를 계속합니다.

    미디어 CDN 플러그인의 경우 다음이 지원되지 않습니다.

    • 헤더: CDN-Loop, connection, keep-alive, proxy-authenticate, proxy-authorization, proxy-connection, te, trailers, transfer-encoding, upgrade, 또는 X-user-IP.
    • 다음으로 시작하는 헤더: x-forwarded, x-goog-,x-google, x-gfe 또는 x-amz-.

    Cloud Load Balancing 플러그인의 경우 다음이 지원되지 않습니다.

    • 헤더: connection, keep-alive, proxy-authenticate, proxy-authorization, proxy-connection, sec-user-ip, te, trailer, transfer-encoding, upgrade, x-dont-count-ads, x-dont-show-ads, x-gr, x-proxyuser-ip 또는 x-user-ip.

      또한 LbTrafficExtension의 경우 method, authority, scheme 또는 호스트 헤더도 지원되지 않습니다.

    • 다음으로 시작하는 헤더: sec-gfe-, sec-google-, x-amz-, x-forwarded-, x-gfe-, x-goog-, x-google- 또는 x-gproxy-.

HTTP/1.1 클라이언트 및 백엔드 제한사항

확장 프로그램에 REQUEST_BODY 또는 RESPONSE_BODY를 구성할 때 부하 분산기가 일치하는 요청을 수신하면 응답에서 Content-Length 헤더를 삭제하고 청크된 본문 인코딩으로 전환합니다.

다음 단계