Modèles de distribution d'applications pour la mise à l'échelle des applications et des API
Aujourd’hui, la mise à l’échelle des applications et des API ne consiste pas à choisir le bon algorithme d’équilibrage de charge. Au cours des deux décennies d’évolution de la distribution d’applications, la seule chose qui est restée relativement constante sont les algorithmes d’équilibrage de charge. Leur principal avantage est de maintenir la disponibilité. Leur impact sur les performances est, au mieux, minime.
Cela ne veut pas dire que le choix d’un algorithme n’est pas pertinent. Après tout, le round robin est rarement le meilleur choix pour une API ou une application, mais le choix entre le moins de connexions et la réponse la plus rapide est moins susceptible d’avoir un impact sur les performances globales et la disponibilité d’un service numérique que son architecture.
Il s’agira d’une perspective architecturale sur la distribution d’applications en réponse à l’élévation de la distribution d’applications comme l’une des six capacités clés requises pour concevoir et exploiter des services numériques.
Qu'est-ce qu'un algorithme d'équilibrage de charge ?
Un algorithme d'équilibrage de charge est une approche programmatique permettant de répartir la charge sur un pool de ressources afin de garantir la disponibilité et d'améliorer les performances.
Un algorithme d'équilibrage de charge spécifie comment des ressources spécifiques sont choisies et quelles variables sont prises en compte.
Round Robin est l'algorithme le plus simple et itère simplement sur un ensemble connu de ressources dans un ordre séquentiel. S'il y a trois ressources (A, B et C), le routage circulaire oriente la première requête vers A, la deuxième vers B et la troisième vers C. Le processus de sélection recommence alors.
Least Connections est un algorithme basé sur le deuxième axiome opérationnel qui stipule que « lorsque la charge augmente, les performances diminuent ». Ainsi, l'algorithme du plus petit nombre de connexions choisira la ressource avec le moins de connexions (charge). Il existe des variantes de cet algorithme, notamment les connexions minimales pondérées , qui permettent de tenir compte des différences de capacité entre les ressources.
Le temps de réponse le plus rapide est utilisé lorsque les performances sont une priorité absolue. L'équilibreur de charge déterminera, de manière passive ou active, le temps de réponse de chaque ressource et, pour chaque demande, choisira la plus rapide. Cet algorithme ne garantit pas le temps de réponse de l'utilisateur car il n'a aucun effet sur le dernier kilomètre ou sur les conditions du réseau de l'utilisateur.
L'IP source est un algorithme hérité de l'équilibrage de la charge réseau qui utilise une simple valeur de hachage pour l'IP source (client) pour choisir une ressource. Cet algorithme sélectionnera toujours la même ressource pour une IP source donnée. Cet algorithme est tombé en disgrâce car il est sujet au problème du « méga proxy », où tous les utilisateurs provenant d'un seul proxy/adresse IP sont dirigés vers la même ressource. Cela tend à submerger la ressource cible, ce qui entraîne de mauvaises performances et, en fin de compte, un échec.
Les algorithmes d’équilibrage de charge constituent un élément important de l’architecture de distribution d’applications, mais ont moins d’impact sur les performances et l’échelle d’une application ou d’un service numérique que l’approche architecturale globale.
Qu'est-ce que la livraison d'applications ?
La livraison d'applications est la discipline consistant à concevoir une architecture évolutive et performante pour les applications, les API et les services numériques. Il s’appuie fortement sur l’équilibrage de charge en tant que composant principal, mais intègre des fonctionnalités modernes telles que le routage de couche 7 et exploite des modèles d’architecture communs pour optimiser les performances et l’utilisation efficace des ressources.
Nous utilisons le terme « livraison d’applications » pour tracer délibérément une ligne entre l’équilibrage de charge, qui est un détail d’implémentation, et l’architecture, qui est un processus de conception.
Pourquoi évoluons-nous ?
L'échelle est la réponse technique à un résultat commercial. Il s’agit notamment de la nécessité de maintenir la disponibilité et les performances des charges de travail qui composent un service numérique afin d’améliorer les scores de satisfaction client, les taux de conversion et la génération de revenus. Cette dernière partie est particulièrement importante, car nos recherches nous indiquent qu’une majorité (58 %) des entreprises génèrent aujourd’hui au moins la moitié de leurs revenus grâce aux services numériques.
Pensez également, par exemple, à l’utilisation du cloud public pour la continuité des activités (BC). Le BC est l’une des principales utilisations du cloud public et, à la base, se trouve une implémentation à l’échelle mondiale, c’est-à-dire un équilibrage de charge global. Le basculement est une fonctionnalité essentielle de la distribution d'applications qui, lorsqu'elle est appliquée à un site entier, permet de rediriger rapidement les demandes d'un emplacement à un autre. La disponibilité continue de la présence numérique d’une entreprise est un résultat commercial, rendu possible par une réponse technique.
Comment évoluer ?
Répondre à cette question marque le début de notre voyage technique vers l’architecture de distribution d’applications. Il existe deux modèles d'échelle : verticale (vers le haut) et horizontale (vers l'extérieur).
L’échelle verticale est basée sur le principe selon lequel l’ajout de puissance de traitement supplémentaire à un système augmentera sa capacité. Cette méthode de mise à l’échelle profite principalement aux applications monolithiques et aux systèmes autonomes. Outre l’infrastructure, la plupart des organisations ne dépendent plus de l’échelle verticale, car cela nécessite de modifier l’environnement physique, en ajoutant des processeurs ou de la RAM ou en étendant la capacité du réseau. Bien que l’évolution verticale soit beaucoup plus rapide grâce à la virtualisation, en particulier dans les environnements de cloud public, la nécessité de migrer des logiciels et des systèmes, même vers une nouvelle machine virtuelle, peut être perturbatrice.
L'échelle horizontale est une approche architecturale permettant d'ajouter davantage de puissance de traitement en augmentant les ressources totales disponibles. Cela est réalisé en répartissant la puissance de traitement sur plusieurs instances d’une application, d’un service ou d’un système. Il s’agit de la méthode de mise à l’échelle la plus courante aujourd’hui, car elle repose sur la duplication des ressources au lieu de leur migration. De plus, l’échelle horizontale offre une plus grande variété d’options architecturales que l’échelle verticale , ce qui la rend mieux adaptée à toutes les applications et API.
Il n’est donc pas surprenant que les modèles modernes de distribution d’applications soient basés sur le principe de l’échelle horizontale.
Modèles de diffusion des applications
Le simple choix de l’échelle horizontale ne met pas fin à la discussion.
Une fois la décision prise (généralement c'est la décision par défaut), des considérations supplémentaires doivent guider une décision architecturale concernant la mise en œuvre. La manière la plus simple d’aborder cette décision est d’utiliser le prisme du cube d’échelle tel que décrit dans le livre The Art of Scalability .
Très simplement, il y a trois axes dans le cube évolutif : x, y et z. Chacun correspond à un modèle architectural d’équilibrage de charge. Chacun de ces modèles est adapté pour atteindre des résultats spécifiques liés aux performances et à la disponibilité compte tenu de différents types d’applications et d’API.
Un service numérique est susceptible d’utiliser une architecture qui intègre plusieurs modèles pour optimiser les performances et la consommation de ressources en même temps. Cette approche nécessite une réflexion systémique, car elle doit prendre en compte tous les composants, la manière dont ils interagiront et la manière dont les demandes circuleront de l’utilisateur vers l’application et vice versa.
Échelle de l'axe X
Le modèle de l'axe X est le modèle le plus basique. Il est basé sur la duplication horizontale et l’essentiel du travail est réalisé via un algorithme d’équilibrage de charge. C'est le modèle le plus simple et il aboutit à ce que j'appelle le Plain Old Load Balancing (POLB).
Nous l’appelons ainsi en raison de la simplicité de l’architecture, qui ne tire aucun parti des capacités avancées des équilibreurs de charge modernes pour interagir avec les demandes et les réponses au niveau de la couche applicative.
Dans ce modèle, les applications sont dupliquées et les demandes sont transmises à une instance en fonction de la décision de l'algorithme d'équilibrage de charge configuré.
Étant donné que ce modèle est souvent utilisé en conjonction avec TCP (couche 4), il présente des avantages en termes de performances par rapport aux autres modèles qui reposent sur l’inspection de HTTP (couche 7). Principalement, les connexions peuvent être cousues ensemble plutôt que proxy, ce qui transforme efficacement l'équilibreur de charge en un saut de réseau après la connexion initiale. Cela se traduit par de meilleures performances globales, mais élimine la capacité de l'équilibreur de charge à inspecter ou à agir sur les demandes et les réponses après la connexion initiale. Étant donné que les architectures de l'axe X excellent à garantir la disponibilité et peuvent être très performantes, elles sont souvent utilisées pour faire évoluer les services d'infrastructure et de sécurité tels que les pare-feu et les passerelles d'application.
Une variété d'applications traditionnelles (monolithes, Web à trois niveaux et client-serveur) ont tendance à être mises à l'échelle à l'aide de ce modèle, car il est rare que ces applications soient décomposées en composants plus discrets qui peuvent être exploités pour les architectures de distribution d'applications modernes.
Échelle de l'axe Y
Ce modèle est basé sur la décomposition fonctionnelle et exploite les capacités de la couche applicative (couche 7) de livraison d'applications pour évoluer en fonction des fonctions plutôt que des systèmes entiers. Le modèle de l’axe Y est le premier modèle dans lequel le routage de couche 7 devient un outil clé dans la boîte à outils de l’architecture de distribution d’applications.
En général, les modèles basés sur Y et Z tirent parti du routage de couche 7 pour choisir un pool, puis un algorithme d'équilibrage de charge est utilisé pour sélectionner une ressource spécifique. Cela diverge du modèle x de base, dans lequel aucun routage de couche 7 n'est utilisé.
Ce modèle suppose un fonctionnement au niveau de la couche 7, généralement HTTP, et utilise une variable pour distribuer le trafic vers des instances spécifiques d'une application ou d'un service. Par exemple, si le modèle /login est trouvé dans l'URI, l'équilibreur de charge choisira une instance, en fonction de l'algorithme d'équilibrage de charge configuré, dans un pool d'instances d'application qui gèrent uniquement les demandes de connexion. La variable peut être n’importe quoi dans l’en-tête de la requête ou dans la charge utile de la requête. Cela permet un routage basé sur l'agent, un routage API et un routage basé sur le contenu (images, scripts, etc.).
Les instances d’application peuvent être des clones. C'est souvent le cas lorsqu'il existe une disparité dans l'utilisation d'une application qui peut être identifiée par une variable dans la demande. Par exemple, les fonctions de connexion et de paiement peut être discerné dans une requête basée sur l'URI, une valeur dans l'en-tête HTTP ou par une valeur dans la charge utile de la requête. L'application d'un modèle d'axe Y permet aux applications traditionnelles d'évoluer en fonction de la fonction, ce qui se traduit par une plus grande efficacité d'utilisation des ressources, car davantage de ressources peuvent être allouées à la gestion de fonctions à volume élevé tout en maintenant les performances attendues des autres fonctions.
L’utilisation du modèle de l’axe Y pour mettre à l’échelle fonctionnellement les applications traditionnelles est née avant la prévalence des microservices, qui décomposent aujourd’hui fonctionnellement les applications. Le modèle de l’axe Y est toujours applicable aux microservices et le modèle est en effet implémenté par les contrôleurs d’entrée aujourd’hui. Les lecteurs astucieux noteront que ce modèle s’applique également aux API, étant donné qu’elles s’appuient sur des constructions HTTP (couche 7), ce qui n’est pas surprenant que les passerelles API exploitent ce modèle fondamental.
Ce modèle a été rendu populaire par eBay aux débuts du Web 2.0. Son architecture d’évolutivité incluait alors la segmentation des fonctions en pools d’applications distincts. La fonctionnalité de vente était assurée par un ensemble de serveurs d'applications, les enchères par un autre, la recherche par un autre encore. Au total, ils ont organisé environ 16 000 serveurs d’applications en 220 pools différents. Cela leur a permis de faire évoluer chaque pool indépendamment des autres, en fonction des exigences et de la consommation de ressources de sa fonction. Cela leur a également permis d'isoler et de rationaliser les dépendances en matière de ressources : le pool de vente n'avait besoin de communiquer qu'avec un sous-ensemble relativement restreint de ressources back-end, par exemple.
Le modèle de l'axe Y peut également être utilisé pour distribuer différents types de demandes de contenu, tels que des images, à un pool de ressources et d'autres types de contenu à d'autres.
L’utilisation de l’axe Y pour répartir la charge permet aux composants d’un service numérique de s’adapter individuellement, ce qui est beaucoup plus efficace en termes d’utilisation des ressources qu’un modèle d’axe X. Il permet une optimisation de la configuration au niveau de la couche service ou application qui peut améliorer ses performances en ajustant des variables spécifiques dans le serveur Web ou d'application pour optimiser un type de contenu donné.
Échelle de l'axe Z
Le modèle de l'axe Z est devenu populaire par pure nécessité avec la croissance explosive des médias sociaux et d'Internet en général. Il s’agit, à la base, d’un modèle de mise à l’échelle de l’axe Y avec une segmentation supplémentaire appliquée, généralement basée sur une variable spécifique comme un nom d’utilisateur ou un identifiant d’appareil.
Ce modèle permet une différenciation architecturale à l’aide d’une technique dérivée du partitionnement des données.
Ce modèle applique les principes utilisés dans les bases de données pour distribuer les requêtes en fonction d'un élément de données dans la requête. Il peut être utilisé pour aider à résoudre les goulots d’étranglement dans la couche de données, ainsi que comme moyen de garantir le respect des règles de souveraineté des données. Il utilise une variable identifiable – et généralement unique – pour acheminer les requêtes sur un pool de ressources évolutif horizontalement. Ce modèle est généralement utilisé lorsqu'un débit élevé est nécessaire, comme dans le cas de volumes importants de demandes pour un service ou une application spécifique.
Le modèle de l’axe Z est particulièrement utile pour la gestion des appareils Edge et IoT, qui peuvent se compter par millions. En utilisant les identifiants d’appareils comme modèle de base pour les demandes de partitionnement, la vitesse à laquelle les données peuvent être transférées peut être considérablement améliorée. Cela peut être particulièrement utile pour les appareils qui stockent leurs configurations dans un emplacement distant (cloud ou centre de données), car ces données sont uniques à l'appareil et peuvent être fragmentées en toute sécurité.
Ce modèle tend à améliorer les performances, car l’accès aux données à forte charge peut considérablement dégrader les performances. Ainsi, en divisant l’accès aux données sur plusieurs instances, la charge diminue et, par conséquent, les performances s’améliorent. Cela nécessite une attention particulière à l’intégrité des données et peut entraîner des problèmes de cohérence lorsqu’il est utilisé pour fragmenter des données partagées. Meta a élevé le sujet du sharding lorsqu'il a développé le sharding de service dans le cadre de son architecture globale. L’attention particulière qu’elle porte au développement d’une architecture de distribution d’applications hautement performante et évolutive est un excellent exemple de la manière dont la reconnaissance de la distribution d’applications en tant que niveau formel au sein d’une architecture plus vaste peut apporter des avantages significatifs.
Pour les services accédant à des sources de données non primaires, un modèle d’axe z peut améliorer le débit sans impacter de manière significative la qualité des données sur l’ensemble du système. Cette approche réduit le besoin d’ajouter du code pour lier une instance spécifique d’une application ou d’une API à une source de données, en s’appuyant plutôt sur la combinaison de la configuration des connecteurs de données au niveau de l’instance et du routage de livraison de l’application pour garantir que la bonne source de données est utilisée.
Le secret de l’évolutivité réside dans l’architecture de diffusion des applications.
Il est rare aujourd’hui, dans un monde où les services numériques sont fournis, d’utiliser un seul modèle de livraison d’application pour concevoir un service numérique performant et fiable. Cela est dû à la complexité inhérente aux services numériques et à la diversité croissante des « utilisateurs », qui peuvent inclure des appareils, des humains et des logiciels.
Ainsi, une approche architecturale prend en compte la meilleure utilisation des modèles de distribution d’applications dans un service numérique pour offrir une expérience optimale aux utilisateurs.
Il n’existe pas de « bonne » ou de « mauvaise » solution architecturale, car elle dépend fortement des services et des applications qui composent un service numérique, sauf qu’une telle solution ne doit pas être basée uniquement sur des algorithmes d’équilibrage de charge.
En effet, il convient de noter qu’aucune mention n’a été faite de la sélection d’algorithmes, car le choix de la manière dont la charge est répartie au sein d’un modèle d’équilibrage de charge n’est pas aussi pertinent que de faire le bon choix architectural pour une application ou une API spécifique.
C’est l’un des facteurs qui motivent la diffusion d’applications en tant que discipline . La manière dont la distribution et la sécurité des applications sont utilisées et mises en œuvre aujourd’hui va bien au-delà de la simple échelle d’un serveur Web. Sa mise en œuvre peut avoir un impact sur les performances, la disponibilité et, en fin de compte, faire ou défaire les résultats commerciaux. Il est donc important pour les organisations d’aborder la distribution d’applications comme un outil stratégique et architectural dans leur boîte à outils de conception.
L’équilibrage de charge reste l’exigence technique fondamentale en matière d’évolutivité. Comprendre les modèles de distribution d’applications et la manière dont ils exploitent l’équilibrage de charge offrira une meilleure perspective sur l’architecture de l’échelle et des performances des services numériques, en particulier lorsque ces services sont susceptibles d’être hybrides et de comprendre un mélange d’API et d’applications modernes et traditionnelles.