Guide : comment lutter contre les pics de trafic prévisibles ?

Si cette scène vous amuse, sachez que c’est exactement la même histoire quand un site ou une application devient indisponible suite à un pic de trafic prévisible, c’est-à-dire un pic dont l’entreprise a connaissance avant qu’il ne se produise (promotion, soldes, expositions médiatiques…). Si vous cherchez des réponses techniques pour contourner ou absorber ces pics, la marche à suivre est simple : testez, anticipez, analysez, corrigez et recommencez. En suivant cette logique, nous avons condensé quelques conseils pour vous aider à vous préparer au mieux le jour J. 

Testez votre plateforme 

Avant même d’envisager des corrections ou des améliorations, mieux vaut savoir avec quelle base vous travaillez. Dans un précédent article nous écrivions que la vitesse et la réactivité d’un site dépendent de son plus mauvais composant, à savoir : 

• Le code
• L’architecture
• L’infrastructure

Encore faut-il savoir lequel incriminer.

Identifier le facteur limitant

Si deux de ces composants sont irréprochables mais que le troisième est un peu plus bancal, vous pouvez être sûr qu’il flanchera dès que le trafic augmentera. Et pour identifier le coupable, quoi de mieux que de confronter le facteur limitant à ses propres limites ? C’est dans ce contexte que le test de montée en charge se révèle particulièrement précieux. Et là, plusieurs options s’offrent à vous pour le réaliser :

Dupliquez intégralement votre plateforme en mode “lab” pour faire tous les tests que vous voulez dessus et identifier ce qui ne va pas (C’est vrai que la méthode est un peu extrême, mais si vous pouvez le faire, c’est ce que nous recommandons.)

Répliquez votre infrastructure avec une fraction des ressources (10% par exemple) pour votre test, calculez les limites et extrapolez les valeurs pour l’intégralité

Réalisez la montée en charge sur votre plateforme, de préférence quand personne ne l’utilise (vers 2H matin si vous êtes encore debout)

Ces tests sont une réelle épreuve du feu pour vos plateformes et vous permettent d’identifier assez rapidement le coupable. Mais la montée en charge a également un autre avantage… 

Établir le seuil de scalabilité

En effet, vous pouvez également déterminer votre seuil de scalabilité pour comprendre comment votre plateforme réagit aux pics de trafic et ainsi chercher à l’optimiser. Ce que nous appelons seuil de scalabilité, c’est la corrélation entre l’augmentation du trafic et la puissance supplémentaire nécessaire pour l’absorber. Schématiquement, si vous devez doubler votre infrastructure pour tenir 10 % de trafic supplémentaires, quelque chose cloche. Si vous cherchez à améliorer ce seuil, nous allons donner quelques pistes à explorer dans la partie « Anticipez comme jamais ». 

Pour l’anecdote, quand nous cherchons le facteur limitant d’une plateforme que nous ne connaissons pas, nous commençons systématiquement par regarder l’architecture. D’expérience, si une architecture est bancale, il en sera de même pour le code et l’infrastructure. À l’inverse, nous n’avons jamais vu une architecture stable, propre et bien conçue accompagnée d’un code et d’une infrastructure qui laissent à désirer. Si vous entreprenez cette démarche sur une plateforme que vous ne connaissez pas, commencez par regarder l’architecture pour vous faire une idée et un diagnostic rapide.

Anticipez comme jamais

En matière de lutte contre les pics de trafic, l’anticipation est le nerf de la guerre. Même si vous ne pourrez jamais anticiper toutes les éventualités car le risque zéro n’existe pas (et ceux qui vous le promettent vous mentent), vous pouvez néanmoins prendre quelques initiatives qui permettront à votre site ou application de tenir un peu mieux la montée en charge. Accessoirement, vous améliorerez votre seuil de scalabilité au passage. Autant de raisons de ne pas lésiner sur cette étape.

Testez (encore)

Oui, encore et au cas où ce ne serait pas assez explicite : testez votre plateforme régulièrement. Au lieu d’attendre la catastrophe pour tirer des conclusions, ces tests de charge réguliers permettent d’anticiper les besoins de votre plateforme en terme de puissance à court et moyen terme en appliquant différents scénarios (“scenarii” pour les tatillons) pour identifier :

• Le volume de trafic maximal absorbable
• Le différentiel entre ce volume et les projections réalisées sur les futurs pics de trafic
• Les facteurs limitants : sont-ils les mêmes selon les volumes des charges ?
• Les modifications à effectuer rapidement pour encaisser les prochains pics
• Les transformations plus profondes à opérer pour s’adapter au volume croissant des pics de trafic (si vous projetez que ces derniers augmenteront)

