- 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 HTTP, 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.
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. La gestion du trafic vous permet de définir des répartitions du trafic basées sur des pourcentages entre plusieurs services de 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è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.
Extensibilité avec des extensions de service
L'intégration avec les extensions de service vous permet d'insérer une logique personnalisée dans le chemin d'accès aux données d'équilibrage de charge des équilibreurs de charge d'application compatibles.
Pour en savoir plus, consultez la page de Présentation des extensions de service.
Composants de gestion du trafic
De manière générale, les équilibreurs de charge assurent la gestion du trafic en exploitant des mappages d'URL régionaux et des services de backend régionaux.Pour les équilibreurs de charge d'application internes interrégionaux, la gestion du trafic utilise les ressources suivantes : les mappages d'URL globaux et les services de backend globaux.
Vous pouvez configurer l'orientation du trafic et les actions de trafic à l'aide de mappages d'URL. 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. Les ressources Google Cloud suivantes sont associées aux services de backend :
- Disjoncteurs
- Règles de l'équilibreur de charge de la zone
- Paramètres de l'équilibreur de charge avec hachage cohérent
- Détection des anomalies
Le schéma suivant décrit les ressources utilisées pour la mise en œuvre de chaque fonctionnalité.
Acheminer les requêtes vers les backends
Dans les équilibreurs de charge d'application internes régionaux, 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
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.
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 lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-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. 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 lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-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.
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.
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).
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é.
Remarque : Les options de correspondance et la sémantique varient selon la partie de la requête que vous faites correspondre. Pour en savoir plus, consultez la description dematchRules[] dans la documentation de l'API sur les mappages d'URL régionaux.
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 :
- Il recherche la première règle de correspondance qui correspond à la requête.
- Il cesse la recherche d'autres règles de correspondance.
- 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.
|
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].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 estexample.net. Dans la requête, le nom d'hôte provient de l'en-têteHost, comme décrit dans l'exemple de commande curl, où10.1.2.9correspond à 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).
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. Notez les limitations suivantes lorsque vous utilisez le durcissement du trafic:
|
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) permettent de gérer les paramètres d'application des requêtes CORS. |
Vous pouvez spécifier l'une des actions de routage suivantes :
- Acheminer le trafic vers un service unique (
service) - Répartir le trafic entre plusieurs services (
weightedBackendServices weight:x, où x doit être compris entre 0 et 1 000). - Rediriger des URL (
urlRedirect)
Vous pouvez également combiner l'une des actions de routage ci-dessus aux actions de routage suivantes :
- Mettre en miroir le trafic (
requestMirrorPolicy) - Réécrire l'hôte et 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 ou de réponse (
headerAction)
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Redirections HTTP vers HTTPS
Si vous devez rediriger le trafic HTTP vers HTTPS, vous pouvez créer deux règles de transfert avec une adresse IP commune.
Pour que deux règles de transfert partagent une adresse IP interne commune, vous devez réserver l'adresse IP et inclure l'option--purpose=SHARED_LOADBALANCER_VIP :
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Pour obtenir un exemple complet, consultez la page Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge d'application internes.
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 (NEG). Ces règles ne prennent effet qu'après la sélection d'un service de backend à l'aide de votre mappage d'URL (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
Règle de trafic (API field name) |
Description |
|---|---|
Règle d'équilibrage de charge de la localité (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 de localité d'équilibrage de charge. Le mode d'équilibrage détermine la pondération/la fraction du trafic à envoyer à chaque backend (groupe d'instances ou NEG Pour connaître les modes d'équilibrage compatibles, consultez la section Mode d'équilibrage. Pour connaître les algorithmes des règles d'équilibrage de charge compatibles, consultez la description de |
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, l'affinité de session basée sur les cookies avec état 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
|
Détection des anomalies (outlierDetection) |
Un ensemble de règles qui spécifient les critères d'exclusion des VM backend ou des points de terminaison défaillants dans les NEG, ainsi que des critères permettant de définir à quel moment un backend ou un point de terminaison est considéré comme suffisamment opérationnel pour recevoir à nouveau le trafic. Pour en savoir plus sur la détection des anomalies, consultez la description de |
Ruptures de circuit (circuitBreakers) |
Définit les limites supérieures du volume de connexions et de requêtes par connexion à un service de backend. Pour en savoir plus sur les ruptures de circuit, consultez la description de |
Étapes suivantes
- Consultez la page Configurer la gestion du trafic pour les équilibreurs de charge d'application internes pour savoir comment configurer la gestion du trafic pour les équilibreurs de charge d'application internes.