Présentation de la gestion du trafic pour les équilibreurs de charge HTTP(S) internes

L'équilibrage de charge HTTP(S) interne comprend des fonctionnalités de gestion avancée du trafic qui vous permettent d'exploiter les options suivantes :
  • Orientation du trafic. Acheminez intelligemment le trafic en fonction de paramètres HTTP(S) (hôte, chemin, en-têtes et autres paramètres de requête, par exemple).
  • Actions de trafic. Effectuez des actions basées sur les requêtes et les réponses (redirections et transformations d'en-tête, par exemple).
  • Règles de trafic. Ajustez le comportement de l'équilibrage de charge (algorithmes avancés d'équilibrage de charge, par exemple).

Vous pouvez configurer ces fonctionnalités à l'aide de mappages d'URL et de services de backend. Pour plus d'informations, consultez les articles suivants :

Exemples de cas d'utilisation

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

Orientation du trafic : routage basé sur l'en-tête

L'orientation du trafic vous permet de diriger le trafic vers des instances de service en fonction de paramètres HTTPS tels que des en-têtes de requête. Par exemple, si le paramètre user-agent:Mobile est présent dans l'en-tête de la requête, indiquant que celle-ci provient d'un appareil mobile, la fonctionnalité d'orientation du trafic peut envoyer ce trafic aux instances de service désignées pour gérer le trafic mobile, et envoyer le trafic qui ne contient pas user-agent:Mobile aux instances désignées pour gérer le trafic provenant d'autres appareils.

Orientation du trafic de Cloud Load Balancing (cliquez pour agrandir)
Orientation du trafic de Cloud Load Balancing

Actions de trafic : répartition du trafic en fonction d'une pondération

Le déploiement d'une nouvelle version d'un service de production comporte généralement des risques. Même si vos tests réussissent dans l'environnement de préproduction, vous ne souhaiterez sans doute pas soumettre immédiatement 100 % de vos utilisateurs à la nouvelle version. L'équilibrage de charge HTTP(S) interne vous permet de définir des répartitions du trafic basées sur des pourcentages entre plusieurs services backend.

Par exemple, vous pouvez envoyer 95 % du trafic vers la version précédente de votre service et 5 % vers la nouvelle version. Après avoir vérifié que la nouvelle version de production fonctionne comme prévu, vous pouvez modifier progressivement les pourcentages jusqu'à ce que 100 % du trafic atteigne la nouvelle version du service. La répartition du trafic est généralement utilisée pour le déploiement de nouvelles versions, les tests A/B, la migration de services et d'autres processus similaires.

Répartition du trafic Cloud Load Balancing
Répartition du trafic Cloud Load Balancing

Règles de trafic : mise en miroir des requêtes

Votre organisation peut imposer des exigences de conformité stipulant que l'ensemble du trafic doit être mis en miroir sur un service supplémentaire pouvant, par exemple, enregistrer les détails des requêtes dans une base de données en vue d'une consultation ultérieure.

Composants de gestion du trafic

De manière générale, les équilibreurs de charge HTTP(S) internes fournissent la gestion du trafic en exploitant des mappages d'URL régionaux et des services de backend régionaux.

Vous pouvez configurer l'orientation du trafic et les actions de trafic à l'aide de mappages d'URL régionaux. Les ressources Google Cloud suivantes sont associées aux mappages d'URL :

  • Règle de routage
  • Correspondance à une règle
  • Action de la règle

Vous pouvez configurer des règles de trafic à l'aide de services de backend régionaux. Les ressources Google Cloud suivantes sont associées aux services de backend :

  • Règles de l'équilibreur de charge de la zone
  • Paramètres de l'équilibreur de charge avec hachage cohérent
  • Disjoncteurs
  • Détection des anomalies
Le schéma suivant décrit les ressources utilisées pour la mise en œuvre de chaque fonctionnalité.

Orientation du trafic de Cloud Load Balancing (cliquez pour agrandir)
Modèle de données Cloud Load Balancing (cliquez pour agrandir)

Acheminer les requêtes vers les backends

Dans l'équilibrage de charge HTTP(S) interne, le backend de votre trafic est déterminé selon une approche en deux étapes :

  • L'équilibreur de charge sélectionne un service de backend avec des backends. Les backends peuvent être des instances de machine virtuelle (VM) Compute Engine dans un groupe d'instances non géré, des VM Compute Engine dans un groupe d'instances géré (MIG) ou des conteneurs via un nœud Google Kubernetes Engine (GKE) dans un groupe de points de terminaison du réseau (NEG). L'équilibreur de charge choisit un service de backend en fonction des règles définies dans un mappage d'URL régional.
  • Le service de backend sélectionne une instance backend en fonction des règles définies dans un service de backend régional.

Lorsque vous configurez le routage, vous avez le choix entre les modes suivants :

  • Règle d'hôte et de chemin d'accès simple
  • Règle avancée d'hôte, de chemin d'accès et de routage

Pour chaque mappage d'URL, vous pouvez choisir d'utiliser des règles d'hôte et de chemin d'accès simples, ou bien des règles avancées d'hôte, de chemin d'accès et de routage. Les deux modes s'excluent mutuellement. Chaque mappage d'URL ne peut être associé qu'à l'un d'eux.

Règle d'hôte et de chemin d'accès simple

Dans une règle d'hôte et de chemin d'accès simple, les mappages d'URL fonctionnent comme décrit dans la présentation des mappages d'URL.

Le schéma suivant illustre le flux logique d'une règle d'hôte et de chemin d'accès simple.

Flux d'un mappage d'URL simple
Flux d'un mappage d'URL simple

Une requête est initialement évaluée à l'aide de règles d'hôte. L'hôte est le domaine spécifié par la requête. Si la requête host correspond à l'une des entrées du champ hosts, l'outil de mise en correspondance des chemins d'accès associé est utilisé.

L'outil de mise en correspondance des chemins d'accès est ensuite évalué. Les règles de chemin d'accès sont évaluées sur la base de la première correspondance de chemin la plus longue et peuvent être spécifiées dans n'importe quel ordre. Une fois la correspondance la plus spécifique trouvée, la requête est acheminée vers le service de backend correspondant. Si la requête ne correspond pas, le service de backend par défaut est utilisé.

Une règle d'hôte et de chemin d'accès simple classique peut se présenter comme suit. Ici, le trafic vidéo est acheminé vers video-backend-service, tandis que le reste du trafic est acheminé vers web-backend-service.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Règle avancée d'hôte, de chemin d'accès et de routage

Les règles avancées d'hôte, de chemin d'accès et de routage fournissent des options de configuration supplémentaires par rapport aux règles simples d'hôte et de chemin d'accès. Ces options permettent d'utiliser des modèles de gestion du trafic plus avancés et de modifier une partie de la sémantique. Par exemple, les règles de routage sont associées à une priorité et sont interprétées dans l'ordre de priorité (plutôt que sur la base de la première correspondance de chemin la plus longue).

Tout comme dans l'exemple précédent de règle d'hôte et de chemin d'accès simple, vous pouvez configurer la gestion avancée du trafic à l'aide d'un mappage d'URL régional. Par exemple, le mappage d'URL suivant configure un routage où 95 % du trafic est acheminé vers un service de backend et où les 5 % restants sont dirigés vers un autre service de backend.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

Règles d'hôte

Lorsqu'une requête parvient à votre équilibreur de charge, le champ host de la requête est évalué par rapport aux règles d'hôte (hostRules) définies dans le mappage d'URL. Chaque règle d'hôte se compose d'une liste d'un ou de plusieurs hôtes et d'un outil de mise en correspondance des chemins d'accès (pathMatcher). Si aucune règle d'hôte (hostRules) n'est définie, la requête est acheminée vers le service par défaut defaultService.

Pour en savoir plus, consultez la description des ressources hostRules[] et defaultService dans la documentation de l'API sur les mappages d'URL régionaux.

Outils de mise en correspondance des chemins d'accès

Lorsqu'une requête correspond à une règle d'hôte, l'équilibreur de charge évalue l'outil de mise en correspondance des chemins d'accès correspondant à l'hôte.

Un outil de mise en correspondance des chemins d'accès comprend les éléments suivants :

  • Une ou plusieurs règles de chemin d'accès (pathRules) ou règles de routage (routeRules).
  • Un service par défaut (defaultService), qui est le service de backend par défaut utilisé lorsqu'aucun autre service de backend ne correspond.
Pour en savoir plus, consultez la description de pathMatchers[], pathMatchers[].pathRules[] et pathMatchers[].routeRules[] dans la documentation de l'API sur les mappages d'URL régionaux.

Règles du chemin d'accès

Les règles de chemin d'accès (pathRules) spécifient un ou plusieurs chemins d'URL, tels que / ou /video. Elles sont généralement destinées au type de routage simple basé sur l'hôte et le chemin d'accès (décrit précédemment).

Pour en savoir plus, consultez la description de pathRules[] dans la documentation de l'API sur les mappages d'URL régionaux.

Règles de routage

Une règle de routage (routeRules) correspond aux informations contenues dans une requête entrante et décide du routage en fonction de la correspondance.

Les règles de routage peuvent contenir différentes règles de correspondance (matchRules) et actions de routage (routeAction).

Une règle de correspondance évalue la requête entrante en fonction du chemin, des en-têtes et des paramètres de la requête HTTP(S). Ces règles acceptent différents types de correspondance (tels que la correspondance du préfixe) et modificateurs (comme l'insensibilité à la casse). Elles vous permettent par exemple d'envoyer des requêtes HTTP(S) à un ensemble de backends en fonction de la présence d'un en-tête HTTP personnalisé.

Si vous possédez plusieurs règles de routage, l'équilibreur de charge les exécute par ordre de priorité (en fonction du champ priority). Cela vous permet de spécifier la logique personnalisée pour la mise en correspondance, le routage et d'autres actions.

Dans une règle de routage donnée, lorsque la première correspondance est effectuée, l'équilibreur de charge arrête l'évaluation des règles de correspondance, et toutes les règles de correspondance restantes sont ignorées.

Google Cloud effectue les actions suivantes :

  1. Il recherche la première règle de correspondance qui correspond à la requête.
  2. Il cesse la recherche d'autres règles de correspondance.
  3. Il applique les actions définies par les actions de routage correspondantes.

Les règles de routage comptent plusieurs composants, comme décrit dans le tableau suivant.

Composant de règle de routage (API field name) Description
Priorité (priority) Nombre compris entre 0 et 2 147 483 647 (soit (2^31)-1) attribué à une règle de routage dans un outil de mise en correspondance des chemins d'accès donné.

La priorité détermine l'ordre d'évaluation des règles de routage. La priorité d'une règle diminue à mesure que le numéro qui lui est attribué augmente. Ainsi, une règle ayant la priorité 4 est évaluée avant une règle avec la priorité 25. La première règle qui correspond à la requête est appliquée.

Il est possible que les numéros de priorité ne soient pas consécutifs. Vous ne pouvez pas créer plusieurs règles avec la même priorité.
Description (description) Description facultative comportant jusqu'à 1 024 caractères.
Service (service) URL complète ou partielle de la ressource de service de backend vers laquelle le trafic est dirigé si la règle correspond.
Règles de correspondance (matchRules) Une ou plusieurs règles évaluées par rapport à la requête. Ces règles de correspondance (matchRules) peuvent correspondre à tous les attributs ou à un sous-ensemble d'attributs HTTP de la requête, tels que le chemin d'accès, les en-têtes HTTP et les paramètres de requête (GET).

Dans une règle de correspondance (matchRule), tous les critères de correspondance doivent être remplis pour que les actions de routage (routeRule) de la règle de routage (routeActions) prennent effet. Si une règle de routage routeRule comporte plusieurs règles de correspondance (matchRules), les actions de routage (routeActions) de la règle de routage (routeRule) prennent effet lorsqu'une requête correspond à l'une des règles de correspondance (routeRule) de la règle de routage (matchRules).
Action de routage (routeAction) Permet de spécifier les actions à effectuer lorsque les critères définis dans les règles de correspondance sont remplis. Ces actions incluent la répartition du trafic, les réécritures d'URL, les tentatives répétées et la mise en miroir, l'injection de pannes ainsi que les règles CORS.
Action de redirection (urlRedirect) Vous pouvez configurer une action pour répondre avec une redirection HTTP lorsque les critères définis dans les règles de correspondance sont remplis. Ce champ ne peut pas être utilisé conjointement avec une action de routage.
Action d'en-tête (headerAction) Vous pouvez configurer des règles de transformation d'en-tête de requête et de réponse lorsque les critères définis dans les règles de correspondance (matchRules) sont remplis.

Pour en savoir plus, consultez les champs suivants dans la documentation de l'API sur les mappages d'URL régionaux :

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

Règles de correspondance

Les règles de correspondance (matchRules) permettent de mettre en correspondance un ou plusieurs attributs d'une requête et d'appliquer les mesures spécifiées dans la règle de routage. La liste suivante fournit quelques exemples d'attributs de requête pouvant être mis en correspondance à l'aide de règles de correspondance :

  • Hôte : un nom d'hôte correspond à la partie de nom de domaine d'une URL. Par exemple, dans l'URL http://example.net/video/hd, le nom d'hôte est example.net. Dans la requête, le nom d'hôte provient de l'en-tête Host, comme décrit dans l'exemple de commande curl, où 10.1.2.9 correspond à l'adresse IP avec équilibrage de charge :

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Les chemins suivent le nom d'hôte. Par exemple, /images. La règle peut spécifier si le chemin d'accès complet doit correspondre ou si la correspondance de la première partie est suffisante.

  • D'autres paramètres de requête HTTP, tels que les en-têtes HTTP, permettent la mise en correspondance à l'aide de cookies, ainsi qu'en fonction des paramètres de requête (variables GET).

Pour obtenir la liste complète des règles de correspondance compatibles, consultez pathMatchers[].routeRules[].matchRules[] dans la documentation de l'API sur les mappages d'URL régionaux.

Actions de routage

Les actions de routage sont des actions spécifiques à effectuer lorsqu'une règle de routage correspond aux attributs d'une requête.

Action de routage (API field name) 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 pondérée (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'équilibreur de charge 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.
Injection de délais (faultInjectionPolicy) Introduit des retards dans une fraction de requêtes définie par l'utilisateur avant de les envoyer au service de backend sélectionné.
Injection d'abandons (faultInjectionPolicy) Répond directement à une fraction des requêtes avec des codes d'état HTTP définis par l'utilisateur au lieu de les transférer au service de backend.
Règles de sécurité (corsPolicy) Les règles de partage des ressources entre origines multiples (CORS, Cross-origin resource sharing) gèrent les paramètres d'équilibrage de charge HTTP(S) interne pour l'application des requêtes CORS.

Vous pouvez spécifier l'une des actions de routage suivantes (appelées actions principales dans Google Cloud Console) :

  • Acheminer le trafic vers un service unique (service)
  • Répartir le trafic entre plusieurs services (weightedBackendServices weight:x, où x < 100).
  • Rediriger des URL (urlRedirect)

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

  • 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)
  • Manipuler les en-têtes de requête/réponse (headerAction)

Pour en savoir plus sur la configuration et la sémantique des actions de routage, consultez les ressources suivantes dans la documentation de l'API sur les mappages d'URL régionaux :

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Règles de trafic

En utilisant des ressources de service de backend, vous pouvez configurer des règles de trafic, qui permettent d'ajuster l'équilibrage de charge au sein d'un groupe d'instances ou d'un groupe de points de terminaison du réseau. Ces règles ne prennent effet qu'après la sélection d'un service de backend à l'aide de votre mappage d'URL régional (comme décrit précédemment).

Les règles de trafic vous permettent d'effectuer les opérations suivantes :

  • Contrôler l'algorithme d'équilibrage de charge pour les instances du service de backend
  • Contrôler le volume des connexions à un service en amont
  • Contrôler l'éviction des hôtes défaillants d'un service de backend

Les fonctionnalités des règles de trafic suivantes sont configurées dans le service de backend régional.

Règle de trafic (API field name) Description
Règle d'équilibrage de charge (LocalityLbPolicy) Pour un service de backend, la répartition du trafic est basée sur un mode d'équilibrage de charge et sur une règle d'équilibrage de charge.

Le service de backend dirige tout d'abord le trafic vers un backend (groupe d'instances ou groupe de points de terminaison du réseau) en fonction du mode d'équilibrage du backend. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances du service de backend conformément à la règle d'équilibrage de charge.

Le mode d'équilibrage permet à l'équilibrage de charge de sélectionner tout d'abord une localité, telle qu'une zone Google Cloud. Ensuite, la règle d'équilibrage de charge détermine une VM de backend spécifique ou un point de terminaison d'un groupe de points de terminaison du réseau.

Différents algorithmes d'équilibrage de charge (tels que les appels aléatoires, le nombre minimal de requêtes et d'autres) sont acceptés. Pour obtenir la liste complète des algorithmes, consultez la description de localityLbPolicy dans la documentation de l'API sur le service de backend régional.
Affinité de session (consistentHash) Inclut l'affinité basée sur les cookies HTTP, l'affinité basée sur un en-tête HTTP, l'affinité d'adresse IP cliente et l'affinité basée sur les cookies générés. L'affinité de session tente au mieux d'envoyer les requêtes d'un client donné au même backend, à condition qu'il soit opérationnel et dispose d'une capacité suffisante.

Pour en savoir plus sur l'affinité de session, consultez la description de consistentHash dans la documentation de l'API sur le service de backend régional.
Détection des anomalies (outlierDetection) Ensemble des règles qui spécifient les critères d'exclusion des VM de backend non opérationnelles ou des points de terminaison défaillants dans les groupes de points de terminaison du réseau, ainsi que les critères définissant à quel moment un backend ou un point de terminaison est considéré comme suffisamment opérationnel pour recevoir à nouveau du trafic.

