La gestion des pics de charge

0:14 Bonjour à tous, je suis Maëlys Assemour et je vais animer le Meetup Tech.Rocks du jour qui va traiter de la gestion des pics de charge en temps de crise ou par période inattendue. Je me présente rapidement, je suis la CEO et cofondatrice de Codist. Donc, Codist est une startup deep tech qui automatise le développement informatique. Et on commence aujourd'hui par automatiser la documentation du code. Donc, ce qu'on fait, c'est qu'on a aujourd'hui des algorithmes capables de comprendre le code, de le traduire en un langage naturel pour documenter automatiquement les codes écrits, qu'ils soient en legacy ou en nouveau code. Donc voilà. Mais j'interviens aujourd'hui parce que dans une vie précédente, j'étais responsable continuité chez BNP Paribas. Et donc BNP qui a des data centers un peu partout dans le monde, dans tous les continents, dans tous les pays. Et mon rôle était de m'assurer que les bascules data centers se faisaient correctement pour assurer la continuité technique du matériel, mais également fonctionnelle du service rendu à l'utilisateur. Tout ça pour la continuité de service, mais aussi pour des raisons de régulation. Et comme vous en doutez, il y a toujours des problèmes auxquels on s'attend.

1:16 On a beau s'exercer, se préparer, on fait toujours face à des imprévus. Et c'est de ça dont on va parler aujourd'hui avec nos trois intervenants qui sont Farzad Farid, responsable de la plateforme de production chez Kapten. James Kretchmar, qui est CTO et VP chez Akamai, et Sacha Moura, qui est CTO chez le groupe Le Monde, qui rassemble plusieurs titres. Donc, en termes de déroulé et de logistique, chaque intervenant va intervenir à son tour durant 20 minutes, où on va discuter des problématiques rencontrées, des bonnes pratiques, du retour d'expérience, avec 5 minutes environ dédiées aux questions-réponses posées par vous. Et à la fin, on aura 20 minutes où tous les speakers viendront sur scène me rejoindre. Et là, on aura une grande table ronde où vous pourrez poser des questions transverses. Voilà, j'ai fait le tour des points logistiques. Donc là, on va accueillir tout de suite Farzad Farid, responsable de la plateforme de production de Kapten.

2:24 Bonjour, bonjour à tous. Bonjour Farid. Alors, ce que je te propose pour commencer, c'est de te présenter déjà, comment c'est ton rôle chez Kapten, et après nous parler, pourquoi pas, de quelques pics de charge que vous avez connus et de comment vous avez réagi. Ok, donc je suis Farzad, je suis responsable de la plateforme de Kapten, qui est un opérateur de VTC européen. Ça fait bientôt 4 ans que je travaille, que j'ai monté l'équipe de production de Kapten. Et mon but, c'est d'avoir une plateforme stable, scalable, parce qu'on a une boîte qui grossit énormément, qui tienne la charge. Voilà, donc ça c'est mon travail. Je gère l'équipe SRE, l'équipe des BA, ainsi que l'équipe des développeurs back-end qui s'occupe de nous fournir tout le tooling pour gérer la plateforme de Kapten. Très clair. Alors, du coup, quelques exemples de pics de charge. Alors, quelques exemples. Celui qui m'a le plus marqué, qui est arrivé début 2017, peu après que j'ai pris mes fonctions, que j'ai appelé l'incident du mailing Uber.

3:29 Début 2017, Uber avait fait un... Notre principal concurrent américain avait fait un mailing à tous ses clients en leur disant qu'il les aimait beaucoup et tout, mais qu'il ne leur offrait rien. Notre équipe marketing a eu l'idée de génie de rebondir sur le mailing Uber parce qu'on sait que nos clients sont aussi des clients Uber, en disant qu'Uber a dit qu'il vous aimait, mais ne vous a rien donné. envoyez-nous une copie du mail que vous avez reçu et on vous passe ce statut gold immédiatement. Et là, ça a été un succès, marketing et un drame, parce que les gens se sont précipités pour cliquer sur le mail. Ça a été un succès phénoménal. Il devait être 18 heures et la plateforme s'est écroulée. En fait, tous les gens essayaient de se connecter, connecter, reconnecter. Les clients qui essayaient de faire les courses arrivaient en même temps. Et la plateforme s'est complètement écroulée. Donc ça, c'était le premier drame, le premier exemple de crise et de gestion de pics de charge. Après, il y a...

4:31 Oui, vas-y. Non, non, mais du coup, première question que je voudrais te poser par rapport à ce drame qui a célébré ton arrivée, c'est quelle était la réponse, justement? Quelle était la manière de gérer la crise et d'assurer pour vos clients une continuité de service derrière? Alors, tout de suite, on s'est réunis en War Room. Et ce qui est important, c'est que dans la War Room, on a réuni non seulement moi en charge de l'infrastructure, le CTO, mais les principaux tech leaders, donc les principaux responsables. Des équipes de développement pour analyser et corriger tout de suite. Donc, on s'est mis ensemble et on a travaillé à trouver quel était le problème. Donc là, pour moi, ça montre l'importance de travailler main dans la main entre les équipes de production et les équipes de développement. De vraiment travailler de concert. Et on a réussi à trouver que le problème venait de notre micro-service d'authentification qui était très lent, mais qui n'avait jamais subi une telle charge. Et le problème, c'est que ce micro-service servait non seulement à authentifier les utilisateurs, mais à authentifier...

5:34 Services entre eux. Donc les utilisateurs se sont précipités en masse pour se connecter. Le service d'authentification s'est écroulé et les microservices, donc notre plateforme et les applications ne pouvaient plus s'authentifier entre elles et elles ont arrêté de fonctionner. Donc ce qui a été fait là, c'est qu'on a essayé de faire grossir le microservice. On a scalé horizontalement, on a rajouté plus de microservices. Ça ne suffisait pas. L'application était toujours très lente. Et là, ce qu'on a fait, c'est qu'on a fait de la mitigation. Quand on ne peut plus rajouter de machine, on ne peut plus rajouter de VM, très rapidement, les tech leaders ont développé, ont trouvé des librairies, ont développé très rapidement un système de rate limiting qu'ils ont testé, intégré dans notre système d'authentification de façon à rejeter, par exemple, une connexion sur 10 ou un peu plus. C'était paramétrable. Ça a été fait en une demi-heure. 10 minutes pour trouver la librairie, 15 minutes pour coder, 10 minutes pour... pour l'intégrer, mettre en production, et on a commencé à souffler un peu, récupérer un peu la plateforme.

6:37 Donc, voilà. Scaling, un maximum. Quand on ne peut plus, on mitige, on arrête des services, on drop des connexions. Ce n'est pas grave si les personnes ne peuvent pas se connecter. L'important, c'est que les autres personnes qui sont là puissent faire des courses. Ce qui est intéressant dans ce que tu dis, c'est que finalement, la gestion de la charge, des pics de charge inattendus chez vous ou des arrêts de service, la réponse que vous proposez en face, ça va être une mitigation. Vous avez débrayé des services, de la priorité à d'autres services. Donc ça, ça fait partie de votre plan de continuité. Oui, exactement. Parce que nous, notre site, là où on fait du business, ce n'est pas sur notre site web. Notre site web, il a très peu de trafic. Très peu de gens commandent sur le site web. Nous, ce qu'on fournit, c'est une API Gateway pour les applications chauffeurs et les applications des clients. Donc, d'avoir du cache, d'avoir de ce qu'il est, d'utiliser un CDN, nous, ça ne nous sert à rien parce qu'on n'a aucun contenu statique, quasiment pas.

7:39 Ce qu'on a, c'est qu'on récupère des positions chauffeurs, on récupère des positions clients et on les met en relation, on calcule des trajets. Donc, l'important, nous, chez nous, c'est des API. Mais on a des services qui sont plus importants que d'autres. Que le client puisse faire des courses, c'est essentiel. Par contre, qu'on puisse les facturer, c'est quelque chose qui peut être... reporter à plus tard. Donc, on a configuré nos services de façon à pouvoir débrouiller des services qui ne sont pas essentiels. Par exemple, si on ne peut pas vérifier la carte bleue de l'utilisateur, on va mettre ça dans une queue, on va le vérifier plus tard, on va faire un rattrapage. L'essentiel, c'est que le client puisse faire la course. Le chauffeur accepte la course, qu'il arrive à la destination, qu'il dépose le client et qu'il puisse mettre fin à la course. Donc ça, c'est une des façons de faire, c'est débrayer les services non essentiels. Et on a appris à même intégrer ça dans le code. On a travaillé avec les développeurs à intégrer ça dans le code et avoir soit des débrayages automatiques, soit des débrayages manuels que mon équipe peut déclencher de façon à alléger le service.

8:41 De façon à assurer une continuité. Donc voilà, ça c'est une des premières façons qu'on a de gérer la source. Une autre façon. Pardon, vas-y. Non, non, vas-y, la deuxième manière. Alors, une deuxième manière, c'est que c'est important pour nous d'avoir des fallback. Nous, comme j'ai dit, on fournit des API, on a une API gateway et on consomme beaucoup d'API, comme par exemple les API de Google Maps pour, non seulement afficher des cartes, mais trouver les meilleurs trajets pour qu'un chauffeur puisse rejoindre un client. Donc, trouver quel est le chauffeur le plus proche. Qui va dans la même direction. Donc, on fait énormément appel à ces API. Alors, si Google Maps tous, nous, on tombe gravement malade. Donc, ce qui est important, c'est d'avoir un fallback. Donc, on a un deuxième fournisseur. Si le premier répond lentement, on est capable de basculer sur le deuxième. Et si le deuxième n'arrive pas à répondre, au pire des cas, pour le calcul du temps de trajet, on passe en vol d'oiseau.

9:42 Ce n'est pas terrible. Le prix de la course ne sera pas optimal pour le chauffeur. On pourra quand même faire la course. C'est déjà arrivé, ça arrive rarement, mais si le service de calcul de temps de trajet d'ETF, Google, ne répond pas, ou qu'on est avec limité, on passe en vol d'oiseau, Et on peut quand même faire la course. Donc finalement, vous ne mettez pas tous vos oeufs dans le même panier et vous assurez une continuité de service tant d'un point de vue technologique, au niveau de l'architecture, de l'infrastructure mise en place, que d'un point de vue finalement de vos dépendances externes, où vous assurez que vous avez à chaque fois des points de redondance qui, normalement, ne vont pas tous tomber en même temps. Voilà, exactement. Donc, on fait quand même un scaling important. On a des bases de données. Les bases de données, on les scale, on va dire. On fait une prévision sur l'année à venir et nos bases de données sont scellées pour l'année à venir. Elles sont une base de données, on ne la redémarre pas, ça ne se redimensionne pas en quart de route. C'est très compliqué, on ne sait pas faire. Donc, les bases de données sont dimensionnées de façon statique.

