Visão geral dos grupos de endpoints de rede sem servidor

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 serviço do Cloud Run, App Engine ou Cloud Functions.

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

  • Um serviço ou um grupo de serviços do Cloud Run.
  • Uma função ou um grupo de funções do Cloud Functions.
  • Um app do App Engine (Standard ou Flex), um serviço específico dentro de um app, uma versão específica de um app ou um grupo de serviços.

Quando o balanceamento de carga HTTP(S) externo está ativado para apps sem servidor, é possível fazer o seguinte:

  • Configurar seu aplicativo sem servidor para ser exibido a partir de um endereço IP IPv4 e/ou IPv6 dedicado que não seja compartilhado com outros serviços.
  • Mapear um único URL para vários aplicativos sem servidor funcionalmente idênticos. Ao executar os aplicativos em diferentes regiões, as solicitações podem ser roteadas para a região mais próxima do usuário. O mapeamento de um único URL para vários aplicativos sem servidor funcionalmente idênticos é compatível apenas com o Cloud Run e o Cloud Functions.
  • Reutilizar os mesmos certificados SSL e as chaves privadas que você usa no Compute Engine, Google Kubernetes Engine e Cloud Storage. A reutilização dos mesmos certificados elimina a necessidade de gerenciar certificados separados para aplicativos sem servidor.

A configuração do balanceamento de carga HTTP(S) também permite que os apps sem servidor se integrem aos serviços existentes do Cloud. Faça o seguinte:

  • Compartilhar o espaço do URL com outras tecnologias do Google Cloud. Ao usar vários serviços de back-end, um único balanceador de carga HTTP(S) externo 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 host ou no caminho do URL da solicitação.
  • Proteger o serviço com o Google Cloud Armor, um produto de borda de segurança de WAF e defesa contra DDoS disponível para todos os serviços acessados por um balanceador de carga HTTP(S) externo. Há algumas limitações associadas a esse recurso, especialmente para o Cloud Run e o App Engine.
  • Ativar o serviço para otimizar os envios usando o Cloud CDN. O Cloud CDN armazena em cache o conteúdo próximo aos usuários. O Cloud CDN fornece recursos como invalidação de cache e URLs assinados do Cloud CDN.
  • Use a infraestrutura de borda do Google para encerrar as conexões HTTP(S) do usuário que estão mais perto dele, diminuindo a latência.

No restante deste documento, você verá como usar grupos de endpoints de rede (NEGs, na sigla em inglês) sem servidor com um balanceador de carga HTTP(S) externo. Não é possível usar NEGs sem servidor com balanceadores de carga HTTP(S) regionais externos ou com qualquer outro tipo de balanceador de carga.

Saiba mais sobre outros tipos de NEGs em:

Tipos de endpoint

Os NEGs sem servidor não têm endpoints de rede, como portas ou endereços IP. Eles só podem apontar para um serviço do Cloud Run, App Engine ou Cloud Functions que já existe e reside na mesma região que o NEG.

Ao criar um NEG sem servidor, você especifica o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) do serviço do Cloud Run, App Engine ou Cloud Functions. O endpoint é do tipo SERVERLESS. Outros tipos de endpoints não são compatíveis com um NEG sem servidor.

Um NEG sem servidor não pode ter mais de um endpoint. Como apenas um endpoint é permitido em cada NEG sem servidor, o balanceador de carga exibe como apenas front-end e envia o tráfego via proxy para o endpoint sem servidor especificado. No entanto, se o serviço de back-end contiver vários NEGs sem servidor, o balanceador de carga equilibrará o tráfego entre esses NEGs, minimizando a latência da solicitação.

Nível da rede

É possível usar um NEG sem servidor em um balanceador de carga usando os níveis de serviço de rede Standard ou Premium. O nível Premium é necessário apenas se você quiser configurar os NEGs sem servidor em várias regiões.

Componentes do balanceamento de carga

