Ottimizzazioni del bilanciamento del carico avanzate

Questa pagina descrive come configurare ottimizzazioni avanzate per costi, latenza e resilienza per i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete proxy.

Cloud Service Mesh supporta anche ottimizzazioni del bilanciamento del carico avanzate. Per maggiori dettagli, consulta la Panoramica del bilanciamento del carico avanzato nella documentazione di Cloud Service Mesh.

Cloud Load Balancing offre le seguenti funzionalità avanzate:

• Policy di bilanciamento del carico del servizio. Un criterio di bilanciamento del carico del servizio (serviceLbPolicy) è una risorsa associata al servizio di backend del bilanciatore del carico. Un criterio di bilanciamento del carico del servizio consente di personalizzare i seguenti parametri per influenzare la modalità di distribuzione del traffico tra i backend associati a un servizio di backend:

  • Algoritmi di bilanciamento del carico. Personalizza l'algoritmo di bilanciamento del carico utilizzato per determinare la modalità di distribuzione del traffico all'interno di una determinata regione o zona.
  • Scarico automatico della capacità. Attiva lo svuotamento automatico della capacità in modo che il bilanciatore del carico possa scaricare rapidamente il traffico dai backend non integri.
  • Soglia di failover. Imposta una soglia di failover per determinare quando un backend è considerato non integro. In questo modo, il traffico viene eseguito in un altro backend per evitare quelli non integri.
  • Isolamento del traffico. Evita gli errori a cascata limitando o vietando l'overflow del traffico tra regioni.

• Backend preferiti. Puoi designare backend specifici come backend preferiti. Questi backend devono essere utilizzati al massimo della loro capacità prima che le richieste vengano inviate ai backend rimanenti.

Il seguente diagramma mostra come Cloud Load Balancing valuta il routing, il bilanciamento del carico e la distribuzione del traffico.

Prima di iniziare

Prima di esaminare i contenuti di questa pagina, esamina attentamente la procedura di distribuzione delle richieste descritta nella pagina Panoramica del bilanciatore del carico delle applicazioni esterno. Per i bilanciatori del carico di livello Premium, tutti gli algoritmi di bilanciamento del carico descritti in questa pagina supportano lo spillover tra regioni se una regione di prima scelta è già piena.

Bilanciatori del carico e backend supportati

I seguenti bilanciatori del carico supportano le policy di bilanciamento del carico del servizio e i backend preferiti:

• Bilanciatore del carico delle applicazioni esterno globale
• Bilanciatore del carico delle applicazioni interno tra regioni
• Bilanciatore del carico di rete proxy esterno globale
• Bilanciatore del carico di rete proxy interno tra regioni

Le funzionalità descritte in questa pagina richiedono backend compatibili che supportano una modalità di bilanciamento. I backend supportati sono riassunti nella tabella seguente:

Algoritmi di bilanciamento del carico

Questa sezione descrive gli algoritmi di bilanciamento del carico che puoi configurare in una policy di bilanciamento del carico del servizio. Se non configuri un algoritmo o se non configuri un criterio di bilanciamento del carico del servizio, il bilanciatore del carico utilizza WATERFALL_BY_REGION per impostazione predefinita.

A cascata per regione

WATERFALL_BY_REGION è l'algoritmo di bilanciamento del carico predefinito. Con questo algoritmo, in aggregato, tutti i front-end di Google (GFEs) nella regione più vicina all'utente tentano di riempire i backend in proporzione alle loro capacità target configurate (modificate dai relativi fattori di scalabilità della capacità).

Ogni singolo GFE di secondo livello preferisce selezionare istanze o endpoint di backend in una zona il più vicina possibile (definita dal tempo di percorrenza della rete) al GFE di secondo livello. Poiché WATERFALL_BY_REGION riduce al minimo la latenza tra le zone, a tassi di richiesta ridotti, ogni GFE di secondo livello potrebbe inviare esclusivamente richieste ai backend nella zona preferita del GFE di secondo livello.

Se tutti i backend nella regione più vicina funzionano al limite della capacità configurata, il traffico inizierà a essere trasferito alla regione più vicina, ottimizzando al contempo la latenza della rete.

Spray a regione

L'algoritmo SPRAY_TO_REGION modifica il comportamento individuale di ogni GFE di secondo livello nella misura in cui ogni GFE di secondo livello non ha preferenze per la selezione di istanze o endpoint di backend che si trovano in una zona il più vicino possibile al GFE di secondo livello. Con SPRAY_TO_REGION, ogni servizio GFE di secondo livello invia richieste a tutte le istanze o gli endpoint di backend, in tutte le zone della regione, senza preferire un tempo di round trip più breve tra il servizio GFE di secondo livello e le istanze o gli endpoint di backend.

Come WATERFALL_BY_REGION, in aggregato, tutti i GFE di secondo livello nella regione compilano i backend in proporzione alle loro capacità target configurate (modificate dai loro scalari di capacità).

Sebbene SPRAY_TO_REGION fornisca una distribuzione più uniforme tra i backend in tutte le zone di una regione, in particolare a tassi di richiesta ridotti, questa distribuzione uniforme comporta le seguenti considerazioni:

• Quando i backend non sono disponibili (ma continuano a superare i controlli di integrità), sono interessati più GFEs di secondo livello, anche se l'impatto individuale è meno grave.
• Poiché ogni GFE di secondo livello non ha preferenze per una zona rispetto a un'altra, i GFE di secondo livello creano più traffico tra zone. A seconda del numero di richieste in fase di elaborazione, ogni GFE di secondo livello potrebbe creare anche più connessioni TCP ai backend.

A cascata per zona

L'algoritmo WATERFALL_BY_ZONE modifica il comportamento individuale di ogni GFE di secondo livello nella misura in cui ogni GFE di secondo livello ha una preferenza molto forte per selezionare istanze o endpoint di backend che si trovano nella zona più vicina possibile al GFE di secondo livello. Con WATERFALL_BY_ZONE, ogni GFE di secondo livello solo invia richieste a istanze o endpoint di backend in altre zone della regione quando il GFE di secondo livello ha riempito (o ha riempito in modo proporzionale) le istanze o gli endpoint di backend nella sua zona più favorita.

Come WATERFALL_BY_REGION, in aggregato, tutti i GFE di secondo livello nella regione compilano i backend in proporzione alle loro capacità target configurate (modificate dai loro scalari di capacità).

L'algoritmo WATERFALL_BY_ZONE riduce al minimo la latenza tenendo conto dei seguenti aspetti:

• WATERFALL_BY_ZONE non riduce intrinsecamente al minimo le connessioni tra zone. L'algoritmo è guidato solo dalla latenza.
• WATERFALL_BY_ZONE non garantisce che ogni GFE di secondo livello sempre compili la sua zona più favorita prima di compilare altre zone. Gli eventi di manutenzione possono temporaneamente causare l'invio di tutto il traffico da un GFE di secondo livello a istanze o endpoint di backend in un'altra zona.
• WATERFALL_BY_ZONE può comportare una distribuzione meno uniforme delle richieste tra tutte le istanze o gli endpoint di backend all'interno della regione nel suo complesso. Ad esempio, gli endpoint o le istanze di backend nella zona più favorita del GFE di secondo livello potrebbero essere esauriti, mentre i backend in altre zone non lo sono.

Confrontare gli algoritmi di bilanciamento del carico

La seguente tabella confronta i diversi algoritmi di bilanciamento del carico.

Scarico e svuotamento automatico della capacità

Lo scarico e il reintegro automatico della capacità combinano i concetti di controlli di integrità e capacità di backend. Con lo svuotamento della capacità automatica, i controlli di integrità vengono utilizzati come un segnale aggiuntivo per impostare la capacità effettiva del backend su zero. Con lo svuotamento automatico della capacità, i controlli di integrità vengono utilizzati come indicatore aggiuntivo per ripristinare la capacità effettiva del backend al suo valore precedente.

Senza lo svuotamento e il riempimento automatico della capacità, se vuoi indirizzare le richieste lontano da tutti i backend di una determinata regione, devi impostare manualmente su zero la capacità effettiva di ciascun backend in quella regione. Ad esempio, puoi utilizzare lo scalatore della capacità per farlo.

