Présentation de la gestion du trafic pour un équilibreur de charge d'application classique

Cette page présente les fonctionnalités de gestion du trafic disponibles pour l'équilibreur de charge d'application classique. Cette page est réservée aux équilibreurs de charge d'application classiques. Si vous utilisez un équilibreur de charge dans un mode différent, compatible avec l'ensemble étendu de fonctionnalités de gestion du trafic, consultez l'une des pages suivantes :

Les équilibreurs de charge d'application classiques sont compatibles avec la fonction de gestion du trafic qui vous permettent d'utiliser les fonctionnalités suivantes :

Vous configurez ces fonctionnalités à l'aide du mappage d'URL de l'équilibreur de charge. Pour plus d'informations, consultez les rubriques suivantes :

Composants de gestion du trafic

De manière générale, les équilibreurs de charge d'application externes assurent la gestion du trafic en utilisant des mappages d'URL globaux.

L'équilibreur de charge permet d'effectuer les actions principales mutuellement exclusives suivantes :

  • Acheminer les requêtes vers un service de backend
  • Effectuer une redirection

Lorsque vous configurez un équilibreur de charge, vous pouvez configurer une action de réécriture d'URL avant que l'équilibreur de charge n'envoie des requêtes au service de backend ou au bucket backend.

Les réécritures ou les redirections peuvent être appliquées à trois niveaux dans le mappage d'URL :

  • Au niveau de la règle de chemin d'accès (pathRule) où l'action prend effet lorsqu'un chemin est mis en correspondance.
  • Au niveau de l'outil de mise en correspondance des chemins d'accès (pathMatcher) où l'action prend effet lorsqu'aucun chemin ne correspond à cet pathMatcher.
  • Au niveau du mappage d'URL (urlMap) où l'action prend effet lorsqu'aucun des hôtes spécifiés dans l'une des règles d'hôte ne correspond.

L'utilisation de règles de routage (routeRules) dans un outil de mise en correspondance des chemins d'accès (pathMatcher) est une alternative à l'utilisation de règles de chemin d'accès (pathRules). Les règles de chemin d'accès (pathRules) et les règles de routage (routeRules) ne peuvent pas apparaître dans le même outil de mise en correspondance des chemins d'accès (pathMatcher). Contrairement aux règles de chemin d'accès (pathRules), pour lesquelles l'ordre n'a pas d'importance, les règles de routage (routeRules) sont examinées dans l'ordre. Une règle de routage (routeRule) peut tester le chemin d'URL, les en-têtes HTTP et les paramètres de requête d'URL.

Exemples de cas d'utilisation

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

Réécritures

Les réécritures d'URL vous permettent de présenter aux utilisateurs externes des URL différentes de celles utilisées par vos services.

Une réécriture d'URL sépare une URL d'une ressource. Vous pouvez partir d'URL conviviales, faciles à mémoriser et à utiliser, et les transformer en URL conviviales pour les moteurs de recherche, ou en URL internes spécifiques à la mise en œuvre.

La fonctionnalité de réécriture d'URL effectue les opérations suivantes :

  1. Lit l'URL entrante dans la requête.
  2. Remplace l'hôte, le chemin d'accès ou les deux, transformant l'URL avant de diriger le trafic vers le service de backend ou le bucket backend.

Dans le schéma suivant :

  1. Un utilisateur au Japon envoie une requête à l'URL www.mydomain.com/static/images/someimage.jpg.
  2. Lorsque la requête atteint l'équilibreur de charge d'application externe, celui-ci utilise les informations du mappage d'URL pour réécrire l'URL en www.myorigin.com/august_snapshot/images/someimage.jpg.
  3. (Facultatif) Dans cet exemple, le mappage d'URL envoie la requête à un backend externe.
Réécriture d'URL avec l'équilibreur de charge d'application classique
Figure 1. Réécriture d'URL avec l'équilibreur de charge d'application classique

Pour obtenir un exemple de configuration, consultez la documentation sur les réécritures.

Redirections

Avec les redirections d'URL, vous pouvez rediriger les requêtes des clients d'une URL vers une autre URL.

Cela inclut les capacités suivantes :

  • Rediriger toutes les requêtes HTTP vers des requêtes HTTPS.
  • Rediriger vers une URL différente formée en modifiant la partie d'hôte, la partie de chemin ou les deux de l'URL, et en supprimant ou en conservant tous les paramètres de requête.
  • Choisir les codes de réponse de redirection à émettre.

