Présentation de l'équilibrage de charge avancé

L'équilibrage de charge avancé comprend des fonctionnalités qui vous permettent d'affiner l'équilibrage de charge et la distribution du trafic à l'échelle mondiale afin de répondre au mieux à vos objectifs de disponibilité, de performances et de rentabilité. Ce document s'adresse aux utilisateurs qui ont au moins une compréhension intermédiaire des concepts de Cloud Service Mesh et d'équilibrage de charge.

Pour implémenter l'équilibrage de charge avancé, vous devez créer une règle d'équilibrage de charge de service (ressource serviceLbPolicies), qui contient des valeurs qui influencent la sélection d'un backend. Vous associez ensuite la règle d'équilibrage de charge de service à un service de backend. La règle d'équilibrage de charge de service spécifie l'algorithme utilisé pour déterminer la façon dont le trafic est équilibré vers les backends.

Vous pouvez choisir parmi les options d'algorithme suivantes pour l'équilibrage de charge avancé :

  • Cascade par région (algorithme par défaut).
  • Répartition dans la région
  • Répartition dans le monde.
  • Cascade par zone.

Les options supplémentaires suivantes sont disponibles :

  • Désignez des backends préférés. Cloud Service Mesh envoie le trafic à ces CMG ou NEG avant de l'envoyer à d'autres backends.
  • Configurez le drainage de capacité automatique.
  • Personnalisez le comportement de basculement.

Avant de configurer l'une des options d'équilibrage de charge avancées, nous vous recommandons de consulter la documentation sur la ressource de service de backend.

Routage et équilibrage de charge du trafic par Cloud Service Mesh

Le schéma suivant montre comment Cloud Service Mesh décide d'acheminer le trafic.

Comment Cloud Service Mesh prend des décisions en matière d'équilibrage de charge
Comment Cloud Service Mesh prend des décisions d'équilibrage de charge (cliquez pour agrandir)

Tout d'abord, Cloud Service Mesh choisit un service de backend en fonction des caractéristiques de la requête et des règles de routage dans la ressource Route ou le mappage d'URL, selon l'API utilisée par votre déploiement.

Ensuite, Cloud Service Mesh choisit un MIG ou un NEG de backend associé au service de backend, en fonction de l'emplacement du client, de l'emplacement, de l'état et de la capacité du MIG ou du NEG, ainsi que des informations contenues dans la règle d'équilibrage de charge du service associée au service de backend.

Enfin, Cloud Service Mesh choisit une instance ou un point de terminaison dans le MIG ou le NEG. Ce choix est basé sur les informations de la règle d'équilibrage de charge de la localité dans les services de backend.

Backends compatibles et non compatibles

Les types de backend suivants sont compatibles avec l'équilibrage de charge avancé :

  • Groupes d'instances non gérés
  • Groupes d'instances gérés (MIG)
  • Groupes de points de terminaison du réseau (NEG) zonaux (NEG GCE_VM_IP_PORT)
  • Groupes de points de terminaison du réseau de connectivité hybride (NEG NON_GCP_PRIVATE_IP_PORT)

Les types de backend suivants ne sont pas compatibles avec l'équilibrage de charge avancé :

  • Groupes d'instances gérés régionaux
  • Groupes de points de terminaison du réseau Internet (NEG INTERNET_FQDN_PORT)

Cas d'utilisation

Les sections suivantes décrivent le fonctionnement de chaque algorithme et celui à choisir en fonction des besoins spécifiques de votre entreprise.

Équilibrer le trafic entre les backends d'une région

L'algorithme d'équilibrage de charge par défaut, "en cascade par région", répartit le trafic de manière uniforme entre tous les MIG ou NEG des zones d'une région. Nous vous recommandons d'utiliser l'algorithme par défaut, sauf si vous avez des exigences particulières.

Avec la cascade par région, les backends reçoivent du trafic en fonction de leur capacité, ce qui permet de les protéger contre la surcharge. Le trafic est envoyé au-delà des limites de zone lorsque cela est nécessaire pour que les backends soient chargés de manière uniforme dans la région. Même si la zone locale du client dispose d'une capacité restante, il existe un trafic interzones. Les requêtes de chaque client peuvent être réparties sur plusieurs MIG ou NEG zonaux de la région, ce qui permet de maintenir une charge uniforme sur les MIG ou les NEG lorsque la charge de trafic des clients n'est pas uniforme.

Améliorez la résilience en répartissant le trafic d'un client sur plusieurs zones

L'algorithme de cascade par région par défaut tente d'équilibrer l'utilisation de la capacité entre plusieurs MIG ou NEG zonaux. Toutefois, avec cet algorithme, les requêtes provenant d'un même client ne sont pas systématiquement envoyées à toutes les zones. Elles sont généralement acheminées vers des MIG ou des NEG dans une seule zone.

Utilisez l'algorithme de répartition par région lorsque vous souhaitez que les clients répartissent leurs requêtes sur tous les MIG ou NEG d'une région. Cela réduit le risque de surcharge des MIG ou NEG dans une seule zone en cas d'augmentation rapide et localisée du volume de trafic.

Avec l'algorithme de répartition du trafic par région, si vous avez deux zones, A et B, et qu'il y a un pic de trafic dans la zone B, le trafic est réparti entre les deux zones. Avec l'algorithme par défaut, un pic dans la zone B peut déclencher une surcharge dans la zone avant que Cloud Service Mesh puisse répondre à la modification.

Notez que lorsque vous utilisez l'algorithme de répartition par région, le trafic de chaque client est toujours réparti entre les zones de backend d'une région. Cela entraîne un trafic entre zones systématiquement plus élevé, même lorsqu'il reste de la capacité dans la zone locale. Cela peut également entraîner une zone affectée plus grande pour le trafic provenant de Cloud Service Mesh, si deux clients Cloud Service Mesh envoient du trafic vers les mêmes zones.

Répartissez le trafic de votre client sur tous les backends de plusieurs régions

Comme indiqué dans les sections précédentes, l'algorithme de répartition du trafic vers une région répartit le trafic de chaque client sur toutes les zones d'une région. Pour les services qui comportent des MIG ou des NEG dans plusieurs régions, Cloud Service Mesh optimise toujours la latence globale en envoyant le trafic vers la région la plus proche.

Si vous préférez un rayon de dispersion plus grand, utilisez l'algorithme de pulvérisation sur le monde. Avec cet algorithme, les clients répartissent leurs requêtes sur tous les MIG ou NEG du monde dans plusieurs régions.

Il est important de noter qu'avec cet algorithme, tout le trafic est réparti sur tous les backends à l'échelle mondiale. Une requête défectueuse peut endommager tous les backends de vos déploiements. L'algorithme entraîne également un trafic plus important entre les régions, ce qui peut augmenter la latence des requêtes et générer des coûts supplémentaires.

Réduisez au maximum le trafic de sortie interzone

Vous pouvez optimiser la latence globale et réduire le trafic inter-zones en utilisant le paramètre "Cascade par zone". Lorsque plusieurs MIG ou NEG sont configurés dans une zone, le trafic client est acheminé vers le MIG ou le NEG le plus proche de la zone, jusqu'à sa capacité, avant d'être envoyé au MIG ou au NEG suivant de la zone, jusqu'à ce que toute la capacité des MIG ou des NEG de la zone soit utilisée. Le trafic n'est déversé vers la zone la plus proche qu'à ce moment-là.

Cet algorithme vous permet de réduire au maximum le trafic interzone inutile. La latence globale peut être légèrement améliorée, car les backends locaux les plus proches sont privilégiés. Toutefois, cela peut également créer un trafic inégal entre les MIG ou les NEG d'une région.

Comparaison des algorithmes d'équilibrage de charge

Le tableau suivant fournit une comparaison détaillée des quatre algorithmes d'équilibrage de charge Cloud Service Mesh.

Comportement Cascade par région Répartition dans la région Répartition dans le monde Cascade par zone
Utilisation uniforme de la capacité dans une région à l'état stable Oui Oui Oui Non
Utilisation uniforme de la capacité dans plusieurs régions en état stable Non Non Oui Non
Répartition uniforme du trafic dans une région en état stable Non Oui Oui Non
Trafic interzone Oui. Cet algorithme répartit le trafic de manière uniforme entre les zones d'une région tout en optimisant la latence du réseau. Le trafic peut être envoyé dans plusieurs zones si nécessaire. Oui Oui Oui, le trafic remplira la zone la plus proche jusqu'à sa capacité maximale. Il passera ensuite à la zone suivante.
Sensibilité aux pics de trafic dans les zones locales Moyenne ; cela dépend du volume de trafic déjà déplacé vers les zones. Inférieure ; les pics de zone uniques sont répartis sur toutes les zones de la région. Inférieure ; les pics de zone uniques sont répartis sur toutes les régions. Élevée ; les pics de zone unique sont plus susceptibles d'être diffusés entièrement par une seule zone jusqu'à ce que Cloud Service Mesh soit en mesure de réagir.

