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.
Balanceadores de carga com suporte
A tabela a seguir lista os produtos sem servidor compatíveis com cada balanceador de carga de aplicativo. Os NEGs sem servidor não são compatíveis com balanceadores de carga de rede de proxy e balanceadores de carga de rede de passagem.
| Plataforma sem servidor | Balanceadores de carga de aplicativos | ||||
|---|---|---|---|---|---|
| Regional interno |
Inter-regional região interna |
Global externo |
Clássico | Regional externo |
|
| Cloud Run | |||||
| App Engine | |||||
| Cloud Functions | |||||
Casos de uso
Quando o balanceador de carga está ativado para aplicativos 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 de aplicativo externo global e balanceador de carga de aplicativo clássico
A configuração de um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico permite que 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 de aplicativo 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:
- Configurar um balanceador de carga de aplicativo externo global com o Cloud Run, App Engine ou Cloud Functions
- Configure um balanceador de carga de aplicativo clássico com o Cloud Run, o App Engine ou o Cloud Functions
A integração de um balanceador de carga de aplicativo externo 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 Balanceador de carga de aplicativo externo para gateway de API. Para configurar um balanceador de carga de aplicativo externo para rotear o tráfego para um gateway de API, consulte Primeiros passos com um balanceador de carga de aplicativo externo para o gateway de API. Essa capacidade está em pré-lançamento.
Balanceador de carga de aplicativo externo regional
Usando um Balanceador de carga de aplicativo 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 de aplicativo externo geralmente será a opção preferencial para atender aos controles jurisdicionais necessários.
Para saber como configurar um balanceador de carga de aplicativo externo regional com um back-end de computação sem servidor, consulte Configurar um balanceador de carga de aplicativo externo regional com o Cloud Run.
Balanceador de carga de aplicativo interno regional e balanceador de carga de aplicativo interno entre regiões
Quando um balanceador de carga de aplicativo interno é configurado com back-ends do Cloud Run, é possível fazer o seguinte:
- Ative recursos avançados de gerenciamento de tráfego, como injeção de falhas, substituições de cabeçalho, redirecionamentos, divisão de tráfego e muito mais, para os 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 de aplicativo interno regional com um back-end de computação sem servidor, consulte Configurar um balanceador de carga de aplicativo interno com o Cloud Run.
O restante desta página discute como usar NEGs sem servidor com os balanceadores de carga do aplicativo. 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, gateway de API 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, gateway de API 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 de aplicativo 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 de aplicativo externos regionais sempre são o nível Standard.
Os balanceadores de carga de aplicativo internos e regionais e regionais 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 de aplicativo internos exigem uma sub-rede somente proxy para executar proxies Envoy em seu nome.
Os diagramas a seguir mostram um exemplo de implantação de NEG sem servidor.
Global externo
Este diagrama mostra como um NEG sem servidor se encaixa em uma arquitetura global de balanceador de carga de aplicativo externo.
Regional externo
Este diagrama mostra como um NEG sem servidor se encaixa em uma arquitetura regional de balanceador de carga de aplicativo externo.
Regional interno
Este diagrama mostra como um NEG sem servidor se encaixa no modelo do balanceador de carga de aplicativo interno.
Entre regiões
Este diagrama mostra como um NEG sem servidor se encaixa no modelo de balanceador de carga de aplicativo interno entre regiões.
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 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.
As restrições a seguir se aplicam, dependendo do tipo de balanceador de carga:
- Um serviço de back-end global (usado por balanceadores de carga de aplicativo 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 de aplicativo internos e externos só pode ter um NEG sem servidor anexado a ele.
- Um serviço de back-end global usado por balanceadores de carga de aplicativo internos entre regiões pode ter apenas serviços do Cloud Run 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.
Detecção de outliers para NEGs sem servidor
A detecção de outliers é uma configuração opcional que pode ser ativada em um serviço de back-end global com NEGs sem servidor anexados a ele. A análise de detecção de outliers está disponível apenas para um balanceador de carga de aplicativo interno entre regiões, um balanceador de carga de aplicativo externo global e não para um balanceador de carga de aplicativo clássico. A análise de detecção de outliers identifica NEGs sem servidor não íntegros com base nos seus padrões de resposta HTTP e reduz a taxa de erro roteando algumas das novas solicitações de serviços não íntegros para serviços íntegros. Para saber como o algoritmo de detecção de outliers funciona e entender as limitações dele, consulte o exemplo a seguir.
Suponha que há um serviço de back-end com dois NEGs sem servidor
anexados a ele, um na região REGION_A e outro na
região REGION_B. Se o NEG sem servidor que serve como back-end para um balanceador de carga de aplicativo externo global na região REGION_A não for responsivo, a detecção de outliers identificará o NEG sem servidor como não íntegro. Assim, com base na análise de detecção de outliers, algumas das novas solicitações serão enviadas para o NEG sem servidor na região REGION_B.
Com base no tipo de erro de servidor encontrado, é possível usar um dos seguintes métodos de detecção de outliers para ativar essa detecção:
- Erros 5xx consecutivos. Um código de status HTTP da série
5xxse qualifica como erro. - Erros de gateway consecutivos. Somente os códigos de status HTTP
502,503e504se qualificam como erros.
Observe que, mesmo depois de ativar a detecção de outliers, você provavelmente verá algumas solicitações sendo enviadas para o serviço não íntegro e, portanto, retornando erros 5XX para os clientes. Isso ocorre porque os resultados do algoritmo de detecção de outliers (remoção de endpoints do pool de balanceamento de carga e retorno deles de volta ao pool) são executados independentemente por cada instância de proxy do balanceador de carga. Na maioria dos casos, mais de uma instância de proxy lida com o tráfego recebido por um serviço de back-end. Assim, é possível que um endpoint não íntegro seja detectado e removido apenas por alguns dos proxies e, enquanto isso acontece, outros proxies podem continuar enviando solicitações para o mesmo endpoint não íntegro.
Para reduzir ainda mais as taxas de erro, é possível configurar parâmetros de detecção de outliers
mais agressivos. Recomendamos configurar valores mais altos para os limites de expulsão
(outlierDetection.baseEjectionTime). Por exemplo, nossos testes mostram que definir outlierDetection.baseEjectionTime como 180 segundos com um QPS sustentado maior que 100 resulta em taxas de erro observadas abaixo de 5%. Para saber
mais sobre a API de detecção de outliers, consulte
outlierDetection
na documentação da API do serviço de back-end
global.
Os seguintes campos outlierDetection não são compatíveis quando o serviço de back-end tem um NEG sem servidor anexado a ele:
outlierDetection.enforcingSuccessRateoutlierDetection.successRateMinimumHostsoutlierDetection.successRateRequestVolumeoutlierDetection.successRateStdevFactor
Para saber como configurar a detecção de outliers, consulte Configurar um balanceador de carga de aplicativo externo global com um back-end sem servidor: ativar a detecção de outliers.
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 de aplicativo 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 de aplicativo 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.
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.
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, gateway de API 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 global usado por balanceadores de carga de aplicativo externos globais pode ter apenas 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 global usado por balanceadores de carga de aplicativo internos entre regiões pode ter apenas um serviço do Cloud Run anexado.
- Um serviço de back-end regional pode ter apenas um NEG sem servidor anexado a ele.
- A referência de serviços entre projetos em uma implantação de VPC compartilhada é compatível com configurações que contêm um NEG sem servidor. Para usar esse recurso, crie os componentes de front-end do balanceador de carga (endereço IP, regra de encaminhamento, proxy de destino e mapa de URL) em um projeto diferente dos componentes de back-end do balanceador de carga (serviço de back-end e NEGs sem servidor). ). O serviço de back-end, os NEGs sem servidor associados e o serviço de suporte sem servidor (Cloud Run, App Engine, gateway de API ou Cloud Functions) precisam ser sempre criados no mesmo 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.timeoutSecdo 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 e 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 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,UTILIZATIONeCONNECTIONnã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 NEG sem servidor não podem ser configurados com verificações de integridade. No entanto, você tem a opção de ativar a detecção de outliers para identificar serviços sem servidor não íntegros e encaminhar novas solicitações para um serviço sem servidor íntegro.
- Não é possível especificar um modo de balanceamento. Em outras palavras, os valores
- Não é possível usar o comando
gcloud compute backend-services editpara modificar um serviço de back-end com um back-end de NEG sem servidor. Como alternativa, use o comandogcloud 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 balanceadores de carga de aplicativo internos e externos regionais
- Os NEGs sem servidor usados com balanceadores de carga internos ou externos regionais do aplicativo só podem apontar para os serviços do Cloud Run.
- Para projetos que usam NEGs sem servidor, o limite de consultas por segundo (QPS) é de 5.000 QPS por projeto para o tráfego enviado a qualquer NEGs sem servidor configurado com balanceadores de carga de aplicativo externos regionais ou balanceadores de carga de aplicativo internos. Esse limite é agregado em todos os balanceadores de carga de aplicativo externos regionais e internos no projeto. Esse não é um limite por balanceador de carga.
Limitações com balanceadores de carga de aplicativo internos entre regiões
- Os NEGs sem servidor usados com balanceadores de carga de aplicativo internos entre regiões só podem apontar para os serviços do Cloud Run.
Limitações com balanceadores de carga globais de aplicativos externos
Nesta seção, listamos as limitações que você vai encontrar ao configurar NEGs sem servidor com balanceadores de carga de aplicativo globais externos.
Limitações com o App Engine
- Os balanceadores de carga de aplicativo externos globais com back-ends de ambiente flexível do App Engine não são compatíveis com o uso de referência de serviços entre projetos. O ambiente padrão do App Engine é compatível.
Limitações com o Cloud Run
- Um balanceador de carga de aplicativo externo com NEGs sem servidor não é compatível com a exibição Knative.
- Os balanceadores de carga de aplicativo externos não são compatíveis com solicitações autenticadas para 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á tiver definido 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.
Limitações dos recursos de gerenciamento de tráfego
- Recursos de gerenciamento de tráfego avançado, como política de localidade de balanceamento de carga, afinidade da sessão e detecção de outliers não são compatíveis com back-ends de NEG sem servidor.
- Especificar uma afinidade da sessão em um serviço de back-end com um NEG sem servidor não vai funcionar. Como solução alternativa para o Cloud Run, use o próprio recurso de afinidade da sessão.
Preços
Para informações sobre preços de balanceadores de carga com NEGs sem servidor, consulte Todos os preços de rede: Cloud Load Balancing.
A seguir
- Configurar um balanceador de carga de aplicativo externo global com o Cloud Run, App Engine ou Cloud Functions
- Configure um balanceador de carga de aplicativo clássico com o Cloud Run, o App Engine ou o Cloud Functions
- Configure um balanceador de carga de aplicativo externo regional com um back-end do Cloud Run
- Configure um balanceador de carga de aplicativo interno regional com um back-end do Cloud Run
- Configure um balanceador de carga de aplicativo interno entre regiões com o Cloud Run