Vista geral dos grupos de pontos finais de rede sem servidor

Um grupo de pontos finais da rede (NEG) especifica um grupo de pontos finais do back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um recurso do Cloud Run, App Engine, Cloud Run Functions ou API Gateway.

Um NEG sem servidor pode representar uma das seguintes opções:

  • Um recurso do Cloud Run ou um grupo de recursos.
  • Uma função do Cloud Run ou um grupo de funções (anteriormente, funções do Cloud Run de 2.ª geração).
  • Uma função do Cloud Run (1.ª geração) ou um grupo de funções
  • Uma app do ambiente padrão do App Engine ou do ambiente flexível do App Engine, um serviço específico numa app, uma versão específica de uma app ou um grupo de serviços.
  • Um gateway da API que fornece acesso aos seus serviços através de uma API REST consistente em todos os serviços, independentemente da implementação do serviço. Esta capacidade está em pré-visualização.

Balanceadores de carga suportados

A tabela seguinte indica os produtos sem servidor suportados por cada Application Load Balancer. Os NEGs sem servidor não são suportados por equilibradores de carga de rede de proxy nem por equilibradores de carga de rede de encaminhamento.

Tipo de NEG sem servidor Balanceadores de carga de aplicações
Regional
interno		 Entre regiões
interna		 Global
externo		 Clássico Regional
externo

Cloud Run

Suporta o Cloud Run e as funções do Cloud Run (2.ª geração)
App Engine

Cloud Functions

Suporta funções do Cloud Run (1.ª geração), anteriormente conhecidas como Cloud Functions de 1.ª geração

Exemplos de utilização

Quando o balanceador de carga está ativado para apps sem servidor, pode fazer o seguinte:

  • Configure a sua app sem servidor para ser servida a partir de um endereço IP IPv4 dedicado que não seja partilhado com outros serviços.
  • Mapear um único URL para várias funções ou serviços sem servidor que são publicados no mesmo domínio. Neste documento, consulte máscaras de URL.
  • Partilhe o espaço de URLs com outras Google Cloud plataformas de computação. Ao usar vários serviços de back-end, um único balanceador de carga pode enviar tráfego para vários tipos de back-end. O balanceador de carga seleciona o serviço de back-end correto com base no anfitrião ou no caminho do URL do pedido.
  • Reutilize os mesmos certificados SSL e chaves privadas que usa para o Compute Engine, o Google Kubernetes Engine e o Cloud Storage. A reutilização dos mesmos certificados elimina a necessidade de gerir certificados separados para apps sem servidor.

Balanceador de carga de aplicações clássico e balanceador de carga de aplicações externo global

A configuração de um Application Load Balancer externo global ou de um Application Load Balancer clássico permite que as suas apps sem servidor se integrem com os serviços na nuvem existentes. Pode fazer o seguinte:

  • Proteja o seu serviço com o Google Cloud Armor, um produto de segurança de WAF e defesa contra DDoS de limite disponível para todos os serviços acedidos através de um Application Load Balancer externo. Existem algumas limitações associadas a esta capacidade, especialmente para o Cloud Run e o App Engine.
  • Ative o seu serviço para otimizar o fornecimento através do Cloud CDN. O Cloud CDN armazena conteúdo em cache perto dos seus utilizadores. A RFC de multimédia na nuvem oferece capacidades como a invalidação da cache e URLs assinados da RFC de multimédia na nuvem.
  • Use a infraestrutura de rede perimetral da Google para terminar as ligações HTTP(S) dos utilizadores mais perto destes, o que diminui a latência.

Para saber como configurar um equilibrador de carga com um back-end de computação sem servidor, consulte a seguinte documentação:

A integração de um Application Load Balancer externo com o API Gateway permite que os seus back-ends sem servidor tirem partido de todas as funcionalidades fornecidas pelo Cloud Load Balancing. Para mais informações, consulte o artigo Balanceador de carga de aplicações externo para o gateway da API. Para configurar um balanceador de carga de aplicações externo para encaminhar tráfego para um gateway da API, consulte o artigo Introdução a um balanceador de carga de aplicações externo para o gateway da API. Esta capacidade está em pré-visualização.

