« Pourquoi votre site web a-t-il planté ? Vous deviez bien savoir qu’il y aurait beaucoup de monde ! »
On entend souvent cela lorsqu'un site web tombe en panne à un moment crucial. Les mêmes questions reviennent sans cesse sur les réseaux sociaux, sur le même ton accusateur : « Ils devaient bien savoir qu'il y aurait beaucoup de monde. Pourquoi n'ont-ils pas ajouté quelques giga-je-ne-sais-quoi supplémentaires ? »
Pour les utilisateurs déçus, il semble évident qu'une entreprise aurait dû mettre en place davantage de mesures préventives avant un pic de trafic important, et que la seule cause possible de ce dysfonctionnement est une mauvaise planification.
Mais quelles sont donc ces mesures préventives ? Des tests de charge ? Un « serveur plus puissant » ? Davantage de serveurs, peut-être ? Et pourquoi pas l'un de ces clouds « sans serveur » magiques et évolutifs… ?!
- À lire : Pourquoi passer à « un serveur plus puissant » ne protégera pas votre site contre les pics de trafic
Souvent, lorsque nous rencontrons pour la première fois les développeurs web d’une équipe, ceux-ci participent à une session d’intégration CrowdHandler, la queue entre les jambes. Ils ont l’impression d’avoir échoué. Ils ont tout fait dans les règles de l’art, mais le site web n’est toujours pas opérationnel ; du coup, faute de temps, ils sont contraints de le rafistoler à la va-vite avec une page d’attente. Les dix premières minutes de la réunion sont consacrées à écarter les excuses.
On a déjà tout entendu. Vous êtes en train de refondre la plateforme et le nouveau site ne présentera pas ces problèmes. Vous avez hérité d’une base de code héritée que vous ne pouvez pas modifier. Vous êtes coincés avec une ancienne version du framework X, qui est connue pour ses problèmes de performances. Vous pourriez bien sûr résoudre tous ces problèmes ; c’est juste une question de timing.
La raison de cette gêne tient au fait que la plupart des goulots d'étranglement — ces problèmes qui empêchent les sites web de gérer des milliers et des milliers d'utilisateurs — trouvent leur origine dans le code, dont les développeurs se sentent responsables.
Ces goulots d'étranglement se situent souvent en arrière-plan : quelque chose derrière la vitrine du site — un système de gestion des billets ou des rendez-vous, ou encore de traitement des paiements par carte bancaire, par exemple. Mais tout aussi souvent, les goulots d'étranglement se trouvent dans la vitrine elle-même. Dans le code web. Un code sur lequel les développeurs ont un contrôle total.
Écouter les excuses des développeurs ne nous donne pas le sentiment d’être suffisants ou supérieurs. Ce que nous ressentons surtout, c’est de la compréhension. Voici la vérité : le code de personne n’est évolutif dès sa création, et la plupart de ce qu’on vous a enseigné sur l’écriture de code évolutif est faux.
Je vais t'expliquer dans un instant pourquoi ce n'est pas de ta faute, mais je voudrais d'abord te présenter une nouvelle façon d'envisager la « salle d'attente ».
Installer CrowdHandler ne revient pas à admettre un échec. Au contraire, cela pourrait constituer la première étape vers la résolution de votre problème d'évolutivité. Plutôt que de le considérer comme un simple pansement, je vous invite à voir CrowdHandler comme un outil de diagnostic qui vous accompagnera dans votre travail et vous aidera à vous améliorer.
Ce n'est pas ta faute
Alors pourquoi ce n'est-il pas la faute des développeurs lorsque le site web ne parvient pas à gérer le trafic ?
Si le code courant est truffé de goulots d'étranglement liés au code, c'est parce que les développeurs web traditionnels ne travaillent généralement pas sur des sites web extrêmement populaires. Lorsque les développeurs web suivent une formation et acquièrent des connaissances, leur compréhension de l'optimisation et de la manière d'écrire du code performant reste, la plupart du temps, théorique.
Apprendre en théorie à écrire du code évolutif, puis voir dans la pratique cent mille utilisateurs se précipiter sur votre site me rappelle cette citation de Mike Tyson : « Tout le monde a un plan jusqu’à ce qu’il prenne un coup dans la figure ». Eh bien, vous avez pris un coup dans la figure. Vous pouvez en être fier ! La grande majorité des développeurs web ne travaillent jamais sur un projet suffisamment populaire pour découvrir ce que cela fait.
Je voudrais donc vous dire, à vous et à votre patron : il est tout à fait normal que votre site web ne puisse pas s'adapter comme par magie pour gérer n'importe quel niveau de trafic. Vous ne devriez pas vous attendre à ce qu'il le fasse.
Alors, quelle est la réponse ?
Bien sûr, vous souhaitez rendre votre site aussi performant et évolutif que possible. Cependant, bon nombre des solutions supposées permettre cette évolutivité, compte tenu des chiffres dont il est question ici, ne fonctionneront pas dans la pratique.
Vous pourriez vous concentrer sur des frameworks et des langages théoriquement plus rapides, mais cela ne change pas grand-chose à l'échelle globale lorsque vous devez répondre aux besoins de milliers, voire de millions d'utilisateurs.
Vous savez ce qui fait vraiment la différence ? La mise en cache. Pas le genre de mise en cache d’objets précise que l’on souhaite mettre en place près du serveur avec Memcached, mais cette mise en cache HTTP « à la limite » proche de l’utilisateur, qui donne l’impression d’échapper à votre contrôle. Cela améliore réellement les performances, mais c’est difficile à mettre en place correctement, et difficile à intégrer a posteriori dans des frameworks et des systèmes de gestion de contenu qui n’en tiennent pas suffisamment compte.
Je suppose donc que vous pourriez commencer par des tests de charge. Mais, même si cela peut paraître controversé, je ne pense pas que des tests de charge réguliers vous soient d’une grande utilité. D’après mon expérience, c’est souvent une perte de temps coûteuse.
Pourquoi ? Parce que le comportement réel des utilisateurs est complexe. Vous pouvez définir des parcours utilisateur basiques pour vos tests de charge, dans lesquels les utilisateurs naviguent sur une page, sélectionnent un produit, l’ajoutent à leur panier et passent commande — mais ce n’est pas ce qui se passe dans la réalité. Dans la réalité, les clients font des allers-retours, examinent toutes les options, changent d’avis, marquent de longues pauses avant de recharger les pages, puis ouvrent quatre onglets sur différents produits pour les comparer. Des milliers de ces parcours complexes peuvent se dérouler simultanément, en interrogeant les mêmes lignes de la base de données de manière imprévisible.
Vous pouvez donc effectuer une série de tests de charge sur l’environnement de préproduction qui provoquent la panne du site web à partir de deux millions d’utilisateurs, puis déclarer que deux millions est le « nombre magique ». Mais dans quelle mesure ces deux millions de parcours utilisateur sont-ils réalistes ? Représentent-ils réellement deux millions d’expériences authentiques et fonctionnelles sur l’environnement de production ? Ou bien le site web en production aurait-il planté bien plus tôt, lorsque les utilisateurs auraient commencé à se comporter de manière réaliste ? (Sans parler du moment où quelqu’un décide de générer un rapport commercial intensif en pleine période de soldes… Ah, vous ne testez pas ce scénario ?)
N’oublions pas que les tests de charge prennent également énormément de temps. Même avec un scénario de parcours utilisateur simplifié, vous devrez relancer les tests à maintes reprises, en corrigeant les problèmes de configuration jusqu’à ce que tout fonctionne. Et ensuite, une fois que cela fonctionne, vous devrez les exécuter jusqu’à ce que le site web tombe en panne. Cela peut devenir un cycle sans fin. Beaucoup de nos clients ne parviennent tout simplement pas à faire en sorte que leurs outils de tests de charge génèrent le volume de trafic auquel ils s'attendent en conditions réelles, ou trouvent que cela coûte une fortune.
Enfin : la nature des tests de charge que nous décrivons relève d’un projet de grande envergure. Je connais de nombreuses entreprises qui effectuent un test de charge à grande échelle une fois par an. Mais elles déploient du nouveau code en production plusieurs fois par semaine. Il est tout à fait possible qu’une seule ligne de code mal placée réduise à néant tous ces efforts de test de charge et modifie complètement les chiffres sur lesquels vous vous basez. Vous déployez désormais du code en production via l'intégration continue. Si seulement il existait un moyen d'effectuer un test de charge en continu…
L'essai de charge continue
Je vous invite à considérer CrowdHandler comme une alternative bien plus productive et abordable aux tests de charge traditionnels. Pourquoi ? Parce que CrowdHandler fournit des informations de performance continues et concrètes, basées sur le site web qu’il protège, et vous permet de travailler de manière plus efficace et itérative.
Pendant une période de vente, votre tableau de bord affiche le temps de chargement de chaque page et résume les performances globales du site. En temps réel, la fonctionnalité d’optimisation automatique de CrowdHandler analyse la vitesse de chargement des pages, suit le nombre d’utilisateurs et détermine le nombre optimal de nouveaux utilisateurs que votre site est capable de gérer.
En d'autres termes, il effectue un test de charge en continu sur votre environnement de production, en utilisant de vrais utilisateurs, et en ajustant les résultats en temps réel.
Mais, contrairement à un test de charge classique, il dispose d'un mécanisme de sécurité intégré : la salle d'attente elle-même. Si les chiffres s'avèrent très éloignés de la réalité, le pire qui puisse arriver n'est pas que le site web soit indisponible, mais que la file d'attente soit plus longue.
Et puis, même si les utilisateurs font la queue un peu plus longtemps que vous ne le souhaiteriez, vous pouvez observer et tirer des enseignements du comportement réel du système. Vous pouvez identifier les pages particulièrement lentes, ce qui vous permet de repérer les goulots d’étranglement de votre application, tandis que la fonction d’ajustement automatique gère la file d’attente et garantit une expérience utilisateur positive. En analysant les données issues d’une mise en vente réelle, vous pouvez déterminer les parties du site sur lesquelles vous devrez vous concentrer pour les optimiser la prochaine fois.
En l’absence d’une « salle d’attente », si votre application subissait un goulot d’étranglement inconnu, il serait très peu probable que vous puissiez le diagnostiquer, voire l’observer, car votre site web serait hors service et vous vous empresseriez de mettre en place des mesures d’urgence pour y remédier. Même si vous parveniez à récupérer des données de diagnostic par la suite, une situation d’urgence liée à une charge en spirale, aggravée par un trafic incontrôlé, ne vous permettrait probablement pas de cerner clairement la cause première.
C'est pourquoi je présente CrowdHandler comme un élément essentiel de votre boîte à outils, et non comme un simple pansement. En optant pour notre « salle d'attente », vous ne baissez pas les bras et ne vous contentez pas d'une solution de fortune : vous intégrez un outil de diagnostic supplémentaire qui peut vous aider à garder la tête froide et à améliorer continuellement vos performances, tout en limitant les critiques sur les réseaux sociaux.
Alors, si vous envisagez d’utiliser CrowdHandler, s’il vous plaît, ne venez pas nous voir la queue entre les jambes. Gardez la tête haute ! Vous êtes développeur web. Vous travaillez sur des projets extrêmement populaires et vous vous engagez à les améliorer encore davantage. Vous faites tout comme il faut.