ID regione
REGION_ID
è un codice abbreviato che Google assegna
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare
simili ai codici paese e provincia di uso comune. Per le app create dopo
febbraio 2020, REGION_ID.r
è incluso
negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.
Scopri di più sugli ID regione.
Puoi utilizzare la suddivisione del traffico per specificare una distribuzione percentuale del traffico in due o più versioni all'interno di un servizio. La suddivisione del traffico consente di eseguire test A/B tra le versioni e di controllare la velocità durante l'implementazione delle funzionalità.
La suddivisione del traffico viene applicata agli URL che non hanno come target esplicitamente una versione. Ad esempio, i seguenti URL suddividono il traffico perché hanno come target tutte le versioni disponibili all'interno del servizio specificato:
-
https://PROJECT_ID.REGION_ID.r.appspot.com
- Distribuisce il traffico alle versioni del serviziodefault
. -
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
: distribuisce il traffico alle versioni del servizio[SERVICE_ID]
.
Per informazioni su come le richieste raggiungono una versione, consulta Come vengono instradate le richieste.
Prima di iniziare
Prima di poter configurare il traffico verso una versione, assicurati che il tuo account utente includa i privilegi necessari.
Evitare i problemi di memorizzazione nella cache
Prima di attivare la suddivisione del traffico, è opportuno prendere in considerazione potenziali problemi di memorizzazione nella cache. Possono sussistere problemi di memorizzazione nella cache per qualsiasi app di App Engine, La suddivisione del traffico spesso rende più evidenti problemi di memorizzazione nella cache.
Supponiamo, ad esempio, che tu stia dividendo il traffico tra due versioni, A e B, e che alcune risorse esterne memorizzabili nella cache siano cambiate da una versione all'altra, ad esempio un file CSS. Supponiamo ora che un client effettui una richiesta e che la risposta contenga un riferimento esterno al file memorizzato nella cache. La cache HTTP locale recupererà il file se si trova nella cache, indipendentemente dalla versione del file memorizzata nella cache e dalla versione dell'applicazione che ha inviato la risposta. La risorsa memorizzata nella cache potrebbe essere incompatibile con i dati inviati nella risposta.
Per evitare problemi di memorizzazione nella cache:
Per le risorse dinamiche, imposta entrambe le intestazioni Cache-Control e Scade. Queste intestazioni indicano ai proxy che la risorsa è dinamica. È preferibile impostare entrambe le intestazioni, poiché non tutti i server proxy supportano correttamente l'intestazione HTTP/1.1
Cache-Control
.Per maggiori informazioni sulla memorizzazione nella cache in generale, consulta Campi di intestazione in HTTP/1.1 RFC e la panoramica della memorizzazione nella cache HTTP in Web Fundamentals.
Per le risorse statiche memorizzabili nella cache che variano da una versione all'altra, modifica l'URL della risorsa tra le versioni. Se le risorse statiche vengono fornite da URL diversi, entrambe le versioni possono coesistere tranquillamente nei server proxy e nelle cache del browser.
Puoi anche fare in modo che la tua app imposti l'intestazione Vary:
Cookie
in modo che l'unicità di una risorsa venga calcolata combinando i cookie
e l'URL per la richiesta. Tuttavia, questo approccio aumenta il carico
sui server cache. Esistono 1000 valori possibili per GOOGAPPUID
, quindi 1000 voci possibili per ogni URL dell'app. A seconda del carico dei proxy tra gli utenti e l'app, la frequenza con cui l'app pubblica un risultato memorizzato nella cache può diminuire. Inoltre, per le 24 ore successive all'aggiunta di un nuovo gruppo di utenti a una versione, questi utenti potrebbero ancora visualizzare le risorse memorizzate nella cache. Tuttavia, l'utilizzo di Vary: Cookie
può semplificare la ridenominazione delle risorse statiche che cambiano da una versione all'altra.
La tecnica Vary: Cookie
non funziona in tutte le circostanze. In generale, se
la tua app usa i cookie per altri scopi, devi considerare come questo
influisce sul carico sui server proxy. Se codeninja
avesse il proprio cookie con 100 valori possibili, lo spazio di tutte le possibili voci della cache diventa un numero molto grande (100 * 1000 = 100.000). Nel peggiore dei casi, esiste un
cookie unico per ogni utente. Due esempi comuni di ciò sono Google Analytics
(__utma
) e SiteCatalyst (s_vi
). In questi casi, ogni utente riceve una copia unica, il che peggiora notevolmente le prestazioni della cache e può anche aumentare
le ore di istanza fatturabili utilizzate dalla tua app.
Suddivisione del traffico tra più versioni
Quando hai specificato due o più versioni per la suddivisione, devi scegliere se suddividere il traffico utilizzando un indirizzo IP del mittente o un cookie HTTP. È più facile impostare una suddivisione degli indirizzi IP, ma una suddivisione dei cookie è più precisa. Per maggiori informazioni, consulta Suddivisione degli indirizzi IP e Suddivisione dei cookie.
Console
Per suddividere il traffico nella console Google Cloud, vai alla pagina Versioni:
- Seleziona una o più versioni per le quali vuoi suddividere il traffico.
- Fai clic su Suddividi traffico e specifica:
- Il metodo da utilizzare per la suddivisione del traffico.
- La percentuale di traffico che ogni versione dovrebbe ricevere.
gcloud
Dopo aver installato Google Cloud CLI, esegui questo comando per suddividere il traffico in più versioni, ad esempio:
gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]
Per dettagli e opzioni aggiuntive, consulta la documentazione di riferimento di gcloud app services
set-traffic
.
API
Per eseguire la migrazione del traffico in modo programmatico, puoi utilizzare l'API Admin. Consulta Migrazione e suddivisione del traffico per i dettagli.
Suddivisione degli indirizzi IP
Se scegli di suddividere il traffico verso la tua applicazione in base all'indirizzo IP del mittente, quando l'applicazione riceve una richiesta, esegue l'hashing dell'indirizzo IP in un valore compreso tra 0 e 999 e utilizza questo numero per instradare la richiesta.
La suddivisione degli indirizzi IP presenta alcune limitazioni significative:
- Gli indirizzi IP dei mittenti sono ragionevolmente fissi, ma non permanenti. Gli utenti che si connettono da telefoni cellulari potrebbero avere un indirizzo IP variabile durante una singola sessione. Analogamente, un utente con un laptop potrebbe spostarsi da casa a un bar per andare al lavoro e passare da un indirizzo IP all'altro. Di conseguenza, l'utente potrebbe avere un'esperienza incoerente con la tua app quando cambia l'indirizzo IP.
- Poiché gli indirizzi IP vengono assegnati alle versioni in modo indipendente, la suddivisione del traffico risultante sarà leggermente diversa da quella specificata. Tuttavia, man mano che la tua applicazione riceve più traffico, più la suddivisione effettiva si avvicina al tuo target. Ad esempio, se richiedi che il 5% del traffico venga inviato a una versione alternativa, la percentuale iniziale di traffico verso la versione potrebbe in realtà essere compresa tra il 3 e il 7%, ma alla fine si avvicina alla media del 5% target.
- Per inviare richieste interne tra le app, devi utilizzare la suddivisione dei cookie. Le richieste inviate tra app in esecuzione nell'infrastruttura cloud di Google provengono da un numero limitato di indirizzi IP che probabilmente sono tutti assegnati alla stessa versione. Pertanto, tutte le richieste interne potrebbero comportarsi in modo simile a quelle inviate da un singolo indirizzo IP, il che significa che queste richieste vengono instradate tutte alla stessa versione. Di conseguenza, le richieste interne non rispettano strettamente le percentuali impostate per le suddivisioni del traffico basate su IP. Ad esempio, se imposti una versione in modo da ricevere l'1% di tutto il traffico verso la tua app e gli indirizzi dell'infrastruttura di Google Cloud sono stati assegnati in modo coincidente a quella versione, il risultato effettivo potrebbe superare di gran lunga l'1% perché tutte le richieste interne vengono sempre instradate alla versione assegnata. Le richieste inviate alla tua app dall'esterno dell'infrastruttura cloud di Google funzionano come previsto poiché provengono da una distribuzione variata di indirizzi IP.
Suddivisione dei cookie
Se scegli di suddividere il traffico verso la tua applicazione in base ai cookie,
l'applicazione cerca
nell'intestazione della richiesta HTTP
un cookie denominato GOOGAPPUID
, che contiene un valore compreso tra 0 e 999:
- Se il cookie esiste, il valore viene utilizzato per instradare la richiesta.
- Se il cookie non è presente, la richiesta viene inoltrata in modo casuale.
Se la risposta non contiene il cookie GOOGAPPUID
, l'app aggiunge
il cookie GOOGAPPUID
con un valore casuale compreso tra 0 e 999
prima di essere inviato.
L'utilizzo dei cookie per suddividere il traffico semplifica l'assegnazione accurata degli utenti alle versioni. La precisione per il routing del traffico può raggiungere fino allo 0,1% alla suddivisione del target. Tuttavia, la suddivisione dei cookie presenta le seguenti limitazioni:
Se stai scrivendo un'app mobile o eseguendo un client desktop, questo deve gestire i cookie di
GOOGAPPUID
. Ad esempio, quando viene utilizzata un'intestazione della rispostaSet-Cookie
, devi memorizzare il cookie e includerlo in ogni richiesta successiva. Le app basate su browser già gestiscono i cookie in questo modo automaticamente.La suddivisione delle richieste interne richiede lavoro aggiuntivo. Tutte le richieste degli utenti inviate dall'infrastruttura cloud di Google richiedono l'inoltro del cookie dell'utente a ogni richiesta. Ad esempio, devi inoltrare il cookie dell'utente nelle richieste inviate dalla tua app a un'altra app o a se stessa. Tieni presente che non è consigliabile inviare richieste interne se non provengono da un utente.
Disabilitazione della suddivisione del traffico
Per disattivare la suddivisione del traffico, esegui la migrazione di tutto il traffico a un'unica versione.