Autres options avancées d'équilibrage de charge

Les sections suivantes présentent les options permettant de modifier l'équilibrage de charge Cloud Service Mesh.

Backends préférés

Vous pouvez configurer l'équilibrage de charge de sorte qu'un groupe de backends d'un service de backend soit désigné comme préféré. Ces backends sont entièrement utilisés avant que les requêtes suivantes ne soient acheminées vers les backends restants. Cloud Service Mesh distribue le trafic client aux backends préférés en premier, ce qui minimise la latence des requêtes pour vos clients.

Tout trafic dépassant la capacité configurée des backends préférés est acheminé vers les backends non préférés. L'algorithme d'équilibrage de charge répartit le trafic entre les backends non préférés.

Un cas d'utilisation est le débordement vers Google Cloud, où vous spécifiez que les ressources de calcul sur site, représentées par un NEG de connectivité hybride, doivent être entièrement utilisées avant que les requêtes ne soient acheminées vers des MIG ou des NEG de backend Google Cloud autoscalés. Cette configuration peut minimiser la consommation de ressources de calcul Google Cloud tout en conservant la résilience nécessaire pour déborder ou basculer progressivement versGoogle Cloud si nécessaire.

Drainage automatique de la capacité

Lorsqu'un backend n'est pas opérationnel, il est généralement souhaitable de l'exclure le plus rapidement possible des décisions d'équilibrage de charge. L'exclusion du backend empêche l'envoi de requêtes au backend non opérationnel. De plus, le trafic est équilibré entre les backends opérationnels pour éviter leur surcharge et optimiser la latence globale.

Cette option est semblable à la définition de capacityscalar sur zéro. Il demande à Cloud Service Mesh de réduire automatiquement la capacité du backend à zéro lorsqu'un backend a moins de 25 % de ses instances ou points de terminaison individuels qui réussissent les vérifications d'état. Avec cette option, les backends non opérationnels sont supprimés de l'équilibrage de charge mondial.

Lorsque les backends drainés automatiquement sont de nouveau opérationnels, ils sont non drainés si au moins 35 % des points de terminaison ou des instances sont opérationnels pendant 60 secondes. Cloud Service Mesh ne draine pas plus de 50 % des points de terminaison d'un service de backend, quel que soit l'état du backend.

Un cas d'utilisation consiste à utiliser la vidange automatique de la capacité avec des backends préférés. Si un MIG ou un NEG de backend est préféré et que de nombreux points de terminaison qu'il contient ne sont pas opérationnels, ce paramètre protège les points de terminaison restants du MIG ou du NEG en détournant le trafic de ce MIG ou NEG.

Personnaliser le comportement de basculement

Cloud Service Mesh envoie généralement le trafic aux backends en tenant compte de plusieurs facteurs. Dans un état stable, Cloud Service Mesh envoie le trafic aux backends sélectionnés en fonction des algorithmes décrits précédemment. Les backends sélectionnés sont considérés comme optimaux en termes de latence et d'utilisation de la capacité. On les appelle des backends principaux.

Cloud Service Mesh effectue également le suivi des backends à utiliser lorsque les backends principaux sont non opérationnels et ne peuvent pas recevoir de trafic. Ces backends sont appelés backends de basculement. Il s'agit généralement de backends à proximité ayant de la capacité restante.

Lorsqu'un backend n'est pas opérationnel, Cloud Service Mesh tente d'éviter de lui envoyer du trafic et le redirige vers des backends opérationnels.

La ressource serviceLbPolicy inclut un champ, failoverHealthThreshold, dont la valeur peut être personnalisée pour contrôler le comportement de basculement. La valeur de seuil que vous définissez détermine le moment où le trafic est transféré des backends principaux vers les backends de basculement.

Lorsque certains points de terminaison du backend principal ne sont pas opérationnels, Cloud Service Mesh ne bascule pas nécessairement le trafic immédiatement. Au lieu de cela, Cloud Service Mesh peut basculer le trafic vers des points de terminaison opérationnels du backend principal pour tenter de stabiliser le trafic.

Si trop de points de terminaison du backend ne sont pas opérationnels, les points de terminaison restants ne peuvent pas gérer le trafic supplémentaire. Dans ce cas, le seuil d'échec est utilisé pour déterminer si le basculement est déclenché ou non. Cloud Service Mesh tolère les états non sains jusqu'au seuil, puis transfère une partie du trafic des backends principaux vers les backends de secours.

Le seuil d'état de basculement est une valeur exprimée en pourcentage. La valeur que vous définissez détermine le moment où Cloud Service Mesh redirige le trafic vers les backends de secours. Vous pouvez définir la valeur sur un nombre entier compris entre 1 et 99. La valeur par défaut pour Cloud Service Mesh est de 70 avec Envoy et de 50 pour gRPC sans proxy. Une valeur plus élevée déclenche le basculement du trafic plus tôt qu'une valeur plus faible.

Dépannage

Les schémas de distribution du trafic peuvent changer en fonction de la façon dont vous configurez le nouveau serviceLbPolicy avec le service de backend.

Pour déboguer les problèmes de trafic, utilisez les systèmes de surveillance existants pour examiner le flux de trafic vers vos backends. D'autres métriques Cloud Service Mesh et réseau peuvent vous aider à comprendre comment les décisions d'équilibrage de charge sont prises. Cette section propose des suggestions générales de dépannage et d'atténuation.

Globalement, Cloud Service Mesh tente d'attribuer le trafic de manière à ce que les backends fonctionnent en dessous de leur capacité configurée. Notez que cela n'est pas garanti. Pour en savoir plus, consultez la documentation du service de backend.

Le trafic est ensuite attribué en fonction de l'algorithme que vous utilisez. Par exemple, avec l'algorithme WATERFALL_BY_ZONE, Cloud Service Mesh tente de maintenir le trafic vers la zone la plus proche. Si vous vérifiez les métriques réseau, vous constaterez que Cloud Service Mesh préfère un backend avec la latence DAR la plus faible lors de l'envoi de requêtes afin d'optimiser la latence DAR globale.

Les sections suivantes décrivent les problèmes que vous pouvez rencontrer avec la règle d'équilibrage de charge de service et les paramètres de backend préférés.

Le trafic est envoyé à des MIG ou des NEG plus éloignés avant les plus proches

Ce comportement est prévu lorsque les backends préférés sont configurés avec des MIG ou des NEG plus éloignés. Si vous ne souhaitez pas ce comportement, modifiez les valeurs dans le champ "Backends préférés".

Le trafic n'est pas envoyé aux MIG ni aux NEG qui comportent de nombreux points de terminaison non opérationnels

Il s'agit du comportement attendu lorsque les MIG ou les NEG sont vidés, car un autoCapacityDrain est configuré. Avec ce paramètre, les MIG ou les NEG comportant de nombreux points de terminaison non opérationnels seront exclus des décisions d'équilibrage de charge et seront donc évités. Si ce comportement n'est pas souhaité, vous pouvez désactiver le paramètre autoCapacityDrain. Toutefois, cela signifie que le trafic peut être envoyé à des MIG ou des NEG comportant de nombreux points de terminaison non opérationnels. Les requêtes peuvent donc échouer et générer des erreurs.

Le trafic n'est pas envoyé à certains MIG ou NEG lorsque certains MIG ou NEG sont préférés

Ce comportement est prévu si les MIG ou les NEG configurés comme préférés n'ont pas encore atteint leur capacité.

Lorsque des backends préférés sont configurés et qu'ils n'ont pas atteint leur limite de capacité, le trafic n'est pas envoyé à d'autres MIG ni NEG. Les MIG ou NEG préférés seront attribués en premier en fonction de la latence DAR de ces backends.

Si vous préférez que le trafic soit envoyé ailleurs, vous pouvez configurer le service de backend sans backends préférés ou avec des estimations de capacité plus prudentes pour les MIG ou les NEG préférés.

