Présentation de la gestion avancée du trafic

Traffic Director fournit des fonctionnalités avancées de gestion du trafic qui vous permettent de contrôler avec précision la manière dont le trafic est géré. Traffic Director est compatible avec les cas d'utilisation suivants :

  • Routage précis des requêtes vers un ou plusieurs services
  • Actions basées sur les requêtes et les réponses, telles que les redirections et les transformations d'en-tête
  • Répartition précise du trafic entre les backends d'un service pour un meilleur équilibrage de charge

Ces fonctionnalités avancées de gestion du trafic vous permettent d'atteindre vos objectifs de disponibilité et de performances. L'un des avantages de Traffic Director dans ces cas d'utilisation est que vous pouvez changer la manière dont le trafic est géré sans avoir à modifier le code de votre application.

Exemples de cas d'utilisation

La gestion avancée du trafic convient à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux.

Vous trouverez davantage d'exemples, y compris des exemples de code, dans les guides Configurer la gestion avancée du trafic et Configurer des services gRPC sans proxy basés sur des VM avec la gestion avancée du trafic.

Routage de trafic ultraprécis pour la personnalisation

Vous pouvez acheminer le trafic vers un service en fonction des paramètres de la requête. Par exemple, vous pouvez vous en servir pour offrir une expérience plus personnalisée aux utilisateurs Android. Dans le schéma suivant, Traffic Director configure votre maillage de services pour envoyer des requêtes avec l'en-tête user-agent:Android à votre service Android au lieu de votre service générique.

Routage basé sur l'en-tête
Routage basé sur l'en-tête user-agent défini sur Android (cliquez pour agrandir)

Répartition du trafic en fonction d'une pondération pour des déploiements plus sûrs

Le déploiement d'une nouvelle version d'un service de production existant peut s'avérer risqué. Même après avoir réussi les tests dans un environnement de test, vous souhaiterez peut-être ne pas diriger immédiatement tous les utilisateurs vers la nouvelle version.

Traffic Director vous permet de définir des répartitions du trafic en fonction d'une pondération pour distribuer le trafic sur plusieurs services. Par exemple, vous pouvez envoyer 1 % du trafic vers la nouvelle version de votre service, vérifier que tout fonctionne, puis augmenter progressivement la part de trafic dirigé vers le nouveau service.

Répartition du trafic en fonction d'une pondération avec Traffic Director (cliquez pour agrandir)
Répartition du trafic en fonction d'une pondération avec Traffic Director (cliquez pour agrandir)

Mise en miroir du trafic pour le débogage

Lorsque vous déboguez un problème, il peut être utile d'envoyer des copies du trafic de production à un service de débogage. Traffic Director vous permet de configurer des règles de mise en miroir des requêtes afin d'envoyer celles-ci à un service et d'envoyer leurs copies à un autre service.

Mise en miroir du trafic avecTraffic Director (cliquez pour agrandir)
Mise en miroir du trafic avec Traffic Director (cliquez pour agrandir)

Équilibrage de charge adapté aux performances

Selon les caractéristiques de votre application, vous pourrez peut-être améliorer les performances et la disponibilité en ajustant avec précision la distribution du trafic sur les backends d'un service. Traffic Director vous permet d'appliquer des algorithmes avancés d'équilibrage de charge pour que le trafic soit distribué en fonction de vos besoins.

Le schéma suivant, contrairement aux schémas précédents, montre à la fois un service de backend de destination (service de production) et les backends de ce service de backend (VM 1, VM 2, Vm 3). La gestion avancée du trafic vous permet de configurer la manière dont un service de backend de destination est sélectionné, ainsi que la manière dont le trafic est réparti entre les backends de ce service.

Équilibrage de chargeTraffic Director (cliquez pour agrandir)
Équilibrage de charge Traffic Director (cliquez pour agrandir)

Fonctionnement de la gestion avancée du trafic

Configurez la gestion avancée du trafic à l'aide de la carte des règles de routage et des ressources des services de backend que vous utilisez lors de la configuration de Traffic Director. Traffic Director, à son tour, configure vos proxys Envoy et vos applications gRPC sans proxy pour appliquer les règles avancées de gestion du trafic que vous configurez.

