Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico

Opzioni per il bilanciamento del carico

A seconda del tipo di traffico inviato all'applicazione, hai a disposizione diverse opzioni per il bilanciamento del carico esterno. La tabella seguente riassume le opzioni a tua disposizione:

Poiché i bilanciatori del carico interni e Cloud Service Mesh non supportano il traffico rivolto agli utenti, non rientrano nell'ambito di questo articolo.

Le misurazioni di questo articolo utilizzano il livello Premium in Network Service Tiers perché il bilanciamento del carico globale richiede questo livello di servizio.

Misurare la latenza

Quando accede a un sito web ospitato in us-central1, un utente in Germania utilizza i seguenti metodi per testare la latenza:

• Ping: sebbene il ping ICMP sia un modo comune per misurare la raggiungibilità del server, il ping ICMP non misura la latenza dell'utente finale. Per saperne di più, consulta Effetti aggiuntivi della latenza di un bilanciatore del carico delle applicazioni esterno.
• Curl: misura il tempo di risposta dal primo byte (TTFB). Esegui ripetutamente un comando curl sul server.

Quando confronti i risultati, tieni presente che la latenza sui collegamenti in fibra è limitata dalla distanza e dalla velocità della luce nella fibra, che è di circa 200.000 km al secondo.

La distanza tra Francoforte, in Germania, e Council Bluffs, nell'Iowa (regione us-central1), è di circa 7500 km. Con fibra diretta tra le località, la latenza di andata e ritorno è la seguente:

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

Il cavo in fibra ottica non segue un percorso lineare tra l'utente e il data center. La luce sul cavo in fibra passa attraverso apparecchiature attive e passive lungo il suo percorso. Una latenza osservata di circa 1,5 volte quella ideale, ovvero 112,5 ms, indica una configurazione quasi ideale.

Confronto della latenza

Questa sezione mette a confronto il bilanciamento del carico nelle seguenti configurazioni:

• Nessun bilanciamento del carico
• Bilanciatore del carico di rete passthrough esterno
• Application Load Balancer esterno o bilanciatore del carico di rete proxy esterno

In questo scenario, l'applicazione è costituita da un gruppo di istanze gestite a livello di regione di server web HTTP. Poiché l'applicazione si basa su chiamate a bassa latenza a un database centralizzato, i server web devono essere ospitati in un'unica posizione. L'applicazione viene dispiata nella regione us-central1 e gli utenti sono distribuiti in tutto il mondo. La latenza osservata dall'utente in Germania in questo scenario illustra ciò che gli utenti di tutto il mondo potrebbero riscontrare.

Nessun bilanciamento del carico

Quando un utente invia una richiesta HTTP, a meno che non sia configurato il bilanciamento del carico, il traffico passa direttamente dalla rete dell'utente alla macchina virtuale (VM) ospitata su Compute Engine. Per il livello Premium, il traffico entra nella rete di Google in un punto di presenza (PoP) perimetrale vicino alla posizione dell'utente. Per il livello Standard, il traffico utente entra nella rete di Google in un PoP vicino alla regione di destinazione. Per saperne di più, consulta la documentazione di Network Service Tiers.

La tabella seguente mostra i risultati quando l'utente in Germania ha testato la latenza di un sistema senza bilanciamento del carico:

  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
  

  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
  

La latenza TTFB è stabile, come mostrato nel seguente grafico delle prime 500 richieste:

Quando esegui un ping all'indirizzo IP della VM, la risposta proviene direttamente dal server web. Il tempo di risposta del server web è minimo rispetto alla latenza della rete (TTFB). Questo perché viene aperta una nuova connessione TCP per ogni richiesta HTTP. È necessario un handshake iniziale a tre vie prima dell'invio della risposta HTTP, come mostrato nel seguente diagramma. Pertanto, la latenza osservata è quasi il doppio della latenza del ping.

Bilanciatore del carico di rete passthrough esterno

Con i bilanciatori del carico di rete passthrough esterni, le richieste degli utenti entrano comunque nella rete Google nel POP di confine più vicino (nel livello Premium). Nella regione in cui si trovano le VM del progetto, il traffico passa prima attraverso un bilanciatore del carico di rete passthrough esterno. Viene poi inoltrata senza modifiche alla VM di backend di destinazione. Il bilanciatore del carico di rete passthrough esterno distribuisce il traffico in base a un algoritmo di hashing stabile. L'algoritmo utilizza una combinazione di porta di origine e di destinazione, indirizzo IP e protocollo. Le VM ascoltano l'IP del bilanciatore del carico e accettano il traffico invariato.

La tabella seguente mostra i risultati quando l'utente in Germania ha testato la latenza per l'opzione di bilanciamento del carico della rete.

  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
  

 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
 

Poiché il bilanciamento del carico avviene all'interno di una regione e il traffico viene solo inoltrato, l'impatto sulla latenza non è significativo rispetto a un bilanciatore del carico non presente.

Bilanciamento del carico esterno

Con i bilanciatori del carico delle applicazioni esterni, i GFE eseguono il proxy del traffico. Questi GFE si trovano sul perimetro della rete globale di Google. La GFE termina la sessione TCP e si connette a un backend nella regione più vicina in grado di gestire il traffico.

La tabella seguente mostra i risultati quando l'utente in Germania ha testato la latenza per l'opzione di bilanciamento del carico HTTP.

 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
 

 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
 

I risultati per il bilanciatore del carico delle applicazioni esterno sono molto diversi. Quando viene eseguito un PING sull'Application Load Balancer esterno, la latenza di andata e ritorno è leggermente superiore a 1 ms. Questo risultato rappresenta la latenza del GFE più vicino, che si trova nella stessa città dell'utente. Questo risultato non riflette la latenza effettiva riscontrata dall'utente quando tenta di accedere all'applicazione ospitata nella regione us-central1. Gli esperimenti che utilizzano protocolli (ICMP) diversi dal protocollo di comunicazione delle applicazioni (HTTP) possono essere fuorvianti.

Quando si misura il TTFB, le richieste iniziali mostrano una latenza di risposta simile. Alcune richieste raggiungono la latenza minima più bassa di 123 ms, come mostrato nel seguente grafico:

Due viaggi di andata e ritorno tra il client e la VM richiedono più di 123 ms anche con fibra diretta. La latenza è inferiore perché i GFE fungono da proxy per il traffico. I GFE mantengono connessioni permanenti alle VM di backend. Pertanto, solo la prima richiesta da un GFE specifico a un backend specifico richiede un handshake a tre vie.

Ogni località ha più GFEs. Il grafico della latenza mostra più picchi fluttuanti la prima volta che il traffico raggiunge ogni coppia di backend GFE. GFE deve quindi stabilire una nuova connessione a quel backend. Questi picchi riflettono hash delle richieste diversi. Le richieste successive mostrano una latenza inferiore.

Questi scenari dimostrano la latenza ridotta che gli utenti possono riscontrare in un ambiente di produzione. La tabella seguente riassume i risultati:

Quando un'applicazione funzionante serve gli utenti in una regione specifica, gli GFE in quella regione mantengono una connessione persistente aperta a tutti i backend di servizio. Per questo motivo, gli utenti di questa regione notano una latenza ridotta nella loro prima richiesta HTTP se sono lontani dal backend dell'applicazione. Se gli utenti si trovano vicino al backend dell'applicazione, non notano alcun miglioramento della latenza.

Per le richieste successive, ad esempio se fai clic sul link di una pagina, non c'è alcun miglioramento della latenza perché i browser moderni mantengono una connessione permanente al servizio. È diverso da un comando curl emesso dalla riga di comando.

Ulteriori effetti della latenza dell'Application Load Balancer esterno

Ulteriori effetti osservabili con il bilanciatore del carico delle applicazioni esterno dipendono dai pattern di traffico.

• L'Application Load Balancer esterno ha una latenza inferiore per gli asset complessi rispetto al bilanciatore del carico di rete passthrough esterno perché sono necessari meno viaggi di andata e ritorno prima del completamento di una risposta. Ad esempio, quando l'utente in Germania misura la latenza sulla stessa connessione scaricando ripetutamente un file di 10 MB, la latenza media per il bilanciatore del carico di rete passthrough esterno è di 1911 ms. Con il bilanciatore del carico delle applicazioni esterno, la latenza media è di 1341 ms. In questo modo si risparmiano circa 5 viaggi di andata e ritorno per richiesta. Le connessioni permanenti tra i GFE e i backend di servizio riducono gli effetti del Avvio lento TCP.

• Il bilanciatore del carico delle applicazioni esterno riduce notevolmente la latenza aggiuntiva per un handshake TLS (in genere 1-2 round trip aggiuntivi). Questo perché il bilanciatore del carico delle applicazioni esterno utilizza il ribaltamento SSL e solo la latenza al PoP di confine è pertinente. Per l'utente in Germania, la latenza minima osservata è di 201 ms se si utilizza il bilanciatore del carico delle applicazioni esterno, rispetto a 525 ms se si utilizza HTTP(S) tramite il bilanciatore del carico di rete passthrough esterno.

• Il bilanciatore del carico delle applicazioni esterno consente un upgrade automatico della sessione rivolta agli utenti a HTTP/2. HTTP/2 può ridurre il numero di pacchetti necessari utilizzando i miglioramenti del protocollo binario, della compressione delle intestazioni e del multiplexing delle connessioni. Questi miglioramenti possono ridurre la latenza osservata anche più di quanto osservato passando al bilanciatore del carico delle applicazioni esterno. HTTP/2 è supportato dai browser attuali che utilizzano SSL/TLS. Per l'utente in Germania, la latenza minima è diminuita ulteriormente da 201 ms a 145 ms quando si utilizza HTTP/2 anziché HTTPS.

Ottimizzazione dei bilanciatori del carico delle applicazioni esterni

Puoi ottimizzare la latenza per la tua applicazione utilizzando il bilanciatore del carico delle applicazioni esterno come segue:

• Se parte del traffico che pubblichi è memorizzabile nella cache, puoi eseguire l'integrazione con Cloud CDN. Cloud CDN riduce la latenza pubblicando gli asset direttamente sul perimetro della rete di Google. Cloud CDN utilizza anche le ottimizzazioni TCP e HTTP di HTTP/2 menzionate nella sezione Effetti aggiuntivi della latenza del bilanciatore del carico delle applicazioni esterno.

• Puoi utilizzare qualsiasi partner CDN con Google Cloud. Se utilizzi uno dei partner CDN Interconnect di Google, puoi usufruire di costi di trasferimento dati scontati.

• Se i contenuti sono statici, puoi ridurre il carico sui server web pubblicandoli direttamente da Cloud Storage tramite il bilanciatore del carico delle applicazioni esterno. Questa opzione si combina con Cloud CDN.

• Il deployment dei server web in più regioni vicine agli utenti può ridurre la latenza perché il bilanciatore del carico indirizza automaticamente gli utenti alla regione più vicina. Tuttavia, se la tua applicazione è parzialmente centralizzata, progettala in modo da diminuire il numero di viaggi di andata e ritorno interregionali.

• Per ridurre la latenza all'interno delle applicazioni, esamina le chiamate di procedura remota (RPC) che comunicano tra le VM. Questa latenza si verifica in genere quando le applicazioni comunicano tra livelli o servizi. Strumenti come Cloud Trace possono aiutarti a ridurre la latenza causata dalle richieste di pubblicazione delle applicazioni.

• Poiché i bilanciatori del carico di rete proxy esterni si basano su GFE, l'effetto sulla latenza è lo stesso osservato con il bilanciatore del carico delle applicazioni esterno. Poiché il bilanciatore del carico delle applicazioni esterno offre più funzionalità rispetto al bilanciatore del carico di rete proxy esterno, consigliamo di utilizzare i bilanciatori del carico delle applicazioni esterni per il traffico HTTP(S).

Passaggi successivi

Ti consigliamo di eseguire il deployment dell'applicazione vicino alla maggior parte degli utenti. Per ulteriori informazioni sulle diverse opzioni di bilanciamento del carico in Google Cloud, consulta i seguenti documenti:

• Bilanciatore del carico di rete passthrough esterno
• Bilanciatore del carico delle applicazioni esterno
• Bilanciatore del carico di rete proxy esterno