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 vers l'adresse IP du site fournie par l'interrogation GSLB. Il s'agit souvent d'un répartiteur de charge local qui applique ses propres algorithmes et prend des décisions pour diriger la requête vers 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’emploie le terme POLB car seuls des algorithmes décident comment orienter les requêtes. Malheureusement, selon l’algorithme utilisé pour répartir les requêtes, de nombreux problèmes peuvent survenir. Par exemple, le round robin ne tient pas compte de la capacité ni des performances. Il choisit simplement « la prochaine application » et la requête est envoyée. Opter pour « le moins de connexions » peut rapidement dégrader les performances en surchargeant une ressource, alors que d’autres seraient plus rapides. Le choix d’algorithmes devient un facteur clé pour garantir 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 de persistance, le principe reste identique. Lorsqu’un indicateur montre qu’une session est déjà ouverte, l’équilibreur de charge maintient la connexion existante tout au long de votre session utilisateur. Sinon, il choisit une ressource selon sa configuration et ses algorithmes, puis établit la connexion.

Cela affecte la planification de la capacité lors du choix d’un algorithme d’équilibrage de charge. Le mode « moindre nombre de connexions » convient parfaitement ici car il évite qu’une ressource unique se surcharge de sessions en cours pendant que d’autres restent inactives. Avec d’autres algorithmes, une seule ressource risque de gérer simultanément de nombreuses sessions utilisateur, ce qui dégrade les performances pour tous ceux 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 commence par le routage, puis par la répartition de la charge. Le schéma classique d'équilibrage de charge HTTP suit ce principe : acheminer –> distribuer. Vous décidez d'abord vers quel serveur virtuel orienter la requête, puis un algorithme sélectionne une ressource dans le pool qui soutient 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 avons cinq grands modèles de scalabilité, dont la plupart peuvent être combinés — et le sont souvent — pour optimiser l'utilisation des ressources et maximiser les performances. Si vous n’en utilisez pas encore, vous allez probablement y recourir. Comprendre leurs bases vous permet de bâtir une architecture évolutive, quel que soit le type d’applications ou leur lieu de déploiement.

À l'échelle !