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 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 limitações específicas do balanceamento de carga HTTP(S) interno, consulte a esta seção.

Conheça as diferenças entre os balanceadores de carga do Google Cloud nos documentos a seguir:

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 função que seu aplicativo legado fornece.

Para começar, é possível configurar 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 são desenvolvidos, você atualiza o mapa de URLs para rotear parcelas de tráfego para esses serviços.

Imagine que seu aplicativo legado contém alguma função 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ê desenvolve outros serviços de substituição, você continua atualizando o mapa de URLs. Com o tempo, menos solicitações seriam encaminhadas para o aplicativo legado. Por fim, existem serviços para substituir todas as funções fornecidas pelo aplicativo legado. Nesse momento, é 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âncias de middleware enviam o tráfego para balanceadores de carga TCP/UDP internos, que balanceiam 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 Balanceamento de carga HTTP(S) 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

No diagrama acima, a sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga HTTP(S) internos. Todos os balanceadores de carga HTTP(S) internos em uma região e rede VPC compartilham a mesma sub-rede somente proxy porque todos os balanceadores de carga HTTP(S) internos na região e na rede VPC compartilham um pool de Proxies do Envoy. Mais:

  • As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
  • As VMs de back-end ou os endpoints de todos os balanceadores de carga HTTP(S) internos em uma região e uma rede VPC recebem conexões da sub-rede somente proxy.
  • O endereço IP de um balanceador de carga HTTP(S) interno não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada interna, descrita abaixo.

Cada balanceador de carga HTTP(S) interno usa estes recursos de configuração do Google Cloud:

  • 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. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, às vezes chamado de endereço IP virtual ou VIP.

    O endereço IP interno associado à regra de encaminhamento pode vir de qualquer sub-rede (na mesma rede e região) com a sinalização --purpose definida como PRIVATE. Observações:

    • O endereço IP pode (mas não é necessário) vir da mesma sub-rede que os grupos de instâncias de back-end.
    • O endereço IP não pode vir da sub-rede somente proxy reservada que tem a sinalização --purpose definida como INTERNAL_HTTPS_LOAD_BALANCER.
  • 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.

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

Certificados SSL

Se você estiver usando o balanceamento de carga baseado em HTTPS, precisará instalar um ou mais certificados SSL no proxy HTTPS de destino.

Esses certificados são usados por proxies HTTPS de destino para proteger as comunicações entre o balanceador de carga e o cliente.

Saiba mais sobre limites e cotas de certificados SSL nesta seção da página de cotas de balanceamento de carga.

Para ter a melhor segurança, use a criptografia de ponta a ponta na implantação do balanceador de carga HTTPS. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Saiba mais sobre como o Google criptografa o tráfego dos usuários no artigo Criptografia em trânsito no Google Cloud.

Regras de firewall

Seu balanceador de carga HTTP(S) interno requer as seguintes regras de firewall:

Tempo limite e tentativas

O tempo limite do serviço de back-end é um tempo limite de solicitação/resposta para o tráfego HTTP(S). Esse é o tempo que o balanceador de carga aguarda até que um back-end retorne uma resposta completa a uma solicitação.

Por exemplo, se o valor do tempo limite do serviço de back-end for o valor padrão de 30 segundos, os back-ends terão 30 segundos para responder às solicitações. O balanceador de carga repetirá a solicitação HTTP GET uma vez se o back-end fechar a conexão ou expirar antes de enviar cabeçalhos de resposta para o balanceador de carga. Se o back-end enviar cabeçalhos de resposta ou se a solicitação enviada ao back-end não for uma solicitação GET HTTP, o balanceador de carga não tentará novamente. Se o back-end não responder, o balanceador de carga retornará uma resposta HTTP 5xx para o cliente. Para esses balanceadores de carga, altere o valor do tempo limite se quiser permitir que os back-ends respondam com mais ou menos tempo às solicitações.

O balanceamento de carga HTTP(S) interno tem dois tipos diferentes de tempo limite:
  • Um tempo limite de serviço de back-end HTTP configurável, que representa o tempo que o balanceador de carga aguarda até que o back-end retorne uma resposta HTTP completa. O valor padrão do tempo limite do serviço de back-end é de 30 segundos. Considere aumentar esse tempo limite em qualquer uma destas circunstâncias:

    • Você espera que um back-end demore mais para retornar respostas HTTP.
    • Você verá respostas HTTP 408 com jsonPayload.statusDetail client_timed_out.
    • A conexão foi atualizada para um WebSocket

    Para o tráfego WebSocket enviado pelo balanceador de carga, o tempo limite do serviço de back-end é interpretado como o tempo máximo em que uma conexão WebSocket pode permanecer aberta, esteja ela inativa ou não. Saiba mais em Configurações do serviço de back-end.

  • O tempo limite de uma sessão TCP, que tem o valor fixado em 10 minutos (600 segundos). Esse período de sessão às vezes é chamado de tempo limite do sinal de atividade ou ocioso e o valor dele não é configurável pela modificação do serviço de back-end. É necessário configurar o software servidor da Web usado pelos seus back-ends para que o tempo limite do sinal de atividade seja maior que 600 segundos para impedir que as conexões sejam fechadas prematuramente pelo back-end. Esse tempo limite não se aplica a WebSockets.

Esta tabela ilustra as mudanças necessárias para modificar os tempos limite de keepalive para o software comum do servidor da Web:

Software servidor da Web Parâmetro Configuração padrão Configuração recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

