Balanceamento de carga para o API Gateway

A integração do Global external Application Load Balancer e do Classic Application Load Balancer para o API Gateway permite que os seus back-ends sem servidor tirem partido de todas as funcionalidades fornecidas pelo Cloud Load Balancing. Ao combinar o API Gateway com um Application Load Balancer externo global ou um Application Load Balancer clássico através de um grupo de pontos finais de rede sem servidor (NEG sem servidor), pode:

  • Alojamento de gateways com domínios personalizados com marca
  • Configure o TLS para gateways com certificados emitidos por uma autoridade de certificação preferencial
  • Crie um ponto de entrada comum para um encaminhamento de gateway para vários back-ends
  • Implemente gateways em várias regiões geográficas para ter uma elevada disponibilidade sem gerir URLs para cada região
  • Proteja gateways com o Cloud Armor
  • Melhore o tempo de resposta do gateway tirando partido do Cloud CDN

Usar um NEG sem servidor para o API Gateway

Um grupo de pontos finais da rede (NEG) especifica um grupo de pontos finais de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um back-end sem servidor alojado na Google, como o Cloud Run, o App Engine ou o API Gateway. Um back-end de NEG sem servidor para o API Gateway pode representar:

  • Uma instância do API Gateway
  • Um grupo de gateways configurados com a mesma configuração da API

A figura seguinte mostra como os NEGs sem servidor podem ser usados no modelo de Cloud Load Balancing:

Diagrama de um NEG sem servidor como back-end para gateways multirregionais

Conforme ilustrado num exemplo anterior, um serviço de back-end pode ser gerido por vários NEGs sem servidor. Cada NEG sem servidor pode conter uma única instância do API Gateway ou usar uma máscara de URL para apontar para vários gateways. Uma vez que todos os NEGs que atuam como um serviço de back-end são usados para o equilíbrio de carga, devem representar implementações de gateway funcionalmente equivalentes. Por exemplo, todos os NEGs devem ter a mesma configuração da API implementada em cada gateway em diferentes regiões. Se um serviço de back-end contiver vários NEGs, o balanceador de carga equilibra o tráfego entre estes NEGs, ao mesmo tempo que minimiza a latência dos pedidos.

Limitações nas NEGs sem servidor e no API Gateway

Devem ser consideradas algumas limitações quando usar NEGs sem servidor para integrar o Cloud Load Balancing para o API Gateway. Em particular:

  • Os NEGs sem servidor não podem ter pontos finais de rede anexados, como endereços IP ou portas.
  • Os NEGs sem servidor só podem apontar para instâncias do API Gateway residentes na mesma região onde o NEG é criado.
  • Os NEGs sem servidor só podem apontar para instâncias do API Gateway criadas no mesmo projeto que o balanceador de carga através do back-end do NEG sem servidor.
  • O API Gateway não suporta definições de controlo de entrada. Como resultado, não existe forma de desativar o acesso ao seu API Gateway através de um URL do gateway gerado pelo serviço e garantir que todo o tráfego é processado pelo equilibrador de carga.

Para mais informações sobre as restrições relativas a NEGs sem servidor e serviços de back-end em geral, consulte o artigo Limitações.

Limitações nas NEGs sem servidor em configurações de serviços de back-end

Um serviço de back-end define como o Cloud Load Balancing distribui o tráfego. A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para estabelecer ligação aos back-ends, várias definições de distribuição e de sessão, verificações de estado e limites de tempo. Para NEGs sem servidor usados como um serviço de back-end para o API Gateway, estas definições oferecem um controlo detalhado sobre o comportamento do seu equilibrador de carga.

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

  • Não é possível usar NEGs sem servidor com outros tipos de NEGs no mesmo serviço de back-end. Por exemplo, não pode encaminhar para um cluster do GKE e uma instância do API Gateway a partir do mesmo serviço de back-end.
  • Todos os NEGs sem servidor combinados num serviço de back-end têm de usar o mesmo tipo de back-end. Isto significa que os NEGs sem servidor do API Gateway só podem ser combinados com outros NEGs sem servidor do API Gateway, e os NEGs sem servidor do App Engine só podem ser combinados com NEGs sem servidor do App Engine.
  • Um serviço de back-end só pode conter um NEG sem servidor por região.

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

  • Não é possível especificar o balancingMode
  • O campo healthCheck tem de estar vazio e não pode ser especificado
  • Não é possível especificar portas
  • Apenas são suportados os protocolos HTTP e HTTPS.
  • Os valores especificados nos campos relacionados com utilization ou connection não são suportados.

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

O que se segue?