Comment gérer les pics de charge ?

Ou comment éviter de voir tout son système tomber du jour au lendemain ? Les causes sont nombreuses, les conséquences potentiellement dramatiques. C’est ce sur quoi a porté le meetup Tech.Rocks dédié à la charge. Replay.

Les speakers, who’s who :

· Farzad Farid est Head of platform de Kapten. L’un des objectifs qu’il partage avec son équipe : avoir une plateforme stable, scalable et qui tienne la charge.

· James Kretchmar, CTO de Akamai, où les moyens - 300 000 serveurs, 1500 réseaux et 4100 implantations - sont mis pour que le CDN apporte la meilleure expérience à ses utilisateurs et faire face aux pics en toutes circonstances.

· Sacha Morard, CTO de Le Monde, a entrepris récemment avec son équipe la transformation du site d’actualité en plateforme dynamique et sa migration sur GCP. Il revient sur le pourquoi du comment.

Ce meetup a été animé par Maëliza Seymour, CEO de Codist

À quels genres de pics de charge êtes-vous confrontés ?

Farzad Farid : "Celui qui m’a le plus marqué s’est produit à mon arrivée, début 2017. Son origine, un de nos concurrents diffuse un emailing à ses clients. Il y explique combien ils comptent et reconnaît ne jamais rien leur offrir. Notre équipe marketing a l’idée de génie de rebondir. Elle fait aussi partir un emailing, sachant que nous avons des utilisateurs en commun. L’idée est de les inviter à nous envoyer une copie du document initial, en l’échange de quoi leur statut passerait Gold immédiatement. Ça a été un succès marketing et un drame technique. Les gens se sont précipités, ont cliqué sur le mail. La plateforme s’est écroulée. Les principaux tech leaders, les principaux responsables des équipes de développement et moi en charge de l’infrastructure, nous nous sommes réunis en war room pour analyser la situation, identifier le problème et corriger."

Illustrations par Tommy Dessine

James Kretchmar : "La gestion des pics de charge fait partie de nos activités courantes. En tant que CDN, réseau de diffusion de contenu, nous nous occupons de vidéo de grands rendez-vous internationaux, comme la Coupe du Monde, les Jeux Olympiques. Des événements où des personnes lancent en masse le même programme en même temps, partout dans le monde. L’expérience de visionnage doit être de bonne qualité. D’autres de nos pics de charge viennent des téléchargements de jeux vidéo. Outre ces pics du quotidien, nous en avons vu apparaître une autre forme avec le confinement. A titre indicatif, en temps normal et à l’échelle mondiale, la croissance sur notre plateforme est d’environ 3 % par mois. Cette année, entre février et mars, elle a été de 30 %. Nous avons mesuré un pic de 167 Tbps en mars 2020, plus du double qu’en mars 2019 (82 Tbps)."


Sacha Morard : "Dans le domaine de l’actualité, les pics sont parfois très violents. Un site comme le Monde a un gros trafic, environ 600 millions de pages vues par mois, 9000 requêtes par secondes. Lors de la soirée des élections européennes de 2019, de 20h à 20h05, nous avons accueilli l’équivalent d’un Parc des Princes, en seulement 5 minutes. C’est pire lors d’événements tragiques. On a connu de gros pics pendant l’incendie de Notre-Dame de Paris et évidemment lors des attentats de 2015. Énormément de français et d’étrangers ont le réflexe de venir s’informer sur notre site. Notre devoir est, justement, d’éviter de tomber et de remplir la mission d’informer."

Illustrations par Tommy Dessine

Que préconisez-vous pour faire face aux pics de charge ?

Farzad Farid : "Pour revenir à l’incident évoqué plus haut, nous avons identifié d’où venait le problème. Notre microservice d’authentification était devenu très lent. Il n’avait jamais subi une telle charge. Seulement, il avait la double fonction d’identifier les utilisateurs et d’authentifier des services entre eux. Dès lors, impossible pour les applications d’y parvenir. Nous avons commencé par scaler horizontalement. Ça n’a pas suffi . L’application était toujours très lente. Les tech leaders ont alors eu l’idée d’une mitigation, un système qui permettait de rejeter une connexion sur dix. Ça a été fait en 30 minutes : 10 pour trouver la librairie, 15 pour coder et 10 autres pour intégrer. Nous avons pu commencer à souffler un peu et récupérer la plateforme.

Puis, pour alléger le service davantage et pour assurer sa continuité, nous avons intégré dans le code des débrayages de services. Certains d’entre eux sont plus importants que d’autres. Nous en priorisons donc, manuellement ou automatiquement. L’essentiel est que le client puisse faire la course et que le chauffeur le dépose à destination."

James Kretchmar : "« Le hasard ne favorise que les esprits préparés », cette citation de Louis Pasteur est une de mes devises. En l’occurrence, ce qui a le plus d’impact dans la gestion des pics de charge tient à ce que l’on anticipe. Cela commence au niveau de la conception du système ou de la plateforme. Il faut tout d’abord qu’ils soient automatisés au maximum. Nous avons plusieurs couches d’automatisation. Chez nous par exemple, un serveur va lui-même déterminer s’il est fonctionnel. Dans le cas inverse, un autre prend le relai et assure le service.

En outre, notre système prévoit une boucle de rétroactions qui fournit des informations détaillées, en temps réel. Elle nous est très utile. Si un de nos centres de données vient à ne plus avoir la capacité de fournir des contenus, on envoie les utilisateurs concernés vers un autre centre de données implanté dans une ville, voire un pays voisin.

