Les cinq principaux modèles d'évolutivité

La disponibilité est une affaire sérieuse dans une économie où les applications sont une monnaie d’échange. Les applications qui ne répondent pas sont supprimées sans préavis et dénigrées sur Internet avec la rapidité et le sarcasme d’un avis négatif sur Yelp.

Depuis les premiers jours d’Internet, les organisations ont cherché à garantir que les applications (les sites Web, autrefois) soient disponibles 24 heures sur 24, 7 jours sur 7 et 365 jours par an. Parce qu’Internet ne dort jamais, ne prend jamais de vacances et ne se déclare jamais malade.

Pour répondre à ce besoin (exigence, en réalité), l’évolutivité est devenue l’un des premiers services applicatifs à assurer la disponibilité. Le service d’application le plus visible – et le mieux compris – répondant aux besoins de disponibilité est l’équilibrage de charge.

Il existe cependant de nombreuses formes d’équilibrage de charge et de modèles d’évolutivité que vous pouvez mettre en œuvre à l’aide de cette technologie de base. Aujourd’hui, je vais mettre en évidence les cinq principaux modèles d’évolutivité utilisés qui permettent aux applications et à Internet de rester en ligne et disponibles 24h/24, 7j/7 et 365j/an.

Équilibrage global de la charge du serveur (GSLB)

Le nom du GSLB est terriblement mal choisi. Il n’a jamais vraiment été question d’équilibrage de la charge du serveur , mais plutôt de disponibilité du site . Aujourd’hui, cela s’étend également à la disponibilité des applications.

GSLB est le moyen par lequel vous garantissez que si un centre de données (cloud ou traditionnel) ne répond pas, vous pouvez en trouver un autre. GSLB peut être appliqué au niveau du domaine ou de l'hôte. Vous pouvez donc l'utiliser pour basculer entre example.com et api.example.com.

Dans sa forme la plus basique, GSLB utilise un équilibrage de charge rudimentaire basé sur DNS. Cela signifie qu’il dispose d’une liste d’adresses IP associées à un domaine ou à un hôte, et si le premier n’est pas disponible, les requêtes sont dirigées vers le deuxième de la liste – ou le troisième, ou le quatrième, et ainsi de suite.

Ce processus se déroule en deux étapes :

1. Demandez à l’équilibreur de charge global l’adresse IP appropriée. Il s'agit du négatif toujours associé à GSLB : si vous avez demandé au cours des 15 dernières minutes ou quel que soit le TTL actuel pour l'adresse IP de cheese.com, vous obtenez la dernière réponse que vous avez reçue. Donc si ce site tombe en panne pendant ce temps, vous ne serez pas connecté.
2. Effectuez la requête à l'adresse IP du site renvoyée par l'enquête GSLB. Il s’agit souvent d’un équilibreur de charge local qui utilise ses propres algorithmes et son propre processus de prise de décision pour transmettre la demande à la ressource appropriée.

En règle générale, la décision prise à l’étape 1 n’est pas intelligente ; elle est strictement basée sur le fait qu’un site donné réponde ou non. Néanmoins, c’est ainsi que vous pouvez utiliser plusieurs emplacements (cloud, fournisseur d’hébergement, sur site) pour garantir la disponibilité. En choisissant stratégiquement des emplacements dans diverses zones géographiques, vous pouvez éviter l’impact des catastrophes naturelles ou des pannes Internet.

Mais il s’agit davantage d’un scénario de reprise après sinistre (DR) ou de continuité des activités (BC). D'autres bénéficient de services d'application GSLB plus intelligents tels que la géolocalisation et les performances des applications. Ainsi, si l’application du site A fonctionne mal, vous souhaiterez peut-être envoyer les visiteurs vers le site B jusqu’à ce que le problème soit résolu. Ou peut-être souhaitez-vous diriger les utilisateurs vers l’emplacement géographiquement le plus proche pour améliorer les performances (car la vitesse de la lumière est toujours une règle et la distance compte pour les performances de l’application).

Quelle que soit la manière dont la décision est prise, le modèle de base reste le même : GLSB distribue les requêtes sur plusieurs sites physiquement séparés en renvoyant l'adresse IP de l'un des sites disponibles. Qu'il s'agisse d'API ou d'applications, GSLB est un modèle d'assurance de disponibilité de haut niveau.  

Équilibrage de charge simple et traditionnel (POLB)

Disponibilité basée sur la connexion

Plain Old Load Balancing (POLB) est un terme que j'aime utiliser pour décrire l'équilibrage de charge standard basé sur TCP. La disponibilité est obtenue à l'aide de ce modèle simplement en clonant les applications et en s'assurant qu'une connexion entre le client (utilisateur, appareil) et l'application peut être établie.

L'équilibreur de charge (ou le proxy si vous préférez) reçoit une demande de connexion, sélectionne une instance d'application disponible et transmet la connexion. C’est la dernière fois que l’équilibreur de charge intervient activement. C'est comme un « e-mail de présentation » dans lequel vous facilitez la rencontre entre deux collègues. Vous participez activement à l’échange initial, mais vous êtes ensuite déplacé vers la ligne CC et ne vous engagez généralement pas davantage.

J’utilise le terme POLB car il n’y a rien de plus que des algorithmes impliqués dans le choix de la manière d’adresser les demandes. Malheureusement, de nombreux problèmes peuvent survenir en fonction de l’algorithme utilisé pour distribuer les requêtes. Par exemple, le round robin ne se soucie pas de la capacité ou des performances. Il suffit de sélectionner « l’application suivante » et la demande est lancée. Choisir « le moins de connexions » peut rapidement avoir un impact sur les performances en chargeant une ressource, tandis que d’autres peuvent être plus rapides. Le choix des algorithmes devient un élément critique du maintien de la disponibilité.

POLB est la méthode par défaut d’équilibrage de charge dans les environnements de conteneurs et pour de nombreux services d’équilibrage de charge natifs du cloud.

Persistance

Sessions persistantes et SSL

L’une des réalités des applications à trois niveaux est qu’elles sont, en règle générale, avec état. Cela signifie qu'ils stockent des informations entre les requêtes et les réponses qui sont essentielles au fonctionnement de l'application. Votre panier d’achat, vos identifiants, votre statut, la dernière page que vous avez visitée et l’étape à laquelle vous vous trouvez dans un processus sont autant d’informations qui sont souvent stockées dans le cadre de la « session ». Le problème est que de nombreuses applications développées à l’aide de frameworks à trois niveaux finissent par stocker cette session sur l’application ou le serveur Web, et non dans une base de données. Cela signifiait qu'une fois que vous étiez connecté à un serveur, vous deviez revenir sans cesse à ce serveur pour vous assurer que toutes vos informations étaient disponibles.

Les équilibreurs de charge implémentent la persistance de diverses manières, la plus populaire étant basée sur les cookies. Les identifiants de session étaient stockés dans un cookie qui était ensuite utilisé par l'équilibreur de charge pour s'assurer que les requêtes parvenaient au bon serveur, contournant ainsi efficacement un processus de sélection algorithmique.

Lorsque l’utilisation de SSL/TLS est devenue une exigence essentielle pour que les acheteurs se sentent en sécurité, les mêmes problèmes sont apparus. SSL/TLS permet une session sécurisée entre un client et un serveur d'application spécifique. Pour garantir que les deux côtés de la conversation puissent décrypter et utiliser les données échangées via cette connexion, l'équilibreur de charge devait pouvoir envoyer les requêtes client au même serveur sur lequel il avait démarré. En utilisant les mêmes techniques que celles permettant la persistance basée sur les sessions, les équilibreurs de charge ont pu prendre en charge la persistance basée sur SSL/TLS.

Quel que soit le type spécifique de persistance utilisé, le modèle est le même. S'il existe un indicateur indiquant qu'une session a déjà été établie, l'équilibreur de charge honore la connexion existante et garantit qu'elle reste en place pendant toute la durée de la session utilisateur. S’il n’y en a pas, l’équilibreur de charge sélectionne une ressource en fonction de sa configuration et de ses algorithmes et établit la connexion.

Cela a des conséquences sur la planification de la capacité lors de la sélection d’un algorithme d’équilibrage de charge. Le nombre minimal de connexions est un bon choix pour ce scénario, car il garantit qu'aucune ressource ne sera surchargée par des sessions en cours tandis que d'autres resteront inactives. Avec d’autres algorithmes, il est probable qu’une seule ressource finisse par gérer plusieurs sessions utilisateur en même temps, ce qui a un impact négatif sur les performances de tous les utilisateurs dirigés vers ce serveur.

Équilibrage de charge basé sur l'hôte

Serveurs virtuels

L’équilibrage de charge basé sur l’hôte est l’un des modèles d’évolutivité les plus courants et les plus largement pris en charge. Vous pourriez penser que vous n’avez pas besoin d’un équilibreur de charge pour implémenter celui-ci, car tous les serveurs Web prennent en charge la possibilité de se faire passer pour plusieurs hôtes en même temps. Mais tu le fais. Bien qu’un serveur Web/d’application puisse héberger plusieurs serveurs virtuels, il n’équilibre pas nécessairement la charge entre eux. Vous avez donc toujours besoin d’un équilibreur de charge pour évoluer. La question est de savoir si l'équilibreur de charge répartira les hôtes ou si vous laisserez cela au serveur Web/d'applications ?

Que vous utilisiez des directives de serveur Web/d'application ou un équilibreur de charge externe, le flux reste le même. Une requête est effectuée et reçue par la cible (équilibreur de charge ou serveur Web/d'application). Le serveur cible inspecte ensuite les en-têtes HTTP et recherche la valeur de l'hôte avant de diriger la demande vers le serveur virtuel approprié. 

L’avantage d’utiliser un équilibreur de charge pour diviser les hôtes réside dans sa capacité à permettre l’isolement des domaines en fonction de l’hôte et à les faire évoluer individuellement. Cela est plus efficace et peut réduire le nombre de serveurs (matériels et logiciels) dont vous avez besoin pour faire évoluer une application. Cela facilite également la planification de la capacité, car vous pouvez mieux prévoir la charge que chaque serveur hôte peut gérer à un moment donné.

C’est parce que l’invocation de la logique métier n’est pas la même en termes de calcul requis que celle de la demande d’une image. Le mélange et la mise en correspondance d'hôtes dans le même domaine d'évolutivité génèrent une charge volatile et une capacité imprévisible. Si vous choisissez d'utiliser un équilibreur de charge pour fournir un équilibrage de charge simple, le serveur Web/d'application est alors chargé de séparer les hôtes et de diriger les requêtes vers le serveur virtuel approprié. L’autre inconvénient de cette approche est la nature de l’infrastructure partagée, avec des conflits de versions et des correctifs ainsi que des mises à jour d’applications pouvant potentiellement provoquer des frictions entre les serveurs virtuels.

L’adoption croissante des conteneurs et des microservices entraîne l’utilisation de l’équilibrage de charge basé sur l’hôte sous la forme de contrôleurs d’entrée .

Itinéraire et retour 

Équilibrage de charge de couche 7 (HTTP)

L'équilibrage de charge de couche 7 (HTTP) est mon préféré grâce à la polyvalence (agilité ?) qu'il offre. Vous pouvez équilibrer la charge des requêtes en fonction de n'importe quel élément HTTP, y compris la charge utile. La plupart des gens (intelligemment, à mon avis) limitent leurs règles d’équilibrage de charge à ce qui peut être trouvé dans l’en-tête HTTP. Cela inclut l'hôte, la méthode HTTP, le type de contenu, les cookies, les en-têtes personnalisés et l'agent utilisateur, entre autres.

L'équilibrage de charge HTTP concerne d'abord le routage, puis l'équilibrage de charge. Un modèle d’équilibrage de charge HTTP typique prend la forme de route –> distribuer. Cela signifie qu’une décision est d’abord prise quant au serveur virtuel vers lequel une demande doit être dirigée, puis un algorithme sélectionne une ressource dans le pool prenant en charge ce serveur virtuel.

L'équilibrage de charge HTTP permet des modèles tels que le contrôle de version d'API, où la version de l'API est intégrée dans l'URI (ou dans un en-tête HTTP personnalisé). L'équilibreur de charge est capable de séparer les versions et de garantir que les clients sont envoyés au bon service back-end pour exécution. Cette migration de clients est toujours gracieuse dans les situations où vous ne pouvez pas forcer la mise à niveau.

Ce type de modèle d’évolutivité prend également en charge d’autres modèles d’évolutivité tels que la décomposition fonctionnelle et le partitionnement des données. Il s’agit du modèle d’évolutivité le plus robuste et le plus agile du mix et il permet une vaste gamme d’options lors de la mise à l’échelle des applications et, de plus en plus, des microservices.

Pour résumer, nous disposons de cinq principaux modèles d’évolutivité, dont la plupart peuvent être (et sont souvent) combinés pour permettre l’utilisation la plus efficace des ressources et les meilleures performances possibles. Il y a de fortes chances que si vous n’en utilisez pas actuellement, vous le fassiez. Par conséquent, comprendre leur composition de base constitue une bonne base pour créer une architecture évolutive, quel que soit le type d’applications que vous utilisez ou l’endroit où vous les avez déployées.

À l'échelle !