Utilisez les redirections d'URL pour les fonctionnalités suivantes :

  • Fournir un raccourcissement d'URL. Les URL destinées aux clients peuvent être considérablement plus courtes. Ce service émet une redirection vers la page Web avec l'URL longue.
  • Empêcher les liens non fonctionnels lorsque les pages Web sont déplacées ou deviennent obsolètes.
  • Autoriser plusieurs noms de domaine appartenant au même propriétaire à se référer à un seul site Web.
  • Éviter les tâches laborieuses et l'inefficacité liées à la configuration des solutions de contournement sur le serveur de backend pour prendre en charge la redirection nécessaire.
  • Réduire la latence. Les redirections créées à la périphérie peuvent entraîner une latence inférieure par rapport aux redirections créées au niveau des points de terminaison de backend.

Les redirections HTTP vers HTTPS vous permettent tout particulièrement de :

  • Répondre aux exigences de conformité (telles que la loi HIPAA) pour le trafic chiffré.
  • Rediriger les requêtes à l'aide de HTTPS au lieu de rejeter les requête envoyées avec le protocole HTTP.
  • Améliorer le profil de sécurité de votre application en redirigeant le trafic au niveau de l'équilibreur de charge de couche 7, par opposition à l'implémentation de la redirection sur le serveur de backend.

Dans le schéma suivant :

  1. Un utilisateur au Japon envoie une requête GET http://example.com/img1.
  2. En fonction de la redirection définie dans le mappage d'URL, l'équilibreur de charge renvoie une redirection HTTP/1.1 302 Found Location: https://example.com/img1, redirigeant la requête HTTP vers une requête HTTPS.
  3. Le navigateur de l'utilisateur envoie une requête GET https://example.com/img1.
Redirection d'URL avec l'équilibreur de charge d'application classique
Figure 2. Redirection d'URL avec l'équilibreur de charge d'application classique

Pour obtenir un exemple de configuration, consultez la documentation sur les redirections.

Codes de réponse acceptés

Les codes de réponse de redirection acceptés sont répertoriés dans ce tableau.

Code de réponse Nombre Remarques
MOVED_PERMANENTLY_DEFAULT 301
FOUND 302
PERMANENT_REDIRECT 308 Dans ce cas, la méthode de requête est conservée.
TEMPORARY_REDIRECT 307 Dans ce cas, la méthode de requête est conservée.
SEE_OTHER 303

Routage basé sur les en-têtes et les paramètres

Le routage basé sur les en-têtes et les paramètres permet à un équilibreur de charge de prendre des décisions de routage basées sur des en-têtes HTTP et des paramètres de requête d'URL.

Grâce à cette fonctionnalité, vous pouvez simplifier votre architecture cloud, sans déployer de niveaux supplémentaires de proxys (NGINX, par exemple) pour effectuer le routage.

Vous pouvez utiliser l'équilibreur de charge d'application externe pour effectuer les opérations suivantes :

  • tests A/B
  • Attribution de clients à différents ensembles de services exécutés sur des backends
  • Fournir différentes pages et expériences basées sur différentes catégories d'appareils à partir desquelles proviennent les requêtes

Une fois qu'un outil de mise en correspondance des chemins d'accès (pathMatcher) est sélectionné en fonction de la chaîne de l'hôte, les règles de routage (routeRules) dans l'outil (pathMatcher) sélectionnent un chemin d'URL. Pour en savoir plus, consultez la présentation des mappages d'URL.

Exemple : Configurer des tests A/B avec un routage basé sur les paramètres de requête

L'exemple suivant montre comment effectuer des tests A/B en faisant correspondre la chaîne de requête pour spécifier le test et l'entrée.

Supposons que vous souhaitiez vous assurer que les requêtes sont traitées comme suit :

  • Toutes les requêtes dont la valeur du paramètre de requête est A vont au service de backend appelé BackendServiceForProcessingOptionA.
  • Toutes les requêtes dont la valeur du paramètre de requête est B vont au service de backend appelé BackendServiceForProcessingOptionB.

Ces exigences sont résumées dans le tableau suivant.

Requête Service de backend
http://test.mydomain.com?ABTest=A BackendServiceForProcessingOptionA
http://test.mydomain.com?ABTest=B BackendServiceForProcessingOptionB

Pour configurer ce paramètre dans votre mappage d'URL global, vous pouvez créer les paramètres suivants.

Correspondance Action
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A		 pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B		 pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB

Pour obtenir un exemple de configuration, consultez la section Routage basé sur les en-têtes et les paramètres.

