La maggior parte dei bilanciatori del carico utilizza un approccio di hashing round robin o basato sul flusso per distribuire il traffico. Tuttavia, i bilanciatori del carico che utilizzano questo approccio possono avere difficoltà ad adattarsi quando la domanda supera la capacità di servizio disponibile. Questo articolo spiega come l'utilizzo di Cloud Load Balancing può risolvere questi problemi e ottimizzare la capacità dell'applicazione globale. Ciò spesso si traduce in una migliore esperienza utente e costi inferiori rispetto alle implementazioni tradizionali del bilanciamento del carico.
Questo articolo fa parte di una serie di best practice incentrate sui prodotti Google Cloud Load Balancing. Per un tutorial che accompagna questo articolo, vedi Gestione della capacità con il bilanciamento del carico. Per un approfondimento sulla latenza, consulta Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.
Sfide relative alla capacità nelle applicazioni globali
Scalare le applicazioni globali può essere difficile, soprattutto se hai budget IT limitati e carichi di lavoro imprevedibili e variabili. Negli ambienti cloud pubblico come Google Cloud, la flessibilità offerta da funzionalità come la scalabilità automatica e il bilanciamento del carico può essere utile. Tuttavia, gli autoscaler presentano alcune limitazioni, come spiegato in questa sezione.
Latenza nell'avvio di nuove istanze
Il problema più comune con lo scaling automatico è che l'applicazione richiesta non è pronta a gestire il traffico abbastanza rapidamente. A seconda delle immagini delle istanze VM, in genere gli script devono essere eseguiti e le informazioni caricate prima che le istanze VM siano pronte. Spesso sono necessari alcuni minuti prima che il bilanciamento del carico sia in grado di indirizzare gli utenti alle nuove istanze VM. Durante questo periodo, il traffico viene distribuito alle istanze VM esistenti, che potrebbero già essere al di sopra della capacità.
Applicazioni limitate dalla capacità del backend
Alcune applicazioni non possono essere scalate automaticamente. Ad esempio, i database spesso hanno una capacità di backend limitata. Solo un numero specifico di frontend può accedere a un database che non viene scalato orizzontalmente. Se la tua applicazione si basa su API esterne che supportano solo un numero limitato di richieste al secondo, non è possibile scalare automaticamente l'applicazione.
Licenze non elastiche
Quando utilizzi software con licenza, spesso la licenza ti limita a una capacità massima preimpostata. Pertanto, la tua capacità di scalabilità automatica potrebbe essere limitata perché non puoi aggiungere licenze al volo.
Spazio libero dell'istanza VM troppo ridotto
Per tenere conto di picchi improvvisi di traffico, un gestore della scalabilità automatica deve includere un ampio margine (ad esempio, il gestore della scalabilità automatica viene attivato al 70% della capacità della CPU). Per risparmiare sui costi, potresti essere tentato di impostare questo target su un valore più alto, ad esempio il 90% della capacità della CPU. Tuttavia, valori di attivazione più elevati potrebbero causare colli di bottiglia di scalabilità in caso di picchi di traffico, ad esempio una campagna pubblicitaria che aumenta improvvisamente la domanda. Devi bilanciare le dimensioni del margine in base alla variabilità del traffico e al tempo necessario per preparare le nuove istanze VM.
Quote regionali
Se si verificano picchi imprevisti in una regione, le quote risorse esistenti potrebbero limitare il numero di istanze a cui puoi scalare al di sotto del livello richiesto per supportare il picco attuale. L'elaborazione di un aumento della quota di risorse può richiedere alcune ore o giorni.
Affrontare queste sfide con il bilanciamento del carico globale
I bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico di rete proxy esterni sono prodotti di bilanciamento del carico globali con proxy tramite server Google Front End (GFE) sincronizzati a livello globale, il che semplifica la mitigazione di questi tipi di problemi di bilanciamento del carico. Questi prodotti offrono una soluzione alle sfide perché il traffico viene distribuito ai backend in modo diverso rispetto alla maggior parte delle soluzioni di bilanciamento del carico regionali.
Queste differenze sono descritte nelle sezioni seguenti.
Algoritmi utilizzati da altri bilanciatori del carico
La maggior parte dei bilanciatori del carico utilizza gli stessi algoritmi per distribuire il traffico tra i backend:
- Round robin. I pacchetti vengono distribuiti equamente tra tutti i backend indipendentemente dall'origine e dalla destinazione dei pacchetti.
- Hashing. I flussi di pacchetti vengono identificati in base agli hash delle informazioni sul traffico, inclusi IP di origine, IP di destinazione, porta e protocollo. Tutto il traffico che produce lo stesso valore hash viene indirizzato allo stesso backend.
Il bilanciamento del carico basato sull'hashing è l'algoritmo attualmente disponibile per i bilanciatori del carico di rete passthrough esterni. Questo bilanciatore del carico supporta l'hashing a 2 tuple (in base all'IP di origine e di destinazione), l'hashing a 3 tuple (in base all'IP di origine, all'IP di destinazione e al protocollo) e l'hashing a 5 tuple (in base all'IP di origine, all'IP di destinazione, alla porta di origine, alla porta di destinazione e al protocollo).
Con entrambi questi algoritmi, le istanze non integre vengono rimosse dalla distribuzione. Tuttavia, il carico attuale sui backend è raramente un fattore nella distribuzione del carico.
Alcuni bilanciatori del carico hardware o software utilizzano algoritmi che inoltrano il traffico in base ad altre metriche, come round robin ponderato, carico più basso, tempo di risposta più rapido o numero di connessioni attive. Tuttavia, se il carico aumenta oltre il livello previsto a causa di picchi di traffico improvvisi, il traffico viene comunque distribuito alle istanze di backend che superano la capacità, con conseguenti aumenti drastici della latenza.
Alcuni bilanciatori del carico consentono regole avanzate in cui il traffico che supera la capacità del backend viene inoltrato a un altro pool o reindirizzato a un sito web statico. In questo modo puoi rifiutare efficacemente questo traffico e inviare un messaggio "servizio non disponibile, riprova più tardi". Alcuni bilanciatori del carico ti danno la possibilità di mettere le richieste in una coda.
Le soluzioni di bilanciamento del carico globale vengono spesso implementate con un algoritmo basato su DNS, che pubblica IP di bilanciamento del carico regionali diversi in base alla posizione dell'utente e al carico del backend. Queste soluzioni offrono il failover in un'altra regione per tutto o parte del traffico per un deployment regionale. Tuttavia, in qualsiasi soluzione basata sul DNS, il failover richiede in genere minuti, a seconda del valore TTL (Time To Live) delle voci DNS. In generale, una piccola quantità di traffico continuerà a essere indirizzata ai vecchi server ben oltre il momento in cui il TTL dovrebbe essere scaduto ovunque. Pertanto, il bilanciamento del carico globale basato su DNS non è la soluzione ottimale per gestire il traffico in scenari burst.
Come funzionano i bilanciatori del carico delle applicazioni esterni
Il bilanciatore del carico delle applicazioni esterno utilizza un approccio diverso. Il traffico viene inviato tramite proxy attraverso i server GFE distribuiti nella maggior parte delle località edge della rete globale di Google. Al momento, si tratta di oltre 80 località in tutto il mondo. L'algoritmo di bilanciamento del carico viene applicato ai server GFE.
Il bilanciatore del carico delle applicazioni esterno è disponibile tramite un unico indirizzo IP stabile annunciato a livello globale nei nodi perimetrali e le connessioni vengono terminate da uno qualsiasi dei GFE.
I GFE sono interconnessi tramite la rete globale di Google. I dati che descrivono i backend disponibili e la capacità di gestione disponibile per ogni risorsa con bilanciamento del carico vengono distribuiti continuamente a tutti i GFE utilizzando un piano di controllo globale.
Il traffico verso gli indirizzi IP bilanciati del carico viene sottoposto a proxy alle istanze di backend definite nella configurazione del bilanciatore del carico delle applicazioni esterno utilizzando un algoritmo di bilanciamento del carico speciale chiamato Waterfall by Region. Questo algoritmo determina il backend ottimale per la gestione della richiesta tenendo conto della vicinanza delle istanze agli utenti, del carico in entrata e della capacità disponibile dei backend in ogni zona e regione. Infine, vengono presi in considerazione anche il carico e la capacità a livello mondiale.
Il bilanciatore del carico delle applicazioni esterno distribuisce il traffico in base alle istanze disponibili. Per aggiungere nuove istanze in base al carico, l'algoritmo funziona in combinazione con i gruppi di istanze con scalabilità automatica.
Flusso di traffico all'interno di una regione
In circostanze normali, tutto il traffico viene inviato alla regione più vicina all'utente. Il bilanciamento del carico viene quindi eseguito in base a queste linee guida:
All'interno di ogni regione, il traffico viene distribuito tra i gruppi di istanze, che possono trovarsi in più zone in base alla capacità di ciascun gruppo.
Se la capacità è diversa tra le zone, le zone vengono caricate in proporzione alla loro capacità di pubblicazione disponibile.
All'interno delle zone, le richieste vengono distribuite uniformemente tra le istanze di ogni gruppo di istanze.
Le sessioni vengono mantenute in base all'indirizzo IP client o a un valore cookie, a seconda dell'impostazione di affinità di sessione.
A meno che il backend non diventi non disponibile, le connessioni TCP esistenti non vengono mai spostate su un backend diverso.
Il seguente diagramma mostra la distribuzione del carico in questo caso, in cui ogni regione è sottoutilizzata e può gestire il carico degli utenti più vicini a quella regione.
Overflow del traffico verso altre regioni
Se un'intera regione raggiunge la capacità massima, come determinato dalla capacità di servizio impostata nei servizi di backend, viene attivato l'algoritmo a cascata per regione e il traffico viene trasferito alla regione più vicina con capacità disponibile. Man mano che ogni regione raggiunge la capacità massima, il traffico viene trasferito alla regione più vicina successiva e così via. La vicinanza di una regione all'utente è definita dal tempo di round trip della rete dal GFE ai backend delle istanze.
Il seguente diagramma mostra il overflow alla regione più vicina quando una regione riceve più traffico di quanto possa gestire a livello regionale.
Overflow tra regioni dovuto a backend non integri
Se i controlli di integrità rilevano che più della metà dei backend in una regione non è integro, i GFE eseguono preventivamente l'overflow di parte del traffico nella regione più vicina successiva. Ciò avviene per evitare che il traffico non vada a buon fine quando la regione non è più integra. Questo overflow si verifica anche se la capacità rimanente nella regione con i backend non integri è sufficiente.
Il seguente diagramma mostra il meccanismo di overflow in vigore, perché la maggior parte dei backend in una zona non è in stato integro.
Tutte le regioni con capacità superiore
Quando il traffico verso tutte le regioni è pari o superiore alla capacità, il traffico viene bilanciato in modo che ogni regione si trovi allo stesso livello relativo di overflow rispetto alla sua capacità. Ad esempio, se la domanda globale supera la capacità globale del 20%, il traffico viene distribuito in modo che tutte le regioni ricevano richieste al 20% in più rispetto alla loro capacità regionale, mantenendo il traffico il più locale possibile.
Il seguente diagramma mostra questa regola di overflow globale in vigore. In questo caso, una singola regione riceve così tanto traffico che non può essere distribuito con la capacità di pubblicazione disponibile a livello globale.
Overflow temporaneo durante la scalabilità automatica
La scalabilità automatica si basa sui limiti di capacità configurati su ogni servizio di backend e crea nuove istanze quando il traffico si avvicina ai limiti di capacità configurati. A seconda della velocità con cui aumentano i livelli di richieste e della velocità con cui vengono attivate nuove istanze, l'overflow in altre regioni potrebbe non essere necessario. In altri casi, l'overflow può fungere da buffer temporaneo finché le nuove istanze locali non sono online e pronte a gestire il traffico live. Quando la capacità espansa dalla scalabilità automatica è sufficiente, tutte le nuove sessioni vengono distribuite alla regione più vicina.
Effetti della latenza dell'overflow
Secondo l'algoritmo Waterfall by Region, può verificarsi un overflow di parte del traffico da parte del bilanciatore del carico delle applicazioni esterno ad altre regioni. Tuttavia, le sessioni TCP e il traffico SSL vengono comunque terminati dal GFE più vicino all'utente. Ciò è vantaggioso per la latenza delle applicazioni. Per maggiori dettagli, consulta Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.
Esercitazione pratica: misurare gli effetti della gestione della capacità
Per capire come si verifica l'overflow e come puoi gestirlo utilizzando il bilanciatore del carico HTTP, consulta il tutorial sulla gestione della capacità con il bilanciamento del carico che accompagna questo articolo.
Utilizzo di un bilanciatore del carico delle applicazioni esterno per risolvere i problemi di capacità
Per contribuire a risolvere le sfide discusse in precedenza, i bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico di rete proxy esterni possono superare la capacità in altre regioni. Per le applicazioni globali, rispondere agli utenti con una latenza complessiva leggermente superiore consente di offrire un'esperienza migliore rispetto all'utilizzo di un backend regionale. Le applicazioni che utilizzano un backend regionale hanno una latenza nominalmente inferiore, ma possono sovraccaricarsi.
Rivediamo in che modo un bilanciatore del carico delle applicazioni esterno può contribuire a risolvere gli scenari menzionati all'inizio dell'articolo:
Latenza nell'avvio di nuove istanze. Se lo scalatore automatico non riesce ad aggiungere capacità abbastanza rapidamente durante i picchi di traffico locale, il bilanciatore del carico delle applicazioni esterno esegue temporaneamente l'overflow delle connessioni alla regione più vicina successiva. In questo modo, le sessioni utente esistenti nella regione originale vengono gestite alla velocità ottimale, in quanto rimangono sui backend esistenti, mentre le nuove sessioni utente subiscono solo un leggero aumento della latenza. Non appena vengono aumentate le istanze di backend aggiuntive nella regione originale, il nuovo traffico viene nuovamente indirizzato alla regione più vicina agli utenti.
Applicazioni limitate dalla capacità del backend. Le applicazioni che non possono essere scalate automaticamente, ma che sono disponibili in più regioni, possono comunque eseguire l'overflow nella regione più vicina successiva quando la domanda in una regione supera la capacità di deployment per le normali esigenze di traffico.
Licenze non elastiche. Se il numero di licenze software è limitato e se il pool di licenze nella regione corrente è esaurito, il bilanciatore del carico delle applicazioni esterno può spostare il traffico in una regione in cui sono disponibili licenze. Affinché questa operazione funzioni, il numero massimo di istanze è impostato sul numero massimo di licenze nello strumento di scalabilità automatica.
Spazio di manovra della VM troppo ridotto. La possibilità di overflow regionale consente di risparmiare denaro, perché puoi configurare la scalabilità automatica con un trigger di utilizzo elevato della CPU. Puoi anche configurare la capacità di backend disponibile sotto ogni picco regionale, perché il overflow verso altre regioni garantisce che la capacità globale sia sempre sufficiente.
Quote regionali. Se le quote delle risorse di Compute Engine non corrispondono alla domanda, l'overflow del bilanciatore del carico delle applicazioni esterno reindirizza automaticamente parte del traffico a una regione che può ancora scalare entro la sua quota regionale.
Passaggi successivi
Le pagine seguenti forniscono ulteriori informazioni e contesto sulle opzioni di bilanciamento del carico di Google:
- Gestione della capacità con il tutorial sul bilanciamento del carico
- Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico
- Codelab Networking 101
- Bilanciatore del carico di rete passthrough esterno
- Bilanciatore del carico delle applicazioni esterno
- Bilanciatore del carico di rete proxy esterno