Este diagrama mostra como um NEG sem servidor se encaixa no modelo de balanceamento de carga HTTP(S).

Balanceamento de carga HTTPS simples (clique para ampliar)
Balanceamento de carga HTTP(S) para aplicativos sem servidor

Regra de encaminhamento

A regra de encaminhamento faz parte da configuração do front-end. Cada regra de encaminhamento tem um endereço IP externo, a versão IP (IPv4 ou IPv6), um protocolo (HTTP ou HTTPS, incluindo HTTP/2) e um número de porta (80 ou 443).

Proxy de destino

Os NEGs sem servidor só podem ser usados com proxies de destino HTTP e HTTPS. Os serviços que usam NEGs sem servidor não podem ser usados com proxies de destino TCP ou SSL.

Mapa de URL

A seleção de encaminhamento para um balanceador de carga HTTP(S) externo é baseada em um mapa de URL. Com um mapa de URL, os proxies HTTP(S) de destino determinam o serviço de back-end a ser usado verificando o nome e o caminho do host da solicitação no mapa de URL. Os balanceadores de carga podem ter vários serviços de back-end referenciados no mapa de URL. Cada serviço de back-end pode ser associado a um tipo de back-end diferente. Por exemplo, é possível ter um serviço de back-end para um NEG sem servidor e outro serviço de back-end para grupos de instâncias do Compute Engine.

Serviço de back-end

Os NEGs sem servidor podem ser usados como back-ends em um balanceador de carga. Um serviço de back-end pode ter vários NEGs sem servidor. Cada NEG sem servidor pode apontar para uma das seguintes opções:

  • O FQDN de uma única função ou serviço
  • Uma máscara de URL que aponta para várias funções ou serviços que exibem no mesmo domínio

Uma máscara de URL é um modelo de esquema de URL que informa ao back-end do NEG sem servidor como mapear a solicitação do usuário para o serviço correto. As máscaras de URL são úteis se você está usando um domínio personalizado para o aplicativo e tem vários serviços do Cloud Run, Cloud Functions ou App Engine exibidos no mesmo domínio. Em vez de criar um NEG separado sem servidor para cada função ou serviço, é possível criar o NEG com uma máscara de URL genérica para o domínio personalizado. Veja mais informações e exemplos em Máscaras de URL.

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

Máscaras de URL

As máscaras de URL opcionais facilitam a configuração de NEGs sem servidor quando o aplicativo tem vários serviços do Cloud Run, Cloud Functions ou App Engine. Um back-end de NEG sem servidor pode apontar para um único serviço do Cloud Run (ou App Engine ou Cloud Functions) ou para uma máscara de URL que aponta para vários serviços.

Uma máscara de URL é um modelo do esquema de URL. O NEG sem servidor usa esse modelo para mapear a solicitação ao serviço apropriado.

As máscaras de URL são úteis se o aplicativo sem servidor é mapeado para um domínio personalizado em vez do endereço padrão fornecido pelo Google Cloud. Com um domínio personalizado, como example.com, é possível implantar vários serviços em subdomínios ou caminhos diferentes no mesmo domínio. Nesses casos, em vez de criar um back-end separado de NEG sem servidor para cada serviço, é possível 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 da solicitação.

A ilustração a seguir mostra um balanceador de carga HTTP(S) externo com um único serviço de back-end e um NEG sem servidor, que usa uma máscara de URL para mapear solicitações de usuários para diferentes serviços.

Distribuição de tráfego para aplicativos sem servidor (clique para ampliar)
Como usar uma máscara de URL para distribuir o tráfego para diferentes serviços

As máscaras de URL funcionam melhor quando os serviços do aplicativo usam um esquema de URL previsível. A vantagem de usar uma máscara de URL em vez de um mapa de URL é que você não precisa criar NEGs sem servidor separados para os serviços login e search. Também não é necessário alterar a configuração do balanceador de carga sempre que adicionar um novo serviço ao aplicativo.

