Dans les approches traditionnelles d'équilibrage de charge, le choix de l'algorithme se réduit le plus souvent à une liste à variable unique : distribuer en round-robin, envoyer au least connections, épingler selon l'adresse source ou utiliser des poids. Ce modèle peut sembler suffisant sous trafic normal ; mais lorsque démarrent une campagne, une explosion d'API, du trafic de streaming ou une affluence soudaine d'utilisateurs, il reste faible pour décider à lui seul.
Par exemple, si deux backends affichent le même temps de réponse et que le système n'a pas la possibilité d'effectuer une seconde comparaison, le trafic se répartit de façon aléatoire. Un service au temps de réponse apparemment faible mais dont la file d'attente est pleine peut être choisi ; un service au faible nombre de connexions apparent mais qui a commencé à produire des erreurs peut rester candidat.
Cette indécision affecte particulièrement les valeurs de latence extrêmes. Alors que le temps de réponse moyen semble acceptable, l'expérience utilisateur peut se dégrader sur les centiles élevés. Lorsque la latence ajoutée par les contrôles de sécurité, de contrôle d'accès ou de couche applicative n'est pas non plus prise en compte, des candidats qui paraissent rapides mais se comportent en fait lentement peuvent ressortir.
Le bon modèle doit lire les signaux de service en direct au moment de la décision et éliminer automatiquement les candidats en mauvaise santé ou en mode maintenance. Si l'affinité de session est active, il ne doit pas rompre le lien de l'utilisateur existant ; il ne doit choisir le service le plus adapté que pour les requêtes libres.
C'est le problème fondamental que résout Fastest+ Routing : lier la décision d'équilibrage de charge non à une seule étiquette, mais au comportement de service en temps réel et en deux étapes.
TR7 traite Fastest+ Routing par la lecture de signaux en direct, un scoring à deux niveaux, la conscience de l'état de santé et une configuration via l'interface.
La logique de décision s'exécute intégrée au plan de données et lit les statistiques de service en direct à chaque requête HTTP ou TCP. Le service choisi est écrit dans la variable de routage et le trafic progresse selon cette décision. L'opérateur obtient une sélection dynamique par requête sans écrire de code personnalisé.
Lors de la première étape, les services ayant la meilleure valeur sur le signal primaire sont placés dans la liste de candidats. Si plusieurs services partagent le même score, le signal secondaire entre en jeu lors de la seconde étape. Ainsi des décisions pratiques comme « si le temps de réponse est identique, choisir celui dont la file est la plus vide » sont appliquées au sein d'un seul algorithme.
Les services en mode maintenance ou dont l'état de santé n'est pas adéquat ne sont pas placés dans la liste de candidats. Si l'affinité de session dynamique est active, la sélection Fastest+ est ignorée et le lien de session existant est préservé. Cette approche optimise la performance sans rompre les sessions utilisateur.
L'opérateur sélectionne uniquement le signal de décision primaire et secondaire. Le système génère automatiquement les lignes de routage nécessaires lors de la phase de génération de configuration. Une logique de décision complexe se transforme en un simple choix de politique pour l'exploitation quotidienne.
Fastest+ Routing offre des capacités de routage avancées qui évaluent ensemble la performance en direct, la santé et le lien de session entre les backends.
Lorsqu'une nouvelle meilleure valeur est trouvée sur le signal de décision primaire, la liste de candidats est réinitialisée ; les services partageant la même valeur sont ajoutés à la liste. Lors de la seconde étape, ces candidats sont à nouveau restreints selon le signal secondaire. Dans la configuration par défaut, Fastest+ préfère parmi les candidats à faible temps de réponse le service dont la charge de session instantanée est plus basse. Ainsi, parmi les services qui paraissent rapides, celui dont la charge est plus faible est préféré.
L'opérateur choisit deux signaux de décision pour Fastest+ : temps de réponse moyen, temps d'établissement de connexion, temps d'attente en file, charge de session instantanée, intensité de file d'attente instantanée, erreurs de connexion, intensité d'erreurs client, intensité d'erreurs serveur, déconnexions d'origine service ou capacité de connexion utilisée. Ces signaux sont liés en interne aux compteurs de service en direct correspondants ; l'utilisateur ne manipule pas de noms de métriques bruts. Ainsi le trafic peut être routé non vers le service qui « paraît rapide », mais vers le backend qui est à cet instant plus sain, plus libre ou produisant moins d'erreurs.
Pour les pools de services ne nécessitant pas de seconde comparaison, le mode mono-signal peut être utilisé. Dans ce mode, la décision est prise uniquement selon la meilleure valeur du signal primaire choisi. Aucune profondeur de décision superflue n'est ajoutée pour les groupes de services plus simples. L'opérateur peut gérer les modes mono-signal et bi-signal depuis la même interface.
Si un backend est en mode maintenance ou si son état de santé n'est pas adéquat, il n'entre pas dans la liste de candidats. Ce comportement est intégré à l'algorithme ; il ne nécessite ni règle manuelle, ni liste de contrôle d'accès supplémentaire, ni intervention opérationnelle. La maintenance planifiée, l'isolation d'un service problématique et le retrait temporaire d'un service se reflètent automatiquement dans la décision de trafic. Ainsi le système ne choisit que parmi les candidats adéquats.
Lorsque les conditions d'affinité de session sont réunies, la sélection Fastest+ est désactivée. La requête est routée vers le service déterminé par la logique de session collante existante. La condition de routage générée est configurée de façon transparente par le système. Ainsi l'optimisation de performance ne prend pas le pas sur la continuité de la session utilisateur.
Fastest+ peut s'exécuter à la fois lors de la phase de requête HTTP et lors de la phase d'inspection de contenu TCP. Pour les services TCP, la fenêtre d'inspection nécessaire à la décision est créée automatiquement. Ainsi le trafic de couche applicative et les services basés sur TCP sont traités dans le même modèle de gestion. L'opérateur n'a pas à apprendre des logiques produit différentes selon le type de service.
Lorsque l'affinité dynamique est utilisée, Fastest+ ne s'exécute que pour les clients n'ayant pas encore de session épinglée. Tandis que les sessions existantes sont préservées, les requêtes nouvelles ou libres sont distribuées selon les signaux en direct. Ce modèle offre une approche équilibrée à la fois pour la continuité de l'utilisateur et l'utilisation instantanée de la capacité. Il aide en particulier à une utilisation plus efficace du pool de services sous un trafic intense et fluctuant.
Si aucun backend adéquat n'est trouvé dans le processus de décision, la décision de routage personnalisée reste vide. Dans ce cas, le comportement d'équilibrage de charge par défaut entre en jeu. Lorsque le système ne peut pas produire de décision de routage personnalisée, il revient au comportement par défaut connu au lieu de laisser le trafic se perdre. Cette logique de repli réduit les risques opérationnels.
Fastest+ Routing n'est pas seulement un choix d'algorithme ; il est conçu conjointement avec des comportements de haute disponibilité, de visibilité, de rechargement et d'intégration.
La logique de décision est chargée au démarrage du service et définie comme deux actions distinctes, mono-signal et bi-signal. L'action mono-signal fonctionne avec une entrée de décision, l'action bi-signal avec deux entrées de décision. Les actions peuvent être utilisées lors des phases de requête HTTP et TCP.
Les statistiques de service sont lues depuis une table en mémoire ; aucun socket supplémentaire, lecture de fichier ou requête externe n'est requis. Le processus de décision effectue un balayage linéaire selon le nombre de services. Cette structure maintient la décision de routage proche du plan de données même dans les pools comptant de nombreux backends.
Dans une configuration de haute disponibilité à deux nodes, chaque node exécute le même algorithme de façon indépendante. Comme les signaux en direct sont évalués localement au node, après un failover le nouveau node actif continue de décider avec les statistiques qu'il observe lui-même. Aucune dépendance à un dépôt de scores partagé externe ne se crée.
Le backend choisi est conservé dans la variable de routage et peut être ajouté au format de log. Ainsi, on peut examiner rétrospectivement quelle requête a été routée vers quel service. Les équipes d'exploitation peuvent voir les décisions de trafic non seulement comme un résultat, mais comme une trace de routage traçable.
Lors d'un rechargement à chaud, le contexte de décision est rechargé et l'algorithme démarre avec un nouvel état mémoire. Comme l'observation passée du temps de réponse n'est pas transférée, les décisions sur les premières requêtes reposent sur les données instantanées actuelles. La possibilité d'appliquer des changements de configuration sans redémarrer le pool réduit l'interruption opérationnelle.
Lorsque la couche WAAP bloque une requête, Fastest+ n'est pas invoqué ; ainsi aucune sélection de service superflue n'est effectuée. Fastest+ ne s'applique qu'aux pools de services HTTP et TCP. Pour les services Layer 4, les options d'algorithme Layer 4 de la plateforme sont utilisées.
Pendant les périodes de ventes intenses, de nombreux backends reçoivent du trafic en même temps. Fastest+ évalue ensemble des signaux comme le temps de réponse et l'intensité de file d'attente pour empêcher que des services rapides mais à file pleine ne ressortent inutilement. Le résultat est une utilisation plus équilibrée des services et une expérience utilisateur plus contrôlée.
Dans les couches d'API financières, une réponse rapide ne suffit pas ; le comportement de production d'erreurs doit aussi faire partie de la décision. Fastest+ peut mettre en avant les services à faible intensité d'erreurs serveur et, en cas d'égalité, prendre en compte la charge de session instantanée. Cette structure permet une distribution plus avisée pour le trafic d'API critique.
Dans le trafic de streaming et de médias, le node le moins chargé ne donne pas toujours la meilleure expérience utilisateur. Fastest+ évalue ensemble, par la combinaison de la capacité de connexion utilisée et du temps de réponse, à la fois l'utilisation de connexion actuelle et le comportement de réponse. Ainsi un partage de trafic plus fin est réalisé entre les services edge.
Dans les structures multi-locataires, le groupe de services de chaque locataire peut présenter un comportement différent. Fastest+ peut préférer les services fonctionnant de façon plus stable grâce à des signaux comme les déconnexions d'origine service et le temps d'établissement de connexion. Cette approche rend la qualité de service par locataire plus gérable.
Distribution de trafic en deux étapes avec des signaux en direct, configurée sans écrire de code. Faisons-en le tour sur une installation en direct sur vos propres services.