10:44 Par contre, le CPU, on a besoin beaucoup de CPU et d'IO. Ça, on est sur du Kubernetes aujourd'hui. Ça, c'est des choses qu'on peut scaler, augmenter, diminuer en fonction de la charge. Donc, ça, c'est la partie non débrillable. Et après, il y a la partie, comme je disais, débrillable et le fait d'avoir plusieurs fournisseurs pour avoir un fallback. Justement, ce choix des Kubernetes et de l'autoscaling pour la partie CPU, c'est un choix qui a été fait dès le début, enfin dès ton arrivée, c'est quelque chose que vous avez mis en place par la suite, suite à des incidents. Comment ce choix a été fait? Alors, c'est un choix qui a été fait par le CTO. Disons que c'était une idée qu'avait eu le CTO avant mon arrivée. Et le but de ma présence était d'aller faire cette direction. On était sur une plateforme qui s'appelle Heroku, qui est du platform as a service, qui ne permettait pas une bonne scalabilité. Et on était déjà en microservice. Donc, aller vers PubAnates, c'était déjà dans l'air du temps.

11:45 Et je trouve que c'était pour nous un bon choix. Et on a fait le choix d'aller vers PubAnates. Parce que d'une part, on avait déjà découpé notre monolithe en microservice et parce que ça nous permettait une scalabilité. Horizontale plus facile. Ok, très clair. Et une question un peu plus macro, du coup, donc là vous avez vos microservices, vos Kubernetes, vos bases de données, la gestion de la charge, comment est-ce que vous faites aujourd'hui pour suivre tout ça et pour dire, maintenant il faut débrayer un service ou alors on peut supporter la charge? Qu'est-ce qui vous permet justement de monitorer tous les services, toutes les métriques et comment vous y prenez? Alors le monitoring est quelque chose de très important, la métrologie, quand je suis arrivé, c'était déjà en place, mais on l'a vraiment intégré partout. Tous les microservices ont des métriques fonctionnelles que nous suivions et avec l'expérience, avec l'aide des équipes développement et des équipes SRE, nous avons identifié ces métriques les plus importantes et c'est celles qui déclenchent des alertes chez nous, des alertes d'astreinte 24-7.

12:52 Donc, on est capable, 24-7, d'avoir une alerte disant attention. Oh. On consomme trop de CPU. On s'en fiche. Ou le disque est plein, ce n'est pas l'important. L'important, c'est est-ce qu'on est capable de prendre des courses? Est-ce que les gens sont capables de prendre des commandes? Donc, beaucoup de métrologie, beaucoup de travail avec les développeurs pour intégrer les métriques business dans les applications, pour les remonter et que ça rentre dans notre système d'Astra. Autre chose aussi, un point important, c'est qu'on suit la règle des Golden Metrics de Google, je vous ai pas mal conseillé là-dessus, c'est d'avoir sur chacun des microservices trois ou quatre indicateurs clés, et ce, toujours les mêmes, sur tous les microservices, à savoir par exemple le nombre de requêtes, le nombre de requêtes en erreur, d'avoir le temps de latence, par exemple, et on utilise ces quelques Golden Metrics quasiment partout pour construire nos indicateurs. Très clair. Et tu mentionnais justement qu'aujourd'hui, les métriques que vous suivez, c'est à la fois des métriques fonctionnelles et des métriques métiers, business, du coup.

13:58 Ça implique une certaine philosophie DevOps, j'imagine. Est-ce que ça rentre en jeu dans votre stratégie de continuité? Oui, clairement. Pour moi, la philosophie DevOps a joué un rôle très important dans la scalabilité, non seulement de nos équipes, la scalabilité de notre plateforme. Le fait que DevOps, pour moi, c'est vraiment une philosophie, une façon de travailler ensemble entre les développeurs, entre les gens des opérations, à parler le même langage, utiliser les mêmes outils. communiquer de façon horizontale, de façon à ce que les développeurs intègrent nos besoins en tant que responsable de l'infrastructure. Nous, nous leur fournissons les outils qui leur permettent de déployer facilement, diagnostiquer, corriger et redéployer très rapidement. Donc pour nous, c'est vraiment clé. Comme je disais, les incidents qu'on peut avoir liés à la charge, ce qu'elle est, ne va pas suffire.

15:00 Alors intervenir, corriger du code. Et donc, je vois une question qu'a posée justement Dominique Zanro sur qu'est-ce qui a limité la montée en charge du service d'authentification sur la partie code. Le service d'authentification avait été écrit il y a longtemps et il faisait beaucoup d'opérations, beaucoup d'opérations legacy sur des façons d'authentifier les utilisateurs. Et les opérations étaient très lentes. C'est ce qui fait que l'authentification, un utilisateur qui s'authentifie une fois, il reste authentifié. Par contre, quand il y a une ligne Uber, ils sont tous arrivés en même temps. Donc, une opération qui est lente pour un utilisateur, il se connecte une fois, après il est connecté pendant plusieurs jours, ça ne se voit pas. Par contre, quand des dizaines, des dizaines, des dizaines arrivent par minute, le service d'authentification, la lenteur se fait ressentir, c'est comme ça que le site s'est écoulé. Et je sais qu'il y a une question qui a disparu, mais qui demandait comment est-ce que vous faites, que ce soit après prod, en test, pour simuler des pics de charge? Déjà, est-ce que vous le faites? Alors, on le fait.

16:00 On a des automates qui nous permettent de faire des tests de charge. Et surtout, toutes nos équipes développement, toutes nos tribes ont leur propre cluster Kubernetes sur lequel ils peuvent faire tous leurs tests. Mais ça ne suffit pas. Donc, une chose que je dirais, c'est peut-être, ce n'est pas très orthodoxe. Nous, nous faisons, on finit par faire des tests en production. Et tout le monde le fait. Enfin, tout le monde ne le dit pas ouvertement. Moi, je le dis ouvertement. On fait des tests en production. Pourquoi? Parce que ça ne suffit pas de... On ne peut pas tester. tester toutes les conditions, on ne peut pas tester toutes les règles métiers, on n'y arrive pas. Donc, il faut pour nous faire des tests en production, mais ça veut dire être réactif, avoir des équipes qui peuvent intervenir dès qu'on sent qu'il y a un incident, intervenir très rapidement pour corriger une requête, pour corriger un index dans une base de données, réécrire une requête. Débrayer un service ou dire ce service, ce microservice, on peut l'arrêter. Ok, il est 18h, c'est bon, on peut l'arrêter, on l'arrête, on le redémarrera à 22h après le pic de charge.

17:02 Justement, quand ouvertement on sait qu'on va faire des tests en production, finalement, quelles sont les bonnes pratiques que vous avez, est-ce que tu pourrais me résumer les bonnes pratiques que vous avez pour faire face à cette situation de crise? C'est déjà, comme je disais, avoir les bons indicateurs, toujours. Avoir des équipes disponibles, des équipes formées, et surtout, roder à intervenir très rapidement sur la plateforme. Et surtout, que les équipes, même les équipes de développement, aient accès au maximum d'outils pour pouvoir intervenir. Aujourd'hui, on est à un point où les développeurs peuvent faire leur mise en production eux-mêmes, en passant toutes les barrières, tous les tests, tous les tests unitaires, les tests fonctionnels. Le fait que les développeurs puissent faire leurs tests eux-mêmes leur permet d'être réactifs lors des incidents qui peuvent être liés à des pics de charge d'atomes. Ok. Alors, juste une précision. Tu as mentionné quelques métriques fonctionnelles. Est-ce que tu pourrais les rappeler dans la liste des métriques que vous suivez aujourd'hui?

18:06 Alors, métriques fonctionnelles, on a par exemple le nombre de personnes qui essaient de se connecter sur la plateforme, le nombre de personnes qui font une cotation pour faire une course, les commandes passées, le taux de prise en charge des commandes passées par les chauffeurs, le nombre de courses qui se terminent, le nombre de paiements. Sur le paiement carte bleue. Donc ça, ce sont les principaux indicateurs. Ou les positions chauffeurs, le nombre de remontées chauffeurs. Les applications chauffeurs renvoient les positions toutes les 10 secondes ou toutes les 20 secondes suivant qu'ils sont en course ou pas. Donc, c'est des dizaines de milliers de positions qui remontent en permanence. Donc ça, c'est les indicateurs qu'on suit. Et s'il y a un indicateur... Qui chute ou qui au contraire, comme les logins, grimpe en flèche. Je sais qu'on a... Il y a un warning qui arrive. Le site Kapten, je dois donner le commentaire, apparemment le site Kapten.com ne répond pas. Alors le site Kapten.com... Ce n'est pas pour me défausser, il n'est pas hébergé sur notre cluster Kubernetes. C'est une question WordPress qui est hébergée sur un prestataire tiers.

19:11 Ça tombe très mal. J'espère que notre prestataire va intervenir pour le réparer. Mais lui, il n'est pas sur le cluster. C'était juste contextualisé pour donner à débattre aujourd'hui. On a également une question sur les tests de montée en charge. Avant la mise en production. Est-ce que vous en faites et quel outil vous utilisez pour en faire? Les tests de montée en charge, on en fait. D'abord, on les faisait ponctuellement. Maintenant, on les fait de façon continue. Sur notre plateforme de pré-production, nous avons un outil développé chez nous qui s'appelle Terminator, qui tourne 24-7 et qui simule des centaines de clients et des centaines de chauffeurs sur la plateforme. Si nous devons faire une mise à jour majeure ou à la veille du nouvel an, qui est un de nos pics de charge les plus importants, on va augmenter le nombre de chauffeurs clients, passer à 1 000 en simultané, 2 000 en simultané, voir ce que la plateforme peut supporter. Parce qu'on a une très grande variabilité, ça peut varier de 1 à 20 dans une même journée le nombre de commandes à la minute.