Durant tout le processus d’anticipation, il s’agit d’envisager les opportunités de dégradations gracieuses dans l’ensemble du système. Pour ce faire, il faut partir de l’idée que chaque partie du système est capable de tomber en panne et prévoir les solutions pour chacune.

Une dimension à préparer aussi est la visibilité. S’il faut chercher les données pendant un incident, les choses vont se détériorer davantage. Enfin, on peut anticiper les fortes variations de charges soudaines. L’intérêt est, d’une part, de voir si le système peut fonctionner quand il y a un pic. Ça montre par ailleurs des points de faiblesse. Enfin, dans ce contexte, il est important d’établir un processus de mesure des incidents et s’assurer que tout le monde le connaisse. Ce n’est pas en plein incident qu’il faut s’en préoccuper."

Illustrations par Tommy Dessine

Sacha Morard : "En ce qui nous concerne, le plus délicat n’est pas de construire une architecture orientée média mais d’absorber les pics de charge. En novembre 2018, nous avons décidé de migrer l’infrastructure du site web Le Monde vers Google Cloud Platform et d’avoir un site dynamique. Le framework que nous avons choisi, Phalcon, est capable de générer des pages très rapidement. Nous faisons tourner ça dans des conteneurs, actuellement sur les VM sachant que nous migrons vers Kubernetes. Nous travaillons beaucoup avec la capacité de scaling de notre cloud provider. Nous pouvons ainsi allumer les VM au fur et à mesure de nos besoins. Nous avons aussi installé un cluster Postgres que nous avons rendu scalable. Notre système n’intègre pas d’API, l’inverse aurait, selon nos études, ralenti la génération des pages. Pour stocker et exploiter la donnée nous utilisons PG. Entre notre stack front et notre CMS, l’isolation est parfaite. Nous faisons des échanges en asynchrone via une technologie de queuing. Enfin, nous avons toujours un CDN en face, il nous sert à cacher les assets et non l’html.

Ce type d’infrastructure nous permet d’offrir une bonne UX et d’être plus robuste lors des pics de charge. D’ailleurs, depuis sa mise en place, nous en avons essuyé plusieurs. Le 15 mars, lors des élections municipales nous devions livrer les résultats des communes à 20 heures. L’infra a scalé sans subir aucune erreur ni ralentissement. On a allumé 300 VM, 30000 requêtes http par seconde. 250 000 personnes étaient sur le site à 21 heures."

Ces solutions sont-elles accompagnées par d’autres mesures ?

Farzad Farid : "On parvient aussi à alléger la charge avec des fallbacks. C’est utile dans la mesure où l’API gateway que nous fournissons consomme elle-même d’autres API. On utilise notamment celle de Google Maps. Or, si cette dernière tousse, on tombe malade. C’est pourquoi il nous est important d’avoir un deuxième fournisseur. Si le premier ne répond pas, on est capable de basculer sur l’autre."

Illustrations par Tommy Dessine

James Kretchmar : "Comme je le disais, pendant le confinement, nous avons été confrontés à d’autres genres de pics de charge. Il nous a fallu ainsi optimiser l’expérience utilisateur. Nous avons ajouté des interconnexions pour gagner en capacité de réseau. Nous avons aussi travaillé avec certains clients afin de décaler leurs lancements. Les distributeurs de jeux vidéo par exemple pouvaient choisir de sortir leurs titres plutôt le soir à des moments où il y a moins de trafic. On a aussi un programme interne avec 9 stream différents où nous réfléchissons à des solutions créatives pour optimiser la capacité du réseau. Un des groupes a récemment imaginé de modifier une procédure appliquée aux serveurs hors service."

Sacha Morard : "On pousse le principe 0 erreur jusqu’au bout. Avec un site dynamique, la moindre faille peut être catastrophique. On n’a pas le CDN en face qui cache l’html et qui permet de protéger l’infrastructure origine. En conséquence, on traque toutes les imperfections, les minimes comme les plus graves et on les envoie toutes dans notre channel slack. Cette chasse ne suffit pas. On a créé un service minimum. Notre CDN est notamment paramétré pour détecter une page en erreur et à la remplacer le cas échéant par une version froide, non personnalisée. Ce qui permet de délivrer les pages en plein incident."

Illustrations par Tommy Dessine

Quid des tests ?

Farzad Farid : "Nous avons des automates pour en faire et surtout toutes nos équipes développement ont leur propre cluster Kubernetes sur lequel elles procèdent aux tests. Ceci étant, ça ne suffit pas. On finit par en faire aussi en production. Ce n’est pas orthodoxe mais ça nous permet de comprendre toutes les situations. C’est délicat, il s’agit d’être réactif, d’avoir des équipes capables d’intervenir si l’on sent qu’il va y avoir un incident, pour corriger une requête, un index dans une base de données, réécrire une requête, débrayer un service ou même l’arrêter.

Pour les tests de montée de charge, on procède en continue sur la plateforme de pré production. Nous utilisons un outils que nous avons développé, Terminator. Il tourne en 24/7 et simule des centaines de clients et des centaines de chauffeurs sur la plateforme. Il teste les versions avant de passer en production. Si ça commence à tousser, le code ne passe pas l’étape suivante."

Merci à Maëliza, Farzad, James et Sacha pour ces retours d’expérience. Merci à Akamai pour nous avoir aidé à organiser ce meetup.

Retrouvez le replay de ce meetup :

Tous Les Articles
×

Vous y êtes presque...

Nous venons de vous envoyer un e-mail. Veuillez cliquer sur le lien contenu dans l'e-mail pour confirmer votre abonnement !

OK