Le trafic est envoyé à un trop grand nombre de MIG ou de NEG distincts à partir d'une même source.

Il s'agit du comportement attendu si la pulvérisation à la région ou au monde est utilisée. Toutefois, vous risquez de rencontrer des problèmes de distribution plus large de votre trafic. Par exemple, les taux de succès de cache (hit) peuvent être réduits, car les backends reçoivent du trafic provenant d'une plus grande sélection de clients. Dans ce cas, envisagez d'utiliser d'autres algorithmes, tels que la cascade par région.

Le trafic est envoyé à un cluster distant lorsque l'état du backend change

Il s'agit du comportement attendu lorsque failoverHealthThreshold est défini sur une valeur élevée. Si vous souhaitez que le trafic reste dans les backends principaux en cas de modifications d'état temporaires, définissez failoverHealthThreshold sur une valeur inférieure.

Les points de terminaison opérationnels sont surchargés lorsque certains points de terminaison ne sont pas opérationnels

Il s'agit du comportement attendu lorsque failoverHealthThreshold est défini sur une valeur faible. Lorsque certains points de terminaison ne sont pas opérationnels, le trafic destiné à ces points de terminaison non opérationnels peut être réparti entre les points de terminaison restants du même MIG ou NEG. Si vous souhaitez que le comportement de basculement se déclenche plus tôt, définissez failoverHealthThreshold sur une valeur plus élevée.

Limites et points à noter

Vous devez tenir compte des limites et des points suivants lorsque vous configurez l'équilibrage de charge avancé.

Cascade par zone

  • Lors des événements de maintenance transparente, il est possible que le trafic soit temporairement équilibré en dehors de la zone locale.

  • Attendez-vous à des cas où certains MIG ou NEG sont à pleine capacité, tandis que d'autres MIG ou NEG de la même région sont sous-utilisés.

  • Si la source du trafic vers votre service se trouve dans la même zone que ses points de terminaison, le trafic entre les zones est réduit.

  • Une zone peut être mappée à différents clusters de matériel physique interne dans les centres de données Google, par exemple en raison de la virtualisation des zones. Dans ce cas, il est possible que les VM d'une même zone ne soient pas chargées de manière uniforme. En général, la latence globale sera optimisée.

Répartition dans la région

  • Si les points de terminaison d'un MIG ou d'un NEG sont hors service, les conséquences sont généralement réparties sur un plus grand nombre de clients. En d'autres termes, un plus grand nombre de clients du maillage peuvent être affectés, mais moins gravement.

  • Étant donné que les clients envoient des requêtes à tous les MIG ou NEG de la région, cela peut parfois augmenter le volume de trafic entre les zones.

  • Le nombre de connexions ouvertes aux points de terminaison peut augmenter, ce qui entraîne une utilisation accrue des ressources.

Backends préférés

  • Les MIG ou les NEG configurés comme backends préférés peuvent être éloignés des clients et entraîner une latence moyenne plus élevée pour les clients. Cela peut se produire même s'il existe d'autres MIG ou NEG qui pourraient servir les clients avec une latence plus faible.

  • Les algorithmes d'équilibrage de charge global (en cascade par région, répartition par région, en cascade par zone) ne s'appliquent pas aux MIG ni aux NEG configurés comme backends préférés.

Drainage de capacité automatique

  • Le nombre minimal de MIG qui ne sont jamais vidés est différent de la valeur définie lors de la configuration à l'aide de serviceLbPolicies.

  • Par défaut, le nombre minimal de MIG qui ne sont jamais vidés est de 1.

  • Si serviceLbPolicies est défini, le pourcentage minimal de groupes d'instances gérés ou de groupes d'instances non gérés qui ne sont jamais vidés est de 50 %. Dans les deux configurations, un MIG ou un NEG est marqué comme non opérationnel si moins de 25 % des instances ou des points de terminaison du MIG ou du NEG sont opérationnels.

  • Pour qu'un MIG ou un NEG soit remis en service après une vidange, au moins 35 % des instances ou des points de terminaison doivent être opérationnels. Cela permet de s'assurer qu'un MIG ou un NEG ne vacille pas entre les états drainé et non drainé.

  • Les mêmes restrictions concernant le scaler de capacité pour les backends qui n'utilisent pas de mode d'équilibrage s'appliquent également ici.

Étapes suivantes