Suddivisione del traffico

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Il codice non corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione in modo simile ai codici paese e provincia di uso comune. Per le app create dopo il giorno Febbraio 2020, REGION_ID.r è incluso in 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 condurre A/B test tra le tue versioni e ti consente di controllare il ritmo durante l'implementazione le funzionalità di machine learning.

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 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 di il 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, devi assicurarti che l'account utente include i obbligatori privilegiati.

Evitare i problemi di memorizzazione nella cache

Prima di attivare la suddivisione del traffico, ti consigliamo di tenere conto del potenziale di memorizzazione nella cache. Possono esistere problemi di memorizzazione nella cache per qualsiasi app di App Engine, in particolare durante il deployment di una nuova versione. La suddivisione del traffico spesso rende i problemi di memorizzazione nella cache sono più evidenti.

Ad esempio, supponiamo che tu stia dividendo il traffico tra due versioni, A e B, mentre alcune risorse esterne memorizzabili nella cache sono cambiate da una versione all'altra, ad esempio 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à file se si trova nella cache, indipendentemente dalla versione del file memorizzata nella cache la 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 sia il valore Controllo cache e Scade headers. Queste intestazioni indicano ai proxy che la risorsa è dinamica. È meglio impostare entrambe le intestazioni, poiché non tutti i server proxy supportano HTTP/1.1 Cache-Control correttamente.

    Per ulteriori informazioni sulla memorizzazione nella cache in generale, consulta la sezione Campi intestazione 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 URL diversi, allora entrambe le versioni possono coesistere nei server proxy e cache del browser.

Puoi anche impostare l'app Vary: Biscotto in modo che l'univocità di una risorsa venga calcolata combinando i cookie e l'URL della richiesta. Tuttavia, questo approccio aumenta il carico Cache. Esistono 1000 valori possibili per GOOGAPPUID, quindi 1000 le voci possibili per ogni URL della tua app. A seconda del carico sui proxy tra gli utenti e la tua app, ciò può diminuire la frequenza con cui l'app pubblica 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. Tuttavia, utilizzando 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 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, c'è un'istanza cookie per ogni utente. Due esempi comuni sono Google Analytics (__utma) e SiteCatalyst (s_vi). In questi casi, ogni utente riceve un ID univoco di testo, il che peggiora gravemente le prestazioni della cache e può anche aumentare le ore di istanza fatturabili utilizzate dalla tua applicazione.

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 dell'indirizzo IP, ma una suddivisione dei cookie è più precisa. Per per ulteriori informazioni, consulta gli articoli sulla suddivisione degli indirizzi 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 per le quali vuoi suddividere il traffico.
  2. 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 quanto segue 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 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 la sezione Migrazione e suddivisione Traffico per informazioni dettagliate.

Suddivisione degli indirizzi IP

Se scegli di suddividere il traffico verso la tua applicazione in base all'indirizzo IP del mittente, quando 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 dei mittenti sono ragionevolmente fissi, ma non permanenti. Utenti che si connettono da telefoni cellulari potrebbero avere un indirizzo IP diverso nell'arco di una singola sessione. Analogamente, un utente con un laptop potrebbe spostarsi da casa al bar al lavoro. anche gli indirizzi IP. Di conseguenza, l'utente potrebbe avere un'esperienza incoerente con la tua app perché il relativo indirizzo IP cambia.
  • Poiché gli indirizzi IP vengono assegnati alle versioni in modo indipendente, la suddivisione del traffico sarà leggermente diversa da quanto specificato. Tuttavia, poiché dell'applicazione riceve più traffico, più la suddivisione effettiva si avvicina al target. Ad esempio, se richiedi che il 5% del traffico venga inviato a una alternativa, la percentuale iniziale di traffico verso la versione potrebbe in realtà è 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 usare i cookie la suddivisione. Richieste inviate tra app in esecuzione su infrastruttura cloud, provengono da un numero ridotto di indirizzi IP che sono probabilmente sono tutte assegnate alla stessa versione. Di conseguenza, tutte le richieste interne potrebbero comportarsi in modo simile alle richieste inviate da un singolo indirizzo IP, tutte le richieste vengono indirizzate alla stessa versione. Di conseguenza, non rispettano strettamente le percentuali che hai impostato per i tuoi dati le suddivisioni del traffico. Ad esempio, se imposti una versione per ricevere l'1% di tutte le il traffico verso la tua app e gli indirizzi dell'infrastruttura cloud di Google assegnato per caso a quella versione, il risultato effettivo potrebbe superare di gran lunga 1% perché tutte le richieste interne vengono sempre instradate completamente gestita. Richieste inviate alla tua app dall'esterno del cloud di Google funzioneranno come previsto poiché provengono da una variegata distribuzione degli indirizzi IP.

Se scegli di suddividere il traffico verso la tua applicazione in base ai cookie, l'applicazione cerca Intestazione della richiesta HTTP per 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, prima l'app aggiunge il cookie GOOGAPPUID con un valore casuale compreso tra 0 e 999 prima quando viene inviato.

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

  • Se stai scrivendo un'app mobile o esegui un client desktop, questo deve gestisci i cookie di GOOGAPPUID. Ad esempio, quando una risposta Set-Cookie , è necessario memorizzare il cookie e includerlo in ogni richiesta. 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 che sono inviate dall'interno dell'infrastruttura cloud di Google, richiedono l'inoltro il cookie dell'utente a ogni richiesta. Ad esempio, devi inoltrare l'email dell'utente il cookie nelle richieste inviate dalla tua app a un'altra app o a se stessa. Tieni presente che non è consigliabile inviare richieste interne se queste provengono da un utente.

Disabilitazione della suddivisione del traffico

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