Répartir le trafic

ID de la région

Le REGION_ID est un code abrégé que Google attribue en fonction de la région que vous sélectionnez lors de la création de votre application. Le code ne correspond pas à un pays ou une province, même si certains ID de région peuvent ressembler aux codes de pays et de province couramment utilisés. Pour les applications créées après février 2020, REGION_ID.r est inclus dans les URL App Engine. Pour les applications existantes créées avant cette date, l'ID de région est facultatif dans l'URL.

En savoir plus sur les ID de région

Vous pouvez utiliser la répartition du trafic pour spécifier une répartition en pourcentage du trafic sur au moins deux versions d'un service. La répartition du trafic permet d'effectuer des tests A/B entre vos versions et de contrôler le rythme de déploiement des fonctionnalités.

Elle s'applique aux URL qui ne ciblent pas explicitement une version. Par exemple, les URL suivantes répartissent le trafic, car elles ciblent toutes les versions disponibles du service spécifié :

  • https://PROJECT_ID.REGION_ID.r.appspot.com - Distribue le trafic vers les versions du service default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com - Distribue le trafic vers les versions du service [SERVICE_ID].

Pour plus d'informations sur la manière dont les requêtes parviennent à une version, consultez la page Mode de routage des requêtes.

Avant de commencer

Avant de pouvoir configurer le trafic sur une version, assurez-vous que votre compte utilisateur inclut les privilèges requis.

Éviter les problèmes de mise en cache

Avant d'activer la répartition du trafic, vous voudrez peut-être prendre en compte les éventuels problèmes de mise en cache. Des problèmes de mise en cache peuvent survenir avec toute application App Engine, notamment lors du déploiement d'une nouvelle version. La répartition du trafic rend souvent les problèmes de mise en cache subtils plus apparents.

Par exemple, supposons que vous répartissiez le trafic entre deux versions, A et B, et que des ressources externes pouvant être mises en cache soient modifiées selon les versions, par exemple un fichier CSS. Supposons maintenant qu'un client effectue une requête et que la réponse contienne une référence externe au fichier mis en cache. Le cache HTTP local récupérera le fichier s'il se trouve dans le cache, quelle que soit la version du fichier mise en cache et celle de l'application qui a envoyé la réponse. La ressource mise en cache peut être incompatible avec les données envoyées dans la réponse.

Pour éviter les problèmes de mise en cache, procédez comme suit :

  • Pour les ressources dynamiques, définissez les en-têtes Cache-Control et Expires. Ces en-têtes indiquent aux serveurs proxy que la ressource est dynamique. Il est préférable de définir les deux en-têtes, car tous les serveurs proxy ne sont pas parfaitement compatibles avec l'en-tête HTTP/1.1 Cache-Control.

    Pour en savoir plus sur la mise en cache en général, consultez Champs d'en-tête dans le RFC HTTP/1.1 et la présentation de la mise en cache HTTP dans Web Fundamentals.

  • Pour les ressources statiques pouvant être mises en cache qui varient selon les versions, modifiez l'URL de la ressource entre les versions. Si les ressources statiques sont diffusées à partir d'URL différentes, alors les deux versions peuvent coexister sans problème dans des serveurs proxy et des caches de navigateur.

Vous pouvez également demander à votre application de définir l'en-tête sur Vary: Cookie afin que le caractère unique d'une ressource soit calculé en combinant les cookies et l'URL de la requête. Toutefois, cette approche augmente la charge des serveurs de cache. Il existe 1 000 valeurs possibles de GOOGAPPUID, et donc 1 000 entrées possibles pour chaque URL de votre application. En fonction de la charge exercée sur les proxys entre vos utilisateurs et votre application, cela peut réduire la fréquence à laquelle votre application diffuse un résultat mis en cache. En outre, pendant les 24 heures qui suivent l'ajout d'un nouveau lot d'utilisateurs à une version, ceux-ci peuvent toujours voir les ressources mises en cache. Toutefois, l'utilisation de Vary: Cookie peut faciliter le changement de nom des ressources statiques qui changent d'une version à l'autre.

La technique Vary: Cookie ne fonctionne pas tout le temps. En règle générale, si votre application utilise des cookies à d'autres fins, vous devez examiner les conséquences en termes de charge pour les serveurs proxy. Si codeninja possède son propre cookie avec 100 valeurs possibles, alors l'espace de toutes les entrées de cache possibles devient un très grand nombre (100 * 1 000 = 100 000). Dans le pire des cas, il existe un cookie unique pour chaque utilisateur. Google Analytics (__utma) et SiteCatalyst (s_vi) en sont deux exemples courants. Dans ce cas, chaque utilisateur obtient une copie unique, ce qui nuit gravement aux performances du cache et peut également augmenter les heures d'instance facturables consommées par votre application.

Répartition du trafic sur plusieurs versions

Une fois que deux versions ou plus ont été spécifiées pour la répartition, choisissez de répartir le trafic en utilisant une adresse IP d'expéditeur ou un cookie HTTP. Il est plus facile de configurer une répartition à l'aide d'une adresse IP, toutefois une répartition à l'aide d'un cookie est plus précise. Pour en savoir plus, consultez les sections Répartir à l'aide d'une adresse IP et Répartir à l'aide d'un cookie.

