Covid-19 : Performance et scalabilité des services numériques à l’heure du télétravail massif

Lundi 16 mars 2020, 9 h. Ma fille s’installe devant l’ordinateur familial pour ouvrir l’Espace numérique de travail (ENT), la plateforme numérique qui relie les élèves à leurs enseignants et les familles aux écoles. But du jeu : poursuivre sa scolarité à distance, comme annoncé par le ministre de l’Éducation. Mais elle n’obtiendra qu’un seul et unique retour : un message d’erreur ! Il l’accompagne toute la journée : l’ENT est saturé de demandes. Il n’est pas prévu/équipé/pensé pour affronter une armée de collégiens affolés !

La crise du coronavirus impose, à travers le monde de nouveaux modes de travail pour ceux qui le peuvent. Le télétravail massif impacte en effet de façon colossale les réseaux et les services numériques, rendant certains d’entre eux inopérants, car saturés. Ces nouveaux usages mettent un poids énorme sur les réseaux, et toutes les interactions habituellement sociales s’y retrouvent déportées. En tant qu’exploitant de système numérique, il se peut que votre service ne tienne plus la charge. Le confinement et le télétravail étant appelés à durer un petit moment encore, nous vous proposons dans cet article de revenir sur les principes de base de la performance et de la scalabilité d’un service numérique. Avec des solutions exploitables rapidement, nous vous proposons une liste d’actions qui vous permettra non seulement de faire face à l’urgence, mais également de mieux anticiper et affronter ce genre de crise. Étape par étape, nous vous aidons à traverser cette période dans l’urgence, et jusqu’à 6 mois après la fin de la crise, afin de réconcilier performance et scalabilité. Il ne s’agit pas ici de lister toutes les actions de manière exhaustive, mais plutôt de vous proposer une vue d’ensemble. Alors, suivez le guide !

Identifier le maillon faible

C’est la première étape. Un bon service numérique, c’est comme une bonne chaîne hifi : il est toujours limité par son maillon le plus faible. La problématique principale consiste à connaître le maillon le plus faible dans le service. Pour cela, il est nécessaire d’avoir mis en place des indicateurs sur chacun des éléments : trafic entrant, occupation RAM et disque, utilisation CPU, temps de réponse HTTP de bout en bout, temps de réponse des requêtes en base de données, trafic réseau interne…. Toutes ces données de monitoring vont vous permettre d’identifier votre ou vos maillons faibles.

À ce stade ces indicateurs seront probablement issus de multiples sources et pour certains collectés manuellement. C’est pourquoi la mise en place de solutions de monitoring complètes et intégrées sera l’une des priorités, afin d’orienter efficacement les efforts.

Bonne nouvelle par ailleurs : de nombreuses solutions existent pour créer autour de votre application un écosystème capable de l’aider à monter en charge. À savoir : Caches, Proxy, Machines Virtuelles, Cloud, Salles d’attente virtuelles, Déploiement automatisé, et méthodologies DevOps … Le tableau ci-dessous recense différents leviers actionnables à plus ou moins court terme.

Ces différentes solutions s’insèrent ensuite à différents endroits dans le cycle requêtes / réponses entre le navigateur et les serveurs.

Dans l’urgence !

On dispose donc de tout un arsenal pour régler le problème. Reste à l’utiliser dans le bon ordre, en fonction de la situation et du niveau d’urgence. Chacun de ces leviers peut être activé facilement en fonction de certaines contraintes. Par exemple, il est plus difficile de tirer profit d’un CDN, si les ressources statiques ne sont pas versionnées. On ne peut pas faire de scalabilité horizontale si l’application n’a pas été prévue pour… Et parfois, c’est simplement un disque trop petit qui bloque tout le système…
Bref, souvent, le premier réflexe doit être de regarder si on peut augmenter la taille de la machine sur laquelle tourne l’application. Autrefois, il fallait intervenir en salle machine, ajouter un disque, de la ram…. Aujourd’hui il suffit souvent de se connecter à la console VMWARE et d’ajouter un CPU ou de la RAM “virtuelle”.

