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)

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.

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

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.

Private Service Connect

É possível usar um balanceamento de carga HTTP(S) interno para enviar solicitações a APIs e serviços regionais do Google compatíveis. Consulte Private Service Connect para mais informações.

Balanceamento de carga para aplicativos do GKE

Se você estiver criando aplicativos no GKE, recomendamos 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 descrita nesta página, exceto pelo fato de o ciclo de vida dela ser totalmente automatizado e controlado pelo GKE.

Documentação relacionada do GKE:

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

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

Sub-rede somente proxy

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 de uma região e rede VPC compartilham a mesma sub-rede somente proxy porque todos os balanceadores de carga HTTP(S) internos da região e da rede VPC compartilham um pool de proxies Envoy. Além disso:

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

Regra de encaminhamento e endereço IP

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.

Os clientes que se conectam a um balanceador de carga HTTP(S) interno precisam usar a versão 1.1 ou posterior. Para ver a lista completa dos protocolos compatíveis, consulte Recursos do balanceador de carga.

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 precisa) 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.

Cada regra de encaminhamento usada em um balanceador de carga HTTP(S) interno pode referenciar a exatamente uma porta TCP. Para balanceadores de carga HTTP, use a porta 80 ou 8080. Para balanceadores de carga HTTPS, use a porta 443.

Proxy de destino

Um proxy HTTP(S) de destino regional encerra as conexões HTTP(S) dos clientes. O proxy HTTP(S) consulta o mapa de URLs para determinar como rotear o tráfego para os back-ends. Um proxy HTTPS de destino usa um certificado SSL para fazer a autenticação para os clientes.

O balanceador de carga preserva o cabeçalho Host da solicitação original do cliente. O balanceador de carga também anexa dois endereços IP ao cabeçalho X-Forwarded-For:

  • O endereço IP do cliente que se conecta ao balanceador de carga
  • O endereço IP da regra de encaminhamento do balanceador de carga

Se não houver nenhum cabeçalho X-Forwarded-For na solicitação recebida, esses dois endereços IP serão o valor inteiro do cabeçalho. Se a solicitação tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registrados por proxies no caminho até o balanceador de carga, serão preservadas antes dos dois endereços IP. O balanceador de carga não verifica endereços IP que precedem os dois últimos endereços IP nesse cabeçalho.

Se você estiver executando um proxy como servidor de back-end, esse proxy normalmente anexará mais informações ao cabeçalho X-Forwarded-For, e o software poderá precisar considerar isso. As solicitações por proxy do balanceador de carga vêm de um endereço IP na sub-rede somente proxy, e seu proxy na instância de back-end pode registrar esse endereço e o endereço IP da própria instância.

Certificados SSL

O Transport Layer Security (TLS) é um protocolo de criptografia usado em certificados SSL para proteger as comunicações de rede.

O Google Cloud usa certificados SSL para fornecer privacidade e segurança de um cliente para um balanceador de carga. Se você estiver usando o balanceamento de carga baseado em HTTPS, precisará instalar um ou mais certificados SSL no proxy HTTPS de destino.

Para mais informações sobre certificados SSL, consulte:

Mapa de URL

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.

Serviço de back-end

Um serviço de back-end regional distribui solicitações para back-ends íntegros: grupos de instâncias que contêm VMs do Compute Engine, NEGs contendo contêineres do GKE ou NEGs do Private Service Connect que apontam para APIs e serviços do Google compatíveis.

Os serviços de back-end são compatíveis com os protocolos HTTP, HTTPS ou HTTP/2. O HTTP/2 só é compatível com TLS. 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.

Um ou mais back-ends precisam estar conectados ao serviço de back-end. 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. 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.

Verificação de integridade

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.

Regras de firewall

