Opzioni per il bilanciamento del carico
A seconda del tipo di traffico inviato alla tua applicazione, sono disponibili per il bilanciamento del carico esterno. La seguente tabella riassume le tue opzioni:
| 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 offloading SSL Utilizza un bilanciatore del carico di rete proxy esterno per traffico non HTTP su porte specifiche. |
La sessione TCP o SSL (TLS) viene terminata sui front-end di Google (GFE), sul perimetro della rete Google, e il traffico viene inviato tramite proxy alla di backend. | Globale |
| Bilanciatore del carico di rete passthrough esterno | Consente al traffico TCP/UDP che utilizza qualsiasi porta di passare attraverso con il bilanciatore del carico di rete passthrough esterno regionale. | Consegnato tramite Maglev per la distribuzione del traffico ai backend. | Regionale |
Poiché i bilanciatori del carico interni e Cloud Service Mesh non per supportare il traffico rivolto agli utenti, non rientrano nell'ambito di questo articolo.
Per le misurazioni di questo articolo viene utilizzato il livello Premium in 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 connettività del server, il ping ICMP non misura la latenza dell'utente finale. Per ulteriori informazioni, vedi Ulteriori effetti di latenza di un bilanciatore del carico delle applicazioni esterno.
- Curl: Curl misura il Time To First Byte (TTFB). Esegui un comando
curlpiù volte al server.
Quando confronti i risultati, tieni presente che la latenza sui link in fibra vincolato 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 (il
us-central1), è di circa 7500 km. Con una fibra dritta tra
di 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 rettilineo tra l'utente e al data center. La luce sul cavo in fibra passa attraverso uno stato attivo e passivo apparecchiature lungo il suo percorso. Una latenza osservata di circa 1,5 volte la ideale, o 112,5 ms, indica una configurazione quasi ideale.
Confronto della latenza
Questa sezione confronta 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 è costituita da un gruppo di istanze gestite a livello di regione
dei server web HTTP. Poiché l'applicazione si basa su chiamate a bassa latenza
centrale, i server web devono essere ospitati in un'unica posizione. La
il deployment dell'applicazione viene eseguito nella regione us-central1 e gli utenti vengono distribuiti
in tutto il mondo. La latenza osservata dall'utente in Germania in questo scenario
illustra l'esperienza che potrebbero capitare agli utenti di 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). ospitati su Compute Engine. Per il livello Premium, il traffico entra quindi nella su un POP perimetrale vicino alla località dell'utente. Per Livello Standard, il traffico degli utenti entra nella rete Google in un POP vicino alla regione di destinazione. Per ulteriori informazioni, consulta Network Service Tiers documentazione.
La tabella seguente mostra i risultati quando l'utente in Germania ha eseguito il test della 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 della prima 500 richieste:
Quando invii 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 HTTP richiesta. È necessario un tre-way handshake iniziale prima della risposta HTTP viene inviato, come illustrato nel diagramma seguente. Di conseguenza, la latenza osservata è una latenza del ping quasi raddoppiata.
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 al bordo più vicino PoP (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. È quindi senza modifiche alla VM di backend di destinazione. Bilanciatore del carico di rete passthrough esterno distribuisce il traffico in base a un algoritmo di hashing stabile. L'algoritmo utilizza un parametro combinazione di porta, indirizzo IP e protocollo di origine e di destinazione. Le VM rimanere in ascolto dell'IP del bilanciatore del carico e accettare il traffico inalterato.
La tabella seguente mostra i risultati quando l'utente in Germania ha eseguito il test della 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 avviene all'interno di una regione e il traffico è vengono inoltrati, non vi è alcun impatto significativo sulla latenza rispetto a un traffico senza carico con il bilanciatore del carico di rete passthrough esterno regionale.
Bilanciamento del carico esterno
Con i bilanciatori del carico delle applicazioni esterni, i GFE eseguono un proxy del traffico. Questi GFE sono a livello perimetrale della rete globale di Google. Il GFE termina la sessione TCP e si connette a un nella regione più vicina in grado di gestire il traffico.
La tabella seguente mostra i risultati quando l'utente in Germania ha eseguito il test della 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 il bilanciatore del carico delle applicazioni esterno sono molto diversi. Quando
quando invii un ping al bilanciatore del carico delle applicazioni esterno, la latenza di andata e ritorno è leggermente superiore
1 ms Questo risultato rappresenta la latenza del GFE più vicino, che si trova nella
nella stessa città dell'utente. Questo risultato non riflette la latenza effettiva che
durante il tentativo di accedere all'applicazione ospitata sul
Regione us-central1. Esperimenti che utilizzano protocolli (ICMP) diversi da
protocollo di comunicazione delle applicazioni (HTTP) può essere fuorviante.
Durante la misurazione del TTFB, le richieste iniziali mostrano una risposta simile una latenza di pochi millisecondi. Alcune richieste raggiungono la latenza minima più bassa, pari a 123 ms, come mostrato in il seguente grafico:
Due viaggi di andata e ritorno tra il client e la VM richiedono più di 123 ms anche con fibra liscia. La latenza è più bassa perché i GFE eseguono un proxy per il traffico. I GFE mantengono connessioni permanenti alle VM di backend. Pertanto, solo per la prima richiesta da un GFE specifico a un backend specifico richiede un handshake.
Ogni sede ha più GFE. Il grafico della latenza mostra più variazioni i picchi la prima volta che il traffico raggiunge ciascuna coppia di backend GFE. GFE deve quindi stabilire una nuova connessione a quel backend. Questi picchi riflette hash delle richieste diversi. Le richieste successive mostrano una latenza più bassa.
Questi scenari dimostrano la latenza ridotta che gli utenti possono sperimentare in un nell'ambiente di produzione. La seguente tabella 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 |
| Application Load Balancer esterno | 1 ms al GFE più vicino | 123 ms |
Quando un'applicazione integro serve gli utenti di una regione specifica, I GFE in quella regione mantengono una connessione permanente aperta a tutta la gestione di backend. Per questo motivo, gli utenti di quella regione notano una latenza ridotta sui propri prima richiesta HTTP se gli utenti sono lontani dal backend dell'applicazione. Se gli utenti vicino al backend dell'applicazione, gli utenti non notano alcun miglioramento della latenza.
Per le richieste successive, come il clic su un link a una pagina, non c'è latenza
perché i browser moderni mantengono una connessione permanente
completamente gestito di Google Cloud. È diverso da un comando curl emesso dalla riga di comando.
Ulteriori effetti di latenza del bilanciatore del carico delle applicazioni esterno
Ulteriori effetti osservabili con il bilanciatore del carico delle applicazioni esterno dipendono dal traffico pattern.
Il bilanciatore del carico delle applicazioni esterno ha meno latenza per gli asset complessi rispetto un bilanciatore del carico di rete passthrough esterno perché sono necessari meno round trip la risposta viene completata. Ad esempio, quando un utente in Germania misura la latenza sulla stessa connessione scaricando ripetutamente un file da 10 MB, la 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 circa 5 viaggi di andata e ritorno a richiesta. Connessioni permanenti tra GFE e la distribuzione dei backend riducono gli effetti della connessione TCP lenta Avvia.
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 l'offloading SSL e solo la latenza il POP periferico è pertinente. Per l'utente in Germania, la latenza minima osservata è 201 ms con il bilanciatore del carico delle applicazioni esterno, rispetto a 525 ms con l'utilizzo di HTTP(S) tramite il bilanciatore del carico di rete passthrough esterno.
Il bilanciatore del carico delle applicazioni esterno consente un upgrade automatico rivolta agli utenti su HTTP/2. HTTP/2 può ridurre il numero di pacchetti necessari grazie ai miglioramenti protocollo binario, compressione delle intestazioni e multiplexing delle connessioni. Questi miglioramenti possono ridurre la latenza osservata anche di più di quella osservata da il passaggio al bilanciatore del carico delle applicazioni esterno. HTTP/2 è supportato con lo standard browser che utilizzano SSL/TLS. Per l'utente in Germania, la latenza minima è diminuita 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 una parte del traffico che gestisci è memorizzabile nella cache, puoi eseguire l'integrazione Cloud CDN. Cloud CDN riduce la latenza gestendo gli asset direttamente sul perimetro della rete Google. Cloud CDN utilizza anche la TCP e le ottimizzazioni HTTP da HTTP/2, menzionate nel capitolo Latenza aggiuntiva effetti del bilanciatore del carico delle applicazioni esterno.
Con Google Cloud puoi utilizzare qualsiasi partner CDN. Utilizzando uno dei Interconnessione CDN partner, puoi usufruire di costi scontati per il trasferimento di dati.
Se i contenuti sono statici, puoi ridurre il carico sui server web gestendo 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 perché il bilanciatore del carico indirizza automaticamente gli utenti al cluster più vicino regione. Tuttavia, se l'applicazione è parzialmente centralizzata, progettala ridurre il numero di viaggi di andata e ritorno tra regioni.
Per ridurre la latenza all'interno delle applicazioni, esamina le chiamate di procedura remota (RPC) che comunicano tra le VM. Questa latenza si verifica solitamente quando le applicazioni comunicano tra livelli o servizi. Strumenti come Cloud Trace può aiutarti a ridurre la latenza causata da di distribuzione delle applicazioni.
Poiché i bilanciatori del carico di rete proxy esterni sono basati sui GFE, l'effetto sulla latenza è lo stesso che si osserva un bilanciatore del carico delle applicazioni esterno. Poiché il bilanciatore del carico delle applicazioni esterno ha più funzionalità rispetto al bilanciatore del carico di rete proxy esterno, consiglia di utilizzare bilanciatori del carico delle applicazioni esterni per il traffico HTTP(S).
Passaggi successivi
Ti consigliamo di eseguire il deployment della tua applicazione vicino alla maggior parte dei 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