Otimize a latência do aplicativo com balanceamento de carga

Neste documento, você verá opções de balanceamento de carga e como sua escolha de um balanceador de carga específico no Google Cloud afeta a latência de ponta a ponta.

Opções para balanceamento de carga

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

Opção Descrição Fluxo de tráfego Escopo
Balanceador de carga de aplicativo externo Compatível com tráfego HTTP(S) e recursos avançados, como mapeamento de URL e descarregamento de SSL
Use um balanceador de carga de rede de proxy externo para tráfego não HTTP em portas específicas.
A sessão TCP ou SSL (TLS) é encerrada nos Google Front Ends (GFEs), na extremidade da rede do Google, e o tráfego é enviado por proxy para os back-ends. Global
Balanceador de carga de rede de passagem externa Permite que o tráfego TCP/UDP use qualquer porta para transmitir pelo balanceador de carga. Entregue usando a tecnologia Maglev do Google para distribuir o tráfego aos back-ends. Regional

Como os balanceadores de carga internos e o Cloud Service Mesh não oferecem suporte ao tráfego voltado ao usuário, eles estão fora do escopo deste artigo.

As medições deste artigo usam o nível Premium nos níveis de serviço de rede porque o balanceamento de carga global exige esse nível de serviço.

Como medir a latência

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

  • Ping: embora o ping ICMP seja uma forma comum de medir a acessibilidade do servidor, o ping ICMP não mede a latência do usuário final. Para mais informações, consulte Outros efeitos de latência de um balanceador de carga de aplicativo externo.
  • Curl o Curl mede o tempo de início até o primeiro byte (TTFB, na sigla em inglês). Emita um comando curl repetidamente para o servidor.

Ao comparar os resultados, esteja ciente de que a latência em links de fibra é restrita pela distância e velocidade da luz em fibra, que é de aproximadamente 200.000 km por segundo.

A distância entre Frankfurt, Alemanha e Council Bluffs, Iowa (a região us-central1) é de aproximadamente 7.500 km. Com a fibra reta entre os locais, a latência de ida e volta é a seguinte:

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

O cabo de fibra ótica não segue um caminho reto entre o usuário e o data center. A luz do cabo de fibra passa por um equipamento ativo e passivo ao longo do caminho. Uma latência observada de aproximadamente 1,5 vezes a ideal, ou 112,5 ms, indica 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;
  • Balanceador de carga de rede de passagem externa
  • Balanceador de carga de aplicativo externo ou balanceador de carga de rede de proxy externo

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 estão distribuídos por todo o mundo. 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.

Cenário de latência.
Cenário de latência (clique para ampliar).

Sem balanceamento de carga;

Quando um usuário faz uma solicitação HTTP, a menos que o balanceamento de carga esteja configurado, o tráfego flui diretamente da rede do usuário para a máquina virtual (VM) hospedada na Compute Engine. No nível Premium, o tráfego entra na rede do Google em um ponto de presença (PoP, na sigla em inglês) de extremidade próximo do local do usuário. No nível Standard, o tráfego do usuário entra na rede do Google em um PoP próximo à região de destino. Para mais informações, consulte a documentação dos níveis de serviço de rede.

Arquitetura sem balanceamento de carga
Arquitetura sem balanceamento de carga (clique para ampliar)

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)
  ping -c 5 compute-engine-vm
  
  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-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
  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  
  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
  
230 ms

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

Latência para VM no gráfico de ms
Latência até a VM no gráfico em ms (clique para ampliar)

Ao dar um ping no endereço IP da VM, a resposta vem diretamente do servidor da Web. O tempo de resposta do servidor da Web é mínimo em comparação com a latência da rede (TTFB). Isso ocorre porque uma nova conexão TCP é aberta para cada solicitação HTTP. 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 observada é aproximadamente o dobro da latência de ping.

Solicitação HTTP de cliente/servidor.
Solicitação HTTP de cliente/servidor (clique para ampliar).

Balanceador de carga de rede de passagem externa

Com balanceadores de carga de rede de passagem externa, as solicitações do usuário ainda entram na Rede do Google no PoP de extremidade mais próximo (no nível Premium). Na região em que as VMs do projeto estão localizadas, o tráfego flui primeiro através de um balanceador de carga de rede de passagem externa. Em seguida, ele é encaminhado sem alterações para a VM de back-end de destino. O balanceador de carga de rede de passagem externa distribui o tráfego com base em um algoritmo de hash estável. O algoritmo 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 um balanceador de carga de rede de passagem externa.
Arquitetura com um balanceador de carga de rede de passagem externa (clique para ampliar)

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
Dar um ping no balanceador de carga de rede de passagem externa
  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
 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 
 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
 
230 ms

Como o balanceamento de carga ocorre dentro de uma região e o tráfego é somente encaminhado, não há impacto de latência significativo em comparação a não ter um balanceador de carga.

Balanceamento de carga externo

Com balanceadores de carga de aplicativo externos, tráfego de proxy dos GFEs. Esses GFEs estão 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 pode disponibilizar o tráfego.

Cenário de balanceador de carga de aplicativo externo.
Cenário do balanceador de carga de aplicativo externo (clique para ampliar).

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
Dar um ping no balanceador de carga de aplicativo externo
 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
 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 
 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
 
123 ms

Os resultados do balanceador de carga de aplicativo externo são significativamente diferentes. Ao dar um ping no balanceador de carga externo, a latência de ida e volta é um pouco acima de 1 ms. Esse resultado representa a latência para o GFE mais próximo, localizado na mesma cidade do usuário. Esse resultado não reflete a latência real que o usuário tem ao tentar acessar o aplicativo hospedado na região us-central1. Experimentos com protocolos (ICMP) diferentes do protocolo de comunicação de aplicativo (HTTP) podem ser enganosos.

Ao medir o TTFB, as solicitações iniciais mostram a latência de resposta semelhante. Algumas solicitações atingem a latência mínima mais baixa de 123 ms, conforme mostrado no gráfico a seguir:

Latência para o balanceador de carga de aplicativo externo no gráfico em ms.
Gráfico da latência até o balanceador de carga de aplicativo externo em ms (clique para ampliar)

Duas viagens de ida e volta entre o cliente e a VM levam mais de 123 ms, mesmo com fibra reta. A latência é menor porque os GFEs fazem o proxy do tráfego. Os GFEs mantêm conexões permanentes com as VMs de back-end. Portanto, somente a primeira solicitação de um GFE específico para um back-end específico requer um handshake de três vias.

Cada local tem vários GFEs. O gráfico de latência mostra vários picos flutuantes na primeira vez que o tráfego atinge cada par de back-end do GFE. O GFE precisa estabelecer uma nova conexão com esse back-end. Esses picos refletem diferentes hashes de solicitação. As solicitações subsequentes apresentam menor latência.

Primeira solicitação HTTP observada versus próxima observação no GFE
Solicitação HTTP observada pela primeira vez versus próxima observação no GFE (clique para ampliar)

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
Balanceador de carga de rede de passagem externa 110 ms até o balanceador de carga de rede de passagem externa na região 230 ms
Balanceador de carga de aplicativo externo 1 ms para o GFE mais próximo 123 ms

Quando um aplicativo íntegro está atendendo usuários em uma região específica, os GFEs nessa região mantêm uma conexão persistente aberta a todos os back-ends de serviço. Por isso, os usuários dessa região notam uma latência reduzida na primeira solicitação HTTP se estiverem longe do back-end do aplicativo. Se os usuários estiverem perto do back-end do aplicativo, eles não notarão uma melhoria na latência.

Para as solicitações subsequentes, como clicar em um link de página, não há melhoria de latência porque os navegadores modernos mantêm uma conexão permanente com o serviço. Isso é diferente de um comando curl emitido da linha de comando.

Outros efeitos de latência do balanceador de carga de aplicativo externo

Os outros efeitos observáveis com o balanceador de carga de aplicativo externo dependem dos padrões de tráfego.

  • O balanceador de carga de aplicativo externo tem menos latência para recursos complexos do que o balanceador de carga de rede de passagem externa, porque menos idas e voltas são necessárias antes de uma resposta ser concluída. Por exemplo, quando o usuário na Alemanha mede a latência na mesma conexão fazendo repetidamente o download de um arquivo de 10 MB, a latência média do balanceamento de carga de rede de passagem externa é de 1.911 ms. Com o balanceador de carga de aplicativo externo, a latência média é de 1.341 ms. Isso economiza aproximadamente cinco viagens de ida e volta por solicitação. As conexões permanentes entre GFEs e disponibilização de back-ends reduzem os efeitos do início lento do TCP.

  • O balanceador de carga de aplicativo externo reduz significativamente a latência adicional para um handshake de TLS (normalmente de 1 a 2 viagens de ida e volta extras). Isso ocorre porque o balanceador de carga de aplicativo externo usa o descarregamento de SSL, e apenas a latência até o PoP de borda é relevante. Para o usuário na Alemanha, a latência mínima observada é de 201 ms usando o balanceador de carga de aplicativo externo, em comparação com 525 ms usando HTTP(S) através do balanceador de carga de rede de passagem externa.

  • O balanceador de carga de aplicativo externo permite um upgrade automático da sessão voltada ao usuário para o HTTP/2. O HTTP/2 pode reduzir o número de pacotes necessários usando melhorias no protocolo binário, compactação de cabeçalho e multiplexação de conexão. Essas melhorias podem reduzir a latência observada ainda mais do que aquela observada ao alternar para o balanceador de carga de aplicativo externo. O HTTP/2 é compatível com navegadores atuais que usam SSL/TLS. Para o usuário na Alemanha, a latência mínima diminuiu ainda mais de 201 ms para 145 ms ao usar HTTP/2 em vez de HTTPS.

Como otimizar balanceadores de carga de aplicativo externos

É possível otimizar a latência do aplicativo usando o balanceador de carga de aplicativo externo da seguinte maneira:

  • Se parte do tráfego veiculado for armazenável em cache, é possível integrar-se ao Cloud CDN. O Cloud CDN reduz a latência exibindo recursos diretamente na extremidade da rede do Google. O Cloud CDN também usa as otimizações TCP e HTTP do HTTP/2 mencionadas na seção Outros efeitos de latência do balanceador de carga de aplicativo externo.

  • É possível usar qualquer parceiro CDN com o Google Cloud. Ao usar um dos parceiros do CDN Interconnect do Google, você aproveita o desconto nos custos de transferência de dados.

  • Se o conteúdo for estático, será possível reduzir a carga nos servidores da Web ao disponibilizar conteúdo diretamente do Cloud Storage através do balanceador de carga de aplicativo externo. Essa opção combina com o Cloud CDN.

  • A implantação dos servidores da Web em várias regiões próximas aos usuários pode reduzir a latência, já que o balanceador de carga direciona os usuários automaticamente para a região mais próxima. No entanto, se o aplicativo for parcialmente centralizado, crie-o para diminuir o número de viagens de ida e volta inter-regionais.

  • Para reduzir a latência dentro dos aplicativos, examine todas as chamadas de procedimento remoto (RPCs, na sigla em inglês) que se comunicam entre as VMs. Essa latência costuma ocorrer quando os aplicativos se comunicam entre níveis ou serviços. Ferramentas como o Cloud Trace podem ajudar você a diminuir a latência causada por solicitações de serviço de aplicativos.

  • Como os balanceadores de carga de rede de proxy externo são baseados nos GFEs, o efeito na latência é o mesmo observado com o balanceador de carga de aplicativo externo. Como o balanceador de carga de aplicativo externo tem mais recursos do que o balanceador de carga de rede de proxy externo, recomendamos o uso de balanceadores de carga de aplicativo externos para o tráfego HTTP(S).

Próximas etapas

Recomendamos que você implante o aplicativo próximo à maioria dos usuários. Para mais informações sobre as diferentes opções de balanceamento de carga no Google Cloud, consulte os seguintes documentos: