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 en question est souvent un composant de l'orchestrateur de conteneurs et utilise par défaut l'algorithme TCP standard de type round robin. Cela signifie qu'une demande arrive et que l'équilibreur de charge choisit la ressource « suivante en ligne » pour répondre.
Cette méthode est souvent comparée à la file d'attente dans une banque ou au DMV. Mais ce n'est pas tout à fait exact. Dans un véritable scénario de round robin, vous n'êtes pas dirigé vers la « prochaine ressource disponible ». Vous êtes dirigé vers la ressource « suivante » — même si cette ressource est occupée. Ironiquement, les méthodes de distribution du DMV et de votre banque locale sont plus efficaces qu'un véritable algorithme round robin.
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 est comme le ratel. Il ne se soucie pas de savoir si une ressource est surchargée par des requêtes contenant des ensembles de données importants en guise de réponses. Le round robin dit « vous êtes le prochain », que vous soyez prêt ou non. Cela peut entraîner des performances inégales pour les utilisateurs dont les requêtes se retrouvent dans une file d’attente sur une ressource de plus en plus surchargée.
Si vous êtes préoccupé par les performances (et vous devriez l'être), une meilleure alternative est, eh bien, n'importe lequel des autres algorithmes standard tels que le moins de connexions ou le temps de réponse le plus rapide. Fondamentalement, vous voulez que votre algorithme prenne en compte la charge et/ou la vitesse au lieu de simplement imposer aveuglément des requêtes à des ressources qui peuvent ne pas être un choix optimal.
L'avenir de l'équilibrage de charge
Certains pourraient penser qu’à mesure que nous gravissons la pile de TCP à HTTP puis à HTTP+, ce problème se résoudra de lui-même. Ce n’est pas du tout le cas. La méthode de distribution (l'algorithme d'équilibrage de charge) reste pertinente quelle que soit la couche sur laquelle elle est basée. Round Robin ne se soucie pas de l'architecture, il se soucie des ressources et prend des décisions en fonction d'un pool disponible. Que ce pool soit destiné à mettre à l'échelle un seul appel d'API ou un monolithe entier ne fait aucune différence pour 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 était capable de ce type de discernement, il pourrait en tenir compte dans sa prise de décision et répartir plus uniformément les demandes entre les ressources disponibles. Ce que nous voulons vraiment, c’est ne pas être obligés de spécifier un algorithme rigide sur lequel prendre des décisions. Il serait préférable que l’équilibreur de charge puisse prendre la décision 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 sur 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.