Si vous prenez le temps d’identifier tous ces points : félicitations, vous avez une roadmap pour l’évolution de votre plateforme ! 

Prévoyez un peu de marge

Ce n’est pas parce que vous commencez à avoir une bonne vision sur la tenue en charge de votre plateforme et sur vos pics de trafic que vous pouvez jouer avec le feu pour autant. Prévoyez systématiquement de la marge en ajoutant un peu de puissance pour éviter que votre plateforme ne soit constamment « au taquet » de ses performances. Ce n’est pas une obligation, mais vous vous épargnerez un risque supplémentaire et quelques sueurs froides. En toute transparence, c’est ce que nous faisons quand nous savons qu’il y aura un pic de trafic, mais que nous ne sommes pas en mesure de le quantifier précisément.

Scalez ce que vous pouvez

Dans un monde idéal, vous devez constituer votre plateforme en vous assurant que tous ses composants puissent être scalables. Si ce n’est pas le cas l’un (ou plusieurs) d’entre eux, vous pouvez être certains qu’il s’agira de votre point de défaillance unique (aussi appelé SPOF : Single Point Of Failure).

Bref, vous l’aurez compris, la disponibilité de votre plateforme est dépendante de sa brique la plus faible.

Instinctivement, le composant qui paraît le plus facilement scalable c’est l’infrastructure. L’ajout de serveur ou de puissance de calcul pour absorber une charge supplémentaire, c’est le b.a.-ba de la lutte contre les pics de trafic. C’est d’ailleurs l’unique action réalisée par les outils estampillé “auto-scaling” vantés par les prestataires cloud. Il s’agit d’un argument marketing sympathique qui peut occasionnellement vous sauver la mise mais qui se révèle très insuffisant sur le long terme. 

Pour assurer la résistance de votre plateforme face à ces importantes montées en charge vous devez aussi scaler les autres composants et notamment le code de votre site, application ou de votre plateforme. Rien de bien compliqué en théorie, puisqu’il suffit de dupliquer votre code pour qu’il s’exécute en simultanée sur N serveurs différents (autant que nécessaire en fait) dans un principe de répartition de charge (load balancing). Mais l’opération peut rapidement se compliquer. Si le fonctionnement de votre site ou application repose uniquement sur des protocoles sans état (stateless), c’est-à-dire qu’ils n’ont pas besoin de stocker de données pour effectuer une requête, la manœuvre peut s’avérer assez simple. En revanche, si votre site ou application a besoin d’enregistrer des informations de contexte et d’historique pour fonctionner (URL, activité récente, préférences…) et empile des protocoles sans états et des protocoles avec états (stateful), l’exercice commence à devenir périlleux.   

Mais ce n’est pas tout. Imaginons que vous ayez réussi à scaler votre code, aussi complexe soit-il, avec succès. Une autre problématique se pose : celle de la base de données. Dupliquer une base de données ou passer sur une base de données distribuée ne se fait pas en claquant des doigts. C’est faisable, mais c’est complexe. Si vous n’avez pas les savoirs et compétences nécessaires pour le faire, vous savez au moins quel est votre point de défaillance unique et vous saurez vers quoi vous tourner en cas d’indisponibilité. C’est en partie une des raisons pour lesquelles les bases de données sont souvent les SPOF des plateformes quand il s’agit de pics de trafic. 

Au risque de nous répéter, la lutte contre les pics de trafic n’est pas qu’une question de puissance de calcul et de machines. Cela suppose une réflexion globale qui implique des compétences en administration systèmes et réseaux ainsi qu’en développement. Ce n’est pas la chasse gardée d’un seul métier ou d’une seule compétence ce qui en fait l’un des sujets DevOps par excellence. 

Et en parlant de DevOps et de bases de données…

Optimisez les réglages par défaut (au moins pour MySQL)

Optimiser les configurations n’a rien de sorcier en soi, il faut simplement y penser. Sans incriminer la « qualité du code » à proprement parler, il est toujours possible d’optimiser le déploiement et la configuration du serveur sur lequel il sera hébergé pour qu’il s’exécute mieux. Mais généralement, il s’agit d’un réflexe assez largement partagé chez les développeurs, donc nous ne nous étalerons pas plus longuement dessus.

