플러그인 개요

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

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

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

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

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

플러그인 작동 방식

다음과 같이 애플리케이션 부하 분산기 및 Media CDN과 함께 서비스 확장 프로그램을 사용할 수 있습니다.

  1. 다음과 같이 플러그인 코드를 준비합니다.

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

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

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

  2. 업로드된 플러그인 코드가 포함된 플러그인을 만듭니다.

  3. Cloud Load Balancing 확장 프로그램 또는 Media 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의 메모리를 사용할 수 있습니다(Media CDN 플러그인의 경우 4MiB).

    • 인스턴스는 최대 1,000개의 동시 요청을 처리할 수 있어야 합니다. 즉, 플러그인은 각 스트림에 대해 최대 16KiB의 메모리를 보유할 수 있습니다 (Media CDN 플러그인의 경우 4KiB). 총 메모리 사용량에는 전역 상태 및 스택 할당이 포함됩니다. 이 한도를 초과하는 플러그인은 종료됩니다.

    • 메모리 사용량이 가장 적은 플러그인을 생성하므로 C++ 및 Rust를 사용하는 것이 좋습니다. Go 런타임 및 가비지 컬렉터에는 최소 기준 메모리 사용량 2~3MiB가 필요하므로 Media CDN에는 Go SDK를 사용하지 않는 것이 좋습니다.

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

API 제한사항

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

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

헤더 조작 제한사항

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

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

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

    Media 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 헤더를 삭제하고 청크 본문 인코딩으로 전환합니다.

다음 단계