O balanceador de carga de aplicativo é um balanceador de carga de camada 7 baseado em proxy que permite executar e escalonar os serviços. O balanceador de carga de aplicativo distribui o tráfego HTTP e HTTPS para back-ends hospedados em várias plataformas do Google Cloud, como o Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage e Cloud Run, bem como back-ends externos conectados pela Internet ou usando conectividade híbrida.
Os balanceadores de carga de aplicativo estão disponíveis nos seguintes modos de implantação:
Balanceador de carga de aplicativo externo: faz o balanceamento de carga do tráfego proveniente de clientes na Internet. Para detalhes de arquitetura, consulte Arquitetura do balanceador de carga de aplicativo externo.
Modo de implantação Nível de serviço da rede Esquema de balanceamento de carga Endereço IP Portas de front-end Global externo Nível Premium EXTERNAL_MANAGED IPv4
IPv6Pode referenciar exatamente uma porta de 1 a 65535.
Regional externo Nível Premium ou Standard EXTERNAL_MANAGED IPv4 Clássico Global no nível Premium.
Regional no nível Standard
EXTERNO* IPv4
IPv6 (exige o nível Premium)* É possível anexar serviços de back-endEXTERNAL_MANAGEDa regras de encaminhamentoEXTERNAL. No entanto, os serviços de back-endEXTERNALnão podem ser anexados às regras de encaminhamentoEXTERNAL_MANAGED. Para aproveitar os novos recursos disponíveis apenas com o balanceador de carga de aplicativo externo global, recomendamos que você migre seus recursosEXTERNALatuais paraEXTERNAL_MANAGEDusando o processo de migração descrito em Migrar recursos do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.Balanceador de carga de aplicativo interno: faz o balanceamento de carga do tráfego na rede VPC ou nas redes conectadas à rede VPC. Para obter detalhes de arquitetura, consulte Arquitetura do balanceador de carga de aplicativo interno.
Modo de implantação Nível de serviço da rede Esquema de balanceamento de carga Endereço IP Portas de front-end Regional interno Nível Premium INTERNAL_MANAGED IPv4 Pode referenciar exatamente uma porta de 1 a 65535.
Interno entre regiões*
Nível Premium INTERNAL_MANAGED IPv4 * O balanceador de carga usa recursos globais e pode ser implantado em uma ou várias regiões do Google Cloud escolhidas.
O esquema de balanceamento de carga é um atributo na regra de encaminhamento e no serviço de back-end de um balanceador de carga e indica se ele pode ser usado para tráfego interno ou externo. O termo _MANAGED no esquema de balanceamento de carga
indica que o balanceador de carga é implementado como um serviço gerenciado no
Google
Front Ends (GFEs) ou no proxy Envoy de código aberto. Em um esquema de balanceamento de carga
_MANAGED, as solicitações são roteadas para o GFE ou para o
proxy Envoy.
Balanceador de carga de aplicativo externo
Os balanceadores de carga de aplicativos externos são implementados usando front-ends do Google (GFEs) ou proxies gerenciados. Os balanceadores de carga de aplicativo externos globais e os balanceadores de carga de aplicativo clássicos usam GFEs distribuídos globalmente, que funcionam juntos usando a rede global e o plano de controle do Google. Os GFEs oferecem balanceamento de carga multirregional no nível Premium, direcionando o tráfego para o back-end íntegro mais próximo que tem capacidade e encerrando o tráfego HTTP(S) o mais próximo possível de seus usuários. Os balanceadores de carga de aplicativo externos globais e externos regionais usam o software de proxy Envoy de código aberto para ativar recursos avançados de gerenciamento de tráfego.
Eles podem ser implantados em um dos seguintes modos: global, regional ou clássico.
Os balanceadores de carga de aplicativo externos são compatíveis com os seguintes recursos:
- Gerenciamento de tráfego avançado, como espelhamento de tráfego, divisão de tráfego com base em ponderação e transformações de cabeçalho com base em solicitação/resposta. Para detalhes, consulte Visão geral do gerenciamento de tráfego.
- Tráfego de balanceamento de carga para back-ends hospedados em várias plataformas do Google Cloud, como Compute Engine, Google Kubernetes Engine (GKE), Cloud Run e muito mais. O suporte de back-end depende do modo de implantação do balanceador de carga. Para mais detalhes, consulte a Visão geral do balanceador de carga de aplicativo externo.
- Respostas em cache com o Cloud CDN.
- Proteção contra DDoS ou outros ataques da Web usando o Google Cloud Armor.
- Balanceamento de carga para o GKE usando a Entrada ou o Gateway (totalmente orquestrado) ou os NEGs independentes.
- Os balanceadores de carga de aplicativo externos regionais são compatíveis com o App Hub, que está em pré-lançamento.
O diagrama a seguir mostra um exemplo de arquitetura do balanceador de carga de aplicativo externo.
Para uma visão geral completa, consulte Visão geral da arquitetura para balanceadores de carga de aplicativos externos.
Balanceador de carga de aplicativo interno
Os balanceadores de carga de aplicativo internos são balanceadores de carga regionais de camada 7 baseados em proxy do Envoy que permitem executar e escalonar o tráfego de aplicativo HTTP por trás de um endereço IP interno. Os balanceadores de carga de aplicativo internos são compatíveis com back-ends em uma região, mas podem ser configurados para serem acessados globalmente por clientes de qualquer região do Google Cloud.
O balanceador de carga distribui o tráfego para back-ends hospedados no Google Cloud, no local ou em outros ambientes de nuvem. Os balanceadores de carga de aplicativo internos também são compatíveis com os seguintes recursos:
- Políticas de localidade. Em um grupo de instâncias de back-end ou de endpoint de rede, é possível configurar como as solicitações são distribuídas para instâncias ou endpoints de membro. Para detalhes, consulte Gerenciamento de tráfego.
- Acesso global. Quando o acesso global está ativado, clientes de qualquer região podem acessar o balanceador de carga. Para detalhes, consulte Ativar acesso global.
- Acesso a partir de redes conectadas. É possível tornar seu balanceador de carga acessível para clientes de redes além da própria rede de nuvem privada virtual (VPC) do Google Cloud. As outras redes precisam estar conectadas à rede VPC do balanceador de carga usando o peering de rede VPC, o Cloud VPN ou o Cloud Interconnect. Para detalhes, consulte Acessar redes conectadas.
- Compatibilidade com o GKE usando o Ingress (totalmente orquestrado). Para mais detalhes, consulte Configurar o Ingress para balanceadores de carga de aplicativos internos.
- Os balanceadores de carga de aplicativo internos regionais são compatíveis com o App Hub, que está em pré-lançamento.
Para uma visão geral completa, consulte Visão geral da arquitetura para balanceadores de carga internos do aplicativo.
Casos de uso
As seções a seguir apresentam alguns casos de uso comuns para balanceadores de carga de aplicativo.
Serviços da Web de três camadas
É possível implantar uma combinação de balanceadores de carga de aplicativo e de rede para dar suporte a serviços da Web de três camadas tradicionais. O exemplo a seguir mostra como implantar cada nível, dependendo do tipo de tráfego:
- Nível da Web. O front-end do aplicativo é disponibilizado por um balanceador de carga de aplicativo externo com back-ends de grupos de instâncias. O tráfego entra da Internet e é enviado por proxy do balanceador de carga para um conjunto de back-ends de grupos de instâncias em várias regiões. Esses back-ends enviam tráfego HTTP(S) para um conjunto de balanceadores de carga de aplicativos internos.
- Nível do aplicativo. O middleware do aplicativo é implantado e escalonado usando um balanceador de carga de aplicativo interno e back-ends de grupos de instâncias. Os balanceadores de carga distribuem o tráfego para grupos de instâncias de middleware. Esses grupos de instâncias de middleware enviam o tráfego para balanceadores de carga de rede de passagem interna.
- Nível do banco de dados. Os balanceadores de carga de rede servem como front-ends para o nível do banco de dados. Eles distribuem o tráfego para back-ends de armazenamento de dados em várias regiões.
Acesso global para balanceadores de carga de aplicativo regionais internos
Se você ativar o acesso global para o balanceador de carga de aplicativo interno regional, as VMs de cliente da camada da Web poderão estar em outra região.
Neste exemplo de aplicativo de vários níveis, mostramos o seguinte:
- Uma camada da Web voltada à Internet e disponível globalmente que balanceia a carga usando um balanceador de carga de aplicativo externo.
- Uma camada interna de banco de dados de balanceamento de carga de back-end na região
us-east1acessada pela camada global da Web. - Uma VM cliente que faz parte da camada da Web na região
europe-west1com acesso à camada do banco de dados de balanceamento de carga interno localizada emus-east1.
Cargas de trabalho com compliance com jurisdição
Algumas cargas de trabalho com requisitos regulatórios ou de conformidade exigem que as configurações de rede e a terminação de tráfego estejam em uma região específica. Para essas cargas de trabalho, um balanceador de carga de aplicativo regional geralmente é a opção preferencial para fornecer os controles jurisdicionais que essas cargas de trabalho exigem.
Gerenciamento de tráfego avançado
Os balanceadores de carga de aplicativo são compatíveis com recursos avançados de gerenciamento de tráfego que oferecem controle refinado sobre como seu tráfego é processado. Esses recursos incluem o seguinte:
- É possível atualizar a forma como o tráfego é gerenciado sem precisar modificar o código do aplicativo.
- Você pode rotear o tráfego de maneira inteligente com base nos parâmetros HTTP(S), como host, caminho, cabeçalhos e outros parâmetros de solicitação. Por exemplo, é possível usar buckets do Cloud Storage para processar qualquer conteúdo de vídeo estático e grupos de instâncias ou NEGs para processar todas as outras solicitações.
- É possível reduzir os riscos ao implantar uma nova versão do aplicativo usando a divisão de tráfego baseada em peso. Por exemplo, é possível enviar 95% do tráfego à versão anterior do serviço e 5% à nova versão dele. Depois de validar se a nova versão funciona conforme o esperado, é possível alterar gradualmente as porcentagens até que 100% do tráfego chegue à nova versão do serviço. A divisão de tráfego normalmente é usada para implantar novas versões, testes A/B, migração de serviços, modernização de serviços legados e processos semelhantes.
Veja a seguir um exemplo de roteamento baseado em caminho implementado usando um balanceador de carga de aplicativo interno. Cada caminho é processado por um back-end diferente.
Para ver mais detalhes, consulte os seguintes tópicos:
- Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais
- Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais
Extensibilidade com extensões de serviço
A integração com as extensões de serviço permite injetar lógica personalizada no caminho de balanceamento de carga dos balanceadores de carga de aplicativo com suporte.
Para mais informações, consulte Visão geral das extensões de serviço.
Como migrar serviços legados para o Google Cloud
Migrar um serviço para o Google Cloud permite que você libere a capacidade local e reduza o custo e o custo de manutenção de uma infraestrutura local. É possível configurar temporariamente uma implantação híbrida que permite rotear o tráfego para o serviço local atual e para um endpoint de serviço do Google Cloud correspondente.
O diagrama a seguir demonstra essa configuração com um balanceador de carga de aplicativo interno. Se você estiver usando um balanceador de carga interno, é possível configurar o balanceador de carga do Google Cloud para usar a divisão de tráfego baseada em peso para dividir o tráfego entre os dois serviços. A divisão de tráfego permite que você comece enviando 0% do tráfego para o serviço do Google Cloud e 100% para o serviço local. Em seguida, é possível aumentar gradualmente a proporção de tráfego enviado para o serviço do Google Cloud. Em algum momento, você enviará 100% do tráfego para o serviço do Google Cloud e poderá desativar o serviço local.
Balanceamento de carga para aplicativos do GKE
Há três maneiras de implantar balanceadores de carga de aplicativo em clusters do GKE:
- GKE Gateway controller. Compatível apenas com balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos regionais. Para instruções de configuração, consulte Como implantar gateways.
- Controlador de entrada do GKE. É possível usar o controlador de Entrada do GKE integrado, que implanta balanceadores de carga do Google Cloud em nome dos usuários do GKE. Isso é o mesmo que a arquitetura de balanceamento de carga independente, exceto pelo fato de o ciclo de vida dela ser totalmente automatizado e controlado pelo GKE. Compatível com balanceadores de carga de aplicativos externos e internos. Para instruções de configuração, consulte:
- NEGs independentes por zona. Os NEGs independentes são implantados e gerenciados por meio do controlador de NEG do GKE, mas todos os recursos de balanceamento de carga (regras de encaminhamento, verificações de integridade e assim por diante) são implantados manualmente. Elas são compatíveis com balanceadores de carga de aplicativos internos e externos.
Balanceamento de carga para aplicativos do Cloud Run, do Cloud Run functions e do App Engine
É possível usar um balanceador de carga de aplicativo como front-end para seus aplicativos sem servidor do Google Cloud. Isso permite que você configure os aplicativos sem servidor para atender às solicitações de um endereço IP dedicado que não é compartilhado com outros serviços.
Para configurar essa opção, use um NEG sem servidor para o back-end do balanceador de carga. Os diagramas a seguir mostram como um aplicativo sem servidor é integrado a um balanceador de carga de aplicativo.
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. Esse balanceador de carga é compatível apenas com back-ends do Cloud Run.
Regional interno
Este diagrama mostra como um NEG sem servidor se encaixa no modelo do balanceador de carga de aplicativo interno. Esse balanceador de carga é compatível apenas com back-ends do Cloud Run.
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. Esse balanceador de carga é compatível apenas com back-ends do Cloud Run.
Documentação relacionada:
- Visão geral dos NEGs sem servidor
- Configure um balanceador de carga de aplicativo externo global com um back-end do Cloud Run, do Cloud Run functions ou do App Engine
- 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
Balanceamento de carga para back-ends fora do Google Cloud
Os balanceadores de carga de aplicativo são compatíveis com o tráfego de balanceamento de carga para endpoints que se estendem além do Google Cloud, como data centers locais e outros ambientes de nuvem. Normalmente, os back-ends externos são acessíveis de uma das seguintes maneiras:
Acessível pela Internet pública. Para esses endpoints, use um NEG da Internet como back-end do balanceador de carga. O NEG da Internet está configurado para apontar para um único endpoint FQDN:Port ou IP:Port no back-end externo. Os NEGs da Internet podem ser globais ou regionais.
O diagrama a seguir demonstra como se conectar a back-ends externos acessíveis pela Internet pública usando um NEG global da Internet.
Balanceador de carga de aplicativo externo global com um back-end externo. Para mais detalhes, consulte Visão geral de NEGs da Internet.
Acessível usando conectividade híbrida (Cloud Interconnect ou Cloud VPN). Para esses endpoints, use um NEG híbrido como o back-end do balanceador de carga. O NEG híbrido está configurado para apontar para endpoints de IP:Port no back-end externo.
Os diagramas a seguir demonstram como se conectar a back-ends externos acessíveis usando o Cloud Interconnect ou o Cloud VPN.
Externo
Conectividade híbrida com balanceadores de carga globais de aplicativos externos. Interno
Conectividade híbrida com balanceadores de carga de aplicativo interno. Para mais detalhes, consulte Visão geral de NEGs híbridos.
Integração com o Private Service Connect
O Private Service Connect permite o consumo privado de serviços em redes VPC que pertencem a diferentes grupos, equipes, projetos ou organizações. Use o Private Service Connect para acessar APIs e serviços do Google ou serviços gerenciados em outra rede VPC.
É possível usar um balanceador de carga de aplicativo externo global para acessar serviços publicados usando o Private Service Connect. Para mais informações, consulte Sobre back-ends do Private Service Connect.
É possível usar um balanceador de carga de aplicativo interno para enviar solicitações a serviços e APIs regionais do Google compatíveis. Para mais informações, consulte Acessar APIs do Google por meio de back-ends.
Alta disponibilidade e failover entre regiões
O failover entre regiões só está disponível com balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões. Esses balanceadores de carga permitem melhorar a disponibilidade do serviço ao criar serviços de back-end globais com back-ends em várias regiões. Se os back-ends de uma determinada região estiverem inativos, o tráfego fará automaticamente o failover para outra região.
Para saber mais sobre como o failover funciona, consulte os seguintes tópicos:
- Balanceadores de carga de aplicativo externos globais: como as solicitações são distribuídas
- Balanceadores de carga de aplicativo internos entre regiões: alta disponibilidade e failover entre regiões