Balanceador de carga de aplicações externo regional

A utilização de um Application Load Balancer externo regional permite-lhe executar cargas de trabalho com requisitos regulamentares ou de conformidade em backends do Cloud Run ou das funções do Cloud Run (2.ª geração). Por exemplo, se precisar que as configurações de rede e a terminação de tráfego da sua aplicação residam numa região específica, um Application Load Balancer externo regional é frequentemente a opção preferencial para agir em conformidade com os controlos jurisdicionais necessários.

Para saber como configurar um balanceador de carga de aplicações externo regional com um back-end de computação sem servidor, consulte o artigo Configure um balanceador de carga de aplicações externo regional com o Cloud Run.

Balanceador de carga de aplicações interno regional e balanceador de carga de aplicações interno entre regiões

Quando um Application Load Balancer interno é configurado com back-ends do Cloud Run ou das funções do Cloud Run (2.ª geração), pode fazer o seguinte:

  • Ative as funcionalidades avançadas de gestão de tráfego, como a injeção de falhas, a reescrita de cabeçalhos, os redirecionamentos, a divisão de tráfego e muito mais, para os seus serviços do Cloud Run e das funções do Cloud Run (2.ª geração).
  • Migre facilmente serviços antigos do Compute Engine, do GKE ou no local para o Cloud Run e as funções do Cloud Run (2.ª geração) para tirar partido da divisão de tráfego baseada em ponderação para mudar gradualmente o tráfego para o Cloud Run sem tempo de inatividade.
  • Proteja os seus serviços do Cloud Run e das funções do Cloud Run (2.ª geração) com os controlos de serviços da VPC.
  • Estabeleça um único ponto de entrada interno de aplicação de políticas para os seus serviços em execução no Cloud Run, nas funções do Cloud Run (2.ª geração), no Compute Engine e no GKE.

Para saber como configurar um Application Load Balancer interno regional com um back-end de computação sem servidor, consulte o artigo Configure um Application Load Balancer interno regional com o Cloud Run.

O resto desta página aborda a utilização de NEGs sem servidor com os seus equilibradores de carga de aplicações. Para mais informações sobre outros tipos de NEGs, consulte o artigo Vista geral dos grupos de pontos finais de rede.

Tipos de pontos finais

Os NEGs sem servidor não têm pontos finais de rede, como portas ou endereços IP. Só podem apontar para um recurso Cloud Run, App Engine, API Gateway ou Cloud Run Functions existente residente na mesma região que o NEG.

Quando cria um NEG sem servidor, especifica o nome do domínio totalmente qualificado (FQDN) do recurso do Cloud Run, App Engine, API Gateway ou Cloud Run Functions. O ponto final é do tipo SERVERLESS. Outros tipos de pontos finais não são suportados num NEG sem servidor.

Um NEG sem servidor não pode ter mais do que um ponto final. O ponto final aponta para uma aplicação sem servidor ou uma máscara de URL. O equilibrador de carga serve como interface para a aplicação de computação sem servidor e encaminha o tráfego para o ponto final especificado. No entanto, se o serviço de back-end contiver vários NEGs sem servidor em diferentes regiões, o balanceador de carga envia tráfego para o NEG na região mais próxima para minimizar a latência dos pedidos.

Nível da rede

Para equilibradores de carga de aplicações externos globais, pode usar um NEG sem servidor num equilibrador de carga usando os níveis de serviço de rede Standard ou Premium. O nível Premium só é necessário se quiser configurar NEGs sem servidor em várias regiões.

Os balanceadores de carga de aplicações externos regionais são sempre de nível padrão.

Os balanceadores de carga de aplicações internos entre regiões e os balanceadores de carga de aplicações internos regionais são sempre de nível Premium.

Componentes de balanceamento de carga