Là où le bât blesse, c’est lorsqu’il s’agit d’optimiser les configurations par défaut des bases de données ou des serveurs de bases de données. Une étape souvent négligée, faute de tests suffisamment poussés. En l’absence de compétences admin sys, les tests du site ou de l’application se feront sur un laptop quelconque. Ça tournera certainement très bien (à un moment) mais c’est complètement optimisable surtout au niveau du serveur de base de données. Et ce ne sont pourtant pas les documentations officielles qui manquent. Si certaines optimisations permettent de gagner 10 % en matière de performances, d’autres vont jusqu’à les multiplier par 4 ! 

La première consiste à harmoniser les moteurs de stockage utilisés pour les tables de vos bases de données. En l’occurrence, vérifiez que vous n’avez pas de MyISAM qui traîne par erreur. Si InnoDB est aujourd’hui le moteur utilisé par défaut sur MySQL, il se peut que certaines tables utilisent encore du MyISAM par des malheureux effets de copier-coller de code un peu daté, ou parce que le code n’a pas été touché depuis longtemps. Or, InnoDB prend en charge les transactions et le volume, ce qui est particulièrement adapté en cas de requêtes nombreuses. Si votre table ne peut fonctionner qu’avec MyISAM n’y touchez pas, mais dans le cas contraire, nous vous préconisons de passer toutes vos tables sous InnoDB. 

Autre optimisation possible sur MySQL : les index. Comme l’explique cet article dans la rubrique “C. Optimiser les Requêtes - Optimiser les index” : 

“Le but d’un index est d’accélérer la recherche de l’information […]. Mais l’optimisation des requêtes ne passe pas par l’ajout massif d’index. Les index se doivent d’être pertinents car ils peuvent ralentir les requêtes d’écritures.” 

Comme il s’agit d’un élément assez transparent pour les développeurs, ils peuvent avoir tendance à mettre trop ou pas assez. Ce qui, dans les deux cas, impactera négativement les temps de réponse. Toujours d’après le même article : 

“Lorsqu’un index est créé, c’est toute la longueur de la chaîne de caractères qui est indexée. Mais ce n’est pas toujours utile, si les x premiers caractères sont suffisamment discriminants, il est intéressant de n’indexer qu’eux. Au final j’ai un index plus petit, avec comme incidence majeure, une diminution des accès disque et donc des temps de réponse plus rapides.” 

Une optimisation assez simple et efficace, qui a l’avantage d’être rapide à effectuer sans pour autant remettre tout en question.

Intégrez des mécanismes de mise en cache

Cela peut paraître évident pour les plus chevronnés d’entre vous mais vous seriez étonnés de voir le nombre de sites qui font l’impasse dessus. Les outils de mise en cache peuvent pourtant faire quelques miracles pour accélérer les temps de réponse et éviter les indisponibilités d’un site web ou d’une application. 

Nous avons récemment eu le cas avec le site d’un client qui tombait régulièrement (avant de passer chez nous cela va sans dire). Sa page d’accueil mettait 500 millisecondes à charger. Ce n’est pas extraordinaire mais c’est complètement transparent pour les utilisateurs… quand ils ne sont pas trop nombreux. Dès qu’un pic de trafic se présentait, la page mettait plusieurs secondes à charger. Nous avons donc utilisé l’outil de cache Varnish pour diminuer le temps de chargement et conserver cette diminution même en cas de montée en charge. 

En revanche, vous n’êtes pas obligés d’utiliser la mise en cache pour une page complète si celle-ci ne s’y prête pas. Il existe des mécanismes de cache partiels. Par exemple, n’hésitez pas à mettre le calcul de votre « TOP 3 » des produits les plus vendus dans un cache éphémère type Memcache ou Redis plutôt que de le recalculer à chaque visiteur.

Analysez pendant et après le pic de trafic

Le travail ne s’arrête évidemment pas à l’anticipation. Une autre clé essentielle pour lutter contre les pics de trafic prévisibles réside dans la métrologie. En d’autres termes, avoir de la visibilité sur votre plateforme et obtenir des données chiffrées sur son comportement pendant et après le pic de trafic. Objectif : savoir ce qui se passe pour savoir quoi faire.

Même si les tests vous permettent d’anticiper la manière dont votre plateforme réagira, c’est en conditions réelles que vous pourrez valider ou invalider les résultats obtenus. Notamment en ce qui concerne l’identification du ou des facteurs limitants de votre plateforme. Prenons un exemple évident : si le CPU de votre base de données est à 100% alors que le reste de votre plateforme ne tourne pas à plein régime, cela vous donne un bel indice sur la nature de facteur limitant. Mais pour ça, vous devez mesurer ce qui se passe pendant le pic de trafic. 

