Cloud Load Balancing fornisce meccanismi per distribuire il traffico degli utenti a più istanze di un'applicazione. A questo scopo, distribuiscono il carico tra le istanze dell'applicazione e offrono prestazioni ottimali agli utenti finali. Questa pagina descrive alcune best practice per garantire che il bilanciatore del carico sia ottimizzato per la tua applicazione. Per garantire prestazioni ottimali, ti consigliamo di eseguire il benchmarking dei pattern di traffico della tua applicazione.
Posiziona i backend vicino ai client
Più gli utenti o le applicazioni client sono vicini ai workload (backend del bilanciatore del carico), minore è la latenza di rete tra loro. Pertanto, crea i backend del bilanciatore del carico nella regione più vicina a quella in cui prevedi che il traffico degli utenti arrivi al frontend di Google. In molti casi, l'esecuzione dei backend in più regioni è necessaria per ridurre al minimo la latenza per i client in diverse parti del mondo.
Per ulteriori informazioni, consulta i seguenti argomenti:
- Distribuzione del traffico per i bilanciatori del carico delle applicazioni esterni
- Best practice per la scelta della regione per Compute Engine
Configura l'alta affidabilità e il failover
Per proteggerti da interruzioni dell'infrastruttura regionali o globali ed errori di configurazione, configura l'alta affidabilità e il failover multiregionali utilizzando le policy di routing e i controlli di integrità di Cloud DNS:
- Per i bilanciatori del carico delle applicazioni esterni globali, esegui il deployment di bilanciatori del carico delle applicazioni esterni regionali in più regioni come bilanciatori del carico di failover. Se la tua architettura non si basa sul bilanciamento del carico del backend globale sensibile alla capacità, preferisci una strategia di bypass da globale a regionale di tipo attivo-attivo, in cui un bilanciatore del carico delle applicazioni esterno globale funge da frontend perimetrale davanti ai bilanciatori del carico delle applicazioni esterni regionali. Se la tua applicazione richiede il bilanciamento del carico del backend globale per distribuire e trasferire il traffico tra le regioni in base alla capacità del backend, implementa una strategia di failover globale-regionale attivo-passivo. Per saperne di più, consulta Failover per i bilanciatori del carico delle applicazioni esterni globali.
- Per i bilanciatori del carico delle applicazioni esterni regionali, esegui il deployment di bilanciatori del carico delle applicazioni esterni regionali indipendenti in più regioni e utilizza i controlli di integrità e le policy di routing di Cloud DNS per implementare il failover delle regioni attivo-passivo o il routing di prossimità attivo-attivo tra le regioni. Per saperne di più, consulta Alta affidabilità per i bilanciatori del carico delle applicazioni esterni regionali.
Abilita la memorizzazione nella cache con Cloud CDN
Attiva Cloud CDN e la memorizzazione nella cache nell'ambito della configurazione predefinita del bilanciatore del carico delle applicazioni esterno globale. Per saperne di più, consulta Cloud CDN.
Quando abiliti Cloud CDN, potrebbero essere necessari alcuni minuti prima che le risposte inizino a essere memorizzate nella cache. Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache. Se le risposte per un URL non vengono memorizzate nella cache, controlla quali intestazioni della risposta vengono restituite per quell'URL e come viene configurata la memorizzazione nella cache per il backend. Per maggiori dettagli, consulta la sezione Risoluzione dei problemi di Cloud CDN.
Selezione del protocollo della regola di forwarding
Per il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni classico, consigliamo HTTP/3, un protocollo internet basato su IETF QUIC. HTTP/3 è abilitato per impostazione predefinita in tutti i principali browser, Android Cronet e iOS. Per utilizzare HTTP/3 per le tue applicazioni, assicurati che il traffico UDP non sia bloccato o limitato nella tua rete e che HTTP/3 non sia stato precedentemente disattivato sui bilanciatori del carico delle applicazioni esterni globali. I client che non supportano ancora HTTP/3, come i browser o le librerie di networking meno recenti, non saranno interessati. Per saperne di più, consulta HTTP/3 QUIC.
Per il bilanciatore del carico delle applicazioni esterno regionale, supportiamo HTTP/1.1, HTTPS e HTTP/2. Sia HTTPS che HTTP/2 richiedono un overhead iniziale per configurare TLS.
Selezione del protocollo del servizio di backend
La scelta del protocollo di backend (HTTP, HTTPS o HTTP/2) influisce sulla latenza dell'applicazione e sulla larghezza di banda di rete disponibile per l'applicazione. Ad esempio, l'utilizzo di HTTP/2 tra il bilanciatore del carico e l'istanza di backend può richiedere un numero di connessioni TCP all'istanza significativamente maggiore rispetto a HTTP(S). Il pooling delle connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP(S), non è disponibile con HTTP/2. Di conseguenza, potresti riscontrare latenze di backend elevate perché le connessioni di backend vengono effettuate più di frequente.
Il protocollo del servizio di backend influisce anche sul modo in cui il traffico viene criptato in transito. Con i bilanciatori del carico HTTP(S) esterni, tutto il traffico diretto ai backend che risiedono all'interno delle reti VPC Google Cloud viene criptato automaticamente. Questa operazione è chiamata crittografia automatica a livello di rete. Tuttavia, la crittografia automatica a livello di rete è disponibile solo per le comunicazioni con i gruppi di istanze e i backend NEG di zona. Per tutti gli altri tipi di backend, ti consigliamo di utilizzare opzioni di protocollo sicure come HTTPS e HTTP/2 per criptare la comunicazione con il servizio di backend. Per maggiori dettagli, consulta Crittografia dal bilanciatore del carico ai backend.
Durata della connessione consigliata
Le condizioni della rete cambiano e l'insieme di backend potrebbe cambiare in base al carico. Per le applicazioni che generano molto traffico verso un singolo servizio, una connessione di lunga durata non è sempre una configurazione ottimale. Anziché utilizzare una singola connessione al backend a tempo indeterminato, ti consigliamo di scegliere una durata massima della connessione (ad esempio, tra 10 e 20 minuti) e/o un numero massimo di richieste (ad esempio, tra 1000 e 2000 richieste), dopo di che viene utilizzata una nuova connessione per le nuove richieste. La connessione precedente viene chiusa quando tutte le richieste attive che la utilizzano sono state completate.
In questo modo, l'applicazione client può trarre vantaggio dalle modifiche nell'insieme di backend, che includono i proxy del bilanciatore del carico e qualsiasi riottimizzazione della rete necessaria per gestire i client.
Criteri di selezione della modalità di bilanciamento
Per migliorare le prestazioni, valuta la possibilità di scegliere il gruppo di backend per ogni nuova richiesta in base al backend più reattivo. Per farlo, utilizza la modalità di bilanciamento RATE. In questo caso, viene scelto il gruppo di backend con la latenza media più bassa per le richieste recenti o, per HTTP/2 e HTTP/3, il gruppo di backend con il minor numero di richieste in sospeso.
La modalità di bilanciamento UTILIZATION si applica solo ai backend dei gruppi di istanze e distribuisce il traffico in base all'utilizzo delle istanze VM in un gruppo di istanze.
Configura l'affinità sessione
In alcuni casi, potrebbe essere utile che lo stesso backend gestisca le richieste provenienti dagli stessi utenti finali o correlate allo stesso utente finale, almeno per un breve periodo di tempo. Puoi configurare questa opzione utilizzando l'affinità di sessione, un'impostazione configurata sul servizio di backend. L'affinità di sessione controlla la distribuzione delle nuove connessioni dai client ai backend del bilanciatore del carico. Puoi utilizzare l'affinità sessione per assicurarti che lo stesso backend gestisca le richieste provenienti dalla stessa risorsa, ad esempio relative allo stesso account utente o allo stesso documento.
L'affinità di sessione viene specificata per l'intera risorsa del servizio di backend e non per ogni backend. Tuttavia, una mappa URL può puntare a più servizi di backend. Pertanto, non è necessario utilizzare un solo tipo di affinità sessione per il bilanciatore del carico. A seconda dell'applicazione, puoi utilizzare servizi di backend diversi con impostazioni di affinità sessione diverse. Ad esempio, se una parte della tua applicazione fornisce contenuti statici a molti utenti, è improbabile che tragga vantaggio dall'affinità sessione. Per pubblicare le risposte memorizzate nella cache, devi utilizzare un servizio di backend abilitato per Cloud CDN.
Per saperne di più, consulta Affinità di sessione.