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:

  • Um serviço ou um grupo de serviços do Cloud Run que compartilham o mesmo padrão de URL.
  • Uma função ou um grupo de funções do Cloud Functions que compartilham o mesmo padrão de URL.
  • Um aplicativo (Standard ou Flex), um serviço específico dentro de um aplicativo ou até mesmo uma versão específica de um aplicativo do App Engine.

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

  • 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.
  • Mapeie um único URL para vários aplicativos sem servidor idênticos que estão em execução em diferentes regiões, permitindo que as solicitações sejam roteadas para a região mais próxima do usuário. Isso é compatível apenas com o Cloud Run (totalmente gerenciado) e o Cloud Functions.
  • Reutilize os mesmos certificados SSL e as chaves privadas que você usa para o Compute Engine, o Google Kubernetes Engine e o Cloud Storage. Isso 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 aplicativos sem servidor se integrem aos serviços do Cloud existentes. Você pode:

  • 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 o Cloud Run (totalmente gerenciado), o App Engine, o Cloud Functions, o Compute Engine, o Google Kubernetes Engine e o Cloud Storage com base no host ou no caminho do URL de solicitação.
  • Proteja seu serviço com o Google Cloud Armor, um produto de segurança de WAF e defesa de DDoS de borda disponível para todos os serviços acessados por meio de um balanceador de carga HTTP(S) externo. Há algumas limitações associadas a esse recurso, principalmente para o Cloud Run (totalmente gerenciado) e o App Engine.
  • Ative seu serviço para otimizar os envios usando o Cloud CDN. Com o Cloud CDN, é possível armazenar conteúdo em cache 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.

O restante deste documento discute como usar os NEGs sem servidor com o balanceamento de carga HTTP(S). Não é possível usar NEGs sem servidor com outros tipos 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 (totalmente gerenciado), App Engine ou Cloud Functions que já existem e residem 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 (totalmente gerenciado), 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

É assim que 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 e contém 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 para serviços de back-end em um balanceador de carga. Um serviço de back-end pode ter o suporte de vários NEGs sem servidor, mas cada NEG sem servidor só pode apontar para o FQDN de um único serviço do Cloud Run (totalmente gerenciado), App Engine ou Cloud Functions ou então uma máscara de URL que aponte para vários serviços exibidos 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 seu aplicativo e tem vários serviços do Cloud Run (totalmente gerenciado), Cloud Functions ou App Engine exibidos no mesmo domínio. Nesses casos, em vez de criar um NEG sem servidor separado para cada serviço do Cloud Run (totalmente gerenciado), App Engine ou Cloud Functions, você pode criar o NEG com uma máscara de URL genérica para o domínio personalizado (por exemplo, example.com/<service>) e permita que o NEG extraia o nome do serviço do URL da solicitação. Veja mais informações e exemplos em Máscaras de URL.

Há outras restrições a serem lembradas ao adicionar um NEG sem servidor como back-end. Saiba mais em Limitações.

Máscaras de URL

As máscaras de URL são um recurso opcional que facilita a configuração de NEGs sem servidor quando seu aplicativo consiste em vários serviços do Cloud Run (totalmente gerenciado), Cloud Functions ou App Engine. Um back-end de NEG sem servidor pode apontar para um único serviço do Cloud Run (totalmente gerenciado), 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 usará esse modelo (por exemplo, example.com/<service>) para extrair o nome do serviço do URL da solicitação recebida e mapear a solicitação para o 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 do Cloud Run (totalmente gerenciado), Cloud Functions ou App Engine em subdomínios ou caminhos diferentes no mesmo domínio. Nesses casos, em vez de criar um back-end NEG sem servidor para cada serviço do Cloud Run (totalmente gerenciado), App Engine ou Cloud Functions, crie um único NEG sem servidor com uma máscara de URL genérica para o domínio personalizado (por exemplo, example.com/<service>) e permita que o NEG extraia 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.

Como distribuir o 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

  • 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 (totalmente gerenciado), 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 (totalmente gerenciado), App Engine ou Cloud Functions apontados pelo NEG.
  • O Cloud Monitoring não é compatível com back-ends de NEG sem servidor. Os serviços de back-end com outros tipos de back-ends não são afetados.
  • Um balanceador de carga HTTP(S) externo configurado com um NEG sem servidor não consegue detectar se o recurso sem servidor subjacente, como um serviço do App Engine, Cloud Functions ou Cloud Run (totalmente gerenciado), está funcionando conforme esperado. Isso significa que, se o serviço em uma região estiver retornando erros, mas a infraestrutura geral do Cloud Run (totalmente gerenciado), Cloud Functions ou App Engine nessa região estiver funcionando normalmente, o balanceador de carga HTTP(S) externo não 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 conter apenas um NEG sem servidor por região. Se você quiser combinar vários NEGs sem servidor em um único serviço de back-end, todos os NEGs precisam representar implantações funcionalmente equivalentes nas diferentes regiões. Por exemplo, os NEGs podem apontar para o mesmo serviço do Cloud Run (totalmente gerenciado), App Engine ou Cloud Functions implantado em diferentes regiões.
  • Não é possível modificar o tempo limite padrão do serviço de back-end de 30 segundos de um serviço de back-end NEG sem servidor. A tentativa de alterar a configuração do serviço de back-end para aumentar o tempo limite (definindo a propriedade resource.timeoutSec) 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 (totalmente gerenciado) só podem ser combinados com outros NEGs sem servidor do Cloud Run (totalmente gerenciado), ao passo que 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, isso significa que não é possível encaminhar para um cluster do GKE e um serviço do Cloud Run (totalmente gerenciado) 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 (totalmente gerenciado)

  • O Identity-Aware Proxy (IAP) não funciona com o Cloud Run (totalmente gerenciado).
  • Não é possível desativar os URLs que o Google Cloud atribui automaticamente aos serviços do Cloud Run (totalmente gerenciado). Os usuários que já têm o URL padrão do serviço do Cloud Run (totalmente gerenciado) podem ignorar o balanceador de carga e acessar diretamente o URL do serviço. Isso significa que, mesmo que você possa configurar políticas de segurança do Google Cloud Armor por meio do balanceador de carga, os usuários com o URL padrão podem burlar essas políticas.

Limitações com o Cloud Functions

  • O IAP não funciona com o Cloud Functions.
  • Não é possível desativar os URLs que o Google Cloud atribui automaticamente às funções do Cloud Functions. No entanto, você pode usar a configuração de entrada internal-and-gclb para permitir apenas o tráfego interno e o tráfego enviado para um IP público exposto pelo balanceador de carga HTTP(S) externo. O tráfego enviado para cloudfunctions.net ou qualquer outro domínio personalizado configurado por meio do Cloud Functions é bloqueado. Isso evita que os usuários burlem qualquer controle de acesso (como políticas de segurança do Google Cloud Armor) configurado por meio do balanceador de carga HTTP(S) externo.

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ços

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

A seguir