O balanceador de carga repete solicitações GET com falha em determinadas circunstâncias, como quando o tempo limite do serviço de back-end é esgotado. Ele não repete solicitações POST com falha. As repetições são limitadas a duas tentativas. As solicitações repetidas geram apenas uma entrada de registro como resposta final.

Para mais informações, consulte Geração de registros e monitoramento do balanceamento de carga HTTP(S) interno.

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud têm suporte nativo para o protocolo WebSocket ao usar HTTP ou HTTPS como protocolo para o back-end. O balanceador de carga não precisa de configuração para representar conexões WebSocket.

O protocolo WebSocket fornece um canal de comunicação full-duplex entre clientes e servidores. Uma solicitação HTTP(S) inicia o canal. Para informações detalhadas sobre o protocolo, consulte RFC 6455 (em inglês).

Quando o balanceador de carga reconhece uma solicitação WebSocket Upgrade de um cliente HTTP(S) seguido por uma resposta Upgrade bem-sucedida da instância de back-end, o balanceador de carga representa o tráfego bidirecional durante a conexão atual. Se a instância de back-end não retornar uma resposta Upgrade bem-sucedida, o balanceador de carga fechará a conexão.

O tempo limite de uma conexão WebSocket depende do tempo limite configurável do serviço de back-end do balanceador de carga, que é 30 segundos, por padrão. Esse tempo limite se aplica a conexões WebSocket, independentemente de estarem em uso ou não. Para mais informações sobre o tempo limite do serviço de back-end e como configurá-lo, consulte Tempos limite e tentativas.

A afinidade de sessão para WebSockets funciona da mesma forma que para qualquer outra solicitação. Para mais informações, consulte Afinidade da sessão.

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.

Arquiteturas de VPC compartilhada

O balanceamento de carga HTTP(S) interno é compatível com redes que usam VPC compartilhada. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada. Em detalhes:

  • Você designa um projeto host e anexa um ou mais projetos de serviço a ele.
  • O administrador do projeto host cria uma ou mais redes e sub-redes da VPC compartilhada e as compartilha com projetos de serviço.
  • Recursos qualificados de projetos de serviço podem usar sub-redes na rede VPC compartilhada.

No contexto do balanceamento de carga HTTP(S) interno, há duas maneiras de configurar o balanceamento de carga em uma rede VPC compartilhada. É possível criar o balanceador de carga e as instâncias de back-end no projeto de serviço ou no projeto host.

Balanceador de carga e back-ends em um projeto de serviço

Nesse modelo, você implanta o balanceador de carga e as instâncias de back-end em um projeto de serviço. Em seguida, configure o balanceador de carga e as instâncias de back-end para usar a rede VPC compartilhada.

Esse modelo de implantação está alinhado com o caso de uso típico do modelo de implantação de rede VPC compartilhada: divisão de responsabilidade entre administração de rede e desenvolvimento de serviços. Ele permite que os administradores de rede aloquem espaço IP interno com segurança e eficiência e mantém uma separação clara de responsabilidades entre administradores de rede e desenvolvedores de serviços.

Balanceamento de carga HTTP(S) interno na rede VPC compartilhada
Balanceamento de carga HTTP(S) interno na rede VPC compartilhada

Projeto host

O administrador do projeto host:

  • Configura a rede VPC compartilhada no projeto host.
  • Provisiona sub-redes da rede VPC compartilhada.
  • Configura regras de firewall na rede VPC compartilhada.

Projeto de serviço

  • O administrador do projeto de serviço cria o balanceador de carga (regra de encaminhamento, proxy HTTP(S) de destino, mapa de URL, serviços de back-end) e instâncias de back-end no projeto de serviço.
  • Esses recursos de balanceamento de carga e instâncias de back-end referenciam a rede compartilhada e as sub-redes do projeto host da VPC compartilhada.

Esse padrão permite que os desenvolvedores de serviços criem serviços com balanceamento de carga nos próprios projetos de serviço. A equipe de desenvolvimento de serviços também pode atualizar a configuração do balanceador de carga e fazer alterações nas instâncias de back-end sem envolver os administradores do projeto host.

Se os clientes estiverem na mesma rede VPC compartilhada que o balanceador de carga, eles poderão estar no projeto host ou em um projeto de serviço. Esses clientes podem usar o endereço IP particular do balanceador de carga para acessar serviços de balanceamento de carga.

Para saber como configurar um balanceador de carga HTTP(S) interno para uma rede VPC compartilhada, consulte Como configurar o balanceamento de carga HTTP(S) interno com a VPC compartilhada.

Balanceador de carga e back-ends em um projeto host

Com esse modelo de implantação de rede, a rede, o balanceador de carga e os back-ends ficam todos no projeto host. Embora essa configuração funcione, ela não é adequada para implantações típicas de VPC compartilhada porque não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Se você ainda precisar executar um balanceador de carga e os back-ends dele no projeto host, siga as etapas em Como configurar o balanceamento de carga HTTP(S) interno.

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 de HTTP(S) interno não é compatível com os seguintes recursos:

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

    • Todos os componentes e back-ends de balanceamento de carga precisam existir no mesmo projeto, todos em um projeto host ou todos em um projeto de serviço. Por exemplo, não é possível implantar a regra de encaminhamento do balanceador de carga em um projeto e criar instâncias de back-end em outro.

    • Os clientes podem estar localizados no projeto host, em qualquer projeto de serviço anexado ou em qualquer rede conectada. Os clientes precisam usar a mesma rede VPC compartilhada e estar na mesma região do balanceador de carga.

  • 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