Con lo svuotamento e il reintegro automatico della capacità, i controlli di integrità possono essere utilizzati come indicatore per regolare la capacità di un backend, tramite lo svuotamento o il reintegro.

Per attivare lo svuotamento e il ripristino della capacità automatici, consulta Configurare una policy di bilanciamento del carico del servizio.

Scarico automatico della capacità

Il ritiro automatico della capacità imposta su zero la capacità di ogni gruppo di istanze o NEG di backend candidato per il ritiro, purché il rapporto tra gruppi di istanze o NEG di backend candidato per il ritiro e tutti i gruppi di istanze o NEG di backend sia inferiore al 50%. Quando si calcola il rapporto del 50%, i backend con capacità zero non sono inclusi nel numeratore. Tuttavia, tutti i backend sono inclusi nel denominatore.

Un backend candidato per il drenaggio è un gruppo di istanza di backend o un NEG con meno del 25% delle istanze o degli endpoint membri che superano i controlli di integrità del bilanciatore del carico.

I backend con capacità zero sono i seguenti:

• Gruppi di istanze di backend senza istanze membro, in cui la capacità del gruppo di istanze è definita in base a ogni istanza
• NEG di backend senza endpoint membri, in cui la capacità del NEG è definita su base endpoint
• Gruppi di istanze di backend o NEG di cui hai impostato su zero gli scalari della capacità

La capacità del backend scaricata automaticamente è funzionalmente equivalente all'impostazione manuale di backendService.backends[].capacityScaler su 0 per un backend, ma senza impostare il valore dello scalare della capacità.

Scarico automatico della capacità

Lo svuotamento automatico della capacità restituisce la capacità di un backend al valore controllato dallo scalare della capacità del backend quando il 35% o più delle istanze o degli endpoint del backend superano i controlli di integrità per almeno 60 secondi. Il requisito di 60 secondi riduce le probabilità di svuotamento e svuotamento sequenziale quando i controlli di integrità non superano e superano in rapida successione.

Soglia di failover

Il bilanciatore del carico determina la distribuzione del traffico tra i backend in modo multilivello. In stato stazionario, invia il traffico ai backend selezionati in base a uno degli algoritmi di bilanciamento del carico descritti in precedenza. Questi backend, chiamati backend principali, sono considerati ottimali in termini di latenza e capacità.

Il bilanciatore del carico tiene traccia anche di altri backend che possono essere utilizzati se i backend principali non sono più disponibili e non sono in grado di gestire il traffico. Questi backend sono chiamati backend di failover. Questi backend sono in genere quelli vicini con capacità rimanente.

Se le istanze o gli endpoint nel backend principale non sono più disponibili, il bilanciamento del carico non trasferisce immediatamente il traffico ad altri backend. Il bilanciatore del carico, invece, sposta prima il traffico su altre istanze o endpoint integri nello stesso backend per contribuire a stabilizzare il carico del traffico. Se troppi endpoint in un backend primario non sono operativi e gli endpoint rimanenti nello stesso backend non sono in grado di gestire il traffico aggiuntivo, il bilanciatore del carico utilizza la soglia di failover per determinare quando iniziare a inviare traffico a un backend di failover. Il bilanciatore del carico tollera lo stato non corretto nel backend principale fino alla soglia di failover. Dopodiché, il traffico viene spostato dal backend principale.

La soglia di failover è un valore compreso tra 1 e 99, espresso come percentuale di endpoint in un backend che devono essere integri. Se la percentuale di endpoint integri scende al di sotto della soglia di failover, il bilanciatore del carico tenta di inviare il traffico a un backend di failover. Per impostazione predefinita, la soglia di failover è 70.

Se la soglia di failover è impostata su un valore troppo elevato, possono verificarsi fuoriuscite di traffico non necessarie a causa di variazioni temporanee dell'integrità. Se la soglia di failover è impostata troppo bassa, il bilanciatore del carico continua a inviare traffico ai backend principali anche se sono presenti molti endpoint non integri.