20:18 Donc on a cet outil qui teste toutes les versions avant qu'elles passent en production. Et si la place en pré-production commence à tousser, on sait qu'il faut que le code ne passe pas en production. Très bien. Je ne sais pas s'il y a d'autres questions dans le public. Alors, il y a une dernière question qui est arrivée. Sur la mise en place des indicateurs, on imagine que pour suivre les indicateurs, il doit y avoir des petits... Je perds mes mots, pardon. Il doit y avoir un suivi au niveau des machines directement. Donc, est-ce que ça impacte les performances? D'ailleurs, quel outil vous utilisez pour suivre ces métriques? Est-ce que c'est un outil maison ou un outil du marché comme Datadog, Splunk ou autre? Alors au début, quand je suis arrivé, on a mis en place Datadog, parce que l'urgence était d'avoir un outil fonctionnel rapidement. Et après, nous avons internalisé ça et utilisé Prometheus pour toute la remontée des métriques.

21:21 Métiers et métriques techniques. Et Prometheus se marie très bien avec Kubernetes, ça nous permettait d'avoir une bonne maîtrise, une bonne intégration avec notre outil d'astreinte automatique. Et est-ce que ça impacte du coup les performances des process eux-mêmes? Le fait d'avoir ces agents présents pour suivre? Alors, ces agents, effectivement, ils sont présents sur toutes les machines, sur tous les nœuds du cluster Kubernetes. Et oui, on en tient compte, mais l'impact est négligeable. Par rapport au nombre de microservices qu'on fait tourner, le nombre d'agents à la consommation CPU n'est pas la plus importante. Mais comme la plateforme Autoscale, de toute façon, on aura assez. Ce qui peut coûter cher, évidemment, c'est le stockage des métriques. C'est le cas des logs. La partie log, par exemple, on utilise de l'élastique. Celle-là est assez importante, elle a un coût non négligeable par rapport à la production. Par contre, le coût de CPU des Prometheus, des agents, est très raisonnable. Ok, très clair. On a également une question sur la partie DDoS, donc les attaques en bénéfice de service.

22:27 Est-ce que vous avez des mesures pour faire face au DDoS que vous préparez avec des tests et faire face également? Alors, pour le DDoS, on est derrière les load balancers Google. On est hébergé chez Google Cloud Platform. Les load balancers Google et la solution Cloud Armor nous fournissent une première protection face au DDoS. D'autre part, on a intégré dans notre code et dans nos reverse proxys des systèmes de rate limiting, principalement sur les API de login. C'est ce qui nous permet de filtrer. On n'a jamais eu, jusqu'à aujourd'hui, d'attaques de type DDoS. On a plus fait des attaques sur des boîtes qui essayent de trouver les mots de passe de nos clients en utilisant des dictionnaires. C'est pour ça qu'on utilise des systèmes de rate limiting et de blacklist sur nos systèmes d'authentification. Ok, très clair.

23:28 Alors, on repart sur la partie infra. Est-ce que vous gérez vous-même chez Kapten vos clusters K8S ou est-ce que vous passez par... Par EKS. On passe, on est chez Google, on utilise GKE, c'est le Kubernetes as a service de Google, parce qu'on a d'autres priorités que de gérer un cluster nous-mêmes. C'est une très grande complexité. Les grands cloud providers font ça très bien. Donc, cette partie-là est entièrement as a service. Il y avait une question pour justement la partie Kubernetes, puisqu'ils sont en manager chez Google. Qu'est-ce qui est prévu en termes de fallback? Est-ce que tu pourrais nous en parler un petit peu? Alors, on est donc notre cluster entièrement chez Google. Aujourd'hui, on a un seul cluster de production. Par contre, il est réparti, il est sur une région, mais il est réparti sur plusieurs zones de Google, sur trois zones en Europe, de façon à nous assurer un fallback en cas de problème sur une zone Google.

24:39 Aujourd'hui, on n'a pas plusieurs clusters. C'est quelque chose qu'on avait mis à l'étude, mais qui n'a pas été fait aujourd'hui. Donc, fallback, si toute la région européenne de Google tombe en panne, on ne s'en sortira pas. Un tiers des machines... Google sont déconnectés, ou même deux tiers. On va tout ça un petit peu, mais la plateforme ne tombera pas. Ne tombera pas. Très clair. Farzad, on arrive au terme de ta intervention. Merci beaucoup d'avoir partagé avec nous tes expériences dramatiques ou non de pique de charge, les bonnes pratiques également que vous avez mises en place, que vous mettez en place chez Kapten. Donc là, on va laisser la place à James. Je te propose de revenir en fin de meet-up pour la table ronde. Merci, à bientôt. Merci beaucoup. Donc maintenant, on va accueillir James Kretchmar, qui est CTO et VP chez Akamai, donc Content Delivery Network Service.

25:43 Donc James, si tu veux bien nous rejoindre. Alors, voilà, James. Oui, super. Bonjour, James. Bonjour. Donc, comme je le disais, tu es CTO chez Akamai, qui est un Content Delivery Network Service. Alors, si tu pourrais nous en dire un peu plus, déjà te présenter, nous dire un peu plus sur ton rôle chez Akamai et nous parler de vos problèmes de gestion de pic de charge, du pourquoi de l'Akamai. D'accord, oui, avec plaisir. Je suis CTO et pour les gens qui ne connaissent pas Akamai, comme vous avez vu, c'est un service de diffusion de contenu, on dit CDN ou Content Delivery Network en anglais. Et en fait, pour nous, gérer les pics de charge, ça fait une partie de base de notre système et de notre service. Parce que ce qu'on fait, on accélère et on protège les sites web et les mobiles contre les attaques aussi. Et en fait, je voulais dire, même pour les API, on a des services de protection contre les grandes attaques.

26:46 Mais on fait aussi la diffusion de vidéos de haute qualité. Pensez genre le Coupe du Monde ou le Jeux Olympiques. Et ça, c'est le genre d'événement où il y a des gens qui vont venir commencer à lancer une vidéo tous en même temps, de partout dans le monde. Et il faut absolument avoir une très bonne qualité et ne pas avoir de problèmes parce que c'est un match qui commence maintenant. Donc ça, c'est déjà un pic de charge qu'on doit gérer, comme c'est notre service de gérer. Et ce n'est peut-être pas si évident, mais même le téléchargement de logiciels et les jeux vidéo, ces jours-ci, quand il y a un nouveau jeu qui sort, ça peut avoir un pic de charge qui est encore plus haut que les vidéos. Donc, le pic de charge, on le fait tous les jours. Et c'est important pour nous, pour nos clients, de donner un bon service, même dans ces circonstances. Très clair. Alors, tu m'as dit que tu avais une présentation. Est-ce que tu veux l'afficher? Oui, j'ai des slides.

27:47 Je vais partager mon écran. Vous pouvez dire si ça marche. Vous voyez mes slides? Pas encore. Peut-être que c'est... Il faut répondre. Ah non, ça ne marche pas. Ah oui, je comprends, c'était bloqué. Oui, oui, ça marche maintenant. Okay. On a maintenant? Très bien. Ok, super. Bon, j'ai déjà présenté un petit peu ce qui fait l'entreprise dans ce slide, donc je vais juste montrer un peu comment on fait ce qu'on fait, la diffusion de vidéos et d'accélérer le contenu. Ça, c'est grâce à notre plateforme. On a construit une plateforme très, très distribuée dans le monde et ça fait une partie du service et ce qu'on fait pour gérer les pics.

28:53 Aujourd'hui, la plateforme est composée par 300 000 serveurs, comme vous voyez, mais franchement, ce chiffre, c'est peut-être impressionnant de voir, mais comme ingénieur, moi, quand je vois un chiffre comme ça pour les serveurs, pour moi, c'est juste un coût que je voudrais réduire, avoir le minimum possible de serveurs. Mais le 1500 réseaux, les 4000 endroits, pour nous, ça, c'est important parce qu'en même temps, ça aide à donner une bonne expérience, de bonnes performances pour les utilisateurs s'ils reçoivent le contenu d'un serveur qui est juste à QP2. Mais c'est aussi une manière de gérer les... Pique de charge parce que ça peut faire un offload, moins de charge sur les réseaux et les serveurs qui ont le contenu. Et donc, ça, c'est important. Ce n'est pas la seule chose. C'est aussi le logiciel et la conception du système qui est important. Et je vais parler de ça. Mais ça, c'est le réseau de base. Et en fait, je vais parler aujourd'hui de deux genres de pics de charge.

29:56 Il y a des pics de charge qu'on fait tous les jours avec notre... mais il y a aussi le pic de charge qu'on a vu pendant le confinement. Et grâce à le réseau qu'on a avec des clients partout, on diffuse un pourcentage important de... Le trafic internet, on a des graphiques que je peux partager sur ce qui a changé pendant le confinement en termes de trafic du web. Bon, juste pour commencer à comprendre le principe de base, ça c'est un exemple et en fait, je suis désolé qu'il n'y a pas des actes, j'ai supprimé exprès parce que je voulais juste avoir un exemple récent que j'ai trouvé, j'ai choisi un peu aléatoire. Mais ça, c'est le trafic. Pour la sortie d'un jeu vidéo. Et je peux dire que, par exemple, l'auteur de ce pic, c'est genre 13 terabits par seconde. Mais en fait, on peut voir que ça arrive très rapide. Le moment qu'il sort, il y a tous les consoles, tous les passants qui téléchargent le truc.

30:59 Mais même ça, 13 terabits par seconde, pour nous, ça, c'est assez normal. Ce n'est pas un record, ce n'est pas hors de norme. Il y a beaucoup d'événements qui dépassent ça beaucoup. Mais je voulais juste montrer, c'est ça ce qu'on a construit en système pour gérer. Je vais parler de comment on a fait. Pour montrer un peu ce qui s'est passé avec le COVID, qui était un autre genre de pic, dans ce graphique qui est un peu compliqué, ça montre l'augmentation, la croissance du trafic. année après année, pour les quatre pays qui étaient touchés en premier par le virus et qui ont commencé leur confinement avant les autres. Avec sa base, c'est en comparaison avec les pays qui n'avaient pas encore confiné, le reste du monde. Donc, on peut voir à gauche ces quatre pays, par hasard, la croissance année après année, c'était un peu moins que le reste du monde. Mais dès que le confinement a commencé, on a vu une forte augmentation du niveau de trafic.