En règle générale, vous procédez comme suit :

  1. Configurez la carte des règles de routage pour effectuer les opérations suivantes, en fonction des caractéristiques de la requête sortante :

    1. Sélectionnez le service de backend vers lequel les requêtes sont acheminées.

    2. Effectuez d'autres actions le cas échéant.

  2. Configurez le service (service de backend) pour contrôler la manière dont le trafic est distribué aux backends et aux points de terminaison après avoir sélectionnéun service de destination.

Routage du trafic et actions

Dans Traffic Director, la carte des règles de routage fait référence àla combinaison des ressources de règle de transfert, de proxy cible et de mappage d'URL. Toutes les fonctionnalités avancées de gestion du trafic liées au routage et aux actions sont configurées à l'aide du mappage d'URL.

Vous pouvez configurer les fonctionnalités avancées de gestion du trafic suivantes dans votre carte des règles de routage.

Gérer les requêtes

Lorsqu'un client envoie une requête, celle-ci est traitée comme suit :

  1. La requête est mise en correspondance avec une carte de règles de routage spécifique. Cette correspondance est établie comme suit :
    1. Si vous utilisez Envoy :
      1. L'adresse IP et le port de destination de la requête sont comparés à l'adresse IP et au port des règles de transfert dans toutes les cartes de règles de routage. Seules les cartes de règles de routage comportant des règles de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED sont prises en compte.
      2. La règle de transfert qui correspond à la requête fait référence à un proxy HTTP ou gRPC cible, qui fait référence à un mappage d'URL. Ce mappage d'URL contient des informations utilisées pour le routage et les actions.
    2. Si vous utilisez une API gRPC sans proxy :
      1. L'adresse IP de la requête est ignorée, car vous ne pouvez utiliser l'adresse IP 0.0.0.0 que lorsque vous créez une règle de transfert faisant référence à un proxy gRPC cible. Seules les cartes de règles de routage comportant des règles de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED sont prises en compte.
      2. Le port de l'URI cible (par exemple, xds:///foo.myservice:8080) est comparé au port des règles de transfert avec le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED. L'adresse IP d'une règle de transfert n'est pas utilisée.
      3. La règle de transfert qui correspond à la requête fait référence à un proxy gRPC cible, qui fait référence à un mappage d'URL. Ce mappage d'URL contient des informations utilisées pour le routage et les actions.
  2. Lorsque le mappage d'URL approprié est déterminé, le mappage d'URL est évalué pour déterminer le service de backend de destination et, éventuellement, appliquer des actions.
  3. Une fois le service de backend de destination sélectionné, le trafic est réparti entre les backends ou les points de terminaison de ce service de destination, en fonction de la configuration dans la ressource du service de backend.

La deuxième étape est décrite dans la section suivante, Routage simple basé sur l'hôte et le chemin d'accès. La troisième étape est décrite dans la section Routage et actions avancés.

Routage simple en fonction de l'hôte et du chemin d'accès

Traffic Director est compatible avec un schéma de routage simplifié ainsi qu'un schéma plus avancé. Des schémas de routage plus avancés, y compris les actions associées, sont décrits dans la section suivante, Routage et actions avancés. Dans le schéma simple, vous spécifiez un hôte et, éventuellement, un chemin d'accès. L'hôte et le chemin d'accès de la requête sont évalués pour déterminer le service vers lequel une requête doit être acheminée.

  • L'hôte de la requête est la partie correspondant aunom de domaine d'une URL. Par exemple, la partie hôte de l'URL http://example.com/video/ est example.com.
  • Le chemin d'accès de la requête est la partie de l'URL qui suit le nom d'hôte. Par exemple, /video dans http://example.com/video.
Configurer un routage simple basé sur l'hôte et le chemin d'accès

Le routage simple basé sur l'hôte et le chemin d'accès est configuré dans la carte des règles de routage comprenant les éléments suivants :

  • Une règle de transfert globale
  • Un proxy HTTP ou gRPC cible
  • Un mappage d'URL

La majeure partie de la configuration est effectuée dans le mappage d'URL et, après avoir créé la carte initiale des règles de routage, vous n'avez généralement besoin de modifier que la partie URL du mappage d'URL. Dans ce schéma, les règles de chemin d'accès présentent des actions semblables au schéma suivant.

