Balanceamento de carga para o gateway de API

Com a integração do suporte do balanceador de carga de aplicativo externo global e do balanceador de carga de aplicativo clássico ao gateway de API, seus back-ends sem servidor podem aproveitar todos os recursos fornecidos pelo Cloud Load Balancing. Ao combinar o gateway de API com um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico usando um grupo de endpoints de rede sem servidor (NEG sem servidor), é possível:

  • Hospedar gateways com domínios de marca personalizados
  • Configurar TLS para gateways usando certificados emitidos por uma autoridade de certificação preferencial
  • Criar um ponto de entrada comum para um roteamento de gateway para vários back-ends
  • Implantar gateways em várias regiões geográficas para ter alta disponibilidade sem gerenciar URLs para cada região
  • Proteja gateways com o Cloud Armor
  • Melhore o tempo de resposta do gateway aproveitando o Cloud CDN

Como usar um NEG sem servidor para o gateway de APIs

Um grupo de endpoints de rede (NEG) especifica um grupo de endpoints de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um back-end sem servidor hospedado pelo Google, como o Cloud Run, o App Engine ou o gateway de API. Um back-end de NEG sem servidor para o gateway de API pode representar:

  • Uma instância de gateway de API
  • Um grupo de gateways configurado com a mesma configuração de API

A figura a seguir mostra como os NEGs sem servidor podem ser usados no modelo do Cloud Load Balancing:

diagrama de neg sem servidor como back-end para gateways multirregionais

Como ilustrado em um exemplo anterior, um serviço de back-end pode ser gerenciado por vários NEGs sem servidor. Cada NEG sem servidor pode conter uma única instância do gateway de API ou usar uma máscara de URL para apontar para vários gateways. Como todos os NEGs que atuam como um serviço de back-end são usados para balanceamento de carga, eles devem representar implantações de gateway com função equivalente. Por exemplo, todos os NEGs precisam ter a mesma configuração de API implantada em cada gateway em diferentes regiões. Se um serviço de back-end contiver vários NEGs, o balanceador de carga equilibrará o tráfego entre esses NEGs e minimizará a latência da solicitação.

Limitações em NEGs sem servidor e no gateway de API

Algumas limitações devem ser consideradas ao usar NEGs sem servidor para integrar o Cloud Load Balancing para o gateway de API. Em especial:

  • Os NEGs sem servidor não podem ter endpoints de rede anexados, como endereços IP ou portas.
  • NEGs sem servidor só podem apontar para instâncias de gateway de API que residem na mesma região em que o NEG é criado.
  • Os NEGs sem servidor só podem apontar para instâncias de gateway de API criadas no mesmo projeto que o balanceador de carga usando o back-end do NEG sem servidor.
  • O gateway de API não é compatível com as configurações de controle do Entrada. Como resultado, não é possível desativar o acesso ao gateway de API usando um URL gerado pelo serviço e garantir que todo o tráfego seja processado pelo balanceador de carga.

Para mais informações sobre restrições relacionadas a NEGs sem servidor e a serviços de back-end, consulte Limitações.

Limitações em NEGs sem servidor em configurações do serviço de back-end

Um serviço de back-end define como o Cloud Load Balancing distribui tráfego. A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para se conectar a back-ends, várias configurações de distribuição e sessão, verificações de integridade e tempos limite. Para NEGs sem servidor usados como serviço de back-end para gateway de API, essas configurações fornecem um controle refinado sobre como o balanceador de carga se comporta.

A definição de recursos de um serviço de back-end tem as seguintes implicações para o design do balanceamento de carga:

  • Os NEGs sem servidor não podem ser usados com outros tipos de NEGs no mesmo serviço de back-end. Por exemplo, não é possível rotear para um cluster do GKE e uma instância do gateway de API a partir do mesmo serviço de back-end.
  • Todos os NEGs sem servidor combinados em um serviço de back-end também precisam usar o mesmo tipo de back-end. Isso significa que os NEGs sem servidor do gateway de API só podem ser combinados com outros NEGs sem servidor do gateway de API, e os NEGs sem servidor do App Engine só podem ser combinados com os NEGs sem servidor do App Engine.
  • Um serviço de back-end pode conter apenas um NEG sem servidor por região.

Ao definir uma configuração de serviço de back-end que encaminha para um NEG sem servidor, as seguintes limitações de campo se aplicam:

  • Não é possível especificar o balancingMode
  • O campo healthCheck precisa estar vazio e não pode ser especificado
  • Não é possível especificar as portas
  • Somente protocolos HTTP e HTTPS são compatíveis.
  • Os valores especificados nos campos relacionados a utilization ou connection não são compatíveis.

Os campos IAP, cdnPolicy e securityPolicy na configuração do serviço de back-end são válidos para NEGs sem servidor. Esses campos podem ser usados para configurar o Identity-Aware Proxy, o Cloud CDN e o Cloud Armor, respectivamente, com o serviço de gateway de API.

A seguir