Les deux questions auxquelles vous devez répondre pour atteindre une haute disponibilité

L’impact le plus important sur les opérations dû à la migration soudaine des consommateurs et des employés vers les expériences numériques est peut-être la disponibilité. Certes, un pourcentage important d’organisations ont eu du mal à gérer accès à distance lorsque les travailleurs sont passés du bureau à la maison. Mais seuls quelques travailleurs ont fini par travailler à domicile alors que des populations entières sont soudainement devenues dépendantes des équivalents numériques de la vie quotidienne. 

Considérez les conclusions de Nokia , qui rapporte que « le trafic en amont (certains réseaux aux États-Unis) pour le mois de mars 2020 » a connu une « augmentation de 30 % du trafic en amont par rapport à leurs niveaux d'avant la pandémie ». Ou ces données montrant une augmentation de 72 % des transactions (et de 29 % des pages vues) pour la deuxième semaine d'avril.  

La demande d’expériences numériques est en hausse. Et il n’y a rien de plus frustrant pour un utilisateur qu’une application ou un site Web qui ne parvient pas à se charger. Pour être honnête, il n’y a rien de plus frustrant pour un opérateur qu’une application ou un site Web qui ne se charge pas.

Obtenir une haute disponibilité ne consiste pas simplement à insérer un équilibreur de charge dans le chemin des données. Cela fait partie de l’équation, mais ce n’est qu’une des étapes nécessaires pour garantir qu’une application ou un site Web reste disponible.

La première chose que vous devez faire est de répondre à deux questions pas si simples :

• Comment répartir le trafic entre les serveurs pour une haute disponibilité ?
• Quel niveau de contrôle de santé est requis pour valider correctement la disponibilité d'un serveur ?

À première vue, ces choses semblent plus simples qu’elles ne le sont en réalité. C'est parce que pour y répondre, vous devez en savoir beaucoup sur l'application et son infrastructure.

Commençons, d'accord ?

Comment répartir le trafic entre les serveurs pour une haute disponibilité ?

Cette question pose vraiment la question de savoir quel est le bon algorithme d’équilibrage de charge à utiliser, car ce sont les algorithmes qui déterminent la manière dont le trafic (requêtes) est réparti entre les ressources (serveurs). La réponse à cette question dépend de nombreux facteurs, mais commence par l’architecture de l’application et les modèles d’utilisation. 

Vous voyez, si vous essayez de rendre une application traditionnelle (monolithique, client-serveur, Web à trois niveaux) hautement disponible, vous devez comprendre les modèles d'utilisation d'un point de vue entièrement différent.

Cela est dû au fait qu’un « serveur » back-end est responsable de l’exécution de toute la logique métier. Vous essayez de vous connecter ? Commander un produit ? Vous parcourez le catalogue ? Toujours le même « serveur ». Vous pourriez penser que vous pouvez simplement utiliser un algorithme simple comme le round-robin pour distribuer le trafic. Au contraire, mon ami. Chaque fonction commerciale a des exigences différentes en matière de calcul, de mémoire, de réseau et de données. Cela signifie que chaque fonction commerciale exerce une charge différente sur le « serveur ». Une seule instance de « serveur » peut rapidement être surchargée simplement en dirigeant vers elle trop de requêtes gourmandes en ressources.

La meilleure façon d’optimiser la distribution des requêtes pour garantir la disponibilité des applications traditionnelles est d’utiliser un algorithme basé sur le minimum de connexions. Cela permettra de répartir la charge entre les instances de « serveurs » en fonction du nombre de connexions actuellement ouvertes. La raison pour laquelle cela fonctionne est que les demandes gourmandes en ressources prendront plus de temps à traiter, ce qui permet de maintenir les connexions actives. En dirigeant les requêtes vers des « serveurs » avec moins de connexions, vous avez plus de chances de les garder tous disponibles.  

Pour les applications modernes (basées sur des microservices), cette question est plus facile à répondre. C’est parce qu’une application moderne est déjà décomposée en fonctions métier qui s’adaptent individuellement. C'est toujours une bonne idée d'utiliser un algorithme basé sur le moins de connexions, car certaines requêtes pour la même fonction peuvent consommer plus de ressources qu'une autre, mais le trafic est naturellement équilibré dans une architecture d'application moderne, donc à peu près n'importe quel algorithme servira à garder tous les « serveurs » disponibles.

Ce qui est intéressant (pour moi en tout cas) à propos de la disponibilité, c'est que savoir comment distribuer les demandes n'est que la moitié de la bataille. L’autre n’est malheureusement pas les lasers rouges et bleus, mais repose sur la visibilité de l’état de santé de l’ application.

Quel niveau de contrôle de santé est requis pour valider correctement la disponibilité d'un serveur ?

C'est ici que ma thèse sur l'observabilité* devrait être insérée mais, par souci de concision et de votre santé mentale, je vais simplement résumer ainsi : 

Si vous utilisez autre chose que la « disponibilité de application » pour déterminer l'état d'une application, vous mettez en péril la haute disponibilité. C'est parce qu'aucune des autres mesures observables ne vous dit rien sur l'application. Bien que vous ayez besoin de la disponibilité du réseau, du transport et de la plateforme, tant que vous n'êtes pas sûr que l'application est prête à recevoir des requêtes, vous vous exposez à des ennuis si vous lui envoyez du trafic.

Les quatre composantes de l’observabilité sont importantes. Si vous perdez la connectivité réseau, le reste n'a pas vraiment d'importance, après tout. Vous devez donc garder un œil sur les quatre mesures, c’est-à-dire les vérifier toutes. Peu importe l’architecture de l’application. Toutes les applications dépendent des couches réseau, transport et plateforme. C'est au niveau de la couche applicative que l'architecture fait la différence, car elle peut limiter la manière dont vous déterminez si l'application fonctionne ou non.

Vous devez toujours demander un moyen de « vérifier l'état de santé » de l'application pendant le développement. Que ce soit via une API ou une requête HTTP, l'existence d'un « contrôle de santé » dédié offre aux développeurs et aux opérateurs un moyen simple de vérifier que l'application fonctionne correctement. Cela peut inclure des fonctionnalités qui vérifient la connectivité à des ressources externes telles que des données ou des API partenaires. Étant donné que la défaillance de l'un de ces composants peut entraîner l'indisponibilité ou l'absence de réponse de l'application pour le consommateur, il est important de vérifier la disponibilité de tous les composants requis.

La haute disponibilité est plus difficile qu’il n’y paraît

Souvent, les documents marketing vous font croire que la haute disponibilité est aussi simple que de cloner un serveur et de placer un équilibreur de charge devant lui. Mais la réalité est qu’il faut prendre en compte, mesurer et préparer sérieusement pour garantir la haute disponibilité d’une application. Il ne s’agit pas seulement de s’assurer que les instances sont disponibles ; il s’agit de s’assurer que toutes leurs applications dépendantes sont disponibles et de distribuer les requêtes de manière à ne pas submerger une instance donnée.

L’avantage de tous les efforts supplémentaires que vous consacrez à garantir la haute disponibilité des applications est une expérience client positive et moins d’appels frénétiques tard le soir concernant des applications en panne.

_{* Je n'ai pas réellement de thèse sur l'observabilité. Mais si je l'avais fait, c'est ici qu'il aurait été inséré.}