Routage basé sur les ressources hôte et de chemin d'accès (cliquez pour agrandir)
Routage basé sur les ressources hôte et de chemin d'accès (cliquez pour agrandir)

La règle la plus simple est une règle par défaut, dans laquelle vous ne spécifiez qu'une règle d'hôte générique (*) et un outil de mise en correspondance des chemins d'accès avec un service par défaut. Une fois la règle par défaut créée, vous pouvez ajouter des règles supplémentaires, qui spécifient des hôtes et des chemins d'accès différents. Les requêtes sortantes sont évaluées selon ces règles.

Si l'hôte d'une requête (par exemple, example.com) correspond à une règle d'hôte :

  1. L'outil de mise en correspondance des chemins d'accès est ensuite évalué.
  2. Chaque outil de mise en correspondance des chemins d'accès contient une ou plusieurs règles de chemin d'accès évaluées en fonction du chemin de la requête.
  3. Si une correspondance est trouvée, la requête est acheminée vers le service spécifié dans la règle de chemin d'accès.
  4. Chaque outil de mise en correspondance des chemins d'accès contient un service par défaut vers lequel les requêtes sont acheminées si la règle d'hôte correspond, mais qu'aucune règle de chemin d'accès ne correspond.

Si la requête ne correspond à aucune des règles d'hôte que vous avez spécifiées, elle est acheminée vers le service spécifié dans la règle par défaut.

Pour en savoir plus sur les champs de ressource de mappage d'URL et leur fonctionnement, consultez la page de l'API REST urlMaps.

Routage avancé et actions

Si vous souhaitez aller plus loin que le routage d'une requête en fonction de l'hôte et du chemin d'accès de la requête, vous pouvez configurer des règles avancées pour acheminer les requêtes et effectuer des actions.

Routage avancé (cliquez pour agrandir)
Routage avancé (cliquez pour agrandir)

