Applications et API d'équilibrage de charge : Algorithmes versus architecture
Dans l'ensemble, faire évoluer les applications et les API repose sur les mêmes principes. Vous avez besoin d’un équilibreur de charge – souvent un proxy – qui répartit les requêtes sur un ensemble de ressources.
Mais il y a une différence assez importante dans la façon dont vous distribuez ces requêtes entre les ressources. Avec les algorithmes, vous répartissez vraiment la charge, tandis qu'avec l'architecture, vous la dirigez. Cela peut sembler une subtilité trop fine réservée au monde universitaire. En réalité, le choix entre algorithmes et architecture influence profondément l’échelle et les performances. Puisque les deux motivent l'utilisation de l’équilibrage de charge, cette distinction devient capitale.
É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 s'appuie, comme vous pouvez le deviner, sur des algorithmes pour prendre ses décisions. Nous utilisons ainsi des algorithmes de répartition tels que round robin, connexions les plus faibles, réponse la plus rapide, ainsi que leurs versions pondérées, pour choisir la ressource qui traitera chaque demande.
La décision est claire. À l’image du ratel, les algorithmes ne cherchent qu’à s’exécuter selon les données disponibles. Si cinq ressources sont disponibles, l’un des cinq sera choisi par l’algorithme. C’est tout.
L’équilibrage de charge algorithmique est, comme vous vous en doutez, très rapide. Aujourd’hui, la puissance de traitement permet d’exécuter rapidement l’algorithme adapté et de prendre une décision efficace. Sauf pour les algorithmes à tour de rôle et certaines distributions pondérées, les algorithmes conservent un état. Ils doivent donc suivre des variables comme « combien de connexions existe-t-il actuellement vers les ressources A, B et C ? » ou « quelle ressource a répondu le plus vite à sa dernière requête ? » L’équilibreur de charge doit gérer ces données. Ces informations peuvent vite devenir volumineuses et demander plus de ressources pour être gérées dans des environnements qui misent sur des applications monolithiques traditionnelles, avec plusieurs connexions longues.
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 complexes en réalité. Vous les retrouverez souvent supportées par plusieurs services (souvent des microservices) répartis sur plusieurs sites. Elles ne se limitent presque jamais à un seul service. Pour compliquer les choses, nous les mettons à jour plus fréquemment que les anciennes générations d’applications, sans toujours garantir une rétrocompatibilité fiable. Par ailleurs, vos applications mobiles peuvent exploiter à la fois des ressources anciennes et récentes : elles partagent des images avec les applications web et utilisent les mêmes API que les autres.
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.