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
curlrepetidamente 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.
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.
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:
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.
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.
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.
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:
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.
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:
- Balanceador de carga de rede de passagem externo
- Balanceador de carga de aplicativo externo
- Balanceador de carga de rede de proxy externo