Console

Pour répartir le trafic dans la console Google Cloud, accédez à la page "Versions" :

Accéder à la page "Versions"

  1. Sélectionnez une ou plusieurs versions sur lesquelles vous souhaitez répartir le trafic.
  2. Cliquez sur Répartir le trafic, puis spécifiez :
    • la méthode que vous souhaitez utiliser pour répartir le trafic ;
    • le pourcentage de trafic que chaque version doit recevoir.

gcloud

Après avoir installé Google Cloud CLI, exécutez la commande suivante pour répartir le trafic sur plusieurs versions, par exemple :

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

Pour plus d'informations et d'options supplémentaires, consultez la documentation de référence gcloud app services set-traffic.

API

Pour migrer le trafic de manière automatisée, vous pouvez utiliser l'API Admin. Pour en savoir plus, consultez la page Migrer le trafic et le répartir.

Répartir à l'aide d'une adresse IP

Si vous choisissez de répartir le trafic sur votre application par adresse IP d'expéditeur, dès que l'application reçoit une requête, elle hache l'adresse IP à une valeur comprise entre 0 et 999 et utilise ce nombre pour acheminer la requête.

La répartition par adresse IP présente certaines restrictions importantes :

  • Les adresses IP d'expéditeur sont assez persistantes, mais ne sont pas permanentes. Par exemple, l'adresse IP des utilisateurs qui se connectent à partir d'un téléphone portable peut varier au cours d'une même session. De même, un utilisateur qui se sert d'un ordinateur portable peut se rendre de chez lui dans un café pour travailler, ce qui implique le changement de son adresse IP. Dans ce cas, il se peut que l'utilisateur ne profite pas d'une expérience homogène de l'application.
  • Étant donné que les adresses IP sont attribuées aux versions de façon indépendante, la répartition du trafic qui en résulte diffère légèrement de celle que vous spécifiez. Or, plus votre application recevra de trafic, plus la répartition réelle se rapprochera de votre cible. Par exemple, si vous demandez que 5 % du trafic soit diffusé vers une autre version, le pourcentage initial de trafic vers cette version peut en réalité être compris entre 3 et 7 %, mais finit par se rapprocher en moyenne de votre cible de 5 %.
  • Si vous devez envoyer des requêtes internes entre les applications, il est préférable d'utiliser la répartition par cookie. Les requêtes envoyées entre des applications exécutées sur l'infrastructure cloud de Google proviennent d'un petit nombre d'adresses IP, qui sont probablement toutes attribuées à la même version. Par conséquent, toutes les requêtes internes peuvent se comporter de manière semblable aux requêtes envoyées à partir d'une même adresse IP, ce qui signifie que ces requêtes sont toutes routées vers la même version. Les requêtes internes ne respectent donc pas précisément les pourcentages que vous avez définis pour vos répartitions de trafic par adresse IP. Par exemple, si vous définissez une version pour qu'elle reçoive 1 % de tout le trafic de votre application et que les adresses de l'infrastructure cloud de Google sont attribuées de manière fortuite à cette version, le résultat réel risque de dépasser 1 %, car toutes les requêtes internes sont toujours routées vers la version attribuée. Les requêtes envoyées à votre application en dehors de l'infrastructure cloud de Google fonctionneront comme prévu, car elles proviennent d'une distribution variée d'adresses IP.

Si vous choisissez de répartir le trafic vers votre application à l'aide de cookies, l'application recherche dans l'en-tête de la requête HTTP un cookie nommé GOOGAPPUID, qui contient une valeur comprise entre 0 et 999 :

  • Si le cookie existe, la valeur est utilisée pour acheminer la requête.
  • Si le cookie n'existe pas, la requête est acheminée de manière aléatoire.

Si la réponse ne contient pas le cookie GOOGAPPUID, l'application ajoute d'abord le cookie GOOGAPPUID avec une valeur aléatoire comprise entre 0 et 999 avant son envoi.

L'utilisation de cookies pour répartir le trafic facilite l'affectation précise d'utilisateurs aux versions. La précision du routage du trafic peut atteindre 0,1 % de la répartition cible. Toutefois, la répartition par cookie présente les limitations suivantes :

  • Si vous écrivez une application mobile ou exécutez un client de bureau, les cookies GOOGAPPUID doivent être gérés. Par exemple, lorsqu'un en-tête de réponse Set-Cookie est utilisé, vous devez stocker le cookie et l'inclure dans chaque requête suivante. Les applications basées sur un navigateur gèrent déjà automatiquement les cookies de cette manière.

  • La répartition des requêtes internes nécessite un travail supplémentaire. Toutes les requêtes d'utilisateurs envoyées depuis l'infrastructure cloud de Google nécessitent le transfert du cookie de l'utilisateur avec chaque requête. Par exemple, vous devez transférer le cookie de l'utilisateur dans les requêtes envoyées depuis votre application vers une autre application ou vers elle-même. Notez qu'il n'est pas recommandé d'envoyer des requêtes internes si ces requêtes ne proviennent pas d'un utilisateur.

Désactiver la répartition du trafic

Pour désactiver la répartition du trafic, vous devez migrer tout le trafic vers une version unique.