Best practice per le prestazioni del bilanciatore del carico delle applicazioni esterno

Cloud Load Balancing fornisce meccanismi per distribuire il traffico degli utenti a più istanze di un'applicazione. Per farlo, distribuendo il carico tra le istanze dell'applicazione e offrendo prestazioni dell'applicazione 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 prestazioni ottimali, consigliamo di eseguire il benchmarking dei modelli di traffico della tua applicazione.

Posiziona i backend vicino ai client

Più gli utenti o le applicazioni client sono vicini ai tuoi carichi di lavoro (backend del bilanciatore del carico), minore è la latenza di rete tra di loro. Di conseguenza, crea i backend del bilanciatore del carico nella regione più vicina a dove prevedi che il traffico degli utenti arrivi al Google Front End (GFE). 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:

Abilita la memorizzazione nella cache con Cloud CDN

Attiva Cloud CDN e la memorizzazione nella cache come parte 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 è configurata la cache per il backend. Per ulteriori dettagli, consulta Risoluzione dei problemi di Cloud CDN.

Selezione del protocollo della regola di forwarding

  • Per l'Application Load Balancer esterno globale e l'Application Load Balancer classico, consigliamo HTTP/3, un protocollo internet basato su IETF QUIC. HTTP/3 è abilitato per impostazione predefinita in tutti i principali browser, Android Chromet e iOS. Per utilizzare HTTP/3 per le tue applicazioni, assicurati che il traffico UDP non sia bloccato o limitato dalla frequenza di rete sulla tua rete e che HTTP/3 non fosse precedentemente disabilitato sugli Application Load Balancer esterni globali. I client che non supportano ancora HTTP/3, come browser o librerie di rete meno recenti, non saranno interessati. Per ulteriori informazioni, consulta HTTP/3 QUIC.

  • Per l'Application Load Balancer esterno regionale, supportiamo HTTP/1.1, HTTPS e HTTP/2. Sia HTTPS che HTTP/2 richiedono un overhead in anticipo per la configurazione di 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 significativamente maggiore di connessioni TCP all'istanza rispetto a HTTP(S). Il pool di connessioni, un'ottimizzazione che riduce il numero di queste connessioni con HTTP(S), non è attualmente disponibile con HTTP/2. Di conseguenza, potresti notare latenze high-end, perché le connessioni di backend vengono effettuate con maggiore frequenza.

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 che risiedono all'interno delle reti VPC di Google Cloud viene automaticamente criptato. Questa procedura si chiama crittografia automatica a livello di rete. Tuttavia, la crittografia automatica a livello di rete è disponibile solo per le comunicazioni con gruppi di istanze e backend di NEG a livello di zona. Per tutti gli altri tipi di backend, Google Cloud consiglia di utilizzare opzioni di protocollo sicure come HTTPS e HTTP/2 per criptare le comunicazioni con il servizio di backend. Per maggiori dettagli, consulta Crittografia dal bilanciatore del carico ai backend.

Le condizioni di 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 a lunga esecuzione non è sempre una configurazione ottimale. Invece di utilizzare una singola connessione al backend a tempo indeterminato, consigliamo di scegliere una durata massima della connessione (ad esempio, compresa 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 quando vengono eseguite tutte le richieste attive che la utilizzano.

Ciò consente all'applicazione client di trarre vantaggio dalle modifiche all'insieme di backend, che includono i proxy del bilanciatore del carico e l'eventuale riottimizzazione della rete necessaria per gestire i client.

Criteri di selezione della modalità di bilanciamento

Per ottenere prestazioni migliori, ti consigliamo di scegliere il gruppo di backend per ogni nuova richiesta in base al backend più reattivo. A questo scopo, puoi utilizzare la modalità di bilanciamento di RATE. In questo caso, viene scelto il gruppo di backend con la latenza media più bassa rispetto alle richieste recenti oppure, per HTTP/2 e HTTP/3, viene scelto il gruppo di backend con il minor numero di richieste in sospeso.

La modalità di bilanciamento UTILIZATION si applica solo ai backend di gruppi di istanze e distribuisce il traffico in base all'utilizzo delle istanze VM in un gruppo di istanze.

Configura affinità sessione

In alcuni casi, potrebbe essere utile che lo stesso backend gestisca le richieste degli stessi utenti finali o relative allo stesso utente finale, almeno per un breve periodo di tempo. Questa opzione può essere configurata utilizzando l'affinità sessione, un'impostazione configurata nel servizio di backend. L'affinità sessione controlla la distribuzione di nuove connessioni dai client ai backend del bilanciatore del carico. Puoi utilizzare l'affinità sessione per assicurarti che lo stesso backend gestisca le richieste dalla stessa risorsa, ad esempio relative allo stesso account utente o dallo stesso documento.

L'affinità sessione è specificata per l'intera risorsa del servizio di backend e non per il singolo 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 usare diversi servizi di backend con impostazioni di affinità sessione. Ad esempio, se una parte dell'applicazione mostra contenuti statici a molti utenti, è improbabile che tragga vantaggio dall'affinità sessione. Dovresti invece utilizzare un servizio di backend abilitato per Cloud CDN per fornire le risposte memorizzate nella cache.

Per ulteriori informazioni, consulta la sezione sull'affinità delle sessioni.