Como otimizar a latência do aplicativo com balanceamento de carga

Este documento discute as opções de balanceamento de carga e demonstra como a escolha de um balanceador de carga específico no Google Cloud Platform (GCP) afeta a latência de ponta a ponta.

Opções para balanceamento de carga

Dependendo do tipo de tráfego enviado ao seu aplicativo, existem várias opções para o balanceamento de carga. A tabela a seguir resume as opções:

Opção Descrição Fluxo de tráfego Escopo
Balanceamento de carga de HTTP, HTTPS, TCP e SSL Oferece tráfego HTTP(S) e recursos avançados, como mapeamento de URL e descarregamento de SSL.
Compatível com proxy TCP ou proxy SSL para tráfego não HTTP em portas específicas.
A sessão TCP ou SSL (TLS) é encerrada no Google Front Ends (GFEs) na borda da rede do Google e o tráfego é enviado por proxy aos back-ends. Global
Balanceamento de carga de rede Permite que todo o tráfego de TCP/UDP por qualquer porta passe pelo balanceador de carga. Entregue usando a tecnologia Maglev da Google para distribuir o tráfego aos backends. Região

Como o balanceador de carga interno não é compatível com tráfego direcionado ao usuário, ele está fora do escopo deste artigo.

Todas as medições deste artigo foram feitas com o nível de serviço de rede Premium, que é o único nível em que o balanceamento de carga global está disponível.

Como medir a latência

Ao acessar um site hospedado em us-central1, um usuário na Alemanha usou os seguintes métodos para testar a latência:

  • Ping: embora esta seja uma maneira comum de medir a acessibilidade do servidor, o ping ICMP não fornece uma boa indicação de latência do usuário final. Leia uma explicação na seção Outros efeitos de latência do balanceamento de carga HTTP(S).
  • Tempo para primeiro byte (TTFB, na sigla em inglês): uma boa maneira de medir o tempo para a primeira resposta HTTP é emitir um comando curl repetidamente ao servidor para receber uma resposta do servidor da Web.

Ao comparar os resultados, esteja ciente de que a latência em links de fibra é restringida principalmente pela distância e velocidade da luz em fibra, que é de aproximadamente 200.000 km/s (ou 124,724 milhas/s).

A distância entre Frankfurt, Alemanha e Council Bluffs, Iowa, que é a localização da região us-central1, é de aproximadamente 7.500 km. Com a fibra perfeitamente reta entre os locais, a latência de ida e volta seria:

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

Na realidade, o cabo de fibra óptica não segue um caminho ideal entre o usuário e o data center, sendo que a luz no cabo de fibra passa através de equipamentos ativos e passivos ao longo de seu caminho. Uma latência observada de aproximadamente 1,5 vezes a ideal, ou 112,5 ms, indicaria uma configuração perto da ideal.

Como comparar a latência

Esta seção compara o balanceamento de carga nas seguintes configurações:

  • sem balanceamento de carga;
  • balanceamento de carga de rede;
  • balanceamento de carga HTTP ou proxy TCP.

Nesse cenário, o aplicativo consiste em um grupo de instâncias gerenciadas regionais de servidores da Web HTTP. Como o aplicativo depende de chamadas de baixa latência para um banco de dados central, os servidores da web devem ser hospedados em um local. O aplicativo é implantado na região us-central1 e os usuários são distribuídos em todo o globo. A latência que o usuário na Alemanha observa neste cenário ilustra a experiência que os usuários em todo o mundo podem ter.

Diagrama de cenário de latência

Sem balanceamento de carga

Quando um usuário faz uma solicitação HTTP sem balanceamento de carga, o tráfego flui diretamente da rede do usuário para a máquina virtual (VM) hospedada no Google Compute Engine. O tráfego então entra na rede do Google em um ponto de presença (POP) de edge próximo à localização do usuário.

Arquitetura sem balanceamento de carga

A tabela a seguir mostra os resultados quando o usuário na Alemanha testou a latência de um sistema sem balanceamento de carga:

Método Resultado Latência mínima
Ping do endereço IP da VM (resposta diretamente do servidor da Web)

[user@germany ~]$ ping -c 5 gce-vm
PING gce-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from gce-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
64 bytes from gce-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
[...]
--- gce-vm ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
110 ms
TTFB

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w  /
    "%{time_total}\n" -o /dev/null -s gce-vm; done
0.230
0.230
0.231
0.231
0.230
[...]
0.232
0.231
0.231
l10n-attrs-original-order="do,curl,-w,-o,-s,done">
230 ms

A latência TTFB é muito estável, como mostrado no seguinte gráfico das primeiras 500 solicitações:

Latência para VM no gráfico de ms

Ao dar um ping no endereço IP da VM, a resposta é diretamente do servidor da Web. O tempo que o servidor web consome é mínimo em comparação com a latência da rede (TTFB). Essa diferença ocorre porque uma nova conexão TCP é aberta para cada solicitação HTTP e um handshake inicial de três vias é necessário antes que a resposta HTTP seja enviada, conforme mostrado no diagrama a seguir. Portanto, a latência que o usuário na Alemanha observou é aproximadamente o dobro da latência de ping.

