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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

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.
  • Um gateway de API que fornece acesso aos serviços por meio de uma API REST consistente em todos os serviços, independentemente da implementação deles. Essa capacidade está em pré-lançamento.

Casos de uso

Os NEGs sem servidor são compatíveis com os seguintes balanceadores de carga:

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

  • Configure o app sem servidor para ser exibido a partir de um endereço IP IPv4 dedicado que não seja compartilhado com outros serviços.
  • Mapeie um único URL para várias funções ou serviços sem servidor veiculados no mesmo domínio. Neste documento, consulte Máscaras de URL.
  • Compartilhe o espaço do URL com outras plataformas de computação do Google Cloud. 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 host ou no caminho do URL da solicitação.
  • 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.

Balanceador de carga HTTP(S) externo global e balanceador de carga HTTP(S) externo global (clássico)

A configuração de um balanceador de carga HTTP(S) externo global ou um balanceador de carga HTTP(S) externo global (clássico) permite que os seus aplicativos sem servidor se integrem aos serviços de nuvem atuais. Faça o seguinte:

  • 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.

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

A integração do balanceamento de carga HTTP(S) com o gateway de API permite que seus back-ends sem servidor aproveitem todos os recursos fornecidos pelo Cloud Load Balancing. Para mais informações, consulte Balanceamento de carga HTTP(S) para o gateway de API. Para configurar o balanceamento de carga HTTP(S) a fim de rotear o tráfego para um gateway de API, consulte Primeiros passos com o balanceamento de carga HTTP(S) para um gateway de API. Essa capacidade está em pré-lançamento.

Balanceador de carga HTTP(S) externo regional

Usando um Balanceador de carga HTTP(S) externo regional permite executar cargas de trabalho com requisitos regulatórios ou de conformidade sobre (Cloud Run ). Por exemplo, se você precisa que as configurações de rede e o encerramento do tráfego do seu aplicativo residam em uma região específica, um balanceador de carga HTTP(S) externo geralmente será a opção preferencial para atender aos controles jurisdicionais necessários.

Para saber como configurar um balanceador de carga HTTP(S) externo regional com um back-end de computação sem servidor, consulte Como configurar um balanceador de carga HTTP(S) externo regional com o Cloud Run.

Balanceador de carga HTTP(S) interno

Quando o balanceamento de carga HTTP(S) interno é configurado com back-ends (Cloud Run), é possível:

  • Ative os recursos avançados de gerenciamento de tráfego do balanceamento de carga HTTP(S) interno, como injeção de falha, substituições de cabeçalho, redirecionamentos, divisão de tráfego e muito mais, nos serviços do Cloud Run.
  • Migre com facilidade serviços legados do Compute Engine, do GKE ou do local para o Cloud Run e aproveite a divisão de tráfego baseada em peso para transferir gradualmente o tráfego para o Cloud Run sem inatividade.
  • Proteja os serviços do Cloud Run com o VPC Service Controls.
  • Estabeleça um único ponto de entrada interno de política para os serviços em execução no Cloud Run, Compute Engine e GKE.

Para saber como configurar um balanceador de carga HTTP(S) interno com um back-end de computação sem servidor, consulte Como configurar um balanceador de carga HTTP(S) interno com o Cloud Run.

O restante desta página discute como usar NEGs sem servidor com os balanceadores de carga HTTP(S).

Para mais informações sobre outros tipos de NEGs, consulte Visão geral dos grupos de endpoints de rede.

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, API Gateway 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, API Gateway 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. O endpoint aponta para um aplicativo sem servidor ou uma máscara de URL. O balanceador de carga serve como o front-end para o aplicativo de computação sem servidor e encaminha o tráfego para o endpoint especificado. No entanto, se o serviço de back-end contiver vários NEGs sem servidor em regiões diferentes, o balanceador de carga enviará tráfego ao NEG na região mais próxima para minimizar a latência da solicitação.

Nível da rede

Para balanceadores de carga HTTP(S) externos globais, é 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.

Os balanceadores de carga HTTP(S) externos regionais são sempre o nível Standard.

Os balanceadores de carga HTTP(S) internos são sempre de nível Premium.

Componentes do balanceamento de carga

Um balanceador de carga que usa um back-end de NEG sem servidor requer uma configuração especial apenas para o serviço de back-end. A configuração do front-end é igual à de qualquer outro balanceador de carga do Google Cloud baseado em proxy. Além disso, os balanceadores de carga HTTP(S) internos exigem uma sub-rede somente proxy para executar proxies do Envoy em seu nome.

Os diagramas a seguir mostram um exemplo de implantação de NEG sem servidor.

HTTP(S) externo

Este diagrama mostra como um NEG sem servidor se encaixa em uma arquitetura de balanceador de carga HTTP(S) externo global.

Balanceamento de carga HTTP(S) externo global para apps sem servidor
Balanceamento de carga HTTP(S) externo global para apps sem servidor