Um balanceador de carga que use um back-end do NEG sem servidor requer uma configuração especial apenas para o serviço de back-end. A configuração da interface é igual à de qualquer outro balanceador de carga baseado em proxy. Google Cloud Além disso, os balanceadores de carga de aplicações internos requerem uma sub-rede só de proxy para executar proxies Envoy em seu nome.

Os diagramas seguintes mostram uma implementação de NEG sem servidor de exemplo.

Global externo

Este diagrama mostra como um NEG sem servidor se enquadra numa arquitetura de Application Load Balancer externo global.

Balanceador de carga de aplicações externo global para apps sem servidor.
Balanceador de carga de aplicações externo global para apps sem servidor (clique para aumentar).

Regional externo

Este diagrama mostra como um NEG sem servidor se enquadra numa arquitetura de Application Load Balancer externo regional.

Balanceador de carga de aplicações externo regional para apps sem servidor.
Balanceador de carga de aplicações externo regional para apps sem servidor (clique para aumentar).

Regional interno

Este diagrama mostra como um NEG sem servidor se enquadra no modelo do Application Load Balancer interno regional.

Balanceador de carga de aplicações interno regional para apps sem servidor.
Application Load Balancer interno regional para apps sem servidor (clique para aumentar).

Entre regiões

Este diagrama mostra como um NEG sem servidor se enquadra no modelo do Application Load Balancer interno entre regiões.

Balanceador de carga de aplicações interno entre regiões com implementação do Cloud Run.
Balanceador de carga da aplicação interno entre regiões com implementação do Cloud Run (clique para aumentar).

Componentes da interface

Não é necessária nenhuma configuração especial do front-end para o balanceamento de carga com back-ends de NEG sem servidor. As regras de encaminhamento são usadas para encaminhar o tráfego por endereço IP, porta e protocolo para um proxy de destino. Em seguida, o proxy de destino termina as ligações dos clientes.

Os mapas de URLs são usados pelos balanceadores de carga de aplicações para configurar o encaminhamento baseado em URLs de pedidos para os serviços de back-end adequados.

Para mais detalhes sobre cada um destes componentes, consulte as secções de arquitetura das descrições gerais específicas do equilibrador de carga:

Serviço de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Os balanceadores de carga usam as informações num serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados. Os NEGs sem servidor podem ser usados como back-ends para determinados balanceadores de carga.

Aplicam-se as seguintes restrições, consoante o tipo de equilibrador de carga:

  • Um serviço de back-end global usado por balanceadores de carga de aplicações externos globais pode ter vários NEGs sem servidor anexados, mas apenas um NEG sem servidor por região.
  • Um serviço de back-end regional usado por balanceadores de carga de aplicações internos regionais e balanceadores de carga de aplicações externos regionais só pode ter um NEG sem servidor associado.
  • Um serviço de back-end global usado por equilibradores de carga de aplicações internos em várias regiões só pode ter recursos do Cloud Run e das funções do Cloud Run (2.ª geração) anexados.

Cada NEG sem servidor pode apontar para qualquer um dos seguintes elementos:

  • O FQDN de um único recurso
  • Uma máscara de URL que aponta para vários recursos publicados no mesmo domínio

Uma máscara de URL é um modelo de esquema de URL que indica ao back-end do NEG sem servidor como mapear o pedido do utilizador para o serviço correto. As máscaras de URL são úteis se estiver a usar um domínio personalizado para a sua aplicação sem servidor e tiver vários serviços a serem publicados no mesmo domínio. Em vez de criar um NEG sem servidor separado para cada recurso, pode criar o NEG com uma máscara de URL genérica para o domínio personalizado. Para mais informações e exemplos, consulte Máscaras de URL.

Para ver restrições adicionais ao adicionar um NEG sem servidor como back-end, consulte as Limitações.

Deteção de valores atípicos para NEGs sem servidor

