Cloud Load Balancing 콜아웃 개요

Service Extensions를 사용하면 지원되는 애플리케이션 부하 분산기에 부하 분산 데이터 경로에서 사용자 관리 콜아웃 서비스 또는 Google 서비스로 콜아웃을 보내도록 지시할 수 있습니다.

콜아웃 데이터 흐름

부하 분산기는 다음 Envoy gRPC 프로토콜 중 하나를 사용하여 콜아웃과 통신합니다.

  • 외부 처리 또는 ext_proc 프로토콜

    이 프로토콜은 경로, 트래픽, 승인 확장 프로그램에 지원되며 기본적으로 사용됩니다.

    ext_proc 프로토콜을 사용하면 확장 프로그램 서비스가 요청의 헤더나 본문을 검사하고 수정하여 HTTP 요청의 수명 주기에서 이벤트에 응답할 수 있습니다.

  • 외부 승인 또는 ext_authz 프로토콜

    이 프로토콜은 승인 확장 프로그램에만 지원됩니다. ext_authz 지원은 프리뷰 상태입니다.

    ext_authz 프로토콜은 수신 요청에 대한 승인 결정을 외부의 독립 서비스에 위임합니다. 이 API를 사용하면 확장 프로그램 서비스가 요청의 헤더나 메타데이터를 검사하여 복잡한 승인 결정을 위한 HTTP 요청의 수명 주기에서 이벤트에 응답할 수 있습니다.

    승인 확장 프로그램을 구성할 때 wireFormat 옵션으로 이 프로토콜을 지정할 수 있습니다.

가상 머신 (VM) 인스턴스 또는 GKE에 이러한 확장 서비스를 배포하고 인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG)을 구성하여 이러한 서비스의 엔드포인트를 나타낼 수 있습니다.

다음 다이어그램은 VM 인스턴스 또는 Google Kubernetes Engine (GKE) 클러스터와 같은 사용자 관리형 컴퓨팅 리소스에 gRPC 서버를 사용하여 콜아웃 백엔드 서비스를 배포하고 이를 일반 백엔드 서비스로 부하 분산기에 표시하는 방법을 보여줍니다.

애플리케이션 부하 분산기는 콜아웃을 사용하여 콜아웃 백엔드 서비스의 맞춤 로직을 포함합니다.
애플리케이션 부하 분산기는 서비스 확장 프로그램 콜아웃을 전송하여 백엔드 서비스를 호출합니다 (확대하려면 클릭).

ext_proc에서 콜아웃이 작동하는 방식

ext_proc gRPC API의 약식 버전은 다음과 같습니다.

// The gRPC API to be implemented by the external processing server
service ExternalProcessor {
  rpc Process(stream ProcessingRequest) returns (stream ProcessingResponse) {
  }
}

// Envoy sets one of these fields depending on the processing stage.
message ProcessingRequest {
  oneof request {
    HttpHeaders request_headers = 2;
    HttpHeaders response_headers = 3;
    HttpBody request_body = 4;
    HttpBody response_body = 5;
  }
}

message ProcessingResponse {
  oneof response {
    HeadersResponse request_headers = 1;
    HeadersResponse response_headers = 2;
    BodyResponse request_body = 3;
    BodyResponse response_body = 4;

    ImmediateResponse immediate_response = 7;
  }
}

HTTP 요청의 헤더를 수신한 후 부하 분산기는 request_headers 필드가 클라이언트의 HTTP 헤더로 설정된 ProcessingRequest 메시지를 확장 서비스에 전송합니다.

확장 프로그램 서비스는 ProcessingRequest 메시지의 헤더 또는 본문에 구성된 변경사항이 포함된 해당 ProcessingResponse 메시지로 ProcessingRequest 메시지에 응답해야 합니다. 또는 서비스에서 immediate_response 필드를 설정하여 부하 분산기가 요청 처리를 종료하고 지정된 응답을 클라이언트에 다시 전송하도록 할 수 있습니다.

REQUEST_HEADER 및 RESPONSE_HEADER 이벤트의 경우 확장 프로그램 서비스는 요청 또는 응답의 HTTP 헤더를 조작할 수 있습니다. 서비스는 ProcessingResponse 메시지에서 request_headers 또는 response_headers 필드를 적절하게 설정하여 헤더를 추가, 수정 또는 삭제할 수 있습니다. 헤더에는 raw_value 필드를 사용합니다.

트래픽 확장 프로그램을 사용하면 요청과 응답의 헤더와 본문을 모두 변경할 수 있습니다. 확장 프로그램 서버는 처리 모드를 동적으로 재정의하여 요청 처리의 후속 단계에서 확장 프로그램을 사용 설정하거나 사용 중지할 수 있습니다. 부하 분산기는 트래픽 확장 프로그램을 호출한 후 경로 규칙을 재평가하지 않습니다.

