Visão geral do balanceamento de carga HTTP(S) interno

O balanceamento de carga HTTP(S) interno do Google Cloud é um balanceador regional, de camada 7 e com base em proxy que permite executar e escalonar seus serviços atrás de um endereço IP de balanceamento de carga interno.

O balanceamento de carga HTTP(S) interno distribui o tráfego HTTP e HTTPS aos back-ends hospedados no Compute Engine e no Google Kubernetes Engine (GKE). O balanceador de carga só pode ser acessado na região escolhida da rede da nuvem privada virtual (VPC) em um endereço IP interno.

O balanceamento de carga de HTTP(S) interno é um serviço gerenciado baseado no proxy de código aberto Envoy (em inglês). Isso ativa os recursos avançados de controle de tráfego com base em parâmetros HTTP(S). Após a configuração do balanceador de carga, ele aloca proxies Envoy automaticamente para atender às suas necessidades de tráfego.

Em geral, um balanceador de carga HTTP(S) interno é composto pelo seguinte:

  • Um endereço IP interno para onde os clientes enviam tráfego. Apenas os clientes que estão localizados na mesma região que o balanceador de carga podem acessar esse endereço IP. As solicitações internas de cliente permanecem internas na sua rede e região.
  • Um ou mais serviços de back-end para onde o balanceador de carga encaminha o tráfego. Os back-ends podem ser VMs do Compute Engine, grupos de VMs do Compute Engine, por meio de grupos de instâncias, ou nós do GKE, por meio de grupos de endpoint de rede (NEGs, na sigla em inglês). Esses back-ends precisam estar localizados na mesma região que o balanceador de carga.
Serviços internos com balanceamento de carga baseado na camada 7 (clique para ampliar)
Serviços internos com balanceamento de carga baseado na camada 7 (clique para ampliar)

Dois outros componentes são usados para entregar o serviço de balanceamento de carga:

  • Um mapa de URLs, que define regras de controle de tráfego baseadas em parâmetros da camada 7, como cabeçalhos HTTP, que mapeiam em serviços de back-end específicos. O balanceador de carga avalia solicitações recebidas no mapa de URLs para rotear o tráfego para serviços de back-end ou executar outras ações, como redirecionamentos.
  • Verificações de integridade, que conferem periodicamente o status dos back-ends e reduzem o risco do tráfego do cliente ser enviado para um back-end sem resposta.

Para informações sobre como os balanceadores de carga do Google Cloud diferem entre si, consulte os seguintes documentos:

Casos de uso

O balanceamento de carga HTTP(S) interno atende muitos casos de uso. Nesta seção, você verá alguns exemplos detalhados. Para outros exemplos, consulte os casos de uso de gerenciamento de tráfego.

Balanceamento de carga usando roteamento baseado em caminho

Um caso de uso comum é o tráfego de balanceamento de carga entre os serviços. Neste exemplo, um cliente interno pode solicitar conteúdo de vídeo e imagem usando o mesmo URL de base, mygcpservice.internal, com os caminhos /video e /images.

O mapa de URLs do balanceador de carga HTTP(S) interno especifica que as solicitações para o caminho /video precisam ser enviadas para o serviço de back-end de vídeo, enquanto as solicitações para o caminho /images precisam ser enviadas ao serviço de back-end de imagens. No exemplo a seguir, os serviços de back-end de vídeo e imagens são veiculados usando VMs do Compute Engine, mas eles também podem ser veiculados usando pods do GKE.

Quando um cliente interno envia uma solicitação ao endereço IP interno do balanceador de carga, o balanceador avalia a solicitação de acordo com essa lógica e envia a solicitação ao serviço de back-end correto.

O diagrama a seguir mostra esse caso de uso.

Serviços internos (micro) com balanceamento de carga baseado na camada 7 (clique para ampliar)
Serviços internos (micro) com balanceamento de carga baseado na camada 7

Como modernizar serviços legados

O balanceamento de carga HTTP(S) interno pode ser uma ferramenta eficiente para modernizar aplicativos legados.