Le decisioni di failover sono localizzate. Ogni Google Front End (GFE) (GFE) locale si comporta indipendentemente dall'altro. È tua responsabilità assicurarti che i backend di failover possano gestire il traffico aggiuntivo.

Il traffico di failover può causare il sovraccarico dei backend. Anche se un backend non è in stato attivo, il bilanciatore del carico potrebbe comunque inviarvi traffico. Per escludere i backend non funzionanti dal pool di backend disponibili, attiva la funzionalità di scarico rapido automatico della capacità.

Isolamento del traffico

Per impostazione predefinita, Cloud Load Balancing utilizza l'algoritmo WATERFALL_BY_REGION per decidere dove deve essere instradato il traffico degli utenti. Con WATERFALL_BY_REGION, il traffico viene trasferito ad altre regioni quando i backend nella regione più vicina all' utente sono pieni o non integri. L'attivazione dell'isolamento del traffico consente al bilanciatore del carico di instradare il traffico solo alla regione più vicina all'utente, anche se tutti i backend in quella regione funzionano al limite di capacità configurato. L'attivazione dell'isolamento del traffico può aiutarti a evitare errori regionali a cascata e limitare le potenziali interruzioni a una singola regione.

L'isolamento del traffico è configurato come parte del criterio di bilanciamento del carico del servizio. Sono disponibili due modalità di isolamento:

• NEAREST (valore predefinito), in cui il bilanciatore del carico (ovvero il GFE di secondo livello o il proxy Envoy che gestisce la connessione) invia il traffico ai backend nella regione più vicina all'utente. Se non sono configurati backend nella regione più vicina o se i backend nella regione più vicina non sono integri, il traffico viene indirizzato alla regione più vicina ottimizzando la latenza della rete. Questo continua finché la capacità di pubblicazione di ogni regione non si esaurisce.

  La modalità di isolamento NEAREST è disponibile per tutti i balanceri di carico supportati.

• STRICT, in cui il bilanciatore del carico (ovvero il proxy Envoy che gestisce la connessione) invia il traffico solo ai backend nella regione più vicina all'utente. Se non sono configurati backend nella regione più vicina o se i backend nella regione più vicina non sono integri e non possono gestire le richieste, il traffico viene abbandonato e le richieste iniziano a non andare a buon fine.

  La modalità di isolamento STRICT è disponibile solo per i bilanciatori del carico delle applicazioni interni tra regioni e per i bilanciatori del carico di rete proxy interni tra regioni.

Nessun isolamento

Il seguente diagramma mostra il comportamento dei bilanciatori del carico tra regioni quando l'isolamento del traffico non è abilitato.

Il più vicino

Il seguente diagramma mostra il comportamento dei bilanciatori del carico tra regioni quando l'isolamento del traffico è abilitato con la modalità NEAREST.

Restrittiva

Il seguente diagramma mostra il comportamento dei bilanciatori del carico tra regioni quando l'isolamento del traffico è abilitato con la modalità STRICT.

Tieni presente le seguenti considerazioni prima di attivare questa funzionalità:

• Se i backend in una regione sono sovraccaricati, il bilanciatore del carico potrebbe comunque inviare loro traffico aggiuntivo anche se i backend in altre regioni possono gestirlo. Ciò significa che i backend in ogni singola regione hanno maggiori probabilità di subire un sovraccarico a causa del traffico aggiuntivo e devi pianificare di conseguenza.

• Anche con l'isolamento abilitato, il traffico viene comunque indirizzato da un control plane globale. Ciò significa che esiste ancora la possibilità di errori globali in più regioni. Per un isolamento migliore a livello di infrastruttura, scegli un bilanciatore del carico regionale.

Quando configuri la modalità di isolamento del traffico, devi anche impostare la granularità dell'isolamento su REGION, che impedisce il sovraccarico del traffico tra regioni. Se la granularità non è configurata, l'isolamento del traffico non verrà applicato. Per maggiori dettagli su come attivare l'isolamento del traffico, consulta Configurare una policy di bilanciamento del carico del servizio.

Backend preferiti

