Répartir le trafic

La répartition du trafic permet de distribuer un pourcentage du trafic entre deux versions ou plus d'un service, d'effectuer des tests A/B sur vos versions et de contrôler le rythme de déploiement des nouvelles fonctionnalités.

La répartition du trafic s'applique aux URL qui ne ciblent pas une version de manière explicite. 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 vers les versions du service default.
  • [MY_SERVICE].[MY_PROJECT].appspot.com - Distribue le trafic vers les versions du service [MY_SERVICE].

Pour découvrir comment les requêtes parviennent à une version, consultez la page Mode de routage des requêtes.

Avant de commencer

Avant de pouvoir configurer le trafic vers une version, assurez-vous que votre compte utilisateur dispose des droits nécessaires.

Éviter les problèmes de mise en cache

Avant d'activer la répartition du trafic, nous vous recommandons de tenir compte des éventuels problèmes de mise en cache. Ces derniers peuvent survenir pour toute application App Engine, en particulier lors du déploiement d'une nouvelle version. La répartition du trafic fait souvent apparaître les problèmes de mise en cache subtils.

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 entre les versions, par exemple un fichier CSS. Supposons maintenant qu'un client envoie 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. Il se peut donc que la ressource mise en cache soit 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. Ils 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 Cache-Control HTTP/1.1.

    Si vous souhaitez en savoir plus sur la mise en cache en général, consultez la page relative aux champs d'en-tête de la RFC HTTP/1.1 et la section relative à la mise en cache de document dans le Browser Security Handbook.

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

Vous pouvez également demander à votre application de définir l'en-tête Vary: Cookie pour que l'unicité d'une ressource soit calculée en combinant les cookies et l'URL de la requête. Cependant, cette approche alourdit la charge imposée aux serveurs de cache. Il existe 1 000 valeurs possibles de GOOGAPPUID, et par conséquent 1 000 entrées possibles pour chaque URL de l'application. En fonction de la charge appliquée aux serveurs proxy entre les utilisateurs et l'application, cela peut réduire le taux de succès du cache. Notez également que, pendant les 24 heures suivant 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 dans tous les scénarios. 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 disposait de son propre cookie avec 100 valeurs possibles, l'espace de toutes les entrées de cache possibles prendrait une valeur très élevée (100 * 1 000 = 100 000). Dans le pire des cas, il peut y avoir 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 fortement les performances du cache et peut également augmenter les heures facturables d'utilisation de l'instance par votre application.

Répartir le trafic entre plusieurs versions

Après avoir spécifié deux versions ou plus pour la répartition, vous devez choisir de répartir le trafic à l'aide d'une adresse IP ou d'un cookie HTTP. Il est plus facile de configurer une répartition par adresse IP, mais la répartition par cookie est plus précise. Pour en savoir plus, consultez les sections Répartir par 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 entre lesquelles vous souhaitez répartir le trafic.
  2. Cliquez sur Répartir le trafic, puis spécifiez les éléments suivants :
    • La méthode que vous souhaitez employer 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 entre 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 en savoir plus et connaître les options supplémentaires, consultez la documentation de référence sur gcloud app services set-traffic.

API

Pour migrer le trafic de façon automatisée, vous pouvez utiliser l'API Admin. Consultez la page Migrer le trafic et le répartir pour en savoir plus.

Répartir par adresse IP

Si vous choisissez de répartir le trafic vers votre application à l'aide d'une adresse IP, l'application hache l'adresse IP à une valeur comprise entre 0 et 999 lorsqu'elle reçoit une requête, puis utilise ce nombre pour l'acheminer.

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 session. De même, un utilisateur qui se sert d'un ordinateur portable peut se déplacer de son domicile à 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 avec l'application.
  • Comme les adresses IP sont attribuées aux versions de manière indépendante, la répartition du trafic qui en résulte diffère légèrement de celle que vous avez spécifiée. Toutefois, plus l'application reçoit de trafic, plus la répartition réelle se rapproche de votre cible. Par exemple, si vous demandez que 5 % du trafic soit acheminé vers une autre version, le pourcentage initial de trafic acheminé peut en réalité être compris entre 3 et 7 %, mais finit par se rapprocher de votre cible de 5 %.
  • Si vous devez envoyer des requêtes internes d'une application à une autre, la répartition par cookie est recommandée. Les requêtes envoyées entre des applications exécutées sur l'infrastructure Google Cloud 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 comparable aux requêtes envoyées à partir d'une seule adresse IP, ce qui signifie que ces requêtes sont toutes acheminées vers la même version. Ainsi, les requêtes internes ne respectent pas strictement les pourcentages définis pour les répartitions de trafic basées sur les adresses IP. Par exemple, si vous définissez une version pour qu'elle reçoive 1 % de l'ensemble du trafic de votre application et que les adresses de l'infrastructure Google Cloud ont été attribuées à cette version, le résultat réel risque de dépasser largement 1 %, car toutes les requêtes internes sont toujours acheminées vers la version attribuée. Les requêtes envoyées à votre application depuis l'extérieur de l'infrastructure Google Cloud fonctionneront comme prévu, puisqu'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 appelé 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 et lui attribue une valeur aléatoire comprise entre 0 et 999 avant de l'envoyer.

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

  • Si vous développez une application mobile ou exécutez un client de bureau, celui-ci doit gérer les cookies GOOGAPPUID. Par exemple, si un en-tête de réponse Set-Cookie est utilisé, vous devez stocker le cookie et l'inclure à chaque requête ultérieure. Les applications basées sur un navigateur gèrent déjà les cookies de cette manière automatiquement.

  • La répartition des requêtes internes nécessite un travail supplémentaire. Toutes les requêtes utilisateur envoyées depuis l'infrastructure Google Cloud 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. Sachez qu'il est déconseillé d'envoyer des requêtes internes si elles ne proviennent pas d'un utilisateur.

Désactiver la répartition du trafic

Pour désactiver la répartition du trafic, vous devez migrer l'ensemble du 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