32:02 Et je vais vous montrer comme ça, c'était un autre genre de pic à gérer. Le fin de ce graphique, ça arrête juste avant le confinement en France et le reste du monde. Donc, je vais passer pour spécifiquement ce qu'on a vu en France. Là, c'est maintenant en comparaison avec le trafic moyen au mois de février. Et ça, c'est le mois de mars, mais en comparaison avec février. Donc, là, en France, comme vous le savez, il y avait deux discours qui étaient donnés par le président. Le premier qui était le 12 mars et on voit très clairement que le 13, 14, 15, il y avait déjà une croissance importante dans l'utilisation de l'Internet. Ça, c'est ce qu'on a vu sur notre plateforme. Tout le monde restait chez eux. Ils ont beaucoup plus utilisé l'Internet. Et on avoue, 30%, c'est pour nous hors du normal en termes de croissance qui reste comme un nouveau normal, on dirait. Et puis après, il y avait le deuxième discours qui était le 16 pour le confinement qui a commencé le 17.

33:06 Et là, c'est aussi clair qu'il y avait beaucoup plus d'utilisation d'Internet et de notre plateforme. Et ce n'était pas attendu pour nous. Donc, en gros, pour résumer en termes mondiaux, dans un mois normal, on verra genre 3% de croissance de trafic. Mais dans ce mois, entre février et mars, on a beau à 30%, que ce soit d'habitude ce qu'on arrête tout un an. Et en termes de pics, les pics des pics, en mars 2019, le pic qu'on a servi à nos utilisateurs, les utilisateurs de nos clients, c'était 82 Mbps, mais ça s'est doublé en mars 2020 à 167 Mbps. Donc déjà, une quantité de trafic est énorme. Et en fait, chaque jour du deuxième trimestre de 2020, c'était plus de 100 Mbps. La seule autre chose que je vais dire avant de passer sur comment gérer ce genre de problème, c'est qu'avec cette augmentation dans le trafic normal, on a aussi une forte augmentation des attaques,

34:19 soit les attaques DDoS ou les attaques faites par des bots ou pour enlever les informations des utilisateurs. Les attaqueurs, ils ont vraiment... profiter de ce moment pour lancer beaucoup plus d'attaques. Donc, il y avait une augmentation de tout. Et pour nous, il faut absolument protéger contre les grandes attaques, juste comme quand il y a des vrais utilisateurs qui arrivent pour regarder un match. Sauf qu'avec les attaques, ils ne sont presque jamais annoncés en avance. Bon, ce qu'on peut faire, ça c'est une citation de moi qui était, pas de moi, mais c'est une citation préférée que je connais depuis très longtemps, c'est parmi mes préférées, mais je vais... Je ne connaissais pas en français jusqu'à ce que j'ai préparé ce discours. Mais les choses qu'on peut faire qui auront le plus d'impact et qui sont les plus importants sont les choses qu'on peut faire en avance. Je vais commencer avec des principes de conception. Je suis d'accord avec beaucoup de choses qui étaient dites juste avant sur comment faire pour être préparé pour quand il y a beaucoup de gens qui viennent et forment en pic.

35:28 La première chose, il faut absolument avoir votre plateforme, votre système automatisé le plus possible. Chaque chose qui peut être automatisée, on veut avoir automatisée parce que quand il y a un grand événement, attendu ou pas, il n'y a pas vraiment le temps pour réactionner. Un être humain sera juste trop long. Et même si c'est quelque chose où on peut avoir un être humain faire quelque chose pour améliorer la situation, c'est peut-être même pas une question de rapidité, mais une question de scale. S'il y a, par exemple, une centaine de choses à faire et il n'y a pas suffisamment de gens de faire ça. Donc, il faut absolument automatiser. Et il faut aussi faire dans une façon où on peut avoir une réaction rapide. Et pour notre système, et je parle de notre système, mais ça, c'est aussi un modèle de choses qu'on peut faire avec plusieurs systèmes et genres de systèmes. On a une boucle de rétroaction avec des informations détaillées.

36:30 qui vient en temps réel ou dans très peu de délais. Et ça, c'est important pour... Bon, je vais vous donner un exemple. Si, par exemple, on a des utilisateurs à Paris qui, d'habitude, on envoie vers un centre de données à Paris pour recevoir le contenu, ça marche très bien. Peut-être qu'il arrive qu'il y a plus de capacité dans le centre de données à Paris, un pic de charge, un autre genre de problème. La question, c'est qu'est-ce qu'on fait dans ce moment où le centre de données est rempli, il y a plus de capacité? Bon, première chose, j'ai vu dans des systèmes, il y a des systèmes où ils choisissent juste de continuer à envoyer les gens dans le même centre de données. Devrait être optimal, mais parce que c'est surchargé, ça commence à donner mauvaise expérience à tous les utilisateurs. Donc, pas une très bonne option. Deuxième option que j'ai vous, c'est de dire, OK, moi, on va laisser continuer les utilisateurs qui sont là déjà, mais pas laisser introduire des nouveaux utilisateurs.

37:32 Donc, c'est un genre de nid de service. Ce qui est mieux, c'est de trouver une façon d'envoyer ces utilisateurs à un autre centre de données, peut-être à une autre ville en France, voire un centre de données qui est dans un pays voisin. Donc, ce n'est pas la solution optimale, mais ça donne aussi une expérience qui marche, qui est normale. Et ça, c'est beaucoup mieux pour les utilisateurs. Donc, ça, c'est un exemple de ce qu'on appelle un dégringol. dégradation gracieuse. Et il faut vraiment chercher partout dans vos systèmes où il y a la possibilité d'avoir une dégradation gracieuse face à un problème qui va sinon causer un plus grand problème avec le système. Et ça se passe très souvent. Il y a une très petite chose qui tombe en panne et tout le système ne marche pas. Mais exactement comme Farzad a dit juste avant, il y a des solutions où on peut continuer à donner un bon service même quand il y a des petits problèmes.

38:34 Donc, pour trouver tout ça, il faut commencer avec l'idée que toutes les parties de votre système vont tomber en panne et puis après trouver les solutions. Les solutions. Je suis aussi d'accord qu'il faut absolument avoir le plus de visibilité possible et en avance. Si c'est pendant un incident qu'il faut aller chercher les données, ce sera compliqué de faire ça, faire la recherche et résoudre le problème tout en même temps. Alors, juste James, j'aurais une question sur cette In-Advanced Design Principles. Donc, tu parlais d'automatisation, justement, au niveau de Akamai, quels sont les différents stacks techniques qui vous permettent d'automatiser et de gérer les pics de charge rapidement en cas de surcharge. En fait, on a plusieurs retouches de faire l'automatisation. Et ça commence par un attente de faire dans tous les niveaux du système. Donc, c'est un peu comme ça. Ça commence, par exemple, dans un serveur soi-même. Le serveur essaie de...

39:36 De voir automatiquement s'il trouve qu'il est dans un bon état ou pas. Et si le système qui fait, par exemple, des autotests et des tests pour voir si tu vas bien dans le serveur, sinon le serveur peut décider de se mettre hors service. Et ça, c'est avant d'avoir quelqu'un qui va décider de faire ça. Et comme ça, il y a aussi un autre serveur dans le même rack. qui va prendre le service de ce serveur qui s'est mis hors de service et continuer à avoir un bon service. Mais on fait ça au niveau du serveur, on fait ça au niveau de tous les serveurs qui sont ensemble. Il y a une autre manière de mesurer si tout marche bien ou pas et de mettre hors de service. Mais c'est aussi fait par notre système de choisir où envoyer quel utilisateur. Ça, c'est déjà un genre d'automatisation parce qu'on ne fait pas de configuration pour décider quand on va envoyer ce groupe d'utilisateurs dans cette quantité de données. C'est complètement automatique.

40:37 D'accord. Bon, des autres choses qu'on peut faire en avance qui sont très importantes, de faire des tests de charge, juste comme on a dit avant. Ça, c'est important, première chose, pour savoir si votre système va continuer à marcher quand il y a un vrai pic de charge. Mais ça peut aussi montrer où il y a des points de faiblesse parce que ce n'est pas toujours le service principal, le serveur qui fait le service principal qui peut être le problème. Peut-être que c'est un autre service qui est utilisé par le service principal et qui sera le point de faiblesse. Et si on peut ajouter de la capacité là, tout le système va mieux marcher. Donc, il faut absolument tester. C'est très important si vous avez plus de juste quelques personnes dans votre boîte d'établir un processus pour les incidents. Et d'établir en avance et être certain que tout le monde connaît le processus et les moyens de communication. Parce que ce n'est pas pendant un incident que c'est le meilleur moment de faire ça.

41:41 En gros, la préparation, ce que tu dis, c'est qu'il faut une préparation technique sur les tests de charge, que fonctionnelle et humaine également, avec des humains qui soient préparés. On peut rebondir également sur la présentation de Farad qui nous parlait de la War Room qu'ils ont mis en place. Tous ces éléments participent de la survie en cas de pic de charge et de la continuité de service. Absolument, oui. Il faut savoir que les systèmes... Et le processus et les personnes, tout ensemble va marcher dans un problème. Bon, pendant le confinement, juste pour parler un petit peu de ce qu'on a fait dans ce genre, c'est un autre genre de pic, parce que, comme vous avez vu, pour les événements, on a déjà beaucoup de capacités pour le trafic, disons, moyen. Mais pour le, c'est-à-dire que parce qu'on a suffisamment pour les pics, le 30% va enlever suffisamment de capacités pour cette augmentation. Mais pour les pics qui étaient encore plus grands maintenant, on voudrait offrir à nos clients la possibilité d'avoir les événements le plus grand qu'ils voulaient.

42:49 Donc, on a fait des choses pour optimiser pendant l'événement soi-même. Par exemple, c'était possible d'ajouter des connexions pour avoir plus de capacités en termes de réseau. Ça, c'est quelque chose qu'on peut faire assez rapidement. Il y a des autres choses qui sont plus longues, mais ça, on peut faire. On avait aussi travaillé avec nos clients dans certains cas pour décaler leur trafic. Pour les distributeurs de jeux de vidéo, par exemple, ils pouvaient choisir de diffuser ou de sortir des nouveaux titres le soir ou dans les moments où il y a moins de trafic sur le réseau et donc on peut optimiser de cette manière. Mais on a aussi lancé un stream, en fait c'était tout un programme avec neuf streams différents pour trouver des solutions créatives, de trouver des solutions. Plus de capacités. Et par exemple, je donne juste un petit exemple là, il y avait un groupe qui a trouvé qu'on a une certaine procédure pour les serveurs qui sont hors service. Mais cette procédure, c'était un peu conservateur dans la façon de mettre des serveurs hors service, même quand ce n'était pas forcément nécessaire, mais c'était juste plus sûr comme ça.