Cela peut aider à passer un pic, même si ce n’est probablement pas satisfaisant ni intellectuellement ni écologiquement. Mais là, vous avez 2 h pour régler le problème, donc il faut être efficace. On fermera les yeux pour cette fois, alors allez-y !

Dans tous les cas, il est important d’avoir tous les indicateurs nécessaires pour prendre cette décision : si vous n’avez pas d’indicateurs et ne savez pas sur quels éléments agir, la toute première action consiste donc à installer un outil moderne de monitoring tel que Datadog, Newrelic et consorts. La plupart viennent aujourd’hui avec leur lot de sondes système et applicatives, capables de s’adapter à quasiment tous les contextes. Ces outils d’APM (Application Performance Monitoring) ont d’ailleurs souvent généralisé le monitoring jusqu’au navigateur de l’utilisateur, permettant d’avoir une vue de la performance sur toute la chaîne : de l’exécution du JavaScript dans le navigateur, à la performance des requêtes dans la base de données, en passant par le réseau et l’application. Ces outils remonteront très rapidement les indicateurs vous permettant d’identifier votre ou vos maillons faibles. Et surtout, ce sont ces indicateurs qui vous diront, au fur et à mesure de vos actions, l’impact qu’elles auront eu ainsi que les faiblesses suivantes à corriger et vous guideront dans vos priorités d’actions.

Dans la semaine

L’étape d’après, si vous n’en avez pas dans votre architecture à date, c’est de mettre en place des proxy / caches (ex. Varnish). En commençant par les plus simples, ceux que vous mettez devant votre application et qui mémorisent les questions et les réponses.

Reprenons l’exemple de notre élève :
La première fois qu’un élève de 4e A veut accéder à la page “devoirs” du 25 mars, le proxy interroge l’application, qui va chercher en base de données le contenu saisi par le professeur. Ensuite le proxy stocke ce résultat qui est le même pour tous les élèves de la 4e A, il n’a plus besoin d’interroger ni l’application ni la base de données. En caricaturant un peu, vous venez potentiellement de diviser par 30 la charge sur votre application !

Un autre élément important est de décharger au maximum votre service numérique de la livraison des ressources statiques : en fonction de la typologie de votre application, celles-ci peuvent représenter jusqu’à 90% des requêtes http entrantes puisque pour une page demandée, il faut charger la ou les CSS, les scripts js et potentiellement les images / icônes ou autres ressources associées à cette page. La mise en place d’un CDN (Content Delivery Network) est une opération relativement simple aujourd’hui et l’effet sera très immédiat pour désengorger réseau et serveurs de cette gestion.

Cette première semaine d’exploitation sous tension forte de trafic peut être aussi l’occasion de travailler sur l’optimisation de votre ou vos bases de données si elles font partie des éléments fortement sollicités de l’architecture : vérifier les requêtes lentes, ajouter ou modifier les index sur certaines tables s’avèrent des choix payants rapidement et permettant de gagner les précieuses millisecondes qui, démultipliées sur l’ensemble des utilisateurs aideront le service.

Si votre service s’adresse au grand public, vous ne connaissez pas le nombre potentiel d’utilisateurs. Il est donc très important de pouvoir contrôler votre trafic entrant et non pas de le subir. Pour ce faire, des services de salles d’attentes virtuelles existent : elles permettent d’occuper l’utilisateur et donc ne pas le perdre le temps que votre application soit apte à traiter ses requêtes. Dans cette catégorie on peut citer par exemple https://queue-it.com ou encore https://www.netacea.com/.

Pour finir, cette première semaine vous aura également amené à rassembler autour de la table différents corps de métier : chefs de projet, Product Owners, développeurs, administrateurs systèmes. C’est l’occasion de commencer à supprimer les silos et de mettre en place des processus de collaboration plus directs.

Le premier mois

Vous avez mis en place toutes les solutions activables rapidement. Sur un temps un peu plus long, il est aussi possible, via les développeurs de l’application ou les ingénieurs systèmes, d’améliorer cette dernière assez simplement pour gagner encore en performance.

Vous avez, d’ores et déjà, mis en place des caches de type varnish en amont de l’application, qui agissent au niveau http. Il peut souvent être très performant d’en mettre en place au niveau de l’application elle-même ou en interception des entités/requêtes vers la base de données. Des solutions de type Redis ou Memcache permettent ainsi facilement d’y stocker et d’invalider à la demande des informations de session utilisateur, de catalogue sur un site e-commerce, ou autre préférences utilisateur nécessaire au traitement de chaque requête http par l’application.

Ce type d’amélioration est par ailleurs un préambule fréquent à la mise en place d’une scalabilité horizontale sur le service : une fois que le contexte n’est plus stocké par les serveurs applicatifs, ces derniers peuvent être ajoutés ou supprimés bien plus facilement. Cela permettant de partager sur l’ensemble des instances de l’application des informations.

En fonction de la typologie de l’application, il est aussi envisageable de mettre en place, même sur un délai aussi court, certains types de scalabilité horizontale, avec par exemple un répartiteur de charge gérant les sticky sessions.
Enfin, dans un contexte de réseau internet très chargé, industrialiser vos ressources front permettra d’améliorer l’expérience utilisateur avec des chargements de pages moins lourdes donc, plus rapide à récupérer par les utilisateurs. Cette industrialisation passe par l’optimisation des ressources statiques :

• Minification pour les CSS ou le javascript, compression (gzip/brotli),
• Suppression du code mort ou inutilisé,
• Versionning des ressources afin d’utiliser au mieux les fonctionnalités de cache des navigateurs,
• Optimisation des images pour le support de l’utilisateur (mobile, tablette, desktop, …)
• Optimisation des vidéos en fonction de la bande passante de l’utilisateur, éventuellement, comme le font dans un effort de solidarité les grands acteurs du streaming en ce moment, arrêt de la diffusion dans des formats UHD par exemple pour libérer de la bande passante chez les opérateurs.

Dans les mois qui suivent

C’est sur cette timeline qu’il s’avère intéressant de revoir son architecture technique, industrialiser à la fois le front, mais aussi l’ensemble de l’infrastructure afin que celle-ci soit capable de s’adapter au trafic. Et en prime, revoir le code applicatif afin qu’il soit capable de s’adapter à des architectures plus pérennes en termes de gestion du trafic utilisateurs : mise en place de micro-services, de mécanismes asynchrones, de serverless ou encore d’architecture réactives, les possibilités sont aujourd’hui nombreuses pour répondre à ces problématiques.

Au-delà de la plateforme de production elle-même, c’est la chaîne de déploiement et d’outillage qui devra être adaptée :

• L’amélioration de performances se fait de façon incrémentale, en traitant les points de contention les uns après les autres et en observant les résultats pour décider de l’étape suivante.
• Pendant la crise, mobiliser à chaque mise en production 6 personnes pendant plusieurs heures était éventuellement envisageable, mais ce n’est bien sûr pas viable sur le long terme.
• L’automatisation apportée par une chaîne maîtrisée d’intégration et de déploiement continu vous permettra d’entrer véritablement dans une démarche agile.

Ce cercle vertueux, entamé en réponse à une crise, deviendra une véritable force pour votre business en devenant le support de votre innovation. Au-delà de l’outillage, c’est la culture des équipes qui aura été impactée, en montrant qu’il est possible de déployer rapidement des changements, de mesurer leur efficacité et de piloter un projet de façon transverse. Ce qui était une stratégie de réponse à une crise pourrait bien devenir l’un de vos atouts pour reconquérir votre marché à plus long terme !

En résumé, pour parer à l’urgence de l’accès à votre service :

• Mettez en place le monitoring.
• Augmentez mémoire, disque et cpu si l’opération est simple et rapide.
• Suivez vos indicateurs de monitoring.
• Mettez en place des caches, proxy côté infrastructure.
• Suivez vos indicateurs de monitoring.
• Si le service est trop saturé, mettez en place un système de file d’attente virtuelle.
• Suivez vos indicateurs de monitoring.
• Mettez en place des caches applicatifs et/ou bases de données.
• Suivez vos indicateurs de monitoring.
• Mettez en place un système d’agrégation d’API si vous en utilisez et modifiez votre frontend en fonction.
• Suivez vos indicateurs de monitoring.
• Démarrez l’industrialisation infrastructure, frontend et backend et d’éventuelles refontes d’architecture.

En résumé