Um exemplo de aplicativo legado é um grande aplicativo monolítico que não pode ser atualizado facilmente. Nesse caso, é possível implantar um balanceador de carga HTTP(S) interno na frente do aplicativo legado. É possível usar os recursos de controle de tráfego do balanceador de carga para direcionar um subconjunto de tráfego para novos microsserviços que substituem a funcionalidade que seu aplicativo legado fornece.

Para começar, você configuraria o mapa de URLs do balanceador de carga para rotear todo o tráfego para o aplicativo legado por padrão. Isso mantém o comportamento atual. À medida que os serviços para substituição fossem desenvolvidos, você atualizaria o mapa de URLs para rotear parcelas de tráfego para esses serviços.

Imagine que seu aplicativo legado contém alguma funcionalidade de processamento de vídeo que é veiculada quando clientes internos enviam solicitações para /video. É possível dividir este serviço de vídeo em um microsserviço separado da seguinte forma:

  1. Adicione balanceamento de carga HTTP(S) interno na frente do seu aplicativo legado.
  2. Crie um microsserviço de processamento de vídeo substituto.
  3. Atualize o mapa de URLs do balanceador de carga para que todas as solicitações para o caminho /video sejam roteadas para o novo microsserviço em vez do aplicativo legado.

Conforme você desenvolvesse outros serviços de substituição, você continuaria atualizando o mapa de URLs. Com o tempo, menos solicitações seriam encaminhadas para o aplicativo legado. Por fim, existiriam serviços para substituir todas as funções fornecidas pelo aplicativo legado. Nesse momento, seria possível desativar seu aplicativo legado.

Serviços da Web de três camadas

É possível usar o balanceamento de carga HTTP(S) interno para dar suporte a serviços da Web de três camadas tradicionais. O exemplo a seguir mostra como é possível usar três tipos de balanceadores de carga do Google Cloud para escalonar três camadas. Em cada camada, o tipo do balanceador de carga depende do seu tipo de tráfego:

O diagrama mostra como o tráfego passa pelas camadas:

  1. Um balanceador de carga HTTP(S) externo distribui o tráfego da Internet para um conjunto de grupos de instâncias de front-end da Web em várias regiões.
  2. Esses front-ends enviam o tráfego HTTP(S) para um conjunto de balanceadores de carga HTTP(S), regionais e internos (o assunto desta visão geral).
  3. Os balanceadores de carga HTTP(S) internos distribuem o tráfego para grupos de instâncias de middleware.
  4. Esses grupos de instância de middleware enviam o tráfego para balanceadores de carga TCP/UDP internos, que balanceam a carga do tráfego para clusters de armazenamento de dados.
Roteamento baseado na camada 7 para camadas internas em um app de várias camadas (clique para ampliar)
Roteamento baseado na camada 7 para camadas internas em um app de várias camadas

Exemplos de acesso

É possível acessar um balanceador de carga HTTP(S) interno em sua rede VPC a partir de uma rede conectada usando o seguinte:

  • Peering de rede VPC
  • Cloud VPN e Cloud Interconnect

Para exemplos detalhados, consulte o balanceamento de carga interno e redes conectadas.

Arquitetura e recursos

O diagrama a seguir mostra os recursos do Google Cloud necessários para um balanceador de carga HTTP(S) interno.

Componentes do balanceamento de carga HTTP(S) interno (clique para ampliar)
Componentes do balanceamento de carga HTTP(S) interno

