Suddivisione del traffico

ID regione

L'elemento REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province 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.

OK

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 di controllare la velocità di 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, consulta Modalità di routing delle richieste.

Prima di iniziare

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

Evitare problemi di memorizzazione nella cache

Prima di attivare la suddivisione del traffico, potresti voler tenere conto di potenziali problemi di memorizzazione nella cache. I problemi di memorizzazione nella cache possono esistere per qualsiasi app App Engine, soprattutto quando si esegue il deployment di una nuova versione. La suddivisione del traffico spesso rende più evidenti i problemi di memorizzazione nella cache.

Ad esempio, supponiamo di suddividere 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 che la risposta contenga un riferimento esterno al file memorizzato nella cache. La cache HTTP locale recupererà il file se è presente 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 ed Expires. Queste intestazioni indicano ai proxy che la risorsa è dinamica. È consigliabile impostare entrambe le intestazioni, poiché non tutti i server proxy supportano correttamente l'intestazione Cache-Control HTTP/1.1.

  Se vuoi maggiori informazioni sulla memorizzazione nella cache in generale, consulta i campi di intestazione nella RFC HTTP/1.1 e la panoramica della 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 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 e quindi 1000 possibili voci per ogni URL della tua app. A seconda del carico sui proxy tra gli utenti e la tua app, questo 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, questi utenti potrebbero continuare a visualizzare le risorse memorizzate nella cache. Tuttavia, l'utilizzo di Vary: Cookie può semplificare 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 utilizza i cookie per altri scopi, devi considerare l'impatto sul carico dei server proxy. Se codeninja avesse un proprio cookie con 100 valori possibili, lo spazio di tutte le possibili voci della cache diventerebbe un numero molto grande (100 * 1000 = 100.000). Nel peggiore dei casi, esiste un cookie univoco per ogni utente. Due esempi comuni sono Google Analytics (__utma) e SiteCatalyst (s_vi). In questi casi, ogni utente riceve una copia univoca, il che peggiora notevolmente le prestazioni della cache e può anche aumentare le ore di istanza fatturabili consumate dalla tua app.

Suddividere il 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 configurare 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 Google Cloud console, vai alla pagina Versioni:

Vai a Versioni

1. Seleziona una o più versioni a cui vuoi suddividere il traffico.
2. Fai clic su Suddividi traffico e poi specifica:
   • Il metodo che vuoi utilizzare per suddividere il traffico.
   • La percentuale di traffico che ogni versione deve ricevere.

gcloud

Dopo aver installato Google Cloud CLI, esegui il seguente comando 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 dettagli e opzioni aggiuntive, consulta il gcloud app services set-traffic riferimento.

API

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

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 del mittente sono ragionevolmente persistenti, ma non permanenti. Gli utenti che si connettono da telefoni cellulari potrebbero avere un indirizzo IP variabile durante una singola sessione. Allo stesso modo, un utente su un laptop potrebbe spostarsi da casa a un bar per lavorare e cambierà anche gli indirizzi IP. Di conseguenza, l'utente potrebbe avere un'esperienza incoerente con la tua app man mano che 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 l'applicazione riceve più traffico, la suddivisione effettiva si avvicina sempre più al 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 essere compresa tra il 3 e il 7%, ma alla fine la media si avvicina al target del 5%.
• Se devi inviare richieste interne tra le app, devi utilizzare la suddivisione dei cookie. Le richieste inviate tra le app in esecuzione sull'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, il che significa che tutte le richieste vengono instradate alla stessa versione. Di conseguenza, le richieste interne non rispettano da vicino le percentuali impostate per le suddivisioni del traffico basate su IP. Ad esempio, se imposti una versione in modo che riceva l'1% di tutto il traffico verso la tua app e gli indirizzi dell'infrastruttura cloud di Google sono stati assegnati per coincidenza 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 variegata 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 non esiste un cookie di questo tipo, App Engine genera un cookie con un valore casuale mascherato per instradare la richiesta.

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

L'utilizzo dei cookie per suddividere il traffico semplifica l'assegnazione precisa degli utenti alle versioni.

Ad esempio, se hai 3 versioni:

• Versione A con il 10% del traffico
• Versione B con il 60% del traffico
• Versione C con il 30% del traffico

App Engine crea 1000 shard e a ogni versione viene assegnato un numero di shard corrispondente alla percentuale di suddivisione del traffico. In questo esempio, la versione A ha 100 shard, la versione B ha 600 shard e la versione C ha 300 shard.

App Engine utilizza il valore del cookie GOOGAPPUID per determinare a quale shard viene assegnata una richiesta e la instrada alla versione corrispondente. La precisione per l'instradamento del traffico potrebbe raggiungere quasi lo 0,1% rispetto alla suddivisione target. La suddivisione dei cookie presenta le seguenti limitazioni:

• Se stai scrivendo un'app mobile o esegui 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 in ogni richiesta successiva. Le app basate su browser gestiscono già i cookie in questo modo automaticamente.

• La suddivisione delle richieste interne richiede un lavoro aggiuntivo. Tutte le richieste utente inviate dall'infrastruttura cloud di Google richiedono l'inoltro del cookie dell'utente con 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.

• Non è possibile determinare quale versione gestisce un determinato valore del cookie GOOGAPPUID. Tuttavia, la stessa versione gestisce le richieste con lo stesso valore del cookie GOOGAPPUID.

Disattivare la suddivisione del traffico

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