Um 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. O intervalo completo permitido para valores de tempo limite é de 1 a 2.147.483.647 segundos.

    Para o tráfego HTTP, esse tempo limite é a duração máxima da solicitação e da resposta HTTP.

    Para o tráfego WebSocket, esse tempo limite é o tempo máximo que uma conexão WebSocket pode permanecer aberta, esteja ela inativa ou ativa.

    Considere aumentar esse tempo limite em qualquer uma destas circunstâncias:

    • Você espera que um back-end demore mais para retornar respostas HTTP.
    • A conexão recebeu um upgrade para um WebSocket.

  • Um tempo limite de sinal de atividade HTTP, que tem o valor fixado em 10 minutos (600 segundos). Não é possível configurar esse valor modificando o 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;
  • Um tempo limite de inatividade, que tem um valor igual ao tempo limite do serviço de back-end. Os fluxos HTTP e as conexões WebSocket ficam inativos quando não há atividade durante essa duração.

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.

Como acessar redes conectadas

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

Failover

Se um back-end se tornar não íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros na mesma região. Se nenhum back-end estiver íntegro, o balanceador de carga retornará uma resposta HTTP 503 Service Unavailable.

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.

Quando o balanceador de carga reconhece uma solicitação WebSocket Upgrade de um cliente HTTP(S) seguida por uma resposta Upgrade bem-sucedida da instância de back-end, o balanceador de carga faz o proxy do 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 encerrará 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, estando em uso ou não.

A afinidade de sessão para WebSockets funciona da mesma forma que qualquer outra solicitação. Para mais informações, consulte Afinidade da sessã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 conhece bem a VPC compartilhada, leia a documentação de visão geral da 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

Neste modelo, o balanceador de carga e os back-ends existem em um projeto de serviço e usam endereços IP em sub-redes de uma rede VPC compartilhada.

Esse modelo de implantação está alinhado com os casos de uso típicos da VPC compartilhada:

  • Ao dividir a responsabilidade entre a administração de rede e o desenvolvimento de serviços, é possível manter uma separação clara das responsabilidades entre os administradores de rede e os desenvolvedores de serviços.
  • Ele Permite que os administradores de rede gerenciem endereços IP internos com segurança e eficiência.
Balanceamento de carga HTTP(S) interno na rede VPC compartilhada
Balanceamento de carga HTTP(S) interno na rede VPC compartilhada

Projeto host

No projeto host:

Projeto de serviço

  • O proprietário, editor ou papel mais granular do projeto de serviço (como um administrador do Compute) cria instâncias de back-end.
  • O proprietário, editor ou papel mais granular do projeto de serviço (como um administrador de rede ou administrador do balanceador de carga) cria os componentes do balanceador de carga, como regra de encaminhamento e HTTP(S) de destino, proxy, mapa de URL, serviços de back-end e verificações de integridade.
  • Esses recursos de balanceamento de carga e instâncias de back-end referenciam uma rede VPC compartilhadas e sub-redes no projeto host.

Os clientes poderão acessar o balanceador de carga se estiverem na mesma rede e região e VPC compartilhada que o balanceador de carga. Os clientes podem estar em um projeto de serviço ou no projeto host.

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

Neste modelo, a rede VPC compartilhada, os componentes do balanceador de carga e os back-ends estão no projeto host. Esse modelo não separa responsabilidade de administração de rede e desenvolvimento de serviços.

A configuração desse modelo é igual à configuração do balanceador de carga em uma rede VPC independente. Siga as etapas em Como configurar o balanceamento de carga HTTP(S) interno.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 e 1.3 ao encerrar solicitações SSL do cliente.

Quando o balanceador de carga HTTP(S) interno usa HTTPS como um protocolo de serviço de back-end, ele pode negociar TLS 1.0, 1.1, 1.2 ou 1.3 para o back-end.

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.

  • Os clientes que se conectam a um balanceador de carga HTTP(S) interno precisam usar a versão 1.1 ou posterior. O HTTP 1.0 não é compatível.

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

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

  • O balanceamento de carga HTTP(S) interno não é compatível com o Cloud Trace.

  • Os balanceadores de carga HTTP(S) internos não são compatíveis com o peering de rede VPC. É preciso criar as regras de encaminhamento e os back-ends do balanceador de carga na mesma rede VPC.

A seguir