Os recursos a seguir definem um balanceador de carga HTTP(S) interno:

  • Uma regra interna de encaminhamento gerenciada especifica um endereço IP interno, uma porta e um proxy HTTP(S) de destino regional Os clientes usam o endereço IP e a porta para se conectar aos proxies Envoy do balanceador de carga.

  • Um proxy HTTP(S) de destino regional recebe uma solicitação do cliente. O proxy HTTP(S) avalia a solicitação usando o mapa de URLs para tomar decisões de roteamento de tráfego. O proxy também pode autenticar comunicações usando certificados SSL.

  • Se você estiver usando o balanceamento de carga HTTP(S) interno, o proxy HTTP(S) usará certificados SSL regionais para provar a identidade aos clientes. Um proxy HTTP(S) de destino é compatível com até um número documentado de certificados SSL.

  • O proxy HTTP(S) usa um mapa de URLs regionais para fazer a determinação do roteamento com base em atributos HTTP, como caminho de solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha as solicitações de clientes para serviços de back-end regionais específicos. O mapa de URLs pode especificar outras ações a serem executadas, como regravar cabeçalhos, enviar redirecionamentos a clientes e configurar políticas de tempo limite, entre outras.

  • Um serviço de back-end regional distribui solicitações para back-ends íntegros, sendo grupos de instâncias que contêm VMs do Compute Engine ou NEGs contendo contêineres do GKE.

  • Um ou mais back-ends precisam estar conectados ao serviço de back-end. Os back-ends podem ser grupos de instância ou NEGs em qualquer uma das seguintes configurações:

    • Grupos de instâncias gerenciadas (zonais ou regionais)
    • Grupos de instâncias não gerenciadas (zonais)
    • Grupos de endpoints de rede (zonais)

    Não é possível usar grupos de instâncias e NEGs no mesmo serviço de back-end.

  • Uma verificação de integridade regional monitora periodicamente a prontidão de seus back-ends. Isso reduz o risco de que solicitações sejam enviadas para back-ends que não possam atender à solicitação.

  • Uma sub-rede apenas de proxy em que os endereços IP são a origem do tráfego dos proxies do balanceador de carga para os back-ends. É preciso criar uma sub-rede apenas de proxy em cada região de uma rede VPC. Nela, é possível usar balanceadores de carga HTTP(S) internos. O Google gerencia essa sub-rede e todos os balanceadores de carga HTTP(S) internos na região a compartilham. Não é possível usar essa sub-rede para hospedar os back-ends.

  • Um firewallpara que seus back-ends aceitem conexões da sub-rede apenas de proxy. Para detalhes, consulte o exemplo em Como configurar regras de firewall.

Tipos de tráfego, esquema e escopo

Os serviços de back-end são compatíveis com os protocolos HTTP, HTTPS ou HTTP/2. Clientes e back-ends não precisam usar o mesmo protocolo de solicitação. Por exemplo, os clientes podem enviar solicitações para o balanceador de carga usando HTTP/2, e o balanceador de carga pode encaminhar essas solicitações para back-ends usando HTTP/1.1.

Como o escopo de um balanceador de carga HTTP(S) interno é regional e não global, os clientes e as VMs de back-end ou os endpoints precisam estar na mesma região.

Limitações

  • O balanceamento de carga HTTP(S) interno opera em um nível regional.

  • Não há garantia de que uma solicitação de um cliente em uma zona da região seja enviada para um back-end que esteja na mesma zona que o cliente. A afinidade da sessão não reduz a comunicação entre as zonas.

  • O balanceamento de carga HTTP(S) interno não é compatível com os seguintes recursos:

  • Ao criar um balanceador de carga HTTP(S) interno em um projeto host de VPC compartilhada:

    • As VMs cliente podem estar localizadas no projeto host ou em qualquer projeto de serviço conectado. As VMs cliente precisam usar a mesma rede VPC compartilhada e a mesma região do balanceador de carga.
    • Todos os componentes e back-ends do balanceador de carga precisam estar no projeto host. Isso é diferente de outros balanceadores de carga do Google Cloud porque nenhum dos componentes internos do balanceador de carga HTTP(S) pode estar em um projeto de serviço quando o balanceador de carga usa uma rede VPC compartilhada.
    • O projeto host na rede VPC compartilhada tem e cria a sub-rede apenas de proxy (purpose=INTERNAL_HTTPS_LOAD_BALANCER).
  • O protocolo WebSocket não é compatível.

  • Um balanceador de carga HTTP(S) interno é compatível com HTTP/2 somente por TLS.

  • O Google Cloud não alerta se os endereços IP da sub-rede apenas de proxy acabarem.

  • Dentro de cada rede VPC, cada regra interna de encaminhamento gerenciada precisa ter seu próprio endereço IP. Para mais informações, consulte Várias regras de encaminhamento com um endereço IP comum.

  • A regra de encaminhamento interna usada pelo balanceador de carga HTTP(S) interno precisa ter apenas uma porta.

A seguir