L'avenir de l'équilibrage de charge repose sur les données
Les applications cloud natives sont développées à un rythme soutenu. Même s’ils ne dominent pas encore totalement les portefeuilles d’applications, leur nombre augmente. L’intérêt pour les conteneurs est étroitement associé aux architectures cloud natives (basées sur les microservices) en raison de la dépendance inhérente à l’infrastructure pour les communications et l’évolutivité.
En règle générale, la mise à l’échelle des microservices est obtenue via le clonage horizontal. Autrement dit, si nous avons besoin de plus d’instances d’un service donné, nous le clonons simplement et l’ajoutons au pool disponible à partir duquel un équilibreur de charge choisit de répondre aux demandes. Très facile. Lorsque ces microservices représentent étroitement des éléments fonctionnels, ce modèle fonctionne encore mieux.
L'équilibreur de charge est souvent intégré à l'orchestrateur de conteneurs et utilise par défaut l'algorithme standard du secteur basé sur le round robin TCP. Cela signifie qu'à chaque requête, l'équilibreur choisit la ressource suivante pour y répondre.
On compare souvent cette méthode à la file d’attente à la banque ou au DMV, mais ce n’est pas tout à fait juste. Dans un vrai scénario de rotation, on ne vous dirige pas vers la ressource « prochaine disponible ». On vous dirige vers la ressource « suivante dans la file », même si elle est occupée. Ironie du sort, les méthodes utilisées au DMV et à votre banque locale sont plus efficaces qu’un véritable algorithme de rotation.
N'est-ce pas?
Ceci est également vrai pour les applications . Le même service, même au niveau fonctionnel, peut être cloné car ils traitent le même ensemble de requêtes. Mais ces demandes ne sont pas toujours égales en termes d’exécution en raison des données. C'est vrai, des données. La même demande fonctionnelle (ou appel d’API) peut prendre plus ou moins de temps à s’exécuter en fonction des données soumises ou demandées. Après tout, il faudra moins de temps pour récupérer et sérialiser un seul enregistrement client que pour récupérer et sérialiser dix ou cent enregistrements clients.
Et c'est là que le round robin s'effondre un peu et introduit une variabilité qui peut avoir un impact sur les performances. L'axiome opérationnel n°2 s'applique toujours aux architectures cloud natives et basées sur les microservices : à mesure que la charge augmente, les performances diminuent .
Le round robin agit comme un blaireau. Il ne tient pas compte de la surcharge d’une ressource par des requêtes avec des ensembles de données importants en réponse. Le round robin vous dit « c’est votre tour » que vous soyez prêt ou pas. Cela peut provoquer des performances inégales pour les utilisateurs dont les requêtes s’accumulent dans une file sur une ressource de plus en plus sollicitée.
Si la performance vous importe — et elle devrait — optez plutôt pour un autre algorithme classique, comme celui des connexions les plus faibles ou du temps de réponse le plus court. L’algorithme doit tenir compte de la charge et/ou de la rapidité, au lieu de répartir aveuglément les requêtes sur des ressources qui risquent de ne pas être optimales.
L'avenir de l'équilibrage de charge
Vous pourriez croire qu'en montant dans la pile, de TCP à HTTP puis HTTP+, ce problème se résoudra de lui-même. Ce n’est clairement pas le cas. La méthode de distribution — l’algorithme d’équilibrage de charge — reste pertinente, peu importe la couche à laquelle vous vous basez. Le round robin ne prend pas en compte l’architecture ; il considère les ressources et décide en fonction d’un pool disponible. Que ce pool soit destiné à faire évoluer un appel API unique ou un monolithe complet, cela n’affecte pas l’algorithme.
Il serait donc appréciable que l'équilibreur de charge soit suffisamment intelligent pour reconnaître quand une requête génère des données « supérieures à la moyenne » avant son exécution. Les pare-feu application Web comme F5 WAF sont capables de reconnaître lorsqu'un résultat sort de l'ordinaire, mais cela dépend de la réponse et permet principalement une meilleure sécurité des application . Ce dont nous avons besoin, c’est que l’équilibreur de charge devienne suffisamment intelligent pour prédire une réponse légitime « extra-large ».
Si l'équilibreur de charge pouvait discerner cela, il intégrerait cet élément dans sa prise de décision et répartirait plus équitablement les requêtes entre les ressources disponibles. Nous souhaitons avant tout ne pas avoir à définir un algorithme rigide pour guider ces décisions. Il serait plus efficace que l'équilibreur de charge prenne des décisions en fonction des seuils commerciaux et des caractéristiques techniques, telles que les temps de réponse, le temps d'exécution prévu, la taille des données renvoyées et la charge actuelle de chaque ressource.
En fin de compte, c’est le type d’intelligence qui ne peut être réalisé que grâce à une meilleure visibilité et à l’apprentissage automatique. Si l'équilibreur de charge peut apprendre par l'expérience à reconnaître quelles requêtes prennent plus de temps que d'autres, il peut ensuite appliquer ces connaissances pour mieux répartir les requêtes de manière à obtenir un temps de réponse cohérent et prévisible.
L’équilibrage de charge ne va pas disparaître. C'est notre meilleure réponse technique pour faire évoluer tout, du réseau aux applications. Mais il doit évoluer avec le reste de l’infrastructure pour être plus dynamique, autonome et intelligent.