Cloud Load Balancing fornisce per distribuire il traffico degli utenti a più istanze di un'applicazione. Lo fanno distribuendo il carico sulle 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. A garantire prestazioni ottimali, è consigliabile eseguire il benchmarking del traffico della tua applicazione pattern.
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 dei bilanciatori del carico nella regione più vicina a quella in cui prevedi dei tuoi utenti per arrivare 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 regione di Compute Engine selezione
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, vedi Cloud CDN.
Quando abiliti Cloud CDN, potrebbero essere necessari alcuni minuti prima che le risposte iniziano a essere memorizzate nella cache. Cloud CDN memorizza nella cache solo le risposte con . Se le risposte per un URL non vengono memorizzati nella cache, controlla quali intestazioni di risposta vengono restituite per quell'URL e come la memorizzabilità nella cache è configurata per il tuo backend. Per per maggiori dettagli, consulta Cloud CDN risoluzione dei problemi.
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 protocollo UDP il traffico non sia bloccato o limitato di frequenza sulla rete e che HTTP/3 non sia stato precedentemente disattivato su Bilanciatori del carico delle applicazioni esterni globali. Clienti che non supporta ancora HTTP/3, ad esempio i browser meno recenti o le librerie di rete, 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 certo ovverhead iniziale per configurare TLS.
Selezione del protocollo del servizio di backend
La scelta del protocollo di backend (HTTP, HTTPS o HTTP/2) influisce sull'applicazione e la 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). Connessione il pooling, un'ottimizzazione che riduce il numero di queste connessioni HTTP(S), non disponibile con HTTP/2. Di conseguenza, potresti notare e la latenza di backend 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 bilanciatori del carico HTTP(S) esterni, tutto il traffico diretto ai backend che risiedono 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 il NEG a livello di zona di backend. 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 della connessione consigliata
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 lunga la connessione in esecuzione non è sempre una configurazione ottimale. Invece di utilizzare un singolo connessione al backend a tempo indeterminato, ti consigliamo di scegliere una durata massima durata della connessione (ad esempio, tra 10 e 20 minuti) e/o un numero massimo di richieste (ad es. 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.
Ciò consente all'applicazione client di trarre vantaggio dalle modifiche nel set di backend, che includono i proxy del bilanciatore del carico e qualsiasi riottimizzazione della rete necessarie per servire i clienti.
Criteri di selezione della modalità di bilanciamento
Per ottenere prestazioni migliori, valuta la possibilità di scegliere il gruppo di backend per ogni nuova richiesta
in base al backend più reattivo. Ciò può essere ottenuto utilizzando la modalità di bilanciamento RATE. In questo caso, il gruppo di backend con la media più bassa
per le richieste recenti o, per HTTP/2 e HTTP/3, il gruppo di backend con
viene selezionato 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'istanza
gruppo.
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. Può essere configurato utilizzando l'affinità sessione, un configurata nel 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à di 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à sessione è specificata per l'intera risorsa del servizio di backend e non per backend. Tuttavia, una mappa URL può puntare a più backend i servizi di machine learning. 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à di sessione diverse. Ad esempio, se una parte della tua applicazione pubblica contenuti statici per molti utenti, è improbabile che tragga vantaggio dall'affinità di sessione. Dovresti utilizzare un Servizio di backend abilitato per Cloud CDN per gestire i dati memorizzati nella cache risposte.
Per ulteriori informazioni, vedi sessione di affinità.