Applications Web : comment anticiper les crashs en période de crise
Un site ou une application Web est sensible à la montée en charge et autres pics de trafic, qu’ils soient prévus ou totalement fortuits. Cet article délivre quelques conseils pour anticiper ces phénomènes et organiser les réparations quand il est déjà (un peu) trop tard.
Les soldes demandent généralement aux équipes techniques des vendeurs par correspondance de préparer leurs infrastructures IT. Il serait mal venu que leur site tombe dans une période d’affluence. Imaginez maintenant que ce phénomène ne touche pas seulement les e-commerçants, mais une grande partie des services, applications et sites disponibles sur le Web. Imaginez encore que cela dure plusieurs jours, voire plusieurs semaines d’affilée. Oui, cela peut vous paraître familier.
Une page Web est en réalité un rideau derrière lequel se cache différents services, microservices, des applications, des API, etc. Il s’agit souvent d’une interface d’appels vers des éléments disparates pensés pour accomplir des processus : l’achat d’un produit, le paiement d’un service, l’accès à une plateforme de vidéo à la demande, à un outil de communication, etc.
Une telle situation demande une mobilisation forte des équipes de développement, des Ops et des DevOps. Mais avant d’agir, il faut bien trouver la panne ou la cause des ralentissements. Qu’est ce qui provoque le crash d’un site ou d’une application Web dans une période d’affluence ? Quel composant est le plus susceptible de tomber en premier ? Comment y remédier ? Comment anticiper les prochains pics de charge ? Cet article apporte son lot de réponses pour surmonter une crise et se préparer à la suivante.
Au bord du crash, ne nettoyez pas votre cache
Aymeric Aitamer est cofondateur et PDG d’Artifakt, l’éditeur d’une PaaS DevOps principalement dédiée à la gestion des sites et des applications d’e-commerce. Selon lui, « les serveurs front-end crashent en premier. Ces serveurs prennent la requête du client et exécutent le code pour rendre la page ».
Les phénomènes de pics de charge peuvent être soudains. Ils sont généralement anticipables : les autorités garantissent la tenue d’un calendrier des soldes, ou préviennent, même tardivement, quand elles prennent des mesures exceptionnelles comme un confinement. Avant une période de crise, il y a souvent des signes avant-coureurs. Cela peut paraître évident, mais suivre l’actualité permet de détecter les premiers signes d’emballement et donc de se préparer à un éventuel impact sur les activités Web.
« En cas de risque de pic de trafic supplémentaire, évitez de faire des mises en production de dernière minute. »
Aymeric AitamerPDG, Artifakt
Dans ces cas-là, Aymeric Aitamer recommande d’éviter le déploiement de nouveaux éléments de code. « En cas de risque de pic de trafic supplémentaire, évitez de faire des mises en production de dernière minute », affirme-t-il. « Si votre site Web ou votre application fonctionnent avant la montée en charge, ce serait bête de faire des modifications, de vider le cache et d’introduire des bugs alors que le trafic va augmenter ».
S’il est nécessaire d’adapter les offres ou les services disponibles depuis une application ou son site, le nettoyage du cache doit avoir lieu dans la nuit ou dans la matinée.
Si vous avez pu anticiper ce phénomène, il faut alors adapter l’architecture et l’infrastructure. « Quand il ne faut pas seulement augmenter le nombre de serveurs, il faut aussi adapter la base de données, le stockage, le load balancer, etc. Il y a plein de couches à vérifier, il faut toutes les mettre à l’échelle », affirme le PDG d’Artifakt.
Pour les utilisateurs de solution d’hébergement dans le cloud qui disposent d’une option de scaling, la chose est plus aisée, ils peuvent généralement le faire depuis l’interface fournie par l’opérateur. Ils peuvent aussi bénéficier de systèmes d’autoscaling. Mais cela ne suffit pas. « Il faut modifier les règles de scaling. Si le nombre de visiteurs explose soudainement, l’infrastructure ne suivra pas. Le temps qu’un nouveau serveur se lance, le premier serveur est déjà tombé. Il faut donc diminuer la limite du nombre de visiteurs avant le déploiement d’un serveur », selon Aymeric Aitemer.
Pour les entreprises qui n’ont pas d’option de mise à l’échelle comme celle fournie par AWS par exemple, ils doivent augmenter les capacités de la machine. Aymeric Aitamer recommande d’augmenter de trois à quatre fois les capacités des machines qui supportent un site ou une application.
Renforcez la base de données pour éviter les goulets (d’étranglement)
C’est là qu’un autre problème peut apparaître. Les serveurs plus nombreux ou plus adaptés à la demande vont envoyer également plus de requêtes vers la base de données. « Autant c’est assez commun de voir du scaling sur des serveurs front-end, autant c’est assez rare que les entreprises adoptent une base de données capable de s’adapter automatiquement à la montée en charge », estime le PDG d’Artifakt.
Dans ce cas, il faut augmenter les capacités des machines qui exécutent la base de données. Il se peut que lors d’un crash de la base de données, la dernière requête corrompe l’ensemble du SGBD. Des sauvegardes régulières, automatisées et des réplications sont fortement conseillées.
La plupart des SGBD managés dans le cloud offrent cette capacité de prise d’échelle à la volée : RDS, Aurora Serverless, MongoDB Atlas, etc.
Dans le cas où la base de données ne dispose pas de cette capacité, « le DevOps (ou les développeurs et les Ops) est hyper important », selon Aymeric Aitemer. « Il s’occupe de configurer correctement l’infrastructure, des optimisations, de l’observabilité. L’infrastructure est importante, mais s’il n’y a pas d’attention particulière à optimiser l’application, elle consommera plus, coûtera plus cher et elle risque de planter plus régulièrement ». « L’argent de l’entreprise est maintenant dans la main du développeur et du devOps ».
Tout dépend du choix de l’architecture logicielle. Une application monolithique aura tendance à plus facilement tomber si un des services compris en son sein est trop sollicité. « La cause d’une panne est plus difficile à trouver avec un monolithe. De plus, difficile d’estimer quel élément de l’architecture il faudra gonfler pour résister à une montée en charge », considère le PDG d’Artifakt.
« Si l’un des microservices tombe, on peut le redémarrer, il n’y a pas besoin d’éteindre toute l’application ou le site web. »
Aymeric AitamerArtifakt
Avec une architecture basée sur des microservices, c’est chacun des éléments d’une application ou d’un site web qui peut être « renforcé » ou délesté pour supporter le changement de comportement des internautes. « Si l’un des microservices tombe, on peut le redémarrer, il n’y a pas besoin d’éteindre toute l’application ou le site web », estime-t-il.
Le système D peut vous sauver
Le cloud privé ou les infrastructures infogérées demandent une action humaine, de demander à son hébergeur d’ajouter physiquement des serveurs et des disques durs, ou de le faire soi-même. Malheureusement une crise peut provoquer une pénurie de baies, de disques durs ou bloquer les techniciens capables de réaliser ces déploiements. Peu importe, l’optimisation du code ne pourra pas régler le problème.
Dans les cas plus graves où le maintien du site Web est vital pour l’entreprise ou pour les clients, il est possible de créer des files d’attente. « Ce n’est vraiment pas l’idéal, mais cela peut aider à la continuité même partielle des activités », se résigne le PDG d’Artifakt. Une partie des utilisateurs accèdent alors à votre application, ou alors les services sont dégradés. Rediriger le Front-End vers une page statique est également un moyen d’indiquer aux utilisateurs que l’entreprise est en train d’œuvrer à la réparation de son site/de son application, ce qui permet de suivre la liste de conseils évoqués ci-dessus pour rétablir l’architecture.
Dans tous les cas, c’est le rôle de l’équipe DevOps et du SRE (« Site Reliability Engineer ») d’anticiper ces situations, d’observer l’architecture pour réparer les incidents le plus rapidement possible et « de trouver les bonnes technologies pour le faire », selon le PDG d’Artifakt. Les logiciels de monitoring (ELK, New Relic, Dynatrace, DataDog, etc.), les plateformes de gestion de systèmes distribués comme Ansible ou Jenkins sont également là pour vous aider. Le support des services cloud est là pour vous épauler aussi, s'il y a un problème. En cas d’externalisation du support auprès d'agences de développement Web, c’est la même démarche à effectuer.
« L’équipe ou le service externe DevOps n’est pas un centre de coût, c’est essentiel pour le maintien de l’activité, une assurance en somme », conclut Aymeric Aitamer.
