Suddivisione del traffico

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID area geografica potrebbero sembrare simili ai codici paese e provincia più utilizzati. 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 versioni e fornisce il controllo del pacing 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 nelle versioni del servizio default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com: distribuisce il traffico nelle versioni del servizio [SERVICE_ID].

Per informazioni sul modo in cui le richieste raggiungono una versione, vedi Come vengono instradate le richieste.

Prima di iniziare

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

Evitare problemi di memorizzazione nella cache

Prima di attivare la suddivisione del traffico, può essere opportuno tenere conto di potenziali problemi di memorizzazione nella cache. Possono verificarsi problemi di memorizzazione nella cache per qualsiasi app di App Engine, soprattutto durante il deployment di una nuova versione. La suddivisione del traffico spesso rende più evidenti i problemi di memorizzazione nella cache.

Supponi ad esempio di suddividere il traffico tra due versioni, A e B, e di una risorsa memorizzabile all'esterno modificata tra le versioni, 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 è 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 non essere compatibile con i dati inviati nella risposta.

Per evitare problemi di memorizzazione nella cache:

  • Per le risorse dinamiche, imposta le intestazioni Cache-Control e Expiration. Queste intestazioni indicano ai proxy che la risorsa è dinamica. È meglio impostare entrambe le intestazioni, poiché non tutti i server proxy supportano correttamente l'intestazione HTTP/1.1Cache-Control.

    Per maggiori informazioni sulla memorizzazione nella cache in generale, consulta Campi dell'intestazione nella specifica HTTP/1.1 e Panoramica della memorizzazione nella cache HTTP in Web Fundamentals.

  • Per le risorse statiche memorizzabili nella cache che variano tra le versioni, cambia l'URL della risorsa tra le versioni. Se le risorse statiche vengono pubblicate da URL diversi, entrambe le versioni possono coesistere senza problemi nei server proxy e nelle cache dei 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 della richiesta. Tuttavia, questo approccio aumenta il carico sui server di cache. Esistono 1000 valori possibili di GOOGAPPUID, quindi 1000 possibili voci per ogni URL per la tua app. A seconda del carico dei proxy tra gli utenti e l'app, può diminuire la frequenza con cui l'app pubblica un risultato memorizzato nella cache. Inoltre, per le 24 ore successive all'aggiunta di un nuovo gruppo di utenti a una versione, questi utenti potrebbero comunque vedere le risorse memorizzate nella cache. L'utilizzo di Vary: Cookie, tuttavia, può semplificare la ridenominazione delle risorse statiche che cambiano durante l'esecuzione.

La tecnica Vary: Cookie non funziona in tutte le circostanze. In generale, se l'app utilizza cookie per altri scopi, è necessario considerare l'impatto di questa situazione sui server proxy. Se codeninja aveva il proprio cookie che aveva 100 valori possibili, lo spazio di tutte le possibili voci della cache diventerà un numero molto alto (100 * 1000 = 100.000). Nel peggiore dei casi, esiste un cookie unico per ogni utente. Due esempi comuni di questo problema sono Google Analytics (__utma) e SiteCatalyst (s_vi). In questi casi, ogni utente riceve una copia unica, che riduce gravemente le prestazioni della cache e può anche aumentare le ore di fatturazione fatturabili utilizzate dalla tua app.

Suddivisione del traffico in più versioni

Quando hai specificato due o più versioni per la suddivisione, devi scegliere se suddividere il traffico utilizzando un indirizzo IP o un cookie HTTP. È più facile impostare una suddivisione dell'indirizzo IP, ma una 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 Google Cloud Console, vai alla pagina Versioni:

Vai alla pagina Versioni

  1. Seleziona una o più versioni in base alle quali 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 il seguente 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 maggiori dettagli e opzioni, vedi il riferimento gcloud app services set-traffic.

Server

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

Suddivisione degli indirizzi IP

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

La suddivisione degli indirizzi IP presenta alcune limitazioni significative:

  • Gli indirizzi IP sono ragionevolmente permanenti, ma non sono permanenti. Gli utenti che si connettono dai telefoni cellulari potrebbero avere un indirizzo IP in movimento in una singola sessione. Analogamente, un utente su un laptop potrebbe passare da casa a un caffè al lavoro e gli indirizzi IP. Di conseguenza, l'utente potrebbe riscontrare un'esperienza incoerente con la tua app quando il suo indirizzo IP cambia.
  • Poiché gli indirizzi IP vengono assegnati in modo indipendente alle versioni, 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 viene raggiunta per il target. Ad esempio, se chiedi 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 sarà più vicina al 5% target.
  • Se hai bisogno di inviare richieste interne tra le app, utilizza la suddivisione cookie. Le richieste inviate tra le app in esecuzione sull'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 alle richieste inviate da un singolo indirizzo IP, il che significa che tutte queste richieste vengono instradate alla stessa versione. Di conseguenza, le richieste interne non rispettano da vicino le percentuali impostate per le suddivisioni del traffico basate sugli 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 in modo coerente a questa versione, il risultato effettivo potrebbe superare di gran lunga l'1% perché tutte le richieste interne vengono sempre indirizzate alla versione assegnata. Le richieste inviate alla tua app dall'esterno dell'infrastruttura cloud di Google funzioneranno come previsto poiché provengono da una distribuzione variegata di indirizzi IP.

Se scegli di suddividere il traffico della tua applicazione per 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 caso contrario, la richiesta viene instradata in modo casuale.

Se la risposta non contiene il cookie GOOGAPPUID, l'app aggiunge prima il cookie GOOGAPPUID con un valore casuale compreso tra 0 e 999 prima dell'invio.

L'utilizzo dei cookie per suddividere il traffico semplifica l'assegnazione precisa degli utenti alle versioni. La precisione del routing del traffico può raggiungere lo 0,1% rispetto alla suddivisione target. Tuttavia, la suddivisione dei cookie presenta le seguenti limitazioni:

  • Se stai scrivendo un'app per dispositivi mobili o se esegui un client desktop, è necessario gestire i cookie GOOGAPPUID. Ad esempio, quando si utilizza un'intestazione della risposta Set-Cookie, è necessario memorizzare il cookie e includerlo a ogni richiesta successiva. Le app basate su browser gestiscono già i cookie in questo modo automaticamente.

  • La suddivisione delle richieste interne richiede lavoro aggiuntivo. Tutte le richieste utente 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 l'utente non ha avuto origine da tali richieste.

Disattivazione della suddivisione del traffico

Per disattivare la suddivisione del traffico, esegui la migrazione di tutto il traffico in una singola versione.