Este diagrama mostra como um NEG sem servidor se encaixa em uma arquitetura regional de balanceador de carga HTTP(S) externo.

Balanceamento de carga HTTP(S) externo regional para apps sem servidor
Balanceamento de carga HTTP(S) externo regional para apps sem servidor

HTTP(S) interno

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) interno para apps sem servidor

Componentes de front-end

Nenhuma configuração especial de front-end é necessária para o balanceamento de carga com back-ends NEG sem servidor. Regras de encaminhamento são usadas para rotear o tráfego por endereço IP, porta e protocolo para um proxy de destino. O proxy de destino encerra as conexões dos clientes.

Os mapas de URL são usados por balanceadores de carga HTTP(S) para configurar o roteamento baseado em URL de solicitações para os serviços de back-end apropriados.

Para mais detalhes sobre cada um desses componentes, consulte as seções de arquitetura de visões gerais específicas do balanceador 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 de um 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.

Um serviço de back-end global (usado por balanceadores de carga HTTP(S) externos globais) pode ter vários NEGs sem servidor anexados a ele, mas apenas um NEG sem servidor por região. Um serviço de back-end regional usado por balanceadores de carga HTTP(S) internos e por balanceadores de carga HTTP(S) externos só pode ter um NEG sem servidor anexado.

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 seu aplicativo sem servidor e tem vários serviços em exibição 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

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 um recurso opcional que facilita a configuração de NEGs sem servidor quando seu aplicativo consiste em vários serviços do Cloud Run, Cloud Functions ou App Engine. Os NEGs sem servidor usados com balanceadores de carga HTTP(S) internos só podem usar uma máscara de URL que aponte para os serviços do Cloud Run.

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 aprender a criar e configurar uma máscara de URL para um NEG sem servidor, consulte:

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 aplicativos sem servidor residentes na mesma região em que o NEG é criado.
  • Para um balanceador de carga que está usando um back-end NEG sem servidor, o NEG sem servidor precisa ser criado no mesmo projeto que os serviços de backup Cloud Run, App Engine, API Gateway ou Cloud Functions indicados pelo NEG. As solicitações podem falhar se você conectar um serviço que não está no mesmo projeto que o NEG sem servidor.
  • Um balanceador de carga configurado com um NEG sem servidor não consegue detectar se o app ou serviço subjacente sem servidor está funcionando conforme o esperado. Isso significa que, mesmo que o serviço retorne erros, o balanceador de carga continua direcionando tráfego para ele. Faça testes detalhados das novas versões dos serviços antes de encaminhar o tráfego de usuários para eles.

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

As limitações a seguir se aplicam aos 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 (totalmente gerenciado), App Engine ou Cloud Functions implantado em diferentes regiões.
  • Um serviço de back-end regional pode ter apenas um NEG sem servidor anexado a ele.
  • O serviço de back-end precisa ser criado no mesmo projeto que o NEG sem servidor e o serviço de backup do Cloud Run, App Engine, API Gateway ou Cloud Functions. Se você estiver configurando uma implantação de VPC compartilhada com referência de serviço entre projetos, os componentes de front-end do balanceador de carga (endereço IP, regra de encaminhamento, proxy de destino e mapa de URL) podem ser criados em outro projeto.
  • 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.
    Para serviços de back-end com back-ends de NEG sem servidor, o tempo limite padrão é de 60 minutos. Esse tempo limite não é configurável. Se seu aplicativo precisa de conexões de longa duração, configure seus clientes para repetir solicitações em caso de falha.
  • 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.

Outras limitações se aplicam, dependendo do tipo de balanceador de carga e do back-end sem servidor.

Limitações com balanceamento de carga HTTP(S) interno

  • Os NEGs sem servidor usados com balanceadores de carga HTTP(S) internos só podem apontar para serviços do Cloud Run.
  • Não é possível usar o Console do Google Cloud para configurar um balanceador de carga HTTP(S) interno com um back-end NEG sem servidor
  • É necessário que haja pelo menos uma VM na sua rede VPC para configurar um balanceador de carga HTTP(S) interno com um back-end sem servidor.

Limitações com balanceadores de carga HTTP(S) externos regionais

  • Os NEGs sem servidor usados com balanceadores de carga HTTP(S) externos só podem apontar para serviços do Cloud Run.
  • Não é possível usar o Console do Google Cloud para configurar um balanceador de carga HTTP(S) externo regional com um back-end NEG sem servidor.
  • É necessário que haja pelo menos uma VM na sua rede VPC para configurar um balanceador de carga HTTP(S) externo regional com um back-end sem servidor.

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.
  • O balanceamento de carga HTTP(S) externo não é compatível com solicitações autenticadas para os serviços do Cloud Run.

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.

Limitações com o gateway de API

Para mais informações, consulte Limitações em NEGs sem servidor e no gateway de API.

Preços

Para ver informações sobre preços de balanceadores de carga com NEGs sem servidor, consulte Preços de rede.

A seguir