Diagrama de solicitação HTTP de cliente-servidor

Balanceamento de carga de rede

Com um balanceador de carga de rede, as solicitações de usuários ainda entram na rede do Google no POP de edge mais próximo. Na região onde as VMs do projeto estão localizadas, o tráfego flui primeiro através de um balanceador de carga Maglev e, em seguida, é encaminhado sem alterações à VM do back-end de destino. O balanceador de carga Maglev distribui o tráfego com base em um algoritmo de hash estável, que usa uma combinação de porta de origem e de destino, endereço IP e protocolo. As VMs detectam o IP do balanceador de carga e aceitam o tráfego inalterado.

Arquitetura com balanceamento de carga de rede

A tabela a seguir mostra os resultados quando o usuário na Alemanha testou a latência para a opção de balanceamento de carga de rede:

Método Resultado Latência mínima
Ping do balanceador de carga de rede

[user@germany ~]$ ping -c 5 net-lb
PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
[...]
64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
--- net-lb ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
110 ms
TTFB

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w /
    "%{time_total}\n" -o /dev/null -s net-lb
0.231
0.232
0.230
0.230
0.232
[...]
0.232
0.231
l10n-attrs-original-order="do,curl,-w,-o,-s,net-lb">
230 ms

Como o balanceamento de carga ocorre dentro da região e o tráfego é encaminhado, não há impacto de latência significativo em comparação com a opção sem balanceador de carga.

Balanceamento de carga de proxy HTTP(S)/TCP/SSL

Com o balanceamento de carga HTTP, o tráfego é enviado por proxy via GFEs, que normalmente estão localizados na borda da rede global do Google. O GFE encerra a sessão TCP e se conecta a um back-end na região mais próxima que tenha capacidade para atender o tráfego.

Diagrama de cenário de balanceamento de carga HTTP

A tabela a seguir mostra os resultados quando o usuário na Alemanha testou a latência para a opção de balanceamento de carga HTTP:

Método Resultado Latência mínima
Ping do balanceador de carga HTTP

[user@germany ~]$ $ ping -c 5 http-lb
PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
--- http-lb ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
1 ms
TTFB

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w /
    "%{time_total}\n" -o /dev/null -s http-lb; done
0.309
0.230
0.229
0.233
0.230
[...]
0.123
0.124
0.126
l10n-attrs-original-order="do,curl,-w,-o,-s,done">
123 ms

Os resultados para o balanceamento de carga HTTP são significativamente diferentes. Ao fazer um ping no balanceador de carga HTTP, a latência de ida e volta é apenas superior a 1 ms. No entanto, esse resultado representa a latência para o GFE mais próximo, que nesse caso está localizado na mesma cidade que o usuário. Esse resultado não tem nada a ver com a latência real que o usuário vivencia ao tentar acessar o aplicativo hospedado na região us- central1. Isso demonstra que experimentos usando protocolos (ICMP) diferentes do seu protocolo de comunicação de aplicativos (HTTP) podem ser enganosos.

Ao medir o TTFB, as solicitações iniciais mostram aproximadamente a mesma latência de resposta. Durante os pedidos, solicitações adicionais atingem a menor latência mínima de 123 ms, conforme mostrado no gráfico a seguir:

Latência para balanceamento de carga HTTP no gráfico de ms

No entanto, duas viagens de ida e volta entre o cliente e a VM levariam mais de 123 ms, mesmo com fibra perfeitamente reta. O motivo da menor latência é devido ao tráfego ser enviado por proxy pelos GFEs, que mantêm as conexões persistentes para as VMs do back-end abertas. Portanto, apenas a primeira solicitação de um GFE específico para um back-end específico precisa de um handshake de três vias.

Solicitação HTTP inicial via diagrama GFE

Existem vários GFEs em cada local. No gráfico de latência, é possível observar vários picos flutuantes no início, enquanto o tráfego alcança cada par de back-end de GFC pela primeira vez, refletindo diferentes hashes de solicitação. Depois que todos os GFEs foram alcançados, as solicitações subsequentes apresentam a menor latência.

Solicitação HTTP subsequente via diagrama GFE

Esses cenários demonstram a latência reduzida que pode ser vivenciada pelos usuários em um ambiente de produção. A tabela a seguir sintetiza os resultados:

Opção Ping TTFB
Sem balanceamento de carga 110 ms para o servidor da Web 230 ms
Balanceamento de carga de rede 110 ms para o balanceador de carga de rede na região 230 ms
Balanceamento de carga HTTP 1 ms para o GFE mais próximo 123 ms