I backend preferiti sono quelli di cui vuoi usare completamente la capacità prima di trasferire il traffico ad altri backend. Qualsiasi traffico superiore alla capacità configurata dei backend preferiti viene indirizzato ai backend non preferiti rimanenti. L'algoritmo di bilanciamento del carico distribuisce quindi il traffico tra i backend non preferiti di un servizio di backend.

Puoi configurare il bilanciatore del carico in modo che preferisca e utilizzi completamente uno o più backend collegati a un servizio di backend prima di inoltrare le richieste successive ai backend rimanenti.

Tieni presenti le seguenti limitazioni quando utilizzi i backend preferiti:

• I backend configurati come preferiti potrebbero essere più lontani dai client e comportare una latenza media più elevata per le richieste dei client. Questo accade anche se sono presenti altri backend più vicini che potrebbero aver servito i client con una latenza inferiore.
• Alcuni algoritmi di bilanciamento del carico (WATERFALL_BY_REGION, SPRAY_TO_REGION e WATERFALL_BY_ZONE) non si applicano ai backend configurati come preferiti.

Per scoprire come impostare i backend preferiti, consulta Impostare i backend preferiti.

Configura una policy di bilanciamento del carico del servizio

La risorsa criterio di bilanciamento del carico del servizio consente di configurare i seguenti campi:

• Algoritmo di bilanciamento del carico
• Scarico automatico della capacità
• Soglia di failover
• Isolamento del traffico

Per impostare un backend preferito, consulta la sezione Impostare i backend preferiti.

Crea un criterio

Per creare e configurare una policy di bilanciamento del carico del servizio, segui questi passaggi.

Disattivare le funzionalità configurate nel criterio

Questa sezione spiega come reimpostare o disattivare le funzionalità configurate nel criterio di bilanciamento del carico del servizio.

Reimpostare l'algoritmo di bilanciamento del carico

Per reimpostare l'algoritmo di bilanciamento del carico, utilizza il seguente comando per impostare nuovamente l'algoritmo predefinito WATERFALL_BY_REGION:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Reimpostare la soglia di failover

Per reimpostare la soglia di failover, utilizza il seguente comando per ripristinare la soglia predefinita di 70 secondi:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Disattivare lo scarico automatico della capacità

Per disattivare lo svuotamento della capacità automatica, utilizza il seguente comando:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Disattivare l'isolamento del traffico

Per disattivare l'isolamento del traffico (Anteprima), imposta entrambi i parametri di configurazione dell'isolamento su UNSPECIFIED, come mostrato nel seguente comando:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=global

Rimuovere una norma

Per rimuovere una policy di bilanciamento del carico del servizio da un servizio di backend, utilizza il seguente comando:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Imposta i backend preferiti

Puoi configurare i backend preferiti utilizzando Google Cloud CLI o l'API.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Risoluzione dei problemi

I pattern di distribuzione del traffico possono cambiare quando colleghi una nuova policy di bilanciamento del carico del servizio a un servizio di backend.

Per eseguire il debug dei problemi di traffico, utilizza Cloud Monitoring per esaminare il flusso di traffico tra il bilanciatore del carico e il backend. Anche i log e le metriche di Cloud Load Balancing possono aiutarti a comprendere il comportamento del bilanciamento del carico.

Questa sezione riassume alcuni scenari comuni che potresti riscontrare quando attivi ciascuna di queste funzionalità.

Algoritmi di bilanciamento del carico

Il traffico da una singola sorgente viene inviato a troppi backend distinti

Questo è il comportamento previsto dell'algoritmo SPRAY_TO_REGION. Tuttavia, potresti riscontrare problemi causati da una distribuzione più ampia del traffico. Ad esempio, i tassi di successo della cache potrebbero diminuire perché i backend rilevano il traffico da una selezione più ampia di client. In questo caso, ti consigliamo di utilizzare altri algoritmi come WATERFALL_BY_REGION.

Scarico automatico della capacità

Il traffico non viene inviato ai backend con molti endpoint non integri

