Opzioni per il bilanciamento del carico
A seconda del tipo di traffico inviato all'applicazione, sono disponibili diverse opzioni per il bilanciamento del carico esterno. La seguente tabella riassume le opzioni disponibili:
| Opzione | Descrizione | Flusso di traffico | Ambito |
|---|---|---|---|
| Bilanciatore del carico delle applicazioni esterno | Supporta il traffico HTTP(S) e funzionalità avanzate, come la mappatura degli URL e l'offload SSL Utilizza un bilanciatore del carico di rete proxy esterno per il traffico non HTTP su porte specifiche. |
La sessione TCP o SSL (TLS) viene terminata ai Google Front End (GFE), sul perimetro della rete Google, e il traffico viene inviato tramite proxy ai backend. | Globale |
| Bilanciatore del carico di rete passthrough esterno | Consente al traffico TCP/UDP di passare attraverso il bilanciatore del carico utilizzando qualsiasi porta. | Fornito utilizzando la tecnologia Maglev di Google per distribuire il traffico ai backend. | Regionale |
Poiché i bilanciatori del carico interni e Traffic Director non supportano il traffico rivolto agli utenti, non rientrano nell'ambito di questo articolo.
Le misurazioni di questo articolo utilizzano il livello Premium di Network Service Tiers perché il bilanciamento del carico globale richiede questo livello di servizio.
Misurazione della 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 ulteriori informazioni, consulta Effetti di latenza aggiuntivi di un bilanciatore del carico delle applicazioni esterno.
- Curl: l'arricciatura misura il tempo per il primo byte (TTFB). Invia ripetutamente un comando
curlal server.
Quando confronti i risultati, tieni presente che la latenza sui collegamenti in fibra è limitata dalla distanza e dalla velocità della luce in fibra, che è di circa 200.000 km al secondo (o 124.724 miglia al secondo).
La distanza tra Francoforte, Germania e Council Bluffs, Iowa (la regione us-central1), è di circa 7500 km. Con una fibra dritta 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 retto tra l'utente e il data center. La luce sul cavo in fibra passa attraverso l'apparecchiatura attiva e passiva lungo il suo percorso. Una latenza osservata di circa 1,5 volte l'ideale, o 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
- Bilanciatore del carico delle applicazioni esterno o bilanciatore del carico di rete proxy esterno
In questo scenario, l'applicazione è composta da un gruppo di istanze gestite a livello di regione di server web HTTP. Poiché l'applicazione si basa su chiamate a bassa latenza per un database centrale, i server web devono essere ospitati in un'unica località. Il deployment
dell'applicazione è stato eseguito 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 potrebbero riscontrare gli utenti in tutto il mondo.
Nessun bilanciamento del carico
Quando un utente effettua 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 perimetrale (PoP) vicino alla località dell'utente. Per il livello Standard, il traffico degli utenti entra nella rete di Google in un punto di presenza (POP) vicino alla regione di destinazione. Per ulteriori informazioni, consulta la documentazione di Network Service Tiers.
La seguente tabella mostra i risultati quando l'utente in Germania ha testato la latenza di un sistema senza bilanciamento del carico:
| Metodo | Risultato | Latenza minima |
|---|---|---|
| Invia un ping all'indirizzo IP della VM (la risposta proviene direttamente dal server 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 |
La latenza TTFB è stabile, come mostrato nel seguente grafico delle prime 500 richieste:
Quando si invia 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 di rete (TTFB). Questo perché viene aperta una nuova connessione TCP per ogni richiesta HTTP. È necessario un handshake a tre vie iniziale prima che venga inviata la risposta HTTP, come mostrato nel diagramma seguente. 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 continuano a entrare nella rete Google al PoP perimetrale 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 quindi inoltrato alla VM backend di destinazione senza modifiche. 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 inalterato.
La seguente tabella mostra i risultati quando l'utente in Germania ha testato la latenza per l'opzione di bilanciamento del carico di rete.
| Metodo | Risultato | Latenza minima |
|---|---|---|
| Invia un ping al bilanciatore del carico di rete passthrough esterno |
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 |
Poiché il bilanciamento del carico ha luogo all'interno di una regione e il traffico viene solo inoltrato, non si verifica un impatto significativo sulla latenza rispetto all'assenza di un bilanciatore del carico.
Bilanciamento del carico esterno
Con gli Application Load Balancer esterni, i GFE eseguono il proxy del traffico. Questi GFE si trovano a livello perimetrale della rete globale di Google. Il GFE termina la sessione TCP e si connette a un backend nella regione più vicina in grado di gestire il traffico.
La seguente tabella mostra i risultati quando l'utente in Germania ha testato la latenza per l'opzione di bilanciamento del carico HTTP.
| Metodo | Risultato | Latenza minima |
|---|---|---|
| Invia un ping al bilanciatore del carico delle applicazioni esterno |
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 |
I risultati per l'Application Load Balancer esterno sono notevolmente diversi. Quando invii un ping all'Application Load Balancer esterno, la latenza di round trip è leggermente superiore a 1 ms. Questo risultato rappresenta la latenza al GFE più vicino, che si trova nella stessa città dell'utente. Questo risultato non riflette la latenza effettiva dell'esperienza utente quando prova ad accedere all'applicazione ospitata nella regione us-central1. Gli esperimenti che utilizzano protocolli (ICMP) diversi dal protocollo di comunicazione dell'applicazione (HTTP) possono essere fuorvianti.
Durante la misurazione del TTFB, le richieste iniziali mostrano una latenza di risposta simile. Alcune richieste raggiungono la latenza minima più bassa di 123 ms, come mostrato nel grafico seguente:
Due round trip tra il client e la VM richiedono più di 123 ms anche con fibra dritta. La latenza è inferiore perché i GFE utilizzano il proxy per il traffico. I GFE mantengono connessioni permanenti alle VM di backend. Di conseguenza, solo la prima richiesta da un GFE specifico a un backend specifico richiede un handshake a tre vie.
Ogni sede ha più GFE. Il grafico della latenza mostra numerosi picchi fluttuanti la prima volta che il traffico raggiunge ciascuna coppia di backend GFE. Il GFE deve quindi stabilire una nuova connessione a quel backend. Questi picchi riflettono i diversi hash delle richieste. Le richieste successive mostrano una latenza minore.
Questi scenari mostrano la latenza ridotta che gli utenti possono riscontrare in un ambiente di produzione. La tabella riportata di seguito riassume i risultati:
| Opzione | Dindin | TTFB |
|---|---|---|
| Nessun bilanciamento del carico | 110 ms al server web | 230 ms |
| Bilanciatore del carico di rete passthrough esterno | 110 ms al bilanciatore del carico di rete passthrough esterno nella regione | 230 ms |
| Bilanciatore del carico delle applicazioni esterno | 1 ms dal GFE più vicino | 123 ms |
Quando un'applicazione in stato integro gestisce gli utenti in una regione specifica, i GFE di quella regione mantengono una connessione permanente aperta a tutti i backend di pubblicazione. Per questo motivo, gli utenti di quella regione notano una latenza ridotta nella loro prima richiesta HTTP se gli utenti sono lontani dal backend dell'applicazione. Se gli utenti si trovano nelle vicinanze del backend dell'applicazione, non notano un miglioramento della latenza.
Per le richieste successive, ad esempio fare clic su un link a una pagina, non ci sono miglioramenti della latenza perché i browser moderni mantengono una connessione permanente al servizio. È diverso da un comando curl emesso dalla riga di comando.
Ulteriori effetti di latenza dell'Application Load Balancer esterno
Gli effetti aggiuntivi osservabili con l'Application Load Balancer esterno dipendono dai pattern di traffico.
L'Application Load Balancer esterno ha una latenza minore per gli asset complessi rispetto all'Application Load Balancer esterno passthrough esterno perché sono necessari meno round trip prima del completamento di una risposta. Ad esempio, quando un utente in Germania misura la latenza sulla stessa connessione scaricando ripetutamente un file da 10 MB, la latenza media per il bilanciatore del carico di rete passthrough esterno è 1911 ms. Con l'Application Load Balancer esterno, la latenza media è di 1341 ms. Ciò consente di risparmiare circa 5 round trip per richiesta. Le connessioni persistenti tra i GFE e i backend di gestione riducono gli effetti della funzionalità Avvio lento TCP.
L'Application Load Balancer esterno riduce in modo significativo la latenza aggiuntiva per un handshake TLS (in genere 1-2 round trip aggiuntivi). Questo perché l'Application Load Balancer esterno utilizza l'offload SSL e solo la latenza verso il PoP perimetrale è pertinente. Per gli utenti in Germania, la latenza minima osservata è 201 ms utilizzando l'Application Load Balancer esterno, rispetto ai 525 ms utilizzando HTTP(S) tramite il bilanciatore del carico di rete passthrough esterno.
L'Application Load Balancer esterno consente un upgrade automatico della sessione rivolta agli utenti a HTTP/2. HTTP/2 può ridurre il numero di pacchetti necessari grazie ai miglioramenti apportati al protocollo binario, alla compressione delle intestazioni e al multiplexing delle connessioni. Questi miglioramenti possono ridurre la latenza osservata ancora di più di quella osservata passando al bilanciatore del carico delle applicazioni esterno. HTTP/2 è supportato dai browser attuali che utilizzano SSL/TLS. Per gli utenti 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 gestito può essere memorizzato nella cache, puoi eseguire l'integrazione con Cloud CDN. Cloud CDN riduce la latenza distribuendo asset direttamente sul perimetro della rete Google. Cloud CDN utilizza inoltre le ottimizzazioni TCP e HTTP da HTTP/2 menzionate nella sezione Effetti di latenza aggiuntivi del bilanciatore del carico delle applicazioni esterno.
Puoi utilizzare qualsiasi partner CDN con Google Cloud. Utilizzando uno dei partner CDN Interconnect di Google, puoi usufruire di costi scontati per il trasferimento di dati.
Se i contenuti sono statici, puoi ridurre il carico sui server web pubblicando i contenuti direttamente da Cloud Storage tramite l'Application Load Balancer esterno. Questa opzione si combina con Cloud CDN.
Il deployment dei tuoi server web in più regioni vicine agli utenti può ridurre la latenza, poiché il bilanciatore del carico indirizza automaticamente gli utenti alla regione più vicina. Tuttavia, se l'applicazione è parzialmente centralizzata, progettala in modo da ridurre il numero di viaggi di andata e ritorno tra regioni.
Per ridurre la latenza all'interno delle tue applicazioni, esamina eventuali 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 distribuzione delle applicazioni.
Poiché i bilanciatori del carico di rete proxy esterni si basano sui GFE, l'effetto sulla latenza è lo stesso osservato con l'Application Load Balancer esterno. Poiché l'Application Load Balancer esterno ha più funzionalità del bilanciatore del carico di rete proxy esterno, consigliamo di utilizzare Application Load Balancer 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