Acheminer les requêtes vers les backends

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 les suivants :

    • Instances de machine virtuelle (VM) Compute Engine dans un groupe d'instances non géré
    • VM Compute Engine dans un groupe d'instances géré
    • Conteneurs utilisant un nœud Google Kubernetes Engine (GKE) dans un groupe de points de terminaison de réseau (network endpoint group, NEG) zonal
    • Backends externes en dehors de Google Cloud dans un NEG Internet
    • Cloud Storage dans les buckets backend
    • Services App Engine, Cloud Run Functions ou Cloud Run dans un NEG sans serveur

    L'équilibreur de charge choisit un service de backend basé sur des règles définies dans un mappage d'URL global.

  • Le service de backend sélectionne une instance de backend en fonction des stratégies définies dans un service de backend global.

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

  • Test simple de l'hôte et du chemin d'accès, à l'aide de pathRules
  • Test de requête avancé, à l'aide de routeRules

Pour chaque mappage d'URL, vous pouvez choisir d'utiliser des règles simples d'hôte et de chemin d'accès, 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 de mappage d'URL avec une règle d'hôte et de chemin d'accès simple.
Figure 3. Flux de mappage d'URL avec une règle d'hôte et de chemin d'accès 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 ext-https-map

defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Pour obtenir un exemple de configuration, consultez la documentation sur les hôtes et les chemins d'accès.

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 exécutées dans l'ordre (plutôt que sur la base de la première correspondance de chemin la plus longue).

Comme dans l'exemple précédent de la 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 global, mais vous utilisez pathMatchers[].routeRules[] au lieu d'utiliser pathMatchers[].pathRules[].

Les sections suivantes décrivent les composants des règles d'hôte, de chemin d'accès et de routage avancées.

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 plus d'informations, consultez hostRules[] et defaultService dans la documentation de l'API sur les mappages d'URL globaux.

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 composants suivants :

  • Une ou plusieurs règles de chemin d'accès (pathRules) ou règles de routage (routeRules).

  • Une règle par défaut qui s'exécute lorsqu'aucun autre service de backend ne correspond. La règle a les options mutuellement exclusives suivantes :

    • Un service par défaut spécifie le service de backend par défaut vers lequel effectuer l'acheminement lorsqu'aucun autre service de backend ne correspond.
    • Une redirection par défaut spécifie l'URL vers laquelle effectuer la redirection lorsqu'aucun autre service de backend ne correspond.

Lorsque l'équilibreur de charge est configuré pour un service par défaut, il peut en outre être configuré pour réécrire l'URL avant d'envoyer la requête au service par défaut.

Pour plus d'informations, consultez pathMatchers[], pathMatchers[].pathRules[] et pathMatchers[].routeRules[] dans la documentation de l'API sur les mappages d'URL globaux.

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 plus d'informations, consultez pathRules[] dans la documentation de l'API sur les mappages d'URL globaux.

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

Pour une liste détaillée des options prises en charge par matchRules, consultez matchRules[] dans la documentation de l'API sur les mappages d'URL globaux.

Si vous disposez de plusieurs règles de routage, l'équilibreur de charge les exécute dans l'ordre, ce qui vous permet de spécifier une 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) Numéro compris entre 0 et 2 147 483 647 (c'est-à-dire, (2^31)-1) attribué à une règle de routage dans un outil de mise en correspondance de chemin donné pour déterminer l'ordre d'évaluation de la règle de routage.

La priorité la plus élevée est 0. La priorité la plus faible est 2147483647. Par exemple, une règle de priorité 4 est évaluée avant une règle de priorité 25. La première règle qui correspond à la requête est appliquée.

Les numéros de priorité peuvent comporter des blancs. ils n'ont pas besoin d'être contigus. 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 une action de réécriture d'URL à effectuer lorsque les critères de la règle de correspondance sont remplis.
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.

Pour plus d'informations, consultez les champs suivants dans la documentation de l'API sur les mappages d'URL globaux :

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

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). Notez que la correspondance des expressions régulières pour les valeurs d'en-tête n'est pas acceptée.

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 globaux.

Configurer la gestion du trafic

Vous pouvez utiliser la console Google Cloud, gcloud ou l'API Cloud Load Balancing pour configurer la gestion du trafic. Dans l'environnement de configuration que vous avez choisi, vous configurez la gestion du trafic à l'aide de configurations YAML.

Pour obtenir de l'aide concernant l'écriture de ces fichiers YAML, vous pouvez utiliser les ressources suivantes :