Cloud Load Balancing fornisce meccanismi per distribuire il traffico degli utenti a più istanze di un'applicazione. Lo fanno distribuendo il carico tra le istanze dell'applicazione e offrendo prestazioni ottimali agli utenti finali. In questa pagina vengono descritte alcune best practice per garantire che il bilanciatore del carico sia ottimizzato per la tua applicazione. Per garantire un rendimento ottimale, 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 carichi di lavoro (backend bilanciatori del carico), minore è la latenza di rete tra loro. Pertanto, crea i backend del bilanciatore del carico nella regione più vicina a dove prevedi che il traffico dei tuoi utenti arrivi al frontend di Google. In molti casi, è necessario eseguire i backend in più regioni 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 bilanciatori del carico delle applicazioni esterni
- Best practice per la scelta dell'area geografica per Compute Engine
Attivare 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 ulteriori informazioni, consulta Cloud CDN.
Quando attivi 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 di risposta vengono restituite per quell'URL e come la memorizzazione nella cache è configurata per il tuo backend. Per maggiori dettagli, consulta la risoluzione dei problemi di Cloud CDN.
Selezione del protocollo della regola di inoltro
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, in Android Cronet e iOS. Per utilizzare HTTP/3 per le tue applicazioni, assicurati che il traffico UDP non sia bloccato o limitato in base alla frequenza sulla 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 rete meno recenti, non saranno interessati. Per ulteriori informazioni, 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 determinato ovverhead 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 molte più connessioni TCP all'istanza 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 notare latenze elevate del backend perché le connessioni al 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 indirizzato ai backend all'interno delle reti VPC di 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 zonali. 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, vedi Crittografia dal bilanciatore del carico ai backend.
Durata consigliata della connessione
Le condizioni di rete cambiano e l'insieme di backend potrebbe variare 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), dopodiché viene utilizzata una nuova connessione per le nuove richieste. La vecchia connessione viene chiusa al termine di tutte le richieste attive che la utilizzano.
In questo modo, l'applicazione client può trarre vantaggio dalle modifiche all'insieme di backend, tra cui i proxy del bilanciatore del carico e qualsiasi ottimizzazione della rete necessaria per servire i client.
Criteri di selezione della modalità di bilanciamento
Per un rendimento migliore, ti consigliamo di scegliere il gruppo di backend per ogni nuova richiesta in base a quello più reattivo. Ciò può essere ottenuto utilizzando 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.
Configurare 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. Questo può essere configurato utilizzando l'affinità 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 di servizio di backend e non su base di backend. Tuttavia, una mappa URL può puntare a più servizi di backend. Di conseguenza, non è necessario utilizzare un solo tipo di affinità sessione per il bilanciatore del carico. A seconda dell'applicazione, puoi utilizzare diversi servizi di backend con impostazioni di affinità sessione diverse. Ad esempio, se una parte della tua applicazione pubblica contenuti statici per molti utenti, è improbabile che tragga vantaggio dall'affinità sessione. Dovresti utilizzare un servizio di backend abilitato per Cloud CDN per pubblicare le risposte memorizzate nella cache.
Per ulteriori informazioni, consulta la sezione sull'affinità della sessione.