Edge, authorization, route 확장 프로그램은 HTTP 헤더만 지원합니다. 이러한 확장 프로그램은 HTTP 본문을 검사하거나 변경할 수 없습니다.

ext_authz에서 콜아웃이 작동하는 방식

ext_authz API는 승인 콜아웃 확장 프로그램만 지원합니다.

API의 축약 버전은 다음과 같습니다.

// A generic interface for performing authorization checks on incoming
// requests to a networked service.
service Authorization {
  // Performs an authorization check based on the attributes associated with
  // the incoming request and return status.
  rpc Check(CheckRequest) returns (CheckResponse) {
  }
}

message CheckRequest {
  // The request attributes.
  AttributeContext attributes = 1;
}

message CheckResponse {
  google.rpc.Status status = 1;
  oneof http_response {
    DeniedHttpResponse denied_response = 2;
    OkHttpResponse ok_response = 3;
  }
  google.protobuf.Struct dynamic_metadata = 4;
}

HTTP 요청의 헤더를 수신한 후 부하 분산기는 확장 프로그램 서비스에 CheckRequest 메시지를 전송합니다.

확장 프로그램 서비스는 다음 정보가 포함된 해당 CheckResponse 메시지로 CheckRequest 메시지에 응답해야 합니다.

  • status: 상태를 나타냅니다. OK는 요청이 허용됨을 나타냅니다. 다른 상태는 요청이 거부되었음을 나타냅니다.

  • denied_response 또는 ok_response: 응답이 허용되는지 거부되는지 나타냅니다. 이 필드에는 승인 확인을 위한 관련 HTTP 응답 속성이 함께 제공됩니다.

    • ok_response 필드는 승인 서비스가 요청을 허용할 때 사용됩니다. 서비스는 원래 요청 헤더를 수정, 추가 또는 삭제하고 클라이언트로 전송되는 HTTP 응답 헤더를 업데이트할 수 있습니다. 헤더에는 raw_value 필드를 사용합니다.

    • denied_response 필드는 승인 서비스에서 요청을 거부할 때 사용됩니다. 서비스는 클라이언트로 전송되는 HTTP 응답 헤더를 업데이트할 수 있습니다.

    확장 프로그램 서비스가 CheckResponse 메시지를 통해 허용되지 않는 헤더 이름이나 값을 반환하면 500 Internal Error 상태 코드로 요청이 거부됩니다. 허용되지 않는 헤더에 대한 자세한 내용은 헤더 조작 시 제한사항을 참고하세요.

  • dynamic_metadata: 승인 확장 프로그램 후에 호출되는 확장 프로그램(예: 트래픽 확장 프로그램)에서 사용할 선택적 메타데이터를 포함합니다.

본문 처리 모드

본문 처리를 지원하는 확장 프로그램의 경우 request_body_send_mode 또는 response_body_send_mode 필드의 값을 설정하여 요청 및 응답 본문 처리에 다음 두 전송 모드 중 하나를 구성할 수 있습니다.

기본 모드는 STREAMED이며 대부분의 사용 사례에 권장됩니다.

모드 설명 지원되는 이벤트 필요 지원되는 확장 프로그램
STREAMED

호출은 스트리밍 모드에서 실행됩니다. 이 기본 설정은 모드가 설정되지 않은 경우에도 사용됩니다.

프록시는 확장 프로그램 서비스에 본문 청크를 전송하고 청크당 단일 응답을 예상합니다. 확장 프로그램은 수정된 청크를 다시 전송하거나, 변경 없이 청크를 승인하거나, 청크를 삭제할 수 있습니다.

프록시는 한 번에 제한된 양의 데이터만 전송합니다. 따라서 확장 프로그램 서비스는 청크를 최대한 빨리 승인해야 합니다.

본문 모드는 동적으로 변경할 수 없지만 고급 확장 프로그램 서버는 수신할 향후 HTTP 이벤트를 동적으로 선택할 수 있습니다. 헤더 요청 중에 ext_proc mode_override 옵션을 반환하면 콜아웃 서버에서 향후 헤더, 본문 또는 트레일러 이벤트를 사용 설정하거나 사용 중지할 수 있습니다.

 요청의 경우 REQUEST_BODY, 응답의 경우 RESPONSE_BODY를 포함해야 합니다. 트래픽 확장 프로그램 (요청 및 응답 모두).
FULL_DUPLEX_STREAMED

통화는 전이중 모드로 실행됩니다.

프록시는 청크가 도착하는 대로 전송하며 버퍼링하지 않습니다. 버퍼링이 없으므로 프록시는 확장 프로그램 지연 시간에 덜 민감합니다.

프록시는 필요한 만큼 많은 대답 청크를 수신할 수 있습니다. 답장 청크는 프록시가 전송하는 청크에서 분리됩니다. 후속 청크는 이전 청크와 이벤트가 완전히 처리될 때까지 기다리지 않고 프록시에 도착하는 대로 처리를 위해 전송됩니다.

