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 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 tra due o più versioni all'interno di un servizio. La suddivisione del traffico ti consente di eseguire test A/B tra le tue versioni e di avere il controllo sul ritmo durante l'implementazione delle funzionalità.

La suddivisione del traffico viene applicata agli URL che non hanno come target esplicito 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 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, vedi Modalità di routing delle richieste.

Prima di iniziare

Prima di poter configurare il traffico a 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, è consigliabile prendere in considerazione potenziali problemi di memorizzazione nella cache. Possono sussistere problemi di memorizzazione nella cache per qualsiasi app App Engine, soprattutto durante il deployment di una nuova versione. La suddivisione del traffico spesso rende più evidenti problemi di memorizzazione nella cache.

Ad esempio, supponiamo che tu stia dividendo il traffico tra due versioni, A e B, e che alcune risorse esterne memorizzabili nella cache siano cambiate tra le versioni, ad esempio un file CSS. Ora supponiamo che un client effettui una richiesta e 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 Scadenza. Queste intestazioni indicano ai proxy che la risorsa è dinamica. È preferibile impostare entrambe le intestazioni, poiché non tutti i server proxy supportano correttamente l'intestazione Cache-Control HTTP/1.1.

    Per ulteriori informazioni sulla memorizzazione nella cache in generale, consulta Campi intestazione nella RFC HTTP/1.1 e Panoramica sulla memorizzazione nella cache HTTP in Web Fundamentals.

  • Per le risorse statiche memorizzabili nella cache che variano tra le versioni, 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 fare in modo che l'app imposti l'intestazione Vary: Cookie in modo che l'unicità di una risorsa venga calcolata combinando i cookie e l'URL della richiesta. Tuttavia, questo approccio aumenta il carico sui server della cache. Esistono 1000 valori possibili di GOOGAPPUID e quindi 1000 voci possibili per ogni URL per la tua app. A seconda del carico sui proxy tra gli utenti e la tua 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 vedere 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 utilizza i cookie per altri scopi, devi considerare come questo influisca sul carico sui server proxy. Se codeninja disponesse di un proprio cookie con 100 valori possibili, lo spazio di tutte le voci di cache possibili diventa un numero molto grande (100 * 1000 = 100.000). Nel peggiore dei casi, esiste un cookie univoco per ogni utente. Due esempi comuni di questo tipo sono Google Analytics (__utma) e SiteCatalyst (s_vi). In questi casi, ogni utente riceve una copia univoca, il che influisce notevolmente sulle prestazioni della cache e può anche aumentare le ore di istanza fatturabili utilizzate dalla tua app.

Suddividere il traffico in più versioni

Dopo aver 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 ulteriori informazioni, consulta Suddivisione dell'indirizzo IP e Suddivisione dei cookie.

Console

Per suddividere il traffico nella console Google Cloud, vai alla pagina Versioni:

Vai alla pagina Versioni

  1. Seleziona una o più versioni in cui vuoi suddividere il traffico.
  2. Fai clic su Suddividi traffico e specifica:
    • Il metodo da utilizzare per suddividere il 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 su gcloud app services set-traffic.

API

Per eseguire la migrazione del traffico in modo programmatico, puoi utilizzare l'API Admin. Per maggiori dettagli, consulta Migrazione e suddivisione del traffico.

Suddivisione degli indirizzi IP

Se scegli di suddividere il traffico verso l'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 quel numero per instradare la richiesta.

La suddivisione degli indirizzi IP presenta alcune limitazioni significative:

  • Gli indirizzi IP dei mittenti sono ragionevolmente fissi, ma non sono permanenti. Gli utenti che si connettono dai cellulari potrebbero avere uno spostamento dell'indirizzo IP nel corso di una singola sessione. Analogamente, un utente che usa un laptop potrebbe passare da casa a un bar al lavoro e anche cambiare indirizzo IP. Di conseguenza, l'esperienza dell'utente potrebbe non essere coerente 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 quanto specificato. Tuttavia, man mano che l'applicazione riceve più traffico, la suddivisione effettiva si avvicina al tuo target. Ad esempio, se richiedi che il 5% del traffico venga consegnato a una versione alternativa, la percentuale iniziale di traffico verso la versione potrebbe essere effettivamente compresa tra il 3 e il 7%, ma alla fine la media si avvicina al 5% target.
  • Se devi inviare richieste interne tra app, utilizza la suddivisione dei cookie. Le richieste inviate tra le app in esecuzione nell'infrastruttura cloud di Google provengono da un numero ridotto di indirizzi IP che probabilmente sono tutti assegnati alla stessa versione. Pertanto, tutte le richieste interne potrebbero comportarsi in modo simile alle richieste inviate da un singolo indirizzo IP, ovvero vengono tutte instradate alla stessa versione. Di conseguenza, le richieste interne non rispettano strettamente le percentuali che imposti 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 Google Cloud sono stati assegnati casualmente 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 funzioneranno come previsto poiché 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.
  • In assenza di questo cookie, 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'utilizzo dei cookie per suddividere il traffico semplifica l'assegnazione precisa degli utenti alle versioni. La precisione per il routing del traffico può arrivare fino allo 0,1% della suddivisione target. Tuttavia, la suddivisione dei cookie presenta le seguenti limitazioni:

  • Se scrivi un'app mobile o esegui un client desktop, quest'ultimo deve gestire i cookie di GOOGAPPUID. Ad esempio, quando viene utilizzata un'intestazione della risposta Set-Cookie, devi archiviare il cookie e includerlo in ogni richiesta successiva. Le app basate sul browser gestiscono già automaticamente i cookie in questo modo.

  • La suddivisione delle richieste interne richiede un lavoro aggiuntivo. Per tutte le richieste degli utenti inviate dall'interno dell'infrastruttura cloud di Google, è necessario inoltrare il 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 queste non provengono da un utente.

Disabilitazione della suddivisione del traffico

Per disabilitare la suddivisione del traffico, esegui la migrazione di tutto il traffico a un'unica versione.