Para saber como construir e configurar uma máscara de URL para um NEG sem servidor, consulte Como configurar um balanceador de carga HTTP(S) com um NEG sem servidor.

Limitações

  • Não é possível usar NEGs sem servidor como back-ends para balanceadores de carga HTTP(S) regionais externos.
  • Um NEG sem servidor não pode ter endpoints de rede, como endereço IP ou porta.
  • Os NEGs sem servidor só podem apontar para os serviços do Cloud Run, App Engine ou Cloud Functions que residem na mesma região em que o NEG é criado.
  • Os balanceadores de carga que usam back-ends de NEG sem servidor precisam ser criados no mesmo projeto que os serviços do Cloud Run, App Engine ou Cloud Functions apontados pelo NEG.
  • Um balanceador de carga HTTP(S) externo configurado com um NEG sem servidor não consegue detectar se o serviço subjacente está funcionando como esperado. Isso significa que, se o serviço em uma região estiver retornando erros, mas a infraestrutura geral nessa região estiver funcionando normalmente, o balanceador de carga HTTP(S) externo não poderá direcionar o tráfego automaticamente para outras regiões. Faça testes detalhados das novas versões dos serviços antes de encaminhar o tráfego de usuários para eles.

Limitações associadas a serviços de back-end que têm um back-end de NEG sem servidor

  • Um serviço de back-end pode ter um NEG sem servidor por região. Para combinar vários NEGs sem servidor em um único serviço de back-end, todos os NEGs precisam representar implantações funcionalmente equivalentes em regiões diferentes. Por exemplo, os NEGs podem apontar para o mesmo serviço do Cloud Run, App Engine ou Cloud Functions implantado em diferentes regiões.
  • A configuração de tempo limite do serviço de back-end não se aplica aos serviços de back-end com back-ends de 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.
  • 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 Cloud Run só podem ser combinados com outros NEGs sem servidor do Cloud Run, os NEGs sem servidor do App Engine só podem ser combinados com os NEGs sem servidor do App Engine etc.
  • Não é possível misturar NEGs sem servidor com outros tipos de NEGs (zonais ou da Internet) no mesmo serviço de back-end. Por exemplo, não é possível rotear para um cluster do GKE e um serviço do Cloud Run a partir do mesmo serviço de back-end.
  • Ao configurar serviços de back-end que encaminham para NEGs sem servidor, alguns campos são restritos:
    • Não é possível especificar um modo de balanceamento. Em outras palavras, os valores RATE, UTILIZATION e CONNECTION não afetam a distribuição de tráfego do balanceador de carga.
    • As verificações de integridade não são compatíveis com back-ends sem servidor. Portanto, os serviços de back-end que contêm back-ends de NEGs sem servidor não podem ser configurados com verificações de integridade.
  • Não é possível 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.

Pode haver outras limitações adicionais dependendo da plataforma de computação sem servidor que você está usando.

Limitações com o Cloud Run

  • O balanceamento de carga HTTP(S) externo com NEGs sem servidor não é compatível com o Cloud Run for Anthos.

Limitações com o Cloud Functions

  • O IAP não funciona com o Cloud Functions.

Limitações com o App Engine

  • O balanceamento de carga multirregional não é compatível com o App Engine. Isso ocorre porque o App Engine requer uma região por projeto.
  • Apenas uma política de IAP é permitida no caminho da solicitação. Por exemplo, se você já definiu uma política de IAP no serviço de back-end, não defina outra no aplicativo do App Engine.
  • Recomendamos usar controles de entrada para que o aplicativo receba apenas solicitações enviadas do balanceador de carga (e da VPC, se você usá-la). Caso contrário, os usuários poderão usar o URL do App Engine do aplicativo para ignorar o balanceador de carga, as políticas de segurança do Google Cloud Armor, os certificados SSL e as chaves privadas transmitidas pelo balanceador de carga.

Preço

Veja informações sobre preços de balanceadores de carga HTTP(S) externos com NEGs sem servidor em Preços de rede.

A seguir