Quando um aplicativo saudável está atendendo regularmente usuários em uma região específica, todos os GFEs nessa região geralmente devem ter uma conexão persistente aberta para todos os back-ends de serviço. Como tal, os usuários nessa região notarão latência significativamente reduzida em sua primeira solicitação HTTP se estiverem longe do back-end do aplicativo. Se os usuários estiverem perto do back-end do aplicativo, nenhuma melhoria de latência será observada por causa da proximidade deles.

Para as solicitações subsequentes, como clicar em um link de página, nenhuma melhoria de latência é observada porque os navegadores modernos já mantêm uma conexão persistente com o serviço a ser reutilizado, ao contrário de um comando de curl emitido a partir da linha de comando.

Efeitos de latência adicionais do balanceamento de carga HTTP(S)

Existem mais alguns efeitos perceptíveis com o balanceamento de carga HTTP(S) que dependem dos padrões de tráfego.

  • O balanceamento de carga HTTP(S) tem menos latência para recursos complexos do que o balanceamento de carga de rede HTTP porque são necessárias menos viagens de ida e volta para que uma resposta seja concluída. Por exemplo, quando o usuário na Alemanha mediu a latência sobre a mesma conexão fazendo repetidamente o download de um arquivo de 10 MB, a latência média para o balanceamento de carga da rede foi de 1911 ms em comparação com 1341 ms do balanceamento de carga HTTP, economizando aproximadamente 5 viagens de ida e volta por solicitação. Essa redução ocorre porque conexões persistentes entre GFEs e back-ends de serviço reduzem os efeitos do Início lento de TCP.

  • O balanceamento de carga HTTP(S) reduz significativamente a latência adicional para um handshake de TLS (normalmente 1 a 2 viagens de ida e volta extras). Essa redução ocorre porque o HTTP(S) usa o descarregamento de SSL, e apenas a latência para o POP de edge é relevante. Para o usuário na Alemanha, a latência mínima observada é de 201 ms usando o balanceamento de carga HTTP(S) em comparação com 525 ms usando HTTP(S) por meio do balanceador de carga de rede.

  • O balanceador de carga HTTP(S) também permite um upgrade automático da sessão direcionada ao usuário para HTTP/2, o que pode reduzir o número de pacotes necessários ao usar melhorias no protocolo binário, na compactação de cabeçalho e na multiplexação de conexão. Isso pode reduzir a latência observada ainda mais do que aquela observada ao alternar para o balanceamento de carga HTTP isoladamente. HTTP/2 é utilizado apenas em conjunto com navegadores atuais usando SSL/TLS. Para o nosso usuário na Alemanha, a latência mínima diminuiu adicionalmente de 201 ms para 145 ms ao usar HTTP/2 em vez de HTTPS simples.

Como otimizar o balanceamento de carga HTTP(S)

Otimize a latência para seu aplicativo usando o balanceador de carga HTTP(S) da seguinte maneira:

  • Se algum do tráfego que você usa é armazenável em cache, é possível integrar-se ao Google Cloud CDN. O Cloud CDN reduz a latência ao fornecer recursos diretamente na borda de rede do Google. O Cloud CDN também faz uso das otimizações TCP e HTTP (HTTP/2) mencionadas na seção Efeitos de latência adicionais do balanceamento de carga HTTP(S).

  • Use qualquer parceiro CDN com o GCP. Ao usar um dos parceiros de interconexão CDN do Google, você se beneficia dos custos de saída com desconto.

  • Se o conteúdo for estático, é possível reduzir a carga nos servidores da Web ao fornecer conteúdo diretamente do Google Cloud Storage por meio do balanceador de carga HTTP/S. Essa opção combina perfeitamente com as opções de CDN mencionadas anteriormente.

  • A implantação dos servidores da Web em várias regiões próximas aos usuários pode reduzir a latência porque o balanceamento de carga HTTP(S), proxy SSL e proxy TCP direcionam os usuários automaticamente para a região mais próxima. No entanto, se o aplicativo for parcialmente centralizado, crie-o para minimizar as viagens de ida e volta inter-regionais.

  • Para reduzir a latência dentro dos aplicativos, examine todas as chamadas de procedimento remoto (RPCs) que se comuniquem entre VMs. Essa latência normalmente ocorre quando os aplicativos se comunicam entre camadas ou serviços. Ferramentas como Stackdriver Trace podem ajudar a minimizar a latência causada por pedidos de serviço de aplicativos.

  • Como o proxy TCP e SSL também são baseados no GFE, o efeito na latência é o mesmo observado com o balanceamento de carga HTTP. Como o balanceamento de carga HTTP(S) possui mais recursos que o proxy TCP/SSL, recomendamos sempre usar balanceamento de carga HTTP(S) para o tráfego HTTP(S).

Próximas etapas

Ao criar a arquitetura do aplicativo no GCP, recomendamos que você implante o aplicativo para que ele esteja próximo da maioria de seus usuários e escolha a melhor configuração para o uso. Para mais informações sobre os diferentes recursos para o balanceamento de carga no GCP, consulte as seguintes páginas:

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine