Suddivisione del traffico

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere simili ai codici di 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 area geografica è facoltativo nell'URL.

Scopri di più sugli ID dell'area geografica.

Puoi utilizzare la suddivisione del traffico per specificare una distribuzione percentuale del traffico su due o più versioni di un servizio. La suddivisione del traffico consente di eseguire test A/B tra le versioni e offre il controllo sull'andatura durante l'implementazione delle funzionalità.

La suddivisione del traffico viene applicata agli URL che non scelgono esplicitamente come target 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: consente di distribuire il traffico alle versioni del servizio default.
  • 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 la pagina Modalità di routing delle richieste.

Prima di iniziare

Prima di poter configurare il traffico di una versione, assicurati che il tuo account utente includa i privilegi necessari.

Evitare problemi di memorizzazione nella cache

Prima di attivare la suddivisione del traffico, potresti prendere in considerazione eventuali problemi di memorizzazione nella cache. Possono verificarsi problemi di memorizzazione nella cache per qualsiasi applicazione App Engine, in particolare durante il deployment di una nuova versione. La suddivisione del traffico spesso rende più evidenti i problemi di memorizzazione nella cache.

Ad esempio, supponiamo che tu stia dividendo il traffico tra due versioni, A e B e che una risorsa memorizzabile nella cache sia cambiata tra le versioni, ad esempio un file CSS. Ora supponiamo che un client effettui una richiesta e che la risposta contenga un riferimento esterno al file memorizzato nella cache. La cache HTTP locale recupera il file se si trova nella cache, a prescindere dalla versione del file memorizzata nella cache e dalla versione dell'applicazione che ha inviato la risposta. La risorsa memorizzata nella cache potrebbe non essere compatibile con i dati inviati nella risposta.

Per evitare problemi di memorizzazione nella cache:

  • Per le risorse dinamiche, imposta entrambe le intestazioni Cache-Control e Expiration. 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.1Cache-Control.

    Per ulteriori informazioni sulla memorizzazione nella cache in generale, consulta Campi dell'intestazione nella configurazione RFC HTTP/1.1 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 pubblicate da URL diversi, entrambe le versioni possono coesistere nei server proxy e nelle cache del browser.

Puoi anche impostare l'intestazione dell'app Vary: Cookie in modo che venga calcolata l'unicità di una risorsa combinando i cookie e l'URL della richiesta. Tuttavia, questo approccio aumenta il carico sui server di cache. Ci sono 1000 valori possibili di GOOGAPPUID, quindi 1000 voci possibili per ogni URL per la tua app. A seconda del carico sui proxy tra gli utenti e la tua app, ciò può ridurre la frequenza con cui la tua app pubblica un risultato memorizzato nella cache. Inoltre, per le 24 ore successive all'aggiunta di un nuovo batch di utenti a una versione, tali utenti potrebbero comunque visualizzare le risorse memorizzate nella cache. Tuttavia, l'utilizzo di Vary: Cookie semplifica la ridenominazione delle risorse statiche che cambiano tra le versioni.

La tecnica Vary: Cookie non funziona in tutte le circostanze. In generale, se la tua app usa i cookie per altri scopi, devi considerare in che modo ciò influisce sul carico sui server proxy. Se codeninja aveva un proprio cookie con 100 valori possibili, lo spazio di tutte le voci della cache possibili diventa un numero molto elevato (100 * 1000 = 100.000). Nel peggiore dei casi, esiste un cookie unico per ciascun utente. Due esempi comuni sono Google Analytics (__utma) e SiteCatalyst (s_vi). In questi casi, ogni utente riceve una copia univoca, che riduce notevolmente le prestazioni della cache e può anche comportare un aumento delle ore fatturabili utilizzate dall'app.

Suddivisione del traffico tra più versioni

Quando hai specificato due o più versioni per la suddivisione, devi scegliere se dividere il traffico utilizzando un indirizzo IP o un cookie HTTP. È più facile impostare una suddivisione degli indirizzi IP, ma la suddivisione dei cookie è più precisa. Per ulteriori informazioni, consulta l'articolo Suddivisione degli indirizzi IP e Suddivisione dei cookie.

Console

Per suddividere il traffico in Cloud Console, vai alla pagina Versioni:

Vai alla pagina Versioni

  1. Seleziona una o più versioni a cui vuoi suddividere il traffico.
  2. Fai clic su Suddividi traffico, quindi specifica:
    • Il metodo che vuoi utilizzare per la suddivisione del traffico.
    • La percentuale di traffico che ogni versione dovrebbe ricevere.

gcloud

Dopo aver installato l'interfaccia a riga di comando di Google Cloud, esegui il comando seguente per suddividere il traffico tra 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 maggiori dettagli e opzioni aggiuntive, consulta la guida di gcloud app services set-traffic.

API

Per eseguire la migrazione del traffico a livello di programmazione, puoi utilizzare l'API Admin, vedi Migrazione e suddivisione del traffico per maggiori dettagli.

Suddivisione indirizzi IP

Se scegli di suddividere il traffico verso la tua applicazione per indirizzo IP, quando l'applicazione riceve una richiesta, esegue l'hashing dell'indirizzo IP a un valore compreso tra 0 e 999 e utilizza tale numero per instradare la richiesta.

La suddivisione degli indirizzi IP presenta alcune limitazioni significative:

  • Gli indirizzi IP sono ragionevolmente fissi, ma non permanenti. Gli utenti che si connettono da telefoni cellulari potrebbero avere un indirizzo IP mobile durante una singola sessione. Analogamente, un utente che utilizza un laptop potrebbe trasferirsi da casa a un bar al lavoro e potrebbe 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 in modo indipendente alle versioni, la suddivisione del traffico risultante sarà in qualche modo diversa da quanto specificato. Sebbene la tua applicazione riceva più traffico, più la suddivisione effettiva si avvicina al tuo target. Ad esempio, se richiedi che il 5% del traffico venga recapitato a una versione alternativa, la percentuale iniziale di traffico verso la versione potrebbe in realtà essere compresa tra il 3 e il 7%, ma in media si avvicina al 5% target.
  • Se hai bisogno di inviare richieste interne tra un'app e l'altra, devi utilizzare la suddivisione dei cookie. Le richieste inviate tra le app in esecuzione sull'infrastruttura cloud di Google provengono da un numero limitato di indirizzi IP, che potrebbero essere tutti assegnati alla stessa versione. Di conseguenza, tutte le richieste interne potrebbero comportarsi in modo simile alle richieste inviate da un singolo indirizzo IP, il che significa che tutte le richieste vengono instradate alla stessa versione. Di conseguenza, le richieste interne non rispettano esattamente le percentuali impostate per le suddivisioni del traffico basate su IP. Ad esempio, se imposti una versione per ricevere l'1% di tutto il traffico verso la tua app e gli indirizzi dell'infrastruttura cloud di Google sono stati assegnati in modo casuale a tale versione, il risultato effettivo potrebbe superare considerevolmente 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 funzioneranno come previsto in quanto provengono da una distribuzione diversa di indirizzi IP.

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 indirizzare 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 che venga inviato.

L'uso dei cookie per suddividere il traffico semplifica l'assegnazione accurata agli utenti delle versioni. La precisione per il routing del traffico può raggiungere lo 0,1% fino alla suddivisione target. Tuttavia, la suddivisione dei cookie presenta le seguenti limitazioni:

  • Se stai scrivendo un'app per dispositivi mobili o un client desktop, devi gestire i cookie GOOGAPPUID. Ad esempio, quando viene utilizzata un'intestazione della risposta Set-Cookie, devi memorizzare il cookie e includerlo a ogni richiesta successiva. Le app basate su browser gestiscono già automaticamente i cookie.

  • La suddivisione delle richieste interne richiede interventi aggiuntivi. Tutte le richieste degli utenti inviate dall'infrastruttura cloud di Google richiedono l'inoltro del cookie dell'utente a ciascuna richiesta. Ad esempio, devi inoltrare il cookie dell'utente nelle richieste inviate dalla tua app a un'altra app o a se stesso. Tieni presente che non è consigliabile inviare richieste interne se tali richieste non provengono da un utente.

Disattivazione della suddivisione del traffico

Per disabilitare la suddivisione del traffico, devi eseguire la migrazione di tutto il traffico a una singola versione.