확장 프로그램은 본문 콘텐츠를 자유롭게 버퍼링하고 수정하고 다시 청크할 수 있습니다. 확장 프로그램이 본문 콘텐츠를 다시 전송하지 않으면 체인의 다음 확장 프로그램이 빈 본문을 수신합니다.

ext_proc mode_override 옵션은 적용할 수 없으며 모드를 동적으로 변경할 수 없습니다.

 요청의 경우 REQUEST_BODY 및 REQUEST_TRAILERS, 응답의 경우 RESPONSE_BODY 및 RESPONSE_TRAILERS를 포함해야 합니다. 트래픽 확장 프로그램 (요청 및 응답 모두).

경로 확장 프로그램 (요청용)

사용자 관리 콜아웃 백엔드 서비스에 지원되는 백엔드

Envoy gRPC 서비스를 실행하는 다음 유형의 백엔드 중 하나를 사용하는 백엔드 서비스에서 사용자 관리 콜아웃 확장 프로그램을 호스팅할 수 있습니다.

콜아웃에 권장되는 최적화

확장 프로그램을 부하 분산 처리 경로에 통합하면 요청과 응답에 추가 지연 시간이 발생합니다. 확장 프로그램 서비스가 처리하는 각 데이터 유형(요청 헤더, 요청 본문, 응답 헤더, 응답 본문 등)은 지연 시간을 추가합니다.

지연 시간을 최소화하려면 다음 최적화를 고려하세요.

  • 부하 분산기의 일반 대상 백엔드 서비스와 동일한 영역에 콜아웃을 배포합니다. 교차 리전 내부 애플리케이션 부하 분산기를 사용하는 경우 확장 서비스 백엔드를 부하 분산기의 프록시 전용 서브넷과 동일한 리전에 배치합니다.
  • 전역 외부 애플리케이션 부하 분산기를 사용하는 경우 일반 부하 분산기의 대상 VM, GKE 워크로드, Cloud Run Functions가 있는 지리적 리전에 콜아웃 서비스 백엔드를 배치합니다.
  • 가능한 경우 필요한 데이터만 처리하도록 확장 프로그램을 구성합니다. 예를 들어 경로 및 트래픽 확장 프로그램의 요청 헤더만 수정하려면 확장 프로그램의 supported_events 필드를 REQUEST_HEADERS로 설정합니다.

제한사항

이 섹션에는 콜아웃의 몇 가지 제한사항이 나열되어 있습니다.

헤더 조작의 제한사항

일부 헤더는 변경할 수 없습니다. 헤더 조작에는 다음과 같은 제한사항이 있습니다.

  • 다음 헤더의 경우 헤더 조작이 지원되지 않습니다.

    • X-user-IP
    • CDN-Loop
    • X-Forwarded, X-Google, X-GFE 또는 X-Amz-로 시작하는 헤더
    • connection
    • keep-alive
    • transfer-encoding, te
    • upgrade
    • proxy-connection, proxy-authenticate, proxy-authorization
    • trailers

    트래픽 및 승인 확장 프로그램의 경우 :method, :authority, :scheme 또는 호스트 헤더에 대해서도 헤더 조작이 지원되지 않습니다.

  • gRPC 서버가 HeaderMutation에서 헤더 값을 지정하면 부하 분산기는 value 필드를 무시합니다.

본문 처리 관련 제한사항

다음은 메시지 본문에 관한 HTTP/1.1 클라이언트 및 백엔드의 제한사항으로, ext_proc에는 적용되지만 ext_authz에는 적용되지 않습니다.

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

  • 메시지 본문을 ext_proc 서버로 스트리밍하는 동안 끝에서 부하 분산기는 스트림이 종료되었음을 나타내기 위해 end_stream이 true로 설정된 빈 본문과 함께 후행 ProcessingRequest 메시지를 전송할 수 있습니다.

기타 제한사항

gRPC 응답 메시지에는 다음과 같은 제한사항이 있습니다.

  • 응답 메시지의 최대 크기는 128KB입니다. 수신된 메시지가 이 한도를 초과하면 스트림이 RESOURCE_EXHAUSTED 오류와 함께 닫힙니다.

  • 호출 백엔드 서비스는 Cloud Armor, IAP 또는 Cloud CDN 정책을 사용할 수 없습니다.

  • 호출 백엔드 서비스는 HTTP/2를 프로토콜로 사용해야 합니다.

  • 승인 확장 프로그램의 경우 부하 분산기가 콜아웃 백엔드 서비스에 요청 본문을 전달하지 않습니다.

  • 경로 확장 프로그램의 경우 콜아웃 백엔드 서비스가 ext_proc 스트림의 처리 모드를 재정의할 수 없습니다.

다음 단계