Questo è il comportamento previsto quando autoCapacityDrain è attivato. I backend con molti endpoint non integri vengono drenati e rimossi dal pool di bilanciamento del carico. Se non vuoi che questo accada, puoi disattivare lo svuotamento della capacità automatica. Tuttavia, ciò significa che il traffico può essere inviato a backend con molti endpoint non integri e le richieste possono non riuscire.

Soglia di failover

Il traffico viene inviato a un backend remoto durante le modifiche temporanee dello stato

Questo è il comportamento previsto quando la soglia di failover è impostata su un valore elevato. Se vuoi che il traffico continui a essere inviato ai backend principali quando si verificano variazioni transitorie dell'integrità, imposta questo campo su un valore inferiore.

Gli endpoint integri sono sovraccaricati quando altri endpoint non sono integri

Questo è il comportamento previsto quando la soglia di failover è impostata su un valore basso. Quando gli endpoint non sono integri, il traffico destinato a questi endpoint viene distribuito tra gli endpoint rimanenti nello stesso backend. Se vuoi che il comportamento di failover venga attivato prima, imposta questo campo su un valore più alto.

Backend preferiti

Il traffico viene inviato a backend più lontani prima di quelli più vicini

Questo è il comportamento previsto se i backend preferiti sono più lontani rispetto ai backend predefiniti. Se non vuoi questo comportamento, aggiorna di conseguenza le impostazioni di preferenza per ogni backend.

Il traffico non viene inviato ad alcuni backend quando vengono utilizzati i backend preferiti

Questo è il comportamento previsto quando i backend preferiti non hanno ancora raggiunto la capacità. I backend preferiti vengono assegnati per primi in base alla latenza tempo di round trip per questi backend.

Se vuoi che il traffico venga inviato ad altri backend, puoi procedere nel seguente modo:

• Aggiorna le impostazioni delle preferenze per gli altri backend.
• Imposta una capacità target inferiore per i backend che preferisci. La capacità di destinazione viene configurata utilizzando i campi max-rate o max-utilization, a seconda della modalità di bilanciamento del servizio di backend.

Isolamento del traffico

Le richieste inviate al bilanciatore del carico interno tra regioni non vanno a buon fine

Se la modalità di isolamento STRICT è attivata e non sono configurati backend nella stessa regione del bilanciatore del carico, il traffico dovrebbe non riuscire. Se questo non è il comportamento previsto, assicurati di avere i backend nella regione in cui prevedi che venga inviato il traffico. In alternativa, imposta la modalità di isolamento su NEAREST in modo che il traffico possa essere indirizzato alla regione più vicina.

Il traffico viene indirizzato da una regione remota a una più vicina

L'isolamento delle richieste impedisce il sovraccarico del traffico in base alla capacità. Pertanto, se i tuoi backend erano già sovraccaricati prima di attivare questa funzionalità, il traffico potrebbe essere già stato inviato a una regione remota. In questo caso, l'attivazione di questa funzionalità potrebbe causare il reindirizzamento di questo traffico alla regione più vicina.

Il traffico non è stato reindirizzato dopo l'attivazione dell'isolamento del traffico

L'isolamento delle richieste impedisce il sovraccarico del traffico in base alla capacità. Pertanto, se i tuoi backend nella regione più vicina non erano sovraccaricati prima di attivare questa funzionalità, è probabile che la regione più vicina sia in grado di gestire tutto il traffico. In questo caso, non dovresti notare alcuna variazione dei percorsi di traffico nel breve termine. Questo valore potrebbe cambiare in base al volume di traffico.

Il traffico si sposta quando i backend vengono aggiunti o rimossi da una regione

Si tratta di un comportamento previsto, in quanto i bilanciatori del carico tentano di indirizzare il traffico per ottimizzare la latenza complessiva della rete. Pertanto, quando vengono implementati nuovi backend in una regione più vicina, il bilanciatore del carico potrebbe inviare più traffico a quella regione. Analogamente, quando i backend vengono rimossi, a seconda dell'impostazione di isolamento delle richieste, il bilanciatore del carico inizia a inviare il traffico in eccesso a una regione più lontana.

Limitazioni

• Ogni servizio di backend può essere associato a una sola risorsa del criterio di bilanciamento del carico del servizio.