Pour en savoir plus sur l'affinité de session, consultez la description de outlierDetection dans la documentation de l'API sur le service de backend régional.
Ruptures de circuit (circuitBreakers) Définit les limites supérieures pour le volume de connexions et de requêtes par connexion à un service de backend.

Pour en savoir plus sur l'affinité de session, consultez la description de circuitBreakers dans la documentation de l'API sur le service de backend régional.

Limites

  • À l'heure actuelle, RouteRule.service ne fonctionne pas. La solution consiste à utiliser le paramètre RouteRule.weightedBackendServices avec un seul service WeightedBackendService.
  • Les expressions régulières de chemin pathMatchers.routeRules.matchRules.regexMatch ne sont pas compatibles avec l'équilibrage de charge HTTP(S) interne.
  • À l'heure actuelle, UrlMap.defaultRouteAction et UrlMap.defaultUrlRedirect ne fonctionnent pas. Vous devez spécifier UrlMap.defaultService pour gérer le trafic qui ne correspond à aucune règle UrlMap.hostRules[] pour ce mappage d'URL (UrlMap).
  • À l'heure actuelle, UrlMap.pathMatchers[].defaultRouteAction et UrlMap.pathMatchers[].defaultUrlRedirect ne fonctionnent pas. Vous devez spécifier UrlMap.pathMatchers[].defaultService pour gérer le trafic qui ne correspond à aucune règle routeRules pour ce mappage d'URL (pathMatcher).
  • Si la valeur de BackendService.SessionAffinity n'est pas "NONE" et que BackendService.localityLbPolicy est défini sur une règle d'équilibrage de charge autre que MAGLEV ou RING_HASH, les paramètres d'affinité de session ne sont pas appliqués.
  • La commande gcloud compute backend-services import ne supprime pas les champs de premier niveau de la ressource, tels que le service de backend et le mappage d'URL. Par exemple, si vous créez un service de backend avec des paramètres pour circuitBreakers, vous pouvez mettre à jour ces paramètres à l'aide d'une commande gcloud compute backend-services import ultérieure. Toutefois, vous ne pouvez pas supprimer ces paramètres du service de backend. Vous pouvez supprimer et recréer la ressource sans les paramètres circuitBreakers.

Étape suivante