Opções de balanceamento de carga
Consoante o tipo de tráfego enviado para a sua aplicação, tem várias opções para o balanceamento de carga externo. A tabela seguinte resume as suas opções:
| Opção | Descrição | Fluxo de tráfego | Âmbito |
|---|---|---|---|
| Balanceador de carga de aplicações externo | Suporta tráfego HTTP(S) e funcionalidades avançadas, como o mapeamento de URLs
e a transferência 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) é terminada nos front-ends da Google (GFEs), na extremidade da rede da Google, e o tráfego é encaminhado por proxy para os back-ends. | Global |
| Balanceador de carga de rede de passagem externo | Permite que o tráfego TCP/UDP que usa qualquer porta passe pelo balanceador de carga. | Entregue através da tecnologia Maglev da Google para distribuir o tráfego pelos back-ends. | Regional |
Uma vez que os equilibradores de carga internos e a Cloud Service Mesh não suportam tráfego virado para o utilizador, estão fora do âmbito 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 requer este nível de serviço.
Medir a latência
Ao aceder a um Website alojado em us-central1, um utilizador 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 utilizador final. Para mais informações, consulte o artigo Efeitos adicionais da latência de um Application Load Balancer externo.
- Curl: o Curl mede o tempo até ao primeiro byte (TTFB). Emitir um comando
curlrepetidamente para o servidor.
Ao comparar os resultados, tenha em atenção que a latência nas ligações de fibra é limitada pela distância e pela velocidade da luz na fibra, que é de aproximadamente 200 000 km por segundo (ou 124 724 milhas por segundo).
A distância entre Frankfurt, Alemanha, e Council Bluffs, Iowa (a região us-central1), é de aproximadamente 7500 km. Com fibra direta entre as localizações, 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 utilizador e o centro de dados. A luz no cabo de fibra passa por equipamento ativo e passivo ao longo do seu percurso. Uma latência observada de aproximadamente 1,5 vezes o ideal, ou 112,5 ms, indica uma configuração quase ideal.
Comparar latência
Esta secção compara o balanceamento de carga nas seguintes configurações:
- Sem balanceamento de carga
- Balanceador de carga de rede de encaminhamento externo
- Balanceador de carga de aplicações externo ou balanceador de carga de rede de proxy externo
Neste cenário, a aplicação consiste num grupo de instâncias geridas regional
de servidores Web HTTP. Uma vez que a aplicação depende de chamadas de baixa latência para uma base de dados central, os servidores Web têm de estar alojados numa localização. A aplicação está implementada na região us-central1 e os utilizadores estão distribuídos por todo o mundo. A latência que o utilizador na Alemanha observa neste cenário
ilustra o que os utilizadores em todo o mundo podem experimentar.
Sem balanceamento de carga
Quando um utilizador faz um pedido HTTP, a menos que o equilíbrio de carga esteja configurado, o tráfego flui diretamente da rede do utilizador para a máquina virtual (VM) alojada no Compute Engine. Para o nível Premium, o tráfego entra na rede da Google num ponto de presença (PoP) periférico próximo da localização do utilizador. Para o Nível padrão, o tráfego de utilizadores entra na rede da Google num PoP próximo da região de destino. Para mais informações, consulte a documentação sobre os níveis de serviço de rede.
A tabela seguinte mostra os resultados quando o utilizador na Alemanha testou a latência de um sistema sem equilíbrio de carga:
| Método | Resultado | Latência mínima |
|---|---|---|
| Ping ao endereço IP da VM (a resposta é diretamente do servidor 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 dos primeiros 500 pedidos:
Quando envia um ping para o endereço IP da VM, a resposta vem diretamente do servidor Web. O tempo de resposta do servidor Web é mínimo em comparação com a latência da rede (TTFB). Isto acontece porque é aberta uma nova ligação TCP para cada pedido HTTP. É necessário um handshake de três vias inicial antes de a resposta HTTP ser enviada, conforme mostrado no diagrama seguinte. Por conseguinte, a latência observada é quase o dobro da latência de ping.
Balanceador de carga de rede de encaminhamento externo
Com os equilibradores de carga de encaminhamento externo, os pedidos dos utilizadores continuam a entrar na rede Google no PoP de limite mais próximo (no nível Premium). Na região onde as VMs do projeto estão localizadas, o tráfego flui primeiro através de um balanceador de carga de rede de encaminhamento externo. Em seguida, é encaminhado sem alterações para a VM de back-end de destino. O balanceador de carga de rede de encaminhamento externo distribui o tráfego com base num algoritmo de hash estável. O algoritmo usa uma combinação da porta de origem e destino, do endereço IP e do protocolo. As VMs ouvem o IP do balanceador de carga e aceitam o tráfego inalterado.
A tabela seguinte mostra os resultados quando o utilizador na Alemanha testou a latência para a opção de equilíbrio de carga de rede.
| Método | Resultado | Latência mínima |
|---|---|---|
| Envie um ping para o balanceador de carga de rede de encaminhamento externo |
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 |
Uma vez que o equilíbrio de carga ocorre numa região e o tráfego é apenas encaminhado, não existe um impacto significativo na latência em comparação com a ausência de um equilibrador de carga.
Balanceamento de carga externo
Com balanceadores de carga de aplicações externos, os GFEs fazem o proxy do tráfego. Estes GFEs estão no limite da rede global da Google. O GFE termina a sessão TCP e liga-se a um back-end na região mais próxima que pode servir o tráfego.
A tabela seguinte mostra os resultados quando o utilizador na Alemanha testou a latência para a opção de equilíbrio de carga HTTP.
| Método | Resultado | Latência mínima |
|---|---|---|
| Envie um ping para o balanceador de carga de aplicações 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 da aplicação externo são significativamente diferentes. Quando
envia um ping para o Application Load Balancer externo, a latência de ida e volta é ligeiramente superior a
1 ms. Este resultado representa a latência para o GFE mais próximo, que se encontra na
mesma cidade que o utilizador. Este resultado não reflete a latência real que o utilizador experimenta quando tenta aceder à aplicação alojada na região us-central1. As experiências que usam protocolos (ICMP) diferentes do protocolo de comunicação da sua aplicação (HTTP) podem ser enganadoras.
Ao medir o TTFB, os pedidos iniciais mostram uma latência de resposta semelhante. Alguns pedidos atingem a latência mínima inferior de 123 ms, conforme mostrado no seguinte gráfico:
Duas viagens de ida e volta entre o cliente e a VM demoram mais de 123 ms, mesmo com fibra reta. A latência é inferior porque os GFEs atuam como proxy do tráfego. Os GFEs mantêm ligações persistentes às VMs de back-end. Por conseguinte, apenas o primeiro pedido de um GFE específico para um back-end específico requer uma negociação tripartida.
Cada localização 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. Em seguida, o GFE tem de estabelecer uma nova ligação a esse back-end. Estes picos refletem hashes de pedidos diferentes. Os pedidos subsequentes mostram uma latência inferior.
Estes cenários demonstram a latência reduzida que os utilizadores podem experimentar num ambiente de produção. A tabela seguinte resume os resultados:
| Opção | Tchim-tchim | TTFB |
|---|---|---|
| Sem balanceamento de carga | 110 ms para o servidor Web | 230 ms |
| Balanceador de carga de rede de encaminhamento externo | 110 ms para o balanceador de carga de rede de passagem externo na região | 230 ms |
| Balanceador de carga de aplicações externo | 1 ms para o GFE mais próximo | 123 ms |
Quando uma aplicação em bom estado está a publicar conteúdo para utilizadores numa região específica, os GFEs nessa região mantêm uma ligação persistente aberta a todos os back-ends de publicação. Por este motivo, os utilizadores nessa região notam uma latência reduzida no primeiro pedido HTTP se estiverem longe do back-end da aplicação. Se os utilizadores estiverem perto do back-end da aplicação, não notam uma melhoria na latência.
Para pedidos subsequentes, como clicar num link de página, não existe uma melhoria da latência, uma vez que os navegadores modernos mantêm uma ligação persistente ao serviço. Isto difere de um comando curl emitido a partir da linha de comandos.
Efeitos de latência adicionais do balanceador de carga de aplicações externo
Os efeitos observáveis adicionais com o Application Load Balancer externo dependem dos padrões de tráfego.
O balanceador de carga de aplicações externo tem uma latência inferior para recursos complexos do que o balanceador de carga de rede de encaminhamento externo, porque são necessárias menos viagens de ida e volta antes de uma resposta ser concluída. Por exemplo, quando o utilizador na Alemanha mede a latência através da mesma ligação transferindo repetidamente um ficheiro de 10 MB, a latência média do Network Load Balancer de passagem externo é de 1911 ms. Com o Application Load Balancer externo, a latência média é de 1341 ms. Isto poupa aproximadamente 5 viagens de ida e volta por pedido. As ligações persistentes entre os GFEs e os backends de publicação reduzem os efeitos do TCP Slow Start.
O Application Load Balancer externo reduz significativamente a latência adicional para um handshake TLS (normalmente, 1 a 2 viagens de ida e volta adicionais). Isto acontece porque o balanceador de carga da aplicação externo usa a transferência de carga SSL e apenas a latência para o PoP de limite é relevante. Para o utilizador na Alemanha, a latência mínima observada é de 201 ms com o balanceador de carga de aplicações externo, em comparação com 525 ms com HTTP(S) através do balanceador de carga de rede de passagem externo.
O Application Load Balancer externo permite uma atualização automática da sessão orientada para o utilizador para HTTP/2. O HTTP/2 pode reduzir o número de pacotes necessários através de melhorias no protocolo binário, na compressão de cabeçalhos e na multiplexação de ligações. Estas melhorias podem reduzir a latência observada ainda mais do que a observada ao mudar para o Application Load Balancer externo. O HTTP/2 é suportado pelos navegadores atuais que usam SSL/TLS. Para o utilizador na Alemanha, a latência mínima diminuiu ainda mais de 201 ms para 145 ms quando usou HTTP/2 em vez de HTTPS.
Otimizar balanceadores de carga de aplicações externos
Pode otimizar a latência da sua aplicação através do balanceador de carga de aplicações externo da seguinte forma:
Se parte do tráfego que publica for memorizável em cache, pode fazer a integração com a RFC do Google Cloud. A RFC do Google Cloud reduz a latência ao publicar recursos diretamente no limite da rede da Google. O Cloud CDN também usa as otimizações de TCP e HTTP do HTTP/2 mencionadas na secção Efeitos adicionais de latência do balanceador de carga de aplicações externo.
Pode usar qualquer parceiro de RFC com Google Cloud. Ao usar um dos parceiros do CDN Interconnect da Google, beneficia de custos de transferência de dados com desconto.
Se o conteúdo for estático, pode reduzir a carga nos servidores Web ao publicar conteúdo diretamente a partir do Cloud Storage através do Application Load Balancer externo. Esta opção combina-se com a RFC do Google Cloud.
A implementação dos seus servidores Web em várias regiões próximas dos seus utilizadores pode reduzir a latência, uma vez que o balanceador de carga direciona automaticamente os utilizadores para a região mais próxima. No entanto, se a sua aplicação for parcialmente centralizada, conceba-a para diminuir o número de viagens de ida e volta inter-regionais.
Para reduzir a latência nas suas aplicações, examine todas as chamadas de procedimentos remotos (RPCs) que comunicam entre VMs. Normalmente, esta latência ocorre quando as aplicações comunicam entre camadas ou serviços. As ferramentas como o Cloud Trace podem ajudar a diminuir a latência causada por pedidos de fornecimento de aplicações.
Uma vez que os balanceadores de carga de rede de proxy externos se baseiam em GFEs, o efeito na latência é o mesmo que o observado com o balanceador de carga de aplicações externo. Uma vez que o balanceador de carga de aplicações externo tem mais funcionalidades do que o balanceador de carga de rede de proxy externo, recomendamos a utilização de balanceadores de carga de aplicações externos para tráfego HTTP(S).
Passos seguintes
Recomendamos que implemente a sua aplicação perto da maioria dos seus utilizadores. 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 aplicações externo
- Balanceador de carga de rede de proxy externo