A deteção de valores atípicos é uma configuração opcional que pode ser ativada num serviço de back-end global que tenha NEGs sem servidor anexados. A análise de deteção de valores atípicos só está disponível para um balanceador de carga de aplicações interno entre regiões, um balanceador de carga de aplicações externo global e não para um balanceador de carga de aplicações clássico. A análise de deteção de valores atípicos identifica NEGs sem servidor não saudáveis com base nos respetivos padrões de resposta HTTP e reduz a taxa de erros encaminhando a maioria dos novos pedidos de recursos não saudáveis para recursos saudáveis. Para saber como funciona o algoritmo de deteção de valores atípicos e compreender as respetivas limitações, veja o exemplo seguinte.

Suponha que existe um serviço de back-end com dois NEGs sem servidor anexados: um na região REGION_A e outro na região REGION_B. Se o NEG sem servidor que funciona como back-end de um Application Load Balancer externo global na região REGION_A não responder, a deteção de valores atípicos identifica o NEG sem servidor como não saudável. Com base na análise de deteção de valores atípicos, algumas das novas solicitações são enviadas para o NEG sem servidor na região REGION_B.

Com base no tipo de erro do servidor encontrado, pode usar um dos seguintes métodos de deteção de valores atípicos para ativar a deteção de valores atípicos:

  • Erros 5xx consecutivos. Um código de estado HTTP da série 5xx é considerado um erro.
  • Erros de gateway consecutivos. Apenas os códigos de estado HTTP 502, 503 e 504 são considerados um erro.

Tenha em atenção que, mesmo depois de ativar a deteção de valores atípicos, é provável que veja alguns pedidos a serem enviados para o recurso não saudável e, por conseguinte, a devolver erros 5XX aos clientes. Isto acontece porque os resultados do algoritmo de deteção de valores atípicos (remoção de pontos finais do conjunto de balanceamento de carga e devolução dos mesmos ao conjunto) são executados de forma independente por cada instância de proxy do balanceador de carga. Na maioria dos casos, mais do que uma instância de proxy processa o tráfego recebido por um serviço de back-end. Assim, é possível que um ponto final não saudável seja detetado e rejeitado apenas por alguns dos proxies e, enquanto isso acontece, outros proxies podem continuar a enviar pedidos para o mesmo ponto final não saudável.

Para reduzir ainda mais as taxas de erro, pode configurar parâmetros de deteção de valores atípicos mais agressivos. Recomendamos que configure valores mais elevados para os limites de rejeição (outlierDetection.baseEjectionTime). Por exemplo, os nossos testes mostram que a definição de outlierDetection.baseEjectionTime para 180 segundos com um QPS sustentado superior a 100 resulta em taxas de erro observadas inferiores a 5%. Para saber mais sobre a API de deteção de valores atípicos, consulte o artigo outlierDetection na documentação da API de serviço de back-end global.

Os seguintes campos outlierDetection não são suportados quando o serviço de back-end tem um NEG sem servidor anexado:

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

Para saber como configurar a deteção de valores atípicos, consulte o artigo Configure um Application Load Balancer externo global com um back-end sem servidor: ative a deteção de valores atípicos.

Máscaras de URL

Um back-end do NEG sem servidor pode apontar para um único recurso do Cloud Run (ou do App Engine ou das funções do Cloud Run, se aplicável) ou para uma máscara de URL que aponte para vários recursos. Uma máscara de URL é um modelo do seu esquema de URL. O NEG sem servidor usa este modelo para mapear o pedido para o recurso adequado.

As máscaras de URL são uma funcionalidade opcional que facilitam a configuração de NEGs sem servidor quando a sua aplicação sem servidor é composta por vários recursos do Cloud Run, das funções do Cloud Run ou do App Engine. Os NEGs sem servidor usados com equilibradores de carga de aplicações internos só podem usar uma máscara de URL que aponte para serviços do Cloud Run ou funções do Cloud Run (2.ª geração).

As máscaras de URL são úteis se a sua app sem servidor estiver mapeada para um domínio personalizado em vez do endereço predefinido que o Firebase fornece. Google Cloud Com um domínio personalizado, como example.com, pode ter vários recursos implementados em diferentes subdomínios ou caminhos no mesmo domínio. Nestes casos, em vez de criar um back-end de NEG sem servidor separado para cada recurso, pode criar um único NEG sem servidor com uma máscara de URL genérica para o domínio personalizado (por exemplo, example.com/<service>). O NEG extrai o nome do serviço do URL do pedido.

A ilustração seguinte mostra um balanceador de carga de aplicações externo com um único serviço de back-end e um NEG sem servidor que usa uma máscara de URL para mapear pedidos de utilizadores para diferentes serviços.

Distribuir tráfego para apps sem servidor.
Usar uma máscara de URL para distribuir o tráfego por diferentes serviços (clique para aumentar).

As máscaras de URL funcionam melhor quando os recursos da sua aplicação usam um esquema de URL previsível. A vantagem de usar uma máscara de URL em vez de um mapa de URL é que não precisa de criar NEGs sem servidor separados para os serviços login e search. Também não precisa de modificar a configuração do equilibrador de carga sempre que adicionar um novo recurso à sua aplicação.

Limitações

  • Um NEG sem servidor não pode ter pontos finais de rede, como um endereço IP ou uma porta.
  • Os NEGs sem servidor só podem apontar para recursos sem servidor localizados na mesma região onde o NEG é criado.
  • Para um balanceador de carga que esteja a usar um back-end de NEG sem servidor, o NEG sem servidor tem de ser criado no mesmo projeto que os recursos de apoio do Cloud Run, do App Engine, do API Gateway ou das funções do Cloud Run apontados pelo NEG. Pode ver pedidos a falhar se associar um serviço que não esteja no mesmo projeto que o NEG sem servidor.
  • Um balanceador de carga configurado com um NEG sem servidor não consegue detetar se o recurso sem servidor subjacente está a funcionar conforme esperado. Isto significa que, mesmo que o seu recurso esteja a devolver erros, o balanceador de carga continua a direcionar tráfego para ele. Certifique-se de que testa exaustivamente as novas versões dos seus recursos antes de encaminhar o tráfego de utilizadores para os mesmos.

Limitações com serviços de back-end

As seguintes limitações aplicam-se aos serviços de back-end que têm um back-end NEG sem servidor:

  • Um serviço de back-end global usado por balanceadores de carga de aplicações externos globais só pode ter um NEG sem servidor por região. Para combinar vários NEGs sem servidor num único serviço de back-end, todos os NEGs têm de representar implementações funcionalmente equivalentes em diferentes regiões. Por exemplo, os NEGs podem apontar para o mesmo recurso do Cloud Run, App Engine ou funções do Cloud Run implementado em diferentes regiões.
  • Um serviço de back-end global usado por equilibradores de carga de aplicações internos entre regiões só pode ter um recurso do Cloud Run ou das funções do Cloud Run (2.ª geração) anexado.
  • Um serviço de back-end regional só pode ter um NEG sem servidor anexado.
  • A referência de serviços entre projetos numa implementação de VPC partilhada é suportada com configurações que contêm um NEG sem servidor. Para usar esta funcionalidade, cria os componentes de front-end do balanceador de carga (endereço IP, regra de encaminhamento, proxy de destino e mapa de URLs) num projeto diferente dos componentes de back-end do balanceador de carga (serviço de back-end e NEGs sem servidor). Tenha em atenção que o serviço de back-end, os NEGs sem servidor associados e o recurso sem servidor de apoio (Cloud Run, App Engine, API Gateway ou funções do Cloud Run) têm sempre de ser criados no mesmo projeto.
  • A definição de limite de tempo do serviço de back-end não se aplica a serviços de back-end com back-ends NEG sem servidor. A tentativa de modificar a propriedade resource.timeoutSec do serviço de back-end resulta no seguinte erro: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Para serviços de back-end com back-ends NEG sem servidor, o limite de tempo predefinido é de 60 minutos. Este limite de tempo não é configurável. Se a sua aplicação precisar de ligações de longa duração, configure os clientes para repetir os pedidos em caso de falha.
  • Todos os NEGs sem servidor combinados num serviço de back-end também têm de usar o mesmo tipo de back-end. Isto significa que os NEGs sem servidor do Cloud Run só podem ser combinados com outros NEGs sem servidor do Cloud Run, e os NEGs sem servidor do App Engine só podem ser combinados com NEGs sem servidor do App Engine.
  • Não pode misturar 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 um serviço do Cloud Run a partir do mesmo serviço de back-end.
  • Quando configurar serviços de back-end que encaminham para NEGs sem servidor, determinados campos estão restritos:
    • Não pode especificar um modo de equilíbrio. Ou seja, os valores RATE, UTILIZATION e CONNECTION não têm efeito na distribuição do tráfego do equilibrador de carga.
    • As verificações de estado não são suportadas para backends sem servidor. Por conseguinte, não é possível configurar os serviços de back-end que contêm back-ends de NEG sem servidor com verificações de estado. No entanto, pode ativar opcionalmente a deteção de valores outliers para identificar recursos sem servidor não saudáveis e encaminhar novos pedidos para um recurso sem servidor saudável.
  • Não pode usar o comando gcloud compute backend-services edit para modificar um serviço de back-end com um back-end de NEG sem servidor. Como alternativa, use o comando gcloud compute backend-services update.