Chez Oxeva, en plus de tous les outils que nous avons développés en interne, nous utilisons aussi New Relic et Datadog pour analyser le code des sites et applications pendant le pic. Vous pouvez récupérer de la métrologie directement dans l’application, le tout trié dans un tableau assez lisible. Ces outils permettent de tirer rapidement des premières conclusions côté développement. À noter : la réaction à chaud est un exercice périlleux qui peut empirer la situation si jamais votre plateforme flanche. Le stress et la précipitation ne sont pas vos alliés dans ce genre de situation. Donc faites votre possible pour rétablir le service et apportez des modifications après la bataille. 

D’un point de vue purement informatique, l’analyse ne différera pas selon le pic de trafic. En revanche, avoir des données chiffrées précises pourra se révéler précieux pour en faire une interprétation marketing. Notamment pour mesurer et interpréter l’impact ou l’efficacité d’une campagne télévisuelle par exemple : Quel format génère le plus de trafic entre le reportage, la publicité ou le pre-roll ? Quelles pages sont impactées selon les formats : juste la page d’accueil ou tout le site ? Donc si vous ne faites pas ces mesures pour vous, faites-le pour le marketing (ils ont un cœur eux aussi). 

Corrigez et… recommencez

Tout a globalement déjà été dit et vous apporter une liste exhaustive de tout ce qui est corrigeable suite à un pic de trafic serait aussi contre-productif pour vous que pour nous (en plus d’être particulièrement chronophage à rédiger et à lire). À minima, assurez-vous de corriger ou d’optimiser le facteur limitant si vous ne l’aviez pas déjà fait pendant les phases de tests. 

Néanmoins, nous ne pouvons que vous conseiller de maintenir votre vigilance. Le code d’un site ou d’une application n’est pas une vérité figée et est mouvant (surtout les bases de données). Ce qui n’est pas un élément bloquant aujourd’hui peut le devenir un peu plus tard. L’exemple le plus récurrent est celui du versioning de WordPress, même en ne touchant rien, une mise à jour peut changer le comportement de votre site face aux pics de trafic. Vous devez donc apporter des correctifs réguliers pour vous assurer que cela n’arrivera pas.

Il ne vous reste plus qu’à répéter les différentes étapes dès que vous prévoyez une montée en charge. Bien évidemment, si vous ne vous sentez pas de faire tout ça vous-même par manque de temps, de moyens ou de connaissances, vous pouvez toujours faire appel à une aide extérieure. 

L’exposition qui fait le larron 

Une autre manière de lutter contre les pics de trafic prévisible, c’est de les voir non pas comme une menace, mais comme une opportunité en vous en amusant et en l’exploitant à votre avantage. C’est particulièrement vrai dans le cadre de ce qu’on appelle l’Effet Capital. Nous nous amusons à voir si les sites des entreprises qui font l’objet d’un reportage tiennent bien la charge. L’une d’elle (nous ne nous rappelons plus de son nom, ce n’était pas un de nos clients) n’avait rien fait pour empêcher l’indisponibilité de son site. 

En revanche, sa page « erreur 503 » était un formulaire qui incitait les visiteurs à laisser leurs coordonnées pour avoir de leurs nouvelles quand tout reviendrait à la normale. À défaut d’avoir effectué des ventes, cette astuce lui a permis de récolter quelques contacts. Le principal enseignement de cette démarche, c’est de prévoir le scénario d’une panne et de mettre en place une réponse appropriée. En l’occurrence, une page 503 qui ressemble à autre chose qu’à une page d’erreur anxiogène et peu esthétique. Une anticipation d’autant plus incontournable que la probabilité d’une panne augmente avec le temps et se rapproche inexorablement du facteur 1.

C’est un peu la même démarche qu’a eue la société Germinal récemment, en créant une Landing Page dédiée le soir de la diffusion du reportage accompagnée d’une annonce sponsorisée Google. L’annonce disait « On sait que vous êtes sur M6, le site de Germinal c’est ici ». Le témoignage du patron de Germinal est à lire ici si vous voulez connaître les résultats de cette initiative (ils sont très bons comme vous vous en doutez). 

Comme nous le disions plus haut, la lutte contre les pics de trafic n’est pas la chasse gardée des responsables infrastructures, c’est aussi la responsabilité des développeurs. Mais en poussant la réflexion, ce n’est pas non plus uniquement une réflexion qui doit se cantonner aux services informatiques. Comme le prouvent les exemples juste au-dessus, le marketing et la communication peuvent aussi avoir leur rôle à jouer. 

Nous ne nous risquerons pas à évoquer un mouvement MarketOps, par crainte d’une volée de bois vert, mais c’est quand même tentant.