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 cible précisément l'algorithme d'équilibrage de charge à adopter, car ce sont ces algorithmes qui déterminent comment le trafic (requêtes) se répartit entre les ressources (serveurs). La réponse dépend de nombreux éléments, en commençant par l’architecture de l’application et ses modes 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 s’explique par le fait qu’un seul « serveur » en back-end exécute toute la logique métier. Vous essayez de vous connecter ? Vous passez une commande ? Vous parcourez le catalogue ? Toujours ce même « serveur ». Vous pensez pouvoir simplement utiliser un algorithme comme le round-robin pour distribuer le trafic ? Pas du tout, mon ami. Chaque fonction métier exige des ressources différentes en calcul, mémoire, réseau et données. Cela signifie que chaque fonction sollicite le « serveur » de manière unique. Une seule instance de « serveur » peut vite être surchargée en recevant trop de requêtes gourmandes en ressources.

La meilleure méthode pour optimiser la répartition des requêtes et garantir la disponibilité des applications traditionnelles consiste à utiliser un algorithme basé sur le nombre minimum de connexions. Nous répartissons ainsi la charge entre les instances des « serveurs » selon le nombre de connexions ouvertes à un instant donné. Cette méthode fonctionne parce que les requêtes gourmandes en ressources prennent plus de temps à traiter, conservant ainsi les connexions actives. En orientant les requêtes vers les « serveurs » ayant le moins de connexions, vous assurez leur disponibilité maximale.  

Pour les applications modernes (basées sur des microservices), vous pouvez répondre facilement à cette question. Une application moderne se décompose déjà en fonctions métier qui s’adaptent individuellement. Nous recommandons toujours un algorithme basé sur le nombre minimum de connexions, car certaines requêtes pour une même fonction utilisent plus de ressources que d’autres, mais le trafic est naturellement équilibré dans une architecture moderne, et presque tous les algorithmes permettent de garder les « serveurs » actifs.

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.

Demandez toujours comment effectuer un contrôle de santé de l’application pendant son développement. Que ce soit via une API ou une requête HTTP, un contrôle de santé dédié offre aux développeurs et aux équipes opérationnelles un moyen simple de vérifier que l’application fonctionne correctement. Cela peut inclure une vérification de la connectivité aux ressources externes comme des données ou des API partenaires. Comme la défaillance de l’un de ces éléments peut rendre l’application indisponible ou non réactive pour l’utilisateur, assurez-vous de vérifier la disponibilité de tous les composants essentiels.

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é.}