Applications et API d'équilibrage de charge : Algorithmes versus architecture

Dans la plupart des cas, la mise à l’échelle des applications et des API est à peu près la même chose. Les deux nécessitent une sorte d’équilibreur de charge – généralement un proxy – et sont nécessaires pour distribuer les requêtes sur un pool de ressources.

Mais il existe une différence assez significative dans la façon dont ces demandes sont réparties entre les ressources. Dans le cas des algorithmes, nous distribuons réellement la charge, tandis que dans le cas de l'architecture, nous dirigeons la charge. Cela peut sembler être une distinction pédante qu’il vaut mieux laisser au monde universitaire. La vérité est que le choix entre les algorithmes et l’architecture a un impact profond sur l’échelle et les performances. Comme les deux sont en quelque sorte la raison pour laquelle vous utilisez l’équilibrage de charge, la distinction devient importante.

Équilibrage de charge simple et traditionnel

L'équilibrage de charge basé sur des algorithmes peut être appelé simplement équilibrage de charge ou, comme j'aime l'appeler, Plain Old Load Balancing . C’est la méthode d’échelle que nous utilisons depuis avant le début du siècle. Son âge ne signifie pas qu’il faille l’abandonner, bien au contraire. Dans de nombreuses situations, l’équilibrage de charge classique constitue le meilleur choix pour équilibrer l’évolutivité et les performances.

L'équilibrage de charge algorithmique classique utilise, comme on peut le deviner, des algorithmes dans son processus de prise de décision. Cela signifie que des algorithmes de distribution tels que le round robin, le moins de connexions, la réponse la plus rapide et leurs équivalents pondérés sont utilisés pour sélectionner une ressource pour répondre à une demande donnée.

Il s’agit d’une décision simple à prendre. Comme le ratel, les algorithmes ne se soucient de rien d’autre que de s’exécuter en fonction des données disponibles. S’il y a cinq ressources disponibles, l’une d’entre elles sera sélectionnée en fonction de l’algorithme. Période.

L’équilibrage de charge basé sur des algorithmes est, comme vous pouvez l’imaginer, assez rapide. Avec la puissance de traitement actuelle, il ne faut pas longtemps pour exécuter l’algorithme approprié et prendre une décision. À l’exception des algorithmes de type round robin et de certains algorithmes de distribution pondérée, les algorithmes sont avec état. Cela signifie qu'ils doivent suivre des variables telles que « combien de connexions existe-t-il actuellement aux ressources A, B et C ? » ou « quelle ressource a répondu le plus rapidement à leur dernière demande ? » L'équilibreur de charge doit garder une trace de ces informations. Ces informations peuvent devenir assez volumineuses et nécessiter davantage de ressources pour être gérées dans des environnements faisant évoluer des applications monolithiques traditionnelles qui nécessitent plusieurs connexions de longue durée.

L'équilibrage de charge classique excelle dans la mise à l'échelle des microservices. C’est parce que chaque microservice a (ou devrait avoir dans une architecture idéale) une fonction. La mise à l’échelle de ces services est facilement réalisée en utilisant un algorithme de base (généralement round robin) car ils sont généralement équivalents en termes de capacité et de performances. En raison de la nature des architectures de microservices, qui peuvent nécessiter plusieurs appels de service pour répondre à une seule demande utilisateur, des décisions rapides sont indispensables. L’équilibrage de charge basé sur des algorithmes de base constitue donc un bon choix pour de tels environnements.

La règle de base est la suivante : si vous faites évoluer des services simples avec un ensemble limité de fonctions, qui sont toutes généralement équivalentes en termes de performances, alors un simple équilibrage de charge suffira. C'est ce que vous voyez à l'intérieur des environnements de conteneurs et pourquoi une grande partie des capacités de mise à l'échelle natives sont basées sur des algorithmes simples.  

Pour d’autres applications et situations, vous devrez vous tourner vers un équilibrage de charge basé sur l’architecture.

Équilibrage de charge HTTP

L'équilibrage de charge basé sur l'architecture est l'art (oui, l'art et non la science) d'utiliser un équilibreur de charge pour découper les requêtes d'une manière qui correspond à l'architecture de l' application qu'il met à l'échelle. L’équilibrage de charge basé sur l’architecture vise davantage à diriger le trafic qu’à le distribuer. C’est parce qu’il tire parti de la couche 7 (généralement HTTP) pour décider où une requête donnée doit aller, et c’est pourquoi nous avons tendance à l’appeler équilibrage de charge HTTP (parmi d’autres termes plus ésotériques (et axés sur le réseau)). 

La capacité de diriger les requêtes est de plus en plus importante dans un monde exposé par des API et construit sur des microservices. C'est parce que vous devez pouvoir diriger les requêtes API en fonction de la version, utiliser des noms d'hôtes ou des chemins URI pour envoyer des requêtes à des microservices spécifiques ou pour décomposer les fonctionnalités d'une application.

La plupart des organisations souhaitent proposer une API cohérente et facile à utiliser. Qu'il s'agisse d'encourager les développeurs citoyens à créer de nouvelles applications qui utilisent l'API ou de permettre aux partenaires de se connecter et de s'intégrer facilement, une API cohérente et simple est impérative pour garantir l'adoption.

Mais les API sont souvent désordonnées dans la réalité. Ils s'appuient sur plusieurs services (souvent des microservices) et peuvent être répartis sur plusieurs sites. Ils se limitent rarement à un seul service. Les choses sont compliquées : elles sont mises à jour plus fréquemment que les générations précédentes d'applications et ne sont pas compatibles de manière fiable avec les versions antérieures. De plus, les applications mobiles peuvent utiliser à la fois des ressources anciennes et nouvelles, en partageant des images avec des applications Web et en utilisant les mêmes API que tout le monde.

Pour faire évoluer ces « applications » et API, une approche architecturale de l’équilibrage de charge est nécessaire. Vous devez diriger le trafic avant de le distribuer, ce qui signifie utiliser un équilibreur de charge compatible avec la couche 7 (HTTP) pour implémenter des modèles d'architecture tels que la répartition d'URL, le partitionnement des données et la décomposition fonctionnelle. Chacun de ces modèles est de nature architecturale et nécessite une plus grande affinité avec la conception de l’ application ou de l’API que celle des applications traditionnelles.

L'équilibrage de charge HTTP devient de plus en plus important dans la quête de mise à l'échelle des applications tout en équilibrant efficacité et agilité, ainsi qu'en prenant en charge les API. 

L'évolutivité nécessite les deux

Vous verrez rarement un seul type d’échelle dans le monde réel. C’est parce que les organisations fournissent de plus en plus un ensemble robuste d’ applications qui couvrent des décennies de développement, d’architectures d’applications, de plates-formes et de technologies. Très peu d’organisations peuvent se vanter de ne prendre en charge que des applications « modernes » (à moins que le terme « moderne » n’inclue tout ce qui ne s’exécute pas sur un mainframe).

Ainsi, vous êtes susceptible de voir – et d’utiliser – l’équilibrage de charge algorithmique et architectural pour faire évoluer une variété d’ applications. C’est pourquoi il est important de comprendre la différence, car utiliser l’un lorsque l’autre est plus approprié peut entraîner de mauvaises performances et/ou des pannes, ce qui n’est pas bon pour les utilisateurs, l’entreprise ou vous-même. 

Vous verrez de plus en plus les deux approches combinées pour faire évoluer les applications modernes. Parfois, les deux existeront en réalité en tant que service unique conçu pour faire évoluer le logique (l'API) et le physique (le service réel derrière l'API). Les contrôleurs de distribution application (ADC) sont généralement la plate-forme sur laquelle une approche combinée est mise en œuvre, car ils sont capables d'effectuer les deux avec la même rapidité.

Parfois, ces opérations sont réalisées par deux systèmes différents. Par exemple, dans les environnements conteneurisés, un contrôleur d'entrée est responsable de l'équilibrage de la charge architecturale tandis que les services internes natifs sont généralement responsables de la mise à l'échelle à l'aide de l'équilibrage de la charge algorithmique.

Quels que soient les détails de mise en œuvre et de déploiement, la réalité est que les approches algorithmiques et architecturales de l’équilibrage de charge ont un rôle à jouer dans la mise à l’échelle des applications et des API. La clé pour maximiser leurs atouts à votre avantage est d’adapter l’équilibrage de charge à l’architecture de application .

Échelle allumée.