Aplicam-se limitações adicionais consoante o tipo de equilibrador de carga e o back-end sem servidor.

Limitações com balanceadores de carga de aplicações internos regionais e balanceadores de carga de aplicações externos regionais

  • Os NEGs sem servidor usados com equilibradores de carga de aplicações internos regionais ou equilibradores de carga de aplicações externos regionais só podem apontar para recursos do Cloud Run ou das funções do Cloud Run (2.ª geração).
  • Para projetos que usam NEGs sem servidor, o limite de consultas por segundo (QPS) é de 5000 QPS por projeto para tráfego enviado para quaisquer NEGs sem servidor configurados com balanceadores de carga de aplicações externos regionais ou balanceadores de carga de aplicações internos regionais. Este limite é agregado em todos os balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais no projeto. Este não é um limite por balanceador de carga.

Limitações com balanceadores de carga de aplicações internos entre regiões

  • Os NEGs sem servidor usados com equilibradores de carga de aplicações internos entre regiões só podem apontar para recursos do Cloud Run ou das funções do Cloud Run (2.ª geração).

Limitações com balanceadores de carga de aplicações externos globais

Estas secções indicam as limitações que vai encontrar quando configurar NEGs sem servidor com balanceadores de carga de aplicações externos globais.

Limitações com o Cloud Run

Limitações com o App Engine

  • O equilíbrio de carga em várias regiões não é suportado com o App Engine. Isto deve-se ao facto de o App Engine exigir 1 região por projeto.
  • Se estiver a usar a IAP, tem de usar o mesmo ID de cliente OAuth para todos os serviços do App Engine associados a um único equilibrador de carga.
  • Só é permitida uma política de IAP no caminho do pedido. Por exemplo, se já tiver definido uma política de CAs no serviço de back-end, não deve definir outra política de CAs na app do App Engine.
  • Os balanceadores de carga de aplicações externos globais com back-ends do ambiente flexível do App Engine e back-ends do ambiente padrão do App Engine não suportam a referência de serviços entre projetos.
  • Recomendamos que use controlos de entrada para que a sua app apenas receba pedidos enviados a partir do equilibrador de carga (e da VPC, se a usar). Caso contrário, os utilizadores podem usar o URL do App Engine da sua app para contornar o balanceador de carga, as políticas de segurança do Cloud Armor, os certificados SSL e as chaves privadas que são transmitidas através do balanceador de carga.

Limitações com o gateway da API

Para mais informações, consulte o artigo Limitações nas NEGs sem servidor e no API Gateway.

Limitações com funcionalidades de gestão de tráfego

Preços

Para ver informações de preços dos balanceadores de carga com NEGs sem servidor, consulte Todos os preços de rede: Cloud Load Balancing.

O que se segue?