De manière générale, les options de routage et d'action avancées fonctionnent comme suit :

  1. Comme pour le routage simple, l'hôte de la requête est comparé aux règles d'hôte que vous configurez dans le mappage d'URL. Si l'hôte d'une requête correspond à une règle d'hôte, l'outil de mise en correspondance des chemins d'accès de la règle d'hôte est évalué.
  2. L'outil de mise en correspondance des chemins d'accès contient une ou plusieurs règles de routage évaluées par rapport à la requête.
    1. Ces règles de routage sont évaluées par ordre de priorité en fonction des attributs de larequête (hôte, chemin d'accès, en-tête et paramètres de requête) en fonction de conditions de correspondance spécifiques, telles que la correspondance de préfixe.
  3. Une fois qu'une règle de routage a été sélectionnée, des actions peuvent s'appliquer. L'action par défaut consiste à acheminer la requête vers un seul service de destination, mais vous pouvez également configurer d'autres actions.
Routage avancé

Le routage avancé est semblable au routage simple décrit ci-dessus, à la différence que vous pouvez spécifier une priorité de règle et des conditions de correspondance supplémentaires, comme décrit ci-dessous.

Avec le routage avancé, vous devez spécifier une priorité unique pour chaque règle. Cette priorité détermine l'ordre d'évaluation des règles de routage, les valeurs de priorité inférieure étant prioritaires sur les valeurs de priorité plus élevée. Lorsqu'une requête correspond à une règle, la règle est appliquée et les autres règles sont ignorées.

Le routage avancé accepte également desconditions de correspondance supplémentaires. Par exemple, vous pouvez spécifier qu'une règle correspond à l'en-tête d'une requête si son nom correspond exactement ou partiellement, par exemple en fonction du préfixe ou du suffixe. La mise en correspondance peut s'effectueren fonction de l'évaluation du nom de l'en-tête par rapport à une expression régulière, ou en fonction d'autres critères comme la vérification de la présence d'un en-tête.

En combinant les paramètres d'hôte, de chemin d'accès, d'en-tête et de requête avec des priorités et des conditions de correspondance, vous pouvez créer des règles très expressives qui répondent à vos besoins précis en termes degestion du trafic.

Hôtes HTTP et hôtes gRPC

Si vous développez une application basée sur HTTP, l'hôte est la partie du nom de domaine de l'URL vers laquelle l'application effectue les appels. Par exemple, la partie hôte de l'URL http://example.com/video/ est example.com.

Si vous écrivez une application basée sur gRPC, l'hôte est le nom qu'un client utilise dans l'URI du canal pour se connecter à un service spécifique. Par exemple, la partie hôte de l'URI du canal xds:///example.com est example.com.

Chemins HTTP et chemins d'accès gRPC

Si vous écrivez une application basée sur HTTP, le chemin correspond à la partie de l'URL qui suit le nom d'hôte, par exemple, /video dans http://example.com/video.

Si vous écrivez une application basée sur gRPC, le chemin d'accès se trouve dans l'en-tête :path de la requête HTTP/2 et se présente sous la forme /SERVICE_NAME/METHOD_NAME/. Par exemple, si vous appelez la méthode Download sur le service gRPC Example, le contenu de l'en-tête :path ressemblera à /Example/Download.

Autres en-têtes gRPC (métadonnées)

gRPC est compatible avec l'envoi de métadonnées entre le client gRPC et le serveur gRPC pour fournir des informations supplémentaires sur un appel RPC. Ces métadonnées se présentent sous la forme de paires clé/valeur transmises en tant qu'en-têtes dans la requête HTTP/2.

Actions

Traffic Director vous permet de spécifier les actions effectuées par vos proxys Envoy ou vos applications gRPC sans proxy lors du traitement d'une requête. Les actions suivantes peuvent être configurées à l'aide de Traffic Director.

Action (nom du champ d'API) Description
Redirections (urlRedirect) Renvoie un code de réponse 3xx configurable. Définit également l'en-tête de réponse Location à l'aide de l'URI approprié, en remplaçant l'hôte et le chemin d'accès comme spécifié dans l'action de redirection.
Réécriture d'URL (urlRewrite) Réécrit la partie nom d'hôte de l'URL, la partie chemin de l'URL, ou les deux, avant d'envoyer une requête au service de backend sélectionné.
Transformations d'en-tête (headerAction) Ajoute ou supprime des en-têtes de requête avant de transférer une requête au service de backend. Peut également ajouter ou supprimer des en-têtes de réponse après avoir reçu une réponse du service de backend.
Mise en miroir du trafic (requestMirrorPolicy) En plus de transmettre la requête au service de backend sélectionné, envoie une requête identique au service de backend en miroir, selon une configuration de type fire and forget. L'équilibreur de charge n'attend pas de réponse du backend auquel il envoie la requête en miroir.

La mise en miroir est utile pour tester une nouvelle version d'un service de backend. Elle permet également de déboguer les erreurs de production sur une version de débogage du service de backend, plutôt que sur la version de production.
Répartition du trafic en fonction d'une pondération(weightedBackendServices) Permet au trafic d'une règle en correspondance d'être distribué à plusieurs services de backend, en fonction d'une pondération définie par l'utilisateur pour un service de backend particulier.

Cette fonctionnalité est utile pour configurer des déploiements par étapes ou des tests A/B. Par exemple, l'action de routage peut être configurée pour envoyer 99 % du trafic à un service qui exécute une version stable d'une application, et 1 % à un service distinct exécutant une version plus récente.
Tentatives répétées (retryPolicy) Configure les conditions dans lesquelles l'équilibrage effectue une nouvelle tentative pour les requêtes ayant échoué, le délai d'attente de l'équilibreur de charge avant une nouvelle tentative et le nombre maximal de tentatives autorisées.
Délai avant expiration (timeout) Indique le délai avant expiration pour la route sélectionnée. Le délai avant expiration est calculé à partir du moment où la requête est entièrement traitée et jusqu'à ce que la réponse soit elle aussi entièrement traitée. Le délai avant expiration inclut l'ensemble des nouvelles tentatives.
Injection de pannes (faultInjectionPolicy) Introduit des erreurs lors du traitement de demandes afin de simuler des pannes, y compris une latence élevée, une surcharge de service, des défaillances de service et un partitionnement réseau. Cette fonctionnalité est utile pour tester la résilience d'un service aux pannes simulées.
Règles de sécurité (corsPolicy) Les règles de partage des ressources entre origines multiples (CORS, Cross-origin resource sharing) permettent de gérer les paramètres d'application des requêtes CORS.

Pour plus d'informations sur les actions et leur fonctionnement, consultez la documentation de référence de l'APIsur les mappages d'URL.

Dans chaque règle de routage, vous pouvez spécifier l'une des actions de routage suivantes (dénommées "actions principales" dans Google Cloud Console) :

  • Acheminer le trafic vers un service unique (service)
  • Répartir le trafic entre plusieurs services (weightedBackendServices).
  • Rediriger des URL (urlRedirect)

Vous pouvez également combiner l'une des actions de routage ci-dessus aux actions de routage suivantes (dénommées "actions complémentaires" dans Google Cloud Console) :

  • Manipuler les en-têtes de requête/réponse (headerAction)
  • Mettre en miroir le trafic (requestMirrorPolicy)
  • Réécrire l'hôte/le chemin de l'URL (urlRewrite)
  • Réessayer les requêtes ayant échoué (retryPolicy)
  • Définir un délai avant expiration (timeout)
  • Introduire des erreurs dans un pourcentage du trafic (faultInjectionPolicy)
  • Ajouter une règle CORS (corsPolicy)

Comme les actions sont associées à des règles de routage spécifiques, le proxy Envoy ou l'application gRPC sans proxy peut appliquer des actions différentes en fonction de la requête à gérer.

Distribuer le trafic entre les backends d'un service

Comme indiqué dans la section Gérer les requêtes, lorsqu'un client traite une requête sortante, il sélectionne d'abord un service de destination. Après avoir sélectionné un service de destination, il doit déterminer quel backend/point de terminaison doit recevoir la requête.

Répartition du trafic entre les backends (cliquez pour agrandir)
Distribution du trafic entre les backends (cliquez pour agrandir)

Dans le diagramme ci-dessus, la Règle a été simplifiée. Il s'agit généralement d'une règle d'hôte, d'une mise en correspondance de chemin d'accès et d'une ou plusieurs règles de chemin ou de routage. Le service de destination est le service de backend. Les Backend 1, …et Backend n reçoivent et gèrent la requête. Ces backends peuvent être, par exemple, des machines virtuelles Compute Engine qui hébergent le code de votre application côté serveur.

Par défaut, le client qui gère la requête envoie des requêtes au backend opérationnel le plus proche disposant d'unecapacité suffisante. Pour éviter de surcharger un backend spécifique, il charge les requêtes suivantes sur les autres backends du service de destination à l'aide de l'algorithme d'équilibrage de charge à tour de rôle. Toutefois, dans certains cas, vous souhaiterez peut-être contrôler plus précisément ce comportement.

Équilibrage de charge, affinité de session et protection des backends

Vous pouvez définir les règles suivantes de distribution du trafic pour chaque service.

Règle (nom de champ d'API) Description
Mode d'équilibrage de charge (balancingMode) Contrôlez la façon dont un groupe de points de terminaison du réseau ou un groupe d'instances géré est sélectionné une fois le service de destination sélectionné. Vous pouvez configurer le mode d'équilibrage pour répartir la charge en fonction de connexions simultanées, du taux de requêtes, etc.
Règle d'équilibrage de charge (localityLbPolicy) Définit l'algorithme d'équilibrage de charge utilisé pour répartir le trafic entre les backends d'un groupe de points de terminaison du réseau ou d'un groupe d'instances géré. Pour optimiser les performances, vous pouvez choisir parmi une variété d'algorithmes (répartition à tour de rôle, plus faible nombre de requêtes, etc.).
Affinité de session (sessionAffinity) L'affinité de session constitue une tentative d'envoi optimale de requêtes d'un client spécifique vers le même backend tant qu'il est opérationnel et dispose de la capacité nécessaire. Traffic Director est compatible avec quatre options d'affinité de session différentes : adresse IP cliente, cookie HTTP, en-tête HTTP et affinité basée sur les cookies générés, définies par Traffic Director lui-même.
Hachage cohérent (consistentHash) Ce paramètre permet de fournir une affinité de session souple en fonction des en-têtes HTTP, des cookies ou d'autres propriétés.
Disjoncteurs (circuitBreakers) Définit les limites supérieures du volume de connexions et de requêtes par connexion à un service de backend.
Détection des anomalies (outlierDetection) Spécifiez les critères pour (1) supprimer les backends ou les points de terminaison défaillants des groupes d'instances gérés ou des groupes de points de terminaison du réseau, et (2) ajoutezun backend ou un point de terminaison lorsque celui-ci est considéré comme suffisamment opérationnel pour recevoir à nouveau le trafic. La vérification d'état d'un backend ou d'un point de terminaison est déterminée par la vérification d'état associée au service.

Pour plus d'informations sur les différentes options de distribution du trafic et leur fonctionnement, consultez la documentation de référence de l'API des services de backend.

Configuration du filtrage

L'une des principales responsabilités de Traffic Director est de générer une configuration et de l'envoyer à divers clients Traffic Director, tels que des proxys Envoy et/ou des applications gRPC. Traffic Director contrôle votre maillage de services en envoyant la configuration à ses clients, ce qui leur indique ce qu'ils doivent faire : Traffic Director est le plan de contrôle.

Lorsque vous créez ou mettez à jour une configuration dans Traffic Director, celui-citraduit cette configuration dans un langage compréhensible par ses clients. Par défaut, Traffic Director partage cette configuration avec tous ses clients. Dans certains cas, vous pouvez avoir besoin de personnaliser les clients Traffic Director qui reçoivent une configuration spécifique, c'est-à-dire de filtrer la configuration sur des clients spécifiques.

Bien qu'il s'agisse d'une fonctionnalité, les exemples suivants illustrent dans quels cas la configuration du filtrage peut être utile :

  • Votre organisation utilise le modèle de réseau VPC partagé, et plusieurs équipes utilisent Traffic Director dans différents projets de service. Si vous souhaitez isoler votre configuration d'autres projets de service, vous pouvez la filtrer de sorte que certains clients Traffic Director ne reçoivent qu'un sous-ensemble de la configuration.
  • Un grand nombre de règles et de services de routage sont configurés dans Traffic Director et vous souhaitez éviter d'envoyer une quantité considérable de configuration à chaque client Traffic Director. Gardez à l'esprit qu'un client devant évaluer une requête sortante à l'aide d'une configuration complexe et volumineuse peut être moins performant qu'un client qui n'a besoin d'évaluer une requête que via une configuration simplifiée.

Le filtrage de la configuration est basé sur le concept de filtres de métadonnées :

  1. Lorsqu'un client Traffic Director se connecte, celui-ci présente les informations de son fichier d'amorçage à Traffic Director.
  2. Ces informations contiennent le contenu des champs de métadonnées, sous la forme de paires clé/valeur, que vous spécifiez dans le fichier d'amorçage lorsque vous déployez vos proxys Envoy et/ou vos applications gRPC.
  3. Vous pouvez ajouter des filtres de métadonnées à la règle de transfert et/ou aux règles de routage que vous configurez dans la carte des règles de routage.
  4. Lorsque vous ajoutez des filtres de métadonnées à ces ressources, Traffic Director ne partage la configuration qu'avec des clients qui contiennent des métadonnées correspondant aux conditions de filtre de métadonnées.

Vous pouvez appliquer des filtres de métadonnées à la règle de transfert. Dans ce cas, la carte des règles de routage et les services associés ne sont partagés qu'avec les clients Traffic Director qui présentent des métadonnées correspondantes.

Vous pouvez également appliquer des filtres de métadonnées à des règles de routage spécifiques. Dans ce cas, Traffic Director ne partage que la règle de routage spécifique et les services associés avec les clients Traffic Director qui présentent des métadonnées correspondantes. Pour en savoir plus sur la configuration des filtres de métadonnées, consultez la section Configurer le filtrage des configurations en fonction de la correspondance MetadataFilter.

Limites

  • Certaines fonctionnalités décrites dans ce document ne peuvent pas être configurées pour les services gRPC sans proxy avec Traffic Director. Pour les fonctionnalités compatibles, consultez les sections Routage et gestion du trafic, Équilibrage de charge et d'autres tableaux dans Fonctionnalités de Traffic Director.

  • Pour connaître les autres limites spécifiques aux applications gRPC sans proxy avec Traffic Director, consultez la section Limites du guide de présentation.

Étape suivante