Répartir le trafic

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é :

  • [MY_PROJECT].appspot.com - Distribue le trafic sur les versions du service default.
  • [MY_SERVICE].[MY_PROJECT].appspot.com - Distribue le trafic sur les versions du service [MY_SERVICE].

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 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 configurer les deux en-têtes, car les serveurs proxy ne sont pas tous entièrement compatibles avec l'en-tête HTTP/1.1 Cache-Control.

    Si vous souhaitez en savoir plus sur la mise en cache en général, consultez la page consacrée aux champs d'en-tête de la RFC HTTP/1.1 et la section sur la mise en cache de documents du manuel sur la sécurité des navigateurs.

  • 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 laisser votre application définir l'en-tête Vary: Cookie afin que l'unicité d'une ressource soit calculée en combinant les cookies et l'URL de la demande. Cependant, cette approche alourdit la charge des serveurs de cache. Il existe 1 000 valeurs possibles de GOOGAPPUID, et par conséquent 1 000 entrées possibles pour chaque URL de votre application. En fonction de la charge sur les serveurs proxy entre vos utilisateurs et votre application, cela peut réduire le taux de succès de cache (hits). En outre, notez que 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 la modification du nom des ressources statiques variant d'une version à l'autre.

La technique Vary: Cookie ne fonctionne pas en toutes circonstances. 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 avait son propre cookie qui aurait 100 valeurs possibles, l'espace de toutes les entrées de cache possibles devient un très grand nombre (100 * 1000 = 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 ces cas, chaque utilisateur reçoit une copie unique, ce qui dégrade gravement les 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 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 par cookie.

Console

Pour répartir le trafic dans la console GCP, 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é le SDK Google Cloud, 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 obtenir plus de détails et des options supplémentaires, consultez la documentation de référence sur 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è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 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 configurez une version pour qu'elle reçoive 1 % de l'ensemble du trafic de votre application et que des adresses de l'infrastructure cloud de Google ont été attribuées à cette version, le résultat réel risque de largement 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 ultérieure. 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 des utilisateurs envoyées depuis l'infrastructure cloud de Google exigent que vous transmettiez le cookie de l'utilisateur à 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.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Python 2