44:00 Donc, quand on a vu qu'il y avait de la capacité qu'on pourrait récupérer dans son circonstance où c'était absolument nécessaire, on a fait ce changement et on a récupéré la capacité. Donc, c'est important juste en termes général, si on fait toutes les choses basiques avant, ça nous laisse l'espace pour faire des choses créatives pendant. Et je vais juste montrer un dernier slide et puis après prendre des autres questions. Il faut aussi regarder après un incident ou un événement comme ça, si les choses se sont passées, ce qui ne s'est pas bien passé pour améliorer. Mais on a constaté quelque chose que je trouve un peu spécial dans nos données, grâce à toute la visibilité qu'on a dans notre système. Ce graphique, ça c'est le trafic que vidéo, c'est la vidéo diffusée en Espagne une semaine en avril. Et on a constaté qu'il y avait un genre de pic en sens inverse. Il y a une chute. Il y avait une chute forte et très rapide chaque soir à 8 heures pile.

45:05 En fait, c'était juste après 8 heures et puis après, ça recommençait juste après. Et c'était bien évident après d'avoir regardé, c'était les applaudissements qu'ils faisaient chaque soir à 8 heures pile en Espagne. Donc pour moi, c'était spécial. On est toujours avec la tête dans des graphiques qui sont un peu abstraits, mais de regarder le lien avec la vie réelle, c'était agréable. Donc vous monitorez, j'imagine, à peu près tout chez Akamai. Et comment est-ce que vous traitez les données à posteriori? Est-ce que vous avez une équipe dédiée qui est là pour faire de l'analyse d'incidents à posteriori, des analyses de corrélation? Quels sont les efforts que vous mettez justement sur toute cette partie analytics des données techniques? La première chose, c'est qu'on a choisi tout au début de construire un système qui diffuse, qui rend disponible beaucoup de données diverses sur le système. On a dit, si on ne sait pas les données dont on aura besoin quand on est au plein milieu d'un nouveau problème.

46:09 Donc, au lieu de faire des reportages ou des reports fixes, on a construit le logiciel dans une manière où on peut demander, quand on veut, vers une grande quantité de serveurs, de nous donner des données qu'on veut et en fait d'agréger ces données dans une manière qui le montre comme un... C'était en database. Mais en réalité, ce n'est pas ça. Mais comme ça, on peut... En chaque moment décider ah oui il y a autre chose qu'on voudrait regarder qu'on n'avait pas pensé avant donc on va faire un petit écrire ce qu'on veut voir et tous les serveurs vont donner C'est aussi vrai qu'on utilise beaucoup de systèmes pour faire les corrélations entre les choses qui se passent, mais je ne sais pas si je peux dire quelque chose comme règle générale qu'on fait là, sauf qu'il y a beaucoup de données dans l'Internet et on est toujours en train de chercher comment faire une relation entre tout ça. Justement, est-ce que tu as des exemples d'être atypique de corrélations qui ont été faites entre, je ne sais pas, peut-être un film ou des lancements qui ont été faits qui correspondaient à des pics de charge critiques pour Akabai?

47:24 Est-ce que tu peux répéter la question? Est-ce que justement, grâce aux corrélations que vous avez faites, vous avez détecté des exemples un peu drôles de pics de charge qui ont été critiques pour Akamai? Ah, bon, souvent, en fait, il y a une histoire qui est très connue dans l'entreprise qui était tout au début quand on a lancé Akamai. En fait, il y avait deux. Il y avait une chose qu'il y avait le... Le défilé des modèles de Victoria's Secret qui avant ils n'étaient pas sur internet la première fois c'était montré par internet il était pas sur Akamai et le système a fait un crash et puis après l'année prochaine ils ont décidé d'utiliser Akamai et puis après ça marchait beaucoup mieux il y avait beaucoup de gens qui voulaient regarder ce truc. Mais il y a une autre histoire sur le lancement de la première nouvelle bande-annonce pour les Star Wars en 1999.

48:25 Donc, c'était après toutes ces années de Star Wars, ils faisaient la première chose. Et bon, en fait, c'était si populaire, il y avait tellement de monde qui voulait regarder que quand ils sont sortis là, le système a fait un crash et c'était pas possible de regarder la vidéo. Sauf qu'il y avait un seul site où c'était possible de voir la vidéo. Et en fait, il y avait Steve Jobs qui a constaté qu'il y avait un site qui marchait, qui était un site qui est sur notre plateforme. On ne savait pas. C'était très débutant comme entreprise qu'en fait, ce site n'avait pas le droit. C'est pour ça que Steve Jobs était un peu étonné, mais ça a marché quand même. Et puis après, maintenant, on fait mieux pour être certain qu'on a des clients qui ont le droit à leur... Il y a également une question qui est, est-ce que vous faites une corrélation directe entre l'augmentation du trafic sur Akamai et le trafic Internet? Est-ce que pour vous, la relation est directe ou est-ce qu'il y a des proxys entre? C'est direct, je dirais que ça montre la tendance générale.

49:33 Donc, on peut voir clairement que quand il y avait tout le monde qui restait chez eux, il y a une forte augmentation de l'Internet. On ne peut pas forcément dire si c'est proportionnel à ce montant ou à notre montant. On n'a pas un chiffre exact. Mais oui, on sait qu'il y a tellement de choses qui sont faites sur notre plateforme. On a des clients qui sont les plus grands distributeurs de vidéos, les banques, les sites. e-commerce. Donc, il y a tellement de choses qui, par Internet, ont fait par notre plateforme que ça montre l'effet général. Je ne sais pas si on a encore des questions, parce qu'on arrive au terme de ta présentation, James. Je regarde, on n'a plus de questions de Q&A et pas dans le chat. Donc, je te remercie énormément, James, pour ta présentation. Et je te dis à tout à l'heure pour la table ronde. Merci beaucoup. Oui, merci. On va maintenant accueillir Sacha Moura, qui est le CTO du groupe Le Monde. Donc, Sacha, voilà, Sacha qui nous rejoint.

50:36 Bonjour à tous. Bonjour. Donc, comme je disais, Sacha est CTO du groupe Le Monde. Donc, il y a différentes publications qui encadrent une équipe d'une soixantaine de personnes aujourd'hui pour gérer tout le back-end, toute la prod du groupe Le Monde. Donc, est-ce que tu peux nous présenter un petit peu ton métier et ton expérience des pics de charge? Oui, bien sûr. Alors, j'ai un petit support de présentation que je vais vous présenter. Puis, il y a une slide dans laquelle je me présente. Ça tombera très bien. Je vais juste partager du coup mon écran. Est-ce que vous voyez correctement ? Très bien. Ok, donc je vais vous parler de scalabilité et dynamisme, comment on gère en fait les pics de charge sur un site d'actualité. Alors, moi je suis Sacha Morard, j'ai 38 ans, je suis CTO du groupe Le Monde et je m'occupe de diriger la technique numérique des sites du groupe. Et comme l'a dit Maeliza, j'ai à peu près une soixantaine de personnes sous ma responsabilité.

51:38 J'ai un parcours un peu bizarroïde, on pourrait même presque dire chelou, parce que j'ai été musicien jusqu'en 2008. 2008, oui, non pas 2018, il y a une erreur dans le truc. Et ensuite, designer, ensuite développeur, et après, CTO, entrepreneur. Voilà, donc c'est quelque chose d'assez étrange, mais la musique m'a beaucoup apporté dans ma vie, et j'ai souhaité changer en 2008, parce que c'était trop compliqué. Aujourd'hui, elle m'apporte encore, puisque souvent on dit que les développeurs sont un peu des artistes, en tout cas, ils créent, ils écrivent, ils créent, et j'essaie de mettre un petit peu de création, de créativité dans mon travail. Alors, en novembre 2018, on a migré l'infrastructure du site web Le Monde vers Google Cloud Platform, donc notre nouvel hébergeur, c'est une grosse migration. Et on a décidé de rendre dynamique notre site. Alors, dit comme ça, on ne se rend pas trop compte de l'ampleur du chantier et surtout du défi que ça représente.

52:43 Je vais vous l'expliquer un petit peu plus en détail. Premièrement, il faut comprendre la spécificité d'un gros trafic de news comme celui du Monde. C'est environ 600 millions de pages vues par mois, en moyenne 9000 requêtes HTTP par seconde. C'est quand même un site qui génère beaucoup de trafic. Mais le plus délicat pour une équipe technique, ce n'est pas de construire une architecture orientée média, c'est plutôt de survivre au pic de charge. Parce que les pics de charge pour un site d'actualité, c'est violent, c'est même très très violent. Ce graphe nous montre le trafic que nous avons eu lors de la soirée des élections européennes en 2019. En 5 minutes à peu près, de 20h à 20h05, on a accueilli sur le site l'équivalent d'un parc des princes rempli. Donc, comme le disait James, le jour de sortie de jeux vidéo ou d'événements particuliers, c'est encore pire, notamment lors des événements tragiques.

53:46 On a connu un gros pic de charge lors de l'incendie de Notre-Dame, par exemple, mais bien évidemment aussi pendant les attentats de 2015. Pendant ces moments-là, c'est énormément de Français et d'étrangers qui ont le réflexe de venir s'informer sur notre pays. Et notre devoir, c'est justement de ne pas tomber. Parce que notre mission première, c'est d'informer. Et pour ça, il existe une architecture assez standard, mais éprouvée, que la majeure partie des sites d'actualité ont mis en place. Alors tout d'abord, vous développez un CMS qui écrit des contenus dans une base de données, évidemment. D'ailleurs, souvent vous choisissez un CMS open source, qui peut être Drupal, WordPress, quelque chose comme ça, ou alors vous achetez... Une distance d'un produit sur étagère, qui est souvent assez chère. Et puis, vous souhaitez de plus en plus une architecture orientée micro-service. Vous développez des API pour ne pas trop exposer votre base de données. Ensuite, vous choisissez un framework.

54:47 Donc là, on voit tout. Symfony, Laravel, Express, Django, Spring, etc. Qui vient taper justement dans ces API. Et là, ça commence à se corser parce que premièrement, ce genre de framework sont assez L'eau est lente, pardon pour ceux que je froisse, mais pour le coup, c'est ce que je pense. Et si vous êtes un site à porte-charge comme celui du Monde, autant vous dire que trois serveurs frontaux, ça ne va pas suffire. Et c'est là que la magie du CDN, donc CDN du type Akamai, ça c'est le travail de Akamai, c'est là que la magie du CDN intervient. Un CDN, du coup, c'est une techno qui permet de cacher les pages HTML et les assets pendant une certaine période. Je suppose que beaucoup d'entre vous savent exactement de quoi on parle, mais je vais quand même vous expliquer comment ça fonctionne pour ceux qui ne savent pas. Par exemple, lorsqu'un utilisateur demande pour la première fois la homepage de votre site, C'est la requête vers votre origine. Votre origine génère la page HTML. Généralement, là, ça peut prendre un peu de temps selon la lourdeur de votre stack.

55:49 Et puis, il leur renvoie au CDN qui en gardera une copie en cache pendant un certain temps. Puis, il la délivre à l'utilisateur. Il renvoie la réponse. Ensuite, lorsqu'un nouvel utilisateur demande la homepage dans les secondes qui suivent, le CDN répondra très rapidement sans interroger votre origine. Cette architecture a l'avantage de pouvoir délivrer beaucoup de requêtes secondes et tenir le coup lors des pics de charge parce que c'est le CDN qui fait le boulot. Le problème dans notre cas, c'est que là vous venez de servir la même page à plusieurs personnes différentes. Donc si vous voulez personnaliser l'expérience utilisateur, vous êtes un peu embêté, il faut partir avec plein d'autres calls JavaScript, enfin vous utilisez beaucoup de JavaScript dans le navigateur pour aller chercher de la perso et de la mettre dans la page. Et donc, on perd un petit peu en efficacité. Et il me semble que lorsqu'on veut faire franchir un cap à son produit, personnaliser l'expérience utilisateur, c'est inévitable. Ça commence simplement lorsqu'on propose à un utilisateur de se connecter.

56:52 Il faut que son nom et son prénom s'affichent correctement à droite de l'écran. Mais il s'agit aussi d'adapter son expérience en fonction de ses droits. Donc un abonné chez nous n'a pas droit à une lecture un petit peu plus large, une pression publicitaire réduite. Après, c'est aussi l'occasion d'expérimenter des choses. Il y a des tests AB, etc. C'est ça la personnalisation. Et tout ça, vous pouvez le faire avec un CDN qui cache le HTML. Vous pouvez le faire. Mais vous devrez utiliser beaucoup de JavaScript et ça alourdira votre webperte, totalement. Et vous devrez probablement aussi utiliser votre CDN et créer des règles particulières au niveau du CDN pour réussir à cacher certaines parties de vos pages et pas d'autres. On a beaucoup vu ça, notamment dans les technos varnish avec les balises ESI. En conséquence, nous, on a voulu sortir un petit peu de cette infrastructure traditionnelle et construire un site dynamique. D'ailleurs, quand j'ai annoncé ça à mes équipes et à mes confrères, certains ont pris un petit peu pour un fou et ont pensé qu'on n'y arriverait jamais.

57:55 Mais c'est sans compter justement la capacité de scalabilité des cloud providers. Donc là, je vais vous expliquer notre architecture. L'équipe qui développe le site du Monde fait du PHP et il fallait choisir un framework capable de générer des pages très rapidement. On a choisi Falcon, qui est un framework compilé, en fait c'est du C, et ce qui permet aux développeurs de continuer à écrire du PHP, mais d'appeler des briques qui sont en C. Ça, on fait tourner ça dans les conteneurs, sur des VM actuellement, mais on est en migration sur Kubernetes. Et on travaille beaucoup avec la capacité de scaling de notre cloud provider, ce qui nous permet d'allumer des VM au fur et à mesure qu'on en a besoin. Puis, on a installé un cluster post-grès qu'on a rendu scalable aussi. Vous remarquez qu'il n'y a plus de couche d'API entre les deux, parce que selon nos études, ça aurait ralenti la génération des pages. Faire des calls sur des API REST, donc des calls curl sur des API en...

58:58 Vraiment en masse, forcément c'est beaucoup plus lent que de faire des appels en base de données. Donc on n'est pas contre les microservices, mais en l'occurrence, si on veut générer la page HTML le plus rapidement possible, il nous a semblé que c'était mieux de faire des appels en base de données. Pour stocker et exploiter la donnée, on utilise PG, on utilise beaucoup aussi de Redis, donc ça c'est quand on est au RITOR, c'est un service manager de l'Internet, et forcément toutes les requêtes sont cachées, on a vraiment besoin d'un moteur de cache, plutôt du cache objet. Ensuite, on a une isolation parfaite entre notre stack front et notre CMS. On fait des échanges en asynchrone via des systèmes de queuing. Là, on utilise Cloud PubSub, mais on pourrait très bien utiliser du Kafka ou autre chose. Alors, on a toujours un CDN en face, mais celui-ci ne cache pas le HTML. Il nous sert par contre à cacher les assets, mais ne cache pas le HTML. Cette infra, elle nous permet de délivrer des pages très rapidement et de garantir une expérience, je pense, unique, en tout cas le plus possible à nos lecteurs, et d'être encore plus robuste lors des pics de charge.

1:00:09 Alors depuis le 12 novembre 2018, là où on a livré le site, notre nouvelle infra est complètement dynamique. On a vécu beaucoup de pics depuis, comme je vous l'ai dit pendant l'incendie de Notre-Dame, lors des résultats des élections européennes 2019, le jour du décès du président Chirac, puis beaucoup, beaucoup de pics pendant cette crise du Covid. Surtout le 15 mars, alors là vous voyez en fait la courbe de trafic le 15 mars. Toute la journée ça a été très très chaud, on a eu un trafic qui était déjà deux voire trois fois supérieur par rapport à notre habitude. Et puis à 20h bien évidemment il y avait les élections municipales, ce qui n'arrangeait rien, et on devait livrer les résultats des communes. Là l'infra a escalé sans subir aucune erreur et aucun ralentissement. On a allumé 300 VM, 30 000 requêtes HTTP secondes, et il y avait 250 000 personnes qui étaient sur le site. À 21h. Alors, une question qui se pose souvent, c'est du coup, comment vous gérez la tolérance aux pannes ?

1:01:10 Puisque le site est dynamique, forcément, ça devient de tout petit peu plus compliqué. On n'a pas le CDN en place qui cache le HTML et qui permet de protéger également l'infrastructure origine. Alors, avoir un site full dynamique, ça veut dire que la moindre erreur, elle est payée très cash. Imaginez, vous avez dans votre équipe un développeur un petit peu arrogant, ça arrive, et ce développeur, il n'aime pas faire des tests unitaires, ça arrive aussi. Et il lui arrive également de développer avec des moufs. Et comme il est arrogant, évidemment, il ne fait pas tester son code, il ne le fait pas relire. Évidemment, ça arrive, ça arrive à tout le monde. Et dans un concours de circonstances formidables, il pousse son code pourri jusqu'en prod. Là, avec ce genre de site, les utilisateurs le sentiraient tout de suite. Faire des 500, c'est la cata. Et dans l'idéal, il serait préférable que vous vous en rendez compte également très très vite, parce que sinon, forcément, vous perdez énormément de clients.

1:02:12 C'est pourquoi chez nous, on traque toutes les erreurs, qu'elles soient minimes ou plus graves. Aussi bien les erreurs de type notice dans le code qui ne génèrent pas d'erreur au niveau de l'utilisateur, mais aussi les erreurs plus graves. On les traque toutes et on les envoie toutes. No, no, no, no. Sur lesquels on a activé les notifications. Donc, ce qui veut dire que vous avez un site web. veut dire qu'on a poussé la philosophie zéro erreur jusqu'au boutiste. Dès qu'on a une erreur, on a un ping. Je vous garantis que quand on livre quelque chose qui ne fonctionne pas, on rollback tout de suite. Parce qu'on le sait. Alors justement, j'aurais juste une question sur ça rapidement. Pour avoir ces alertes qui remontent dans Slack, quels sont les outils de monitoring que vous utilisez aujourd'hui? Et pareil, quelles sont les métriques que vous suivez? Est-ce qu'elles sont plutôt fonctionnelles, techniques? Quel était le choix stratégique que vous avez fait à ce niveau-là? Non, c'est vraiment… Là, on fait vraiment… Une grosse gestion des erreurs, comme on a l'habitude de le faire dans tout applicatif, gestion des erreurs, on va essayer de catcher toutes les erreurs qui se passent dans le code.

1:03:19 Donc aussi bien les erreurs pas graves que celles qui génèrent vraiment des incidents. Et systématiquement dans le code, on est à un assez bas niveau, en fait, un système qui vient les catcher et qui vient les toucher directement dans le sac. En synchrone. Je dis en synchrone parce que c'est quelque chose sur lequel on a beaucoup réfléchi à ce moment-là. Est-ce qu'il fallait le faire synchrone ou asynchrone? Mais en fait, on est dans une situation où quand on doit envoyer une erreur dans Slack, on est dans une situation où on a un incident. Donc en fait, soit en synchrone ou en asynchrone, on s'en tape. On a un incident, il faut réagir très très vite. Donc ça doit arriver quasiment jamais. Donc on l'a fait de manière très très simple. On utilise vraiment du curl pour envoyer une notification dans le chat. Ok. Après, évidemment, on a tout un tas de systèmes de monitoring pour aller lire nos logs, retrouver les erreurs également dans les logs, en faire des graphes, en faire des mesures, en faire de l'alerting, etc. On a une question un peu connexe de Vincent qui dit que beaucoup de publishers ont des challenges avec les bots.

1:04:25 Avez-vous également ces problématiques et comment est-ce que vous vous adaptez au monde? Oui, bien sûr, des bots, on en a énormément qui viennent nous crawler. Des bots qui sont légitimes et d'autres beaucoup moins, en fait. Alors, on a un minimum, mais toute notre... En fait, la meilleure protection qu'on a, c'est justement réussir à faire un applicatif le plus léger possible, le plus performant possible, pour qu'en cas de crawl pro massif, ça scale sans qu'on s'en aperçoive. Après, on a d'autres outils derrière qui viennent... vérifier si une IP, un user agent, un espèce de fingerprinting particulier vient nous crawler trop souvent et dans quel cas on peut le blacklister. Je laisse reprendre la présentation. Alors juste, oui, je continue sur les erreurs. Chasser les erreurs, ça ne suffit pas à les éliminer définitivement. Avec une infradynamique, on est exposé à des risques et d'incidents importants. D'ailleurs, on peut de nouveau imaginer qu'on a un développeur très arrogant.

1:05:33 Ça arrive encore. Et imaginez que ce génie de l'informatique lance une requête de la mort sur votre base de données. Et comme il est arrogant, il n'en parle à personne. Ça arrive encore. Alors, imaginons en plus qu'il est 12h47 et qu'il n'a pas mangé et qu'il file à la cantine. Donc là, on aligne vraiment tout ce qui ne va pas. Là, vous avez un gros problème. Déjà, vous avez un gros problème de recrutement. Ça, c'est sûr, il va falloir le résoudre. Et aussi, à ce moment-là, votre base de données, elle palpite. Votre serveur de cache, Redis, est en arrêt cardio-respiratoire. Votre site, il est en train de faire un AVC. Bref, il y a tout qui pète. Et c'est un gros problème. Là, même catcher les erreurs, ça ne suffit pas parce qu'on a un problème qui n'est pas au niveau du code. Donc, qu'est-ce qu'on fait? Pour pallier ce problème, on a créé un mécanisme de service minimum. James en parlait un petit peu. Moi, je l'appelle service minier. Je ne sais plus quel terme il employait, mais il parlait d'un système équivalent.

1:06:34 Lorsque nos lecteurs visitent une page du site, certains navigateurs vont lancer en arrière-plan un pré-fetch d'une version froide de la page. Cette page, elle n'est pas rendue dans le navigateur, mais elle permet de remplir le cache CDN avec des versions de pages non personnalisées. Donc si par exemple vous êtes connecté, vous voyez votre nom, prénom en haut à droite, mais la version froide de la page, il n'y a pas la connexion. Vous n'êtes pas en état connecté. Donc, on a une certaine faible pourcentage de l'audience qui vient remplir le cache CDN avec des pages froides. On a paramétré notre CDN pour qu'il détecte une page en erreur, quand nos serveurs sont en erreur. Et qu'à ce moment-là, il la remplace par une version froide. Donc en conséquence, en plein incident, on peut quand même délivrer des pages et c'est ce qu'on appelle nous le service in-million. Alors, une autre question qui arrive assez souvent, c'est est-ce que ça coûte plus cher de faire ça?

1:07:37 Forcément, on envoie le pratique à l'origine. Qui revient souvent de la part de ceux qui sont fort consommateurs de CDN, La bande passante, c'est un truc qui coûte très cher chez les cloud providers. En général, le gigabyte des graisses facture à peu près 11 centimes d'euros. C'est-à-dire que la bande passante sort du CDN. C'est à peu près 11 centimes d'euros chez les cloud providers. Le monde consomme environ 600 TB de bande passante par mois. J'ai fait le calcul, si on envoyait tout le trafic directement dans Google Cloud, en l'occurrence, on paierait 44 000 euros par mois juste en bande passante. Ce n'est pas jouable. Mais avec un CDN partenaire, le partenaire de votre cloud provider, donc Akamai, d'ailleurs, Pasquille, etc., Pasquille, c'est votre CDN, on bénéficie d'un tarif différent. Entre les graisses entre le CDN et le cloud descend à 2 centimes de gigas. Parce que le trafic, en fait, il passe par un lien.

1:08:39 interconnect entre le CDN et votre cloud provider. Puis il y a des coûts du CDN qui sont variables, mais on arrive au moins à négocier avec les CDN le coût de la vente. Du coup, la plateforme du monde, elle ne cache pas le HTML, mais on peut dire qu'il y a un surcoût d'environ 2 centimes du giga. Et puis, en plus, qu'est-ce qui pèse lourd dans une page web? C'est les assets. Le HTML, ça ne représente qu'un faible volume de données. Et du coup, le surcoût est négligeable en termes de vente passante. Par contre, oui, il y a un surcoût en infra parce qu'on allume beaucoup plus de VM que si on avait un CDN qui cachait le HTML devant, évidemment. On aurait moins de trafic à l'origine. Mais moi, j'estime que notre site est bien meilleur et que du coup, ça nous permet de convertir plus, donc de faire augmenter aussi notre chiffre d'affaires. Alors justement, vous avez fait le choix d'une architecture qui est plutôt atypique, puisqu'elle ne passe pas par un CDN, parce que vous avez fait le choix du dynamisme.

1:09:43 Qu'est-ce que vous codez vous-même versus, qu'est-ce que vous confiez à un tiers en termes d'infrastructure et d'architecture de manière générale? On code quand même beaucoup de choses nous-mêmes. On a cette fâcheuse tendance, comme beaucoup de CTO et beaucoup d'équipes techniques, de croire qu'on peut tout faire nous-mêmes. Et je dis fâcheuse tendance parce que ce n'est pas bien, je sais que ce n'est pas très bien, il y a plein de belles boîtes qui font des super solutions sur lesquelles on peut s'appuyer et en plus ça nous ferait gagner du temps. En fait, on se pose toujours la question, où est notre valeur? Et là où est notre valeur, on développe, parce qu'on veut garder la maîtrise entière. Le CDN, on n'a aucune valeur à essayer de gérer, nous, le caching de nos coques. Aucune. Donc, on fait appel à un tiers. Sur la sécurité, c'est pareil. On n'a aucune valeur ajoutée à essayer de développer nos propres outils de sécurité. Donc, on fait appel à des tiers. Après, on a plein d'autres choses comme ça. On a même aujourd'hui un tiers qui gère le processus d'abonnement. Voilà, ça, c'est un tiers qui le fait.

1:10:45 Après, sur tout le reste, oui, on fait quand même pas mal de choses. Alors, on arrive bientôt au terme de ta présentation. Il y a une question qui a eu pas mal de votes, c'est sur l'usage des technos d'AMP, donc Accelerated Mobile Pages. Est-ce que vous utilisez l'AMP au monde aujourd'hui? Le monde n'utilise pas AMP. La promesse d'AMP, c'est de rendre vos pages beaucoup plus rapides que les vôtres. C'est justement pour que l'utilisateur puisse avoir la version de l'article, en l'occurrence, très rapidement dans son device. Grâce à ce site dynamique, On a allégé considérablement le poids de la page, le poids du JavaScript. Du coup, on a des webpairs qui sont très, très bonnes. Elles sont tellement bonnes qu'on a beaucoup moins besoin de ce genre de solution. Donc, on n'utilise pas MP. Très clair. Alors, merci à tous pour vos questions. Merci, Sacha, pour ta présentation.

1:11:47 Nous, on arrive au terme de cette présentation individuelle. Là, je vais demander à James et à Farzad de revenir sur scène avec nous pour les questions un peu plus générales sur l'épicarge, sur des questions transversales. Farzad, ton micro est coupé. Merci. Alors, je ne sais pas s'il y a une question générale que vous aimeriez poser à nos participants. S'il n'y en a pas, moi j'en ai une que je vais poser successivement à Farzad, Sacha et James sur un peu la plus grosse erreur que vous ayez commise au moment de pic de charge, que vous ayez détecté et en causant un pic de charge et comment est-ce que vous avez réagi? Que ce soit une erreur humaine, une erreur technique, le gros fail. Alors, mon plus gros fail, c'était peut-être un excès de confiance. Et c'était, j'ai parlé de Kubernetes, c'est le jour où on a migré sur Kubernetes.

1:12:49 Vraiment, on a entièrement mis à la place sur Kubernetes. C'était quatre mois de développement, deux tests, de mise en place, de métriques, de logs et tout, tout mesuré, tout dimensionné. On a passé en propre. On va voir un pot au bar d'à côté. Arrive le soir, 19h, 20h, pic de charge, et la plateforme s'est écroulée. C'est le premier jour de la mise en production qui va à la thèse. Donc là, c'était peut-être un excès de conscience. Et il y a certains paramètres qu'on avait mal réglés sur Kubernetes. C'est pour ça que je parlais de... Les tests de charge ne permettent pas de tout voir. Donc, c'était en grande partie entièrement ma faute. Il y a des paramètres qu'on avait mal réglés. Avec la montée en charge, il y a des microservices. sur Kubernetes qui ne démarrait pas assez rapidement et Kubernetes les tuait au fur et à mesure qu'ils essaient de démarrer pour gérer la charge. Donc, on a dû corriger ça rapidement. Mais après, trois semaines après, on a ouvert Londres, ce qui nous a quasiment doublé le trafic. Donc, je pense qu'on s'en est finalement bien sortis sur cette grosse erreur humaine qui est de ma spécialité.

1:13:56 Merci beaucoup Farzad. James, même question. Pour nous, je crois que le plus grand fail, parce que je ne peux pas penser à un fail qui était lié spécifiquement au kick, parce que probablement parce qu'on est si spécialisé dans les piques, on est toujours sur ça. Mais le plus grand fail, c'était en 2004, en fait. On avait un problème de logiciel. Il y avait un bug qui a fait tomber une très grande partie du système. Et donc, pour nous, c'était un moment où on a dit, OK, il faut absolument... Faire beaucoup plus d'autres choses pour être certain qu'il n'y a jamais un petit problème qui va causer un plus grand problème. Mais pour moi, c'était malheureusement, je travaille en opération à ce moment-là à Akamai et j'avais un mois dans la boîte. Et c'était vraiment pour moi un moment compliqué de voir un si grand problème quand j'étais en opération tout au début. Mais heureusement, je ne sais pas si on dit en français ou pas, mais il y a une expérience.

1:15:00 Spation en anglais quand on tape sur le bois pour éviter de refaire un truc pareil. Donc jusqu'ici, ça va. C'est du bois, oui. Ah, tu es du bois, oui. En 16 ans, ça va. Je ne sais pas reproduire, mais je suis déjà parti. Sacha, même question du coup? Oui, j'ai un fail que j'ai vécu personnellement, donc je ne vais pas parler pour le monde, mais c'était quand je travaillais pour le Parisien notamment, on avait le soir des élections municipales 2012, il me semble. Travailler d'arrache-pied pour, pareil, livrer les résultats auprès de nos utilisateurs. Et ce jour-là, le dimanche arrive, tout le monde était très prêt. Et puis, moi, j'ai chopé la gastro. Et donc, du coup, j'ai dû quand même aller au travail pour vivre cette soirée. Vous m'entendez ? Oui, c'est bon, ça a coupé un petit moment, tu peux reprendre? Tu as du retard de travail? Oui, alors je disais, soirée des élections municipales quand je travaillais au Parisien, je chope la gastro dans la journée et finalement je dois aller au travail parce que je n'ai pas trop le choix à la soirée, on ne va pas la décaler pour moi.

1:16:07 Et à 20h, les résultats tombent, mais le site aussi. Le site est complètement effondré. Et alors, tout simplement, pourquoi? Parce qu'on a pêché par arrogance, encore une fois. On a pensé qu'avec notre infra, on pouvait tenir la recharge sans aucun problème. Il n'y avait pas de système scalable à l'époque. On était en non-problème. On avait par contre du CDN en face. Et on avait capitalisé tout sur le CDN. Et on n'avait pas vraiment contrôlé ce qu'il allait faire ce soir-là. En l'occurrence, ce CDN, avec qui on a arrêté de travailler par la suite, avait allumé tellement de pop. qu'on avait beaucoup trop de trafic à l'origine parce que le... Ça veut dire que chaque serveur sur lequel tapaient les utilisateurs, avec son propre niveau de cache, ce n'est pas un cache centralisé, ce qui fait qu'on avait trop quand même de trafic qui allait à l'origine, et notre infra n'a absolument pas tenu. Le temps qu'on se rende compte que c'était ce CDN qui nous posait problème, il s'est passé quand même au moins une heure et demie, et en fait c'est en le coupant et en basculant sur notre CDN qu'on a résolu le problème. Et justement, j'ai une petite question pour creuser ça, c'est-à-dire que, pareil, aujourd'hui au Monde, le CDN est une solution de backup au cas où la solution dynamique ne fonctionne pas.

1:17:12 Est-ce que vous arrivez aujourd'hui à monitorer ce service minimum? Sûr qu'il va bien fonctionner le jour où vous en aurez besoin. Oui, bien sûr. Dès que ça arrive, nous, on reçoit les notifications dans Slack. On sait que le site est en erreur. Et là, quand on continue à aller sur le site, on voit qu'il est toujours up. Forcément, parce qu'après, c'est le CDN qui prend le relais. Et là où on voit si le système marche ou pas, ou si vraiment tout ne fonctionne pas, c'est par exemple sur la courbe d'analytics, on utilise une qui s'appelle Charbit, qui est beaucoup utilisée par la rédaction, qui nous remonte en temps réel les utilisateurs qui sont sur le site. Dès qu'on a un pic down comme ça, on sait qu'il n'y a rien qui fonctionne. Ok, très clair. Alors là, vous nous avez tous parlé à peu près de passage au legacy, à une version plus nouvelle, de montée de version. Est-ce que vous avez des systèmes en shadow pour tester une nouvelle version? Et en fait, c'est des systèmes qui vont recevoir du trafic de la production sans le délivrer au client derrière? Pour un peu tester les nouvelles versions.

1:18:16 De notre côté, il n'y a pas de système de shadow pour la partie serveur, pour la partie backend. Par contre, pour la partie front-end, toutes les personnes qui travaillent chez Kapten sont bêta-testeurs des applications mobiles. Et on a aussi des chauffeurs qui testent les applications mobiles. Donc, on a au moins les applications mobiles qui, elles, sont testées sur la plateforme de production, mais avec des nouvelles fonctionnalités. Par contre, non, nous n'avons pas de système de shadow qui récupère le trafic. Ok. Et chez vous? En fait, Oui, oui, on fait ça. En fait, on le fait dans deux manières différentes. Il y a pour juste le trafic des utilisateurs pour savoir s'il y a une nouvelle version du logiciel qui tout va bien. Mais ce qui est plus intéressant pour moi, c'est pour le problème de... Le données sera internet en général parce que la manière qui fonctionne notre service c'est qu'en mesure en temps réel la performance entre des parties différentes de l'internet et c'est comme ça qu'on choisit

1:19:21 où on doit servir un certain utilisateur et c'est aussi important pour le contenu dynamique parce qu'on peut trouver des chemins plus rapides par internet pour le contenu qui n'est pas statique et donc on ne va pas cacher mais on peut trouver une façon de diffuser mieux que l'Internet. Donc pour ça, il faut avoir des mesures de toute l'Internet qui est assez énorme. Donc il n'y a pas façon de simuler ça. Donc ce qu'on fait avec nos systèmes qui reçoivent ces mesures de ce qui se passe par Internet, ils dirigent une copie vers des systèmes de test pour utiliser les vraies données pour savoir si ça marche bien ou pas. Donc, c'est une copie des données que vous envoyez, pas les données réelles. Et vous, Sacha, au Monde? Alors, sur la question... J'adore notre shadow. Oui, oui. Alors, il disait qu'on ne délivre pas aux utilisateurs. Il y a un reroutage des données ou comme le check-in? Oui. Pour moi, il n'y a pas trop d'intérêt à tester une fonctionnalité si on ne la renvoie pas aux utilisateurs.

1:20:25 Mais peut-être que la question, je l'ai mal compris. Oui, on fait ce qu'on appelle aussi bien du bêta testing que du déploiement progressif. Donc, on peut très bien décider de délivrer des nouvelles pages, des nouvelles versions du site ou de l'application mobile à nos bêta-testeurs, qui sont à peu près 500-600 abonnés. Mais aussi, dès que cette phase de bêta-test est terminée, on passe au déploiement progressif. Donc, on ouvre la nouvelle version à 1%, on mesure, on regarde si tout va bien, 2%, ou des fois on réduit, des fois on remonte, etc., jusqu'à ce que toutes les KPI soient. OK, et là, on ouvre à 100%. Ok, donc c'est une migration progressive. Très clair. On a une question plus générique sur la protection des données personnelles. Comment est-ce que, dans le cadre d'un pic de charge, de reroutage, de l'activation d'une solution secondaire, comment est-ce que vous assurez la protection des données personnelles de vos utilisateurs ou de vos clients? Parfait. Alors, c'est une question un peu transverse.

1:21:27 Plusieurs niveaux. Déjà, en faisant ça, que les données personnelles des clients, les bases de données évidemment, tous les accès sont protégés un maximum, ne sont pas publiés sur Internet. Le plus gros vecteur d'attaque chez nous, il y a deux vecteurs d'attaque, c'est d'une part les attaques par dictionnaire pour trouver les mots de passe des utilisateurs. Et donc là, on a... Comme je l'ai dit, on a des systèmes de rate limiting, on bloque facilement certains types de bots pas trop intelligents. Et on a une équipe de sécurité qui a développé des outils pour pouvoir détecter ce genre d'attaque, bloquer éventuellement les comptes ou demander une deuxième authentification. Et le deuxième vecteur d'attaque, c'est des fraudes à la carte bleue. Donc, avec des créations automatiques de comptes avec des cartes bleues volées. Et là, on a une équipe de fraude qui travaille avec notre partenaire de paiement qui a développé des outils pour détecter ces cartes bleues et essayer de bloquer les comptes.

1:22:30 Bloquer les comptes automatiquement ou manuellement au fur et à mesure qu'ils sont créés. Et chez vous, James, comment est-ce que vous assurez la protection des données personnelles de vos clients? En fait, il y a deux manières qu'on fait ça. Il y a les choses standards, juste en termes de sécuriser les serveurs, être certain que les données ne vont pas quelque part où elles ne doivent pas aller. Et tant que les données, c'est de nos clients et pas de nous, c'est d'habitude à eux de choisir quel niveau de protection, mais on les offre ça. Mais l'autre niveau, c'est de faire des choses pour les aider à éviter des autres façons de perdre leurs données. Et exactement comme Farzad a dit, c'est très important d'avoir une protection contre les bots. Donc, on a maintenant avec tout ce qu'on peut voir sur ce qui se passe sur Internet, une solution qui bloque les bots et aussi pour ajouter de l'intelligence, de savoir si c'est un vrai humain ou pas derrière un appareil mobile, dans le navigateur. Et aussi, quelque chose qu'on voit de plus en plus, c'est que parce qu'il y a un grand pourcentage du contenu dans le site qui est...

1:23:37 Fait par un tiers et le site principal perdre le concept de ce qu'il y a introduit par tous ces tiers qui a introduit le contenu dans leur site. C'est souvent ça maintenant le mode d'attaque. Il y a des gens qui ajoutent un attaque dans le code d'un tiers pour récupérer un carte crédit dans le site principal. Donc ce qu'on a commencé à faire pour nos clients, c'est avoir un système de détecter s'il y a des mauvais codes dans leur page. Et pour toi, Sacha ? De notre côté, on a énormément de choses concernant la sécurité, la sécurité de façon assez large, bien évidemment la sécurité des données personnelles de nos lecteurs et de nos journalistes. Forcément, le monde est une cible assez privilégiée de certaines attaques. On a plein d'outillages, mais par rapport au pic de charge, en tout cas, on n'est pas plus vigilant pendant le pic de charge qu'hors pic de charge, on est vigilant tout le temps.

1:24:43 On fait beaucoup de pen tests, on a des outils qui mesurent les attaques, les injections SQL, les scans de sécurité, les bruits de force, tout ça, et qui est capable de les bloquer. Qu'est-ce qu'on a d'autre? On est en train d'accueillir Il y a aussi du rate limiting pour se prémunir un petit peu plus du trafic illégitime, même s'il ne nous fait pas trop trop mal, mais quand même. Voilà, on a vraiment toute une arme à la chose. Et après, on est en train vraiment d'augmenter notre culture en matière de sécurité, culture sur... Comment développer sans faille de sécurité, et aussi comment on travaille nous ensemble, comment on protège aussi les journalistes par rapport à tout ça. Merci beaucoup d'avoir répondu à toutes ces questions. On arrive au terme, il nous reste une minute, on arrive au terme de ce meet-up. Je tenais à vous remercier et à remercier également les participants pour toutes les questions. Donc, on avait Farzad Farid qui est responsable de la plateforme de production chez Kapten, qui a fait le choix de contenu.

1:25:49 Zéro statique, donc que des API, des microservices, donc pas de contenu statique. On avait James, Kretchmar, CTO et VP de chez Akamai, qui est un fournisseur CDL. Et on avait également Sacha, Morard, CTO du Monde, qui eux ont fait le choix d'avoir un site dynamique et du statique en solution de backup. Merci à tous les trois de votre présence, du partage d'expérience et merci aux participants également. Je vais replacer la main à Noémie qui va conclure la meet-up.