Como otimizar 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
Balanceamento de carga HTTP(S) Compatível com tráfego HTTP(S) e recursos avançados, como mapeamento de URL e descarregamento de SSL
Balanceamento de carga de proxy TCP ou Balanceamento de carga de proxy SSL 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
Balanceamento de carga de rede 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 Traffic Director não são compatíveis com o 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 do balanceamento de carga HTTP(S).
  • 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
  • Network Load Balancing
  • Balanceamento de carga HTTP(S) ou balanceamento de carga do 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 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.

Diagrama de cenário de latência (clique para ampliar)
Diagrama de 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 (clique para ampliar)
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 até a VM no gráfico em ms (clique para ampliar)
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.

Diagrama de solicitação HTTP cliente-servidor (clique para ampliar)
Diagrama de solicitação HTTP cliente-servidor (clique para ampliar)

Network Load Balancing

Com um balanceador de carga de rede, 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 por meio de um balanceador de carga de rede. Em seguida, ele é encaminhado sem alterações para a VM de back-end de destino. O balanceador de carga de rede 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 balanceamento de carga de rede (clique para ampliar)
Arquitetura com balanceamento de carga de rede (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
Ping do balanceador de carga de rede

  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 o balanceamento de carga HTTP(S), o 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.

Diagrama de cenário do balanceamento de carga HTTP(S) (clique para ampliar)
Diagrama de cenário do balanceamento de carga HTTP(S) (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 balanceamento de carga HTTP(S)

 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 balanceamento de carga HTTP(S) são significativamente diferentes. Ao dar um ping no balanceamento de carga HTTP(S), a latência de ida e volta fica um pouco acima de 1 ms. Esse resultado representa a latência para o GFE mais próximo, localizado na mesma cidade que o 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 balanceamento de carga HTTP(S) no gráfico ms (clique para ampliar)
Latência para balanceamento de carga HTTP(S) no gráfico 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.

Solicitação HTTP inicial por meio do diagrama do GFE (clique para ampliar)
Solicitação HTTP inicial por meio do diagrama do GFE (clique para ampliar)

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.

Solicitação HTTP subsequente por meio do diagrama do GFE (clique para ampliar)
Solicitação HTTP subsequente por meio do diagrama do 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
Balanceamento de carga de rede 110 ms para o balanceador de carga de rede na região 230 ms
Balanceamento de carga de HTTP(S) 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.

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

Outros efeitos observáveis com o balanceamento de carga HTTP(S) 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 porque menos viagens de ida e volta são necessárias antes que uma resposta seja concluída. Por exemplo, quando o usuário na Alemanha mede a latência pela mesma conexão fazendo o download repetidamente de um arquivo de 10 MB, a latência média do balanceamento de carga de rede é de 1.911 ms em comparação com 1.341 ms com balanceamento de carga HTTP(S). 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 balanceamento de carga HTTP(S) reduz significativamente a latência adicional de um handshake de TLS (normalmente uma ou duas viagens de ida e volta). Isso acontece porque o balanceamento de carga HTTP(S) usa a transferência de SSL, e somente a latência para o PoP de borda é relevante. Para o usuário na Alemanha, a latência mínima observada é de 201 ms usando o balanceamento de carga HTTP(S), em vez de 525 ms usando HTTP(S) por meio do balanceamento de carga de rede.

  • O balanceamento de carga HTTP(S) 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, usando melhorias em protocolo binário, compactação de cabeçalho e 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(S). 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 o balanceamento de carga HTTP(S)

Otimize a latência do aplicativo usando o balanceador de carga HTTP(S) 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 Efeitos de latência adicionais do balanceamento de carga HTTP(S).

  • É possível usar qualquer parceiro CDN com o Google Cloud. 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, será possível reduzir a carga nos servidores da Web ao veicular conteúdo diretamente do Cloud Storage por meio do balanceamento de carga HTTP(S). 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 porque o balanceamento de carga HTTP(S), o balanceamento de carga do proxy SSL e o balanceamento de carga do 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 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 o balanceamento de carga de proxy TCP e de proxy SSL são baseados em GFEs, o efeito na latência é o mesmo observado com o balanceamento de carga HTTP(S). Como o balanceamento de carga HTTP(S) tem mais recursos que o balanceamento de carga de proxy TCP e de proxy SSL, recomendamos o uso do balanceamento de carga HTTP(S) para o tráfego HTTP(S).

Próximas etapas

Recomendamos a implantação do 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: