La maggior parte dei bilanciatori del carico utilizza un approccio round-robin o di hashing basato sui flussi per distribuire il traffico. Tuttavia, i bilanciatori del carico che utilizzano questo approccio possono avere difficoltà ad adattarsi quando la domanda raggiunge un picco oltre la capacità di pubblicazione disponibile. Questo articolo spiega come l'utilizzo di Cloud Load Balancing può risolvere questi problemi e ottimizzare la capacità globale delle applicazioni. Ciò spesso comporta una migliore esperienza utente e costi inferiori rispetto alle implementazioni tradizionali di bilanciamento del carico.
Questo articolo fa parte di una serie di best practice incentrata sui prodotti Cloud Load Balancing di Google. Per un tutorial abbinato a questo articolo, vedi Gestione della capacità con il bilanciamento del carico. Per un'analisi approfondita sulla latenza, consulta Ottimizzare la latenza delle applicazioni con il bilanciamento del carico.
Sfide di capacità nelle applicazioni globali
La scalabilità delle applicazioni globali può essere impegnativa, soprattutto se hai budget IT limitati e carichi di lavoro imprevedibili e bursting. 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, i gestori della scalabilità automatica presentano alcune limitazioni, come spiegato in questa sezione.
Latenza nell'avvio di nuove istanze
Il problema più comune della scalabilità automatica è che l'applicazione richiesta non è pronta per gestire il traffico abbastanza rapidamente. A seconda delle immagini delle istanze VM, in genere è necessario eseguire gli script e caricare le informazioni 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 a nuove istanze VM. Durante questo periodo, il traffico viene distribuito alle istanze VM esistenti, che potrebbero aver già superato la capacità.
Applicazioni limitate dalla capacità del backend
Per alcune applicazioni non è possibile scalare automaticamente. Ad esempio, i database hanno spesso una capacità di backend limitata. Solo un numero specifico di frontend può accedere a un database che non scala orizzontalmente. Se la tua applicazione si basa su API esterne che supportano solo un numero limitato di richieste al secondo, anche l'applicazione non può essere scalata automaticamente.
Licenze non elastiche
Quando utilizzi software concesso in licenza, spesso la tua licenza è limitata a una capacità massima preimpostata. La scalabilità automatica potrebbe quindi essere limitata perché non puoi aggiungere licenze al momento.
Margine insufficiente per l'istanza VM
Per tenere conto di picchi di traffico improvvisi, un gestore della scalabilità automatica deve includere un ampio margine di miglioramento (ad esempio, il gestore della scalabilità automatica viene attivato al 70% della capacità della CPU). Per risparmiare sui costi, potresti cedere la tentazione di impostare questo target su un valore più alto, ad esempio il 90% della capacità della CPU. Tuttavia, valori di trigger più elevati potrebbero comportare un aumento della scalabilità in caso di picchi di traffico, come ad esempio una campagna pubblicitaria che aumenta improvvisamente la domanda. Devi bilanciare le dimensioni del margine in base al picco di traffico e al tempo necessario per preparare le nuove istanze VM.
Quote per regione
Se si verificano burst imprevisti in una regione, le quote delle risorse esistenti potrebbero limitare il numero di istanze che puoi scalare al di sotto del livello richiesto per supportare il burst attuale. L'elaborazione di un aumento della quota di risorse può richiedere alcune ore o alcuni giorni.
Affrontare queste sfide con il bilanciamento del carico globale
Gli Application Load Balancer esterni e i bilanciatori del carico di rete proxy esterno sono prodotti di bilanciamento del carico globali trasferiti tramite proxy attraverso server Google Front End (GFE) sincronizzati a livello globale, semplificando la mitigazione di questi tipi di sfide di bilanciamento del carico. Questi prodotti offrono una soluzione alle sfide perché il traffico viene distribuito nei backend in modo diverso rispetto alla maggior parte delle soluzioni di bilanciamento del carico a livello di regione.
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 sono distribuiti equamente tra tutti i backend indipendentemente dall'origine e dalla destinazione dei pacchetti.
- Hashing. I flussi di pacchetti sono identificati in base ad hash di informazioni sul traffico, tra cui IP di origine, IP di destinazione, porta e protocollo. Tutto il traffico che produce lo stesso valore hash passa allo stesso backend.
Il bilanciamento del carico di 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 a IP di origine, IP di destinazione e protocollo) e a 5 tuple (in base a IP di origine, IP di destinazione, porta di origine, porta di destinazione e protocollo).
Con entrambi gli algoritmi, le istanze in stato non integro vengono eliminate 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, ad esempio round robin ponderato, carico più basso, tempo di risposta più rapido o numero di connessioni attive. Tuttavia, se il carico aumenta rispetto al livello previsto a causa di improvvise burst di traffico, il traffico viene comunque distribuito alle istanze di backend che superano la capacità, con un conseguente aumento drastico 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 consentono di inserire le richieste in coda.
Le soluzioni di bilanciamento del carico globali sono spesso implementate con un algoritmo basato su DNS, che gestisce IP di bilanciamento del carico a livello di regione diversi in base alla località e al carico di backend dell'utente. Queste soluzioni offrono il failover a un'altra regione per tutto o parte del traffico relativo a un deployment a livello di regione. Tuttavia, per qualsiasi soluzione basata su DNS, il failover di solito richiede minuti, a seconda del valore di durata (TTL) delle voci DNS. In generale, una piccola quantità di traffico continuerà a essere indirizzata ai server precedenti anche oltre l'ora di scadenza del TTL ovunque. Pertanto, il bilanciamento del carico globale basato su DNS non è la soluzione ottimale per gestire il traffico in scenari di bursty.
Come funzionano i bilanciatori del carico delle applicazioni esterni
L'Application Load Balancer esterno utilizza un approccio diverso. Il traffico viene inviato tramite proxy mediante i server GFE di cui è stato eseguito il deployment nella maggior parte delle località sul perimetro della rete globale di Google. Attualmente sono oltre 80 località in tutto il mondo. L'algoritmo di bilanciamento del carico viene applicato ai server GFE.
L'Application Load Balancer esterno è disponibile tramite un singolo indirizzo IP stabile che viene annunciato a livello globale sui nodi periferici e le connessioni sono 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 con bilanciamento del carico viene inviato tramite proxy alle istanze di backend definite nella configurazione dell'Application Load Balancer esterno utilizzando uno speciale algoritmo di bilanciamento del carico chiamato Cascata per regione. 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.
L'Application Load Balancer esterno distribuisce il traffico in base alle istanze disponibili. Per aggiungere nuove istanze in base al carico, l'algoritmo funziona insieme ai gruppi di istanze con scalabilità automatica.
Flusso di traffico all'interno di una regione
In circostanze normali, tutto il traffico viene inviato all'area geografica 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 a seconda della capacità di ogni gruppo.
Se la capacità è diversa tra le zone, le zone vengono caricate in proporzione alla loro capacità di distribuzione disponibile.
All'interno delle zone, le richieste sono distribuite in modo uniforme tra le istanze in ogni gruppo di istanze.
Le sessioni vengono salvate in modo permanente in base all'indirizzo IP del client o a un valore del cookie, a seconda dell'impostazione di affinità sessione.
A meno che il backend non diventi disponibile, le connessioni TCP esistenti non vengono mai spostate in un backend diverso.
Il seguente diagramma mostra la distribuzione del carico in questo caso, dove ogni regione ha una capacità insufficiente e può gestire il carico degli utenti più vicini all'area geografica.
Riversamento del traffico verso altre regioni
Se un'intera regione raggiunge la capacità determinata dalla capacità di gestione impostata nei servizi di backend, viene attivato l'algoritmo con struttura a cascata per regione e il traffico viene superato nella regione più vicina con capacità disponibile. Man mano che ogni area geografica raggiunge la capacità, il traffico si estende alla successiva area geografica più vicina e così via. La vicinanza di una regione all'utente è definita dal tempo di round trip della rete dal GFE ai backend dell'istanza.
Il seguente diagramma mostra l'overflow alla successiva regione più vicina quando un'area riceve più traffico di quello che può gestire a livello regionale.
Overflow tra regioni non integro a causa di backend in stato non integro
Se i controlli di integrità rilevano che più della metà dei backend in una regione non è integro, i GFE superano preventivamente del traffico verso la successiva area geografica più vicina. Ciò avviene per evitare un errore completo del traffico quando l'area geografica diventa non integro. Questo overflow si verifica anche se la capacità rimanente nell'area geografica con i backend in stato non integro è sufficiente.
Il seguente diagramma mostra il meccanismo di overflow in vigore, perché la maggior parte dei backend in una zona non è integro.
Tutte le regioni al di sopra della capacità
Quando il traffico verso tutte le regioni raggiunge o supera la capacità massima, il traffico viene bilanciato in modo che ogni regione abbia lo 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 tale che tutte le regioni ricevano richieste del 20% rispetto alla capacità regionale, mantenendo il traffico il più locale possibile.
Il seguente diagramma mostra questa regola di overflow globale attiva. In questo caso, una singola regione riceve così tanto traffico che non può essere distribuita affatto con la capacità di distribuzione disponibile a livello globale.
Overflow temporaneo durante la scalabilità automatica
La scalabilità automatica si basa sui limiti di capacità configurati su ciascun servizio di backend e attiva nuove istanze quando il traffico si avvicina ai limiti di capacità configurati. A seconda della velocità con cui aumentano i livelli delle richieste e della velocità con cui le nuove istanze vengono online, l'overflow ad 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 per gestire il traffico in tempo reale. Quando la capacità espansa tramite la scalabilità automatica è sufficiente, tutte le nuove sessioni vengono distribuite nell'area geografica più vicina.
Effetti di latenza dell'overflow
In base all'algoritmo con struttura a cascata per regione, può verificarsi un overflow di una parte del traffico proveniente dall'Application Load Balancer esterno verso 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.
Pratica: misurazione degli 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 associato a questo articolo.
Utilizzo di un bilanciatore del carico delle applicazioni esterno per affrontare le sfide di capacità
Per aiutarti ad affrontare le sfide discusse in precedenza, gli Application Load Balancer esterni e i bilanciatori del carico di rete proxy esterni possono sovraccaricare la capacità di altre regioni. Per le applicazioni globali, rispondere agli utenti con una latenza complessiva leggermente superiore si traduce in un'esperienza migliore rispetto all'utilizzo di un backend regionale. Le applicazioni che utilizzano un backend a livello di regione hanno una latenza nominalmente inferiore, ma possono sovraccaricarle.
Rivediamo in che modo un bilanciatore del carico delle applicazioni esterno può aiutare a risolvere gli scenari menzionati all'inizio dell'articolo:
Latenza nell'avvio di nuove istanze. Se il gestore della scalabilità automatica non è in grado di aggiungere capacità abbastanza velocemente durante i burst del traffico locale, l'Application Load Balancer esterno causa temporaneamente l'overflow delle connessioni alla successiva regione più vicina. In questo modo, le sessioni utente esistenti nella regione originale vengono gestite a una velocità ottimale perché rimangono nei backend esistenti, mentre le sessioni di nuovi utenti subiscono solo un leggero picco di latenza. Non appena viene eseguito lo scale up di altre istanze di backend nella regione originale, il nuovo traffico viene instradato di nuovo 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 overflow alla successiva regione più vicina quando la domanda in un'area geografica supera la capacità implementata per le normali esigenze di traffico.
Licenze non elastiche. Se il numero di licenze software è limitato e il pool di licenze nella regione attuale è esaurito, l'Application Load Balancer esterno può spostare il traffico in una regione in cui sono disponibili le licenze. Affinché questa operazione vada a buon fine, il numero massimo di istanze è impostato sul numero massimo di licenze nel gestore della scalabilità automatica.
Margine insufficiente per le VM. La possibilità di overflow a livello di regione aiuta a risparmiare denaro, perché puoi configurare la scalabilità automatica con un attivatore di utilizzo elevato della CPU. Puoi anche configurare la capacità di backend disponibile al di sotto di ogni picco regionale, perché l'overflow ad altre regioni garantisce che la capacità globale sarà sempre sufficiente.
Quote per area geografica. 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 verso una regione comunque in grado di scalare entro la sua quota regionale.
Passaggi successivi
Le pagine seguenti forniscono ulteriori informazioni e dettagli sulle opzioni di bilanciamento del carico di Google:
- Tutorial sulla gestione della capacità con il bilanciamento del carico
- Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico
- Networking 101 Codelab
- Bilanciatore del carico di rete passthrough esterno
- Bilanciatore del carico delle applicazioni esterno
- Bilanciatore del carico di rete proxy esterno