M6 a fait de l'Euro 2024 de football une vitrine de la chaîne, avec la diffusion de 13 affiches de cette compétition, dont la finale (programmée le 14 juillet). D'où le besoin de fournir une qualité de service irréprochable sur le site web du média, M6+ (auparavant 6play), qui propose la diffusion en direct des matchs, ainsi que de multiples replays (matchs en intégralité, buts, résumés, temps forts). Après quelques problèmes enregistrés lors de la précédente compétition européenne de football, en 2020, la co-entreprise de M6 et RTL a fait le choix de prioriser la disponibilité du service sur l'optimisation des coûts. Alors que 6play fonctionne habituellement à 100% sur des instances spot dans le cloud AWS (soit des capacités de calcul non utilisées), le site bénéficie pour la compétition actuelle de machines réservées et d'instances à la demande, plus chères. « S'y ajoutent des astreintes pour les équipes, même s'il est impossible d'ajouter des machines indéfiniment, du fait du risque de saturation des API dans Kubernetes », souligne Jean-Yves Camier, qui dirige une équipe Devops travaillant sur le coeur de l'application M6+.

Le cloud public pas assez réactif

Mais au-delà des moyens financiers mis en oeuvre pour l'événement, l'enjeu n°1 de Bedrock Streaming, la filiale numérique du groupe qui produit le socle technique et assure l'exploitation des sites de M6 et RTL, consiste à gérer des audiences structurellement très fluctuantes. Une problématique que connaît bien Jean-Yves Camier, puisqu'elle n'est fondamentalement pas si différente de celle que connaît habituellement le site de la chaîne. Avec des audiences en journée assez modestes et des bonds lors de la disponibilité d'une émission ou pour le live en soirée. « Et, avec le foot, tout le monde arrive sur la plateforme en même temps et revient en même temps, après la mi-temps, souligne le responsable de l'équipe Devops. Une problématique que nous connaissions déjà sur des émissions de type Top Chef. »

« Ce profil d'audience pose des problématiques de scalabilité, même avec le cloud public et même avec Kubernetes, indique Jean-Yves Camier. Nous avons donc besoin de 'préchauffer' les environnements. » La durée de disponibilité d'un nouvel environnement technique dans AWS, le cloud qu'exploite Bedrock, étant de 3 à 6 minutes, il faut en effet provisionner les ressources nécessaires en amont des pics d'audience. Certes, la co-entreprise entre M6 et le groupe RTL a commencé à exploiter la technologie Karpenter qui permet de ramener le provisioning dans Kubernetes à environ une minute, mais le composant Open Source, encore relativement jeune aux yeux de Jean-Yves Camier, n'est pour l'heure exploité qu'avec des environnements d'intégration continue.

Un composant pour automatiser les passages à l'échelle

Pour encaisser les variations de trafic sur la production, Bedrock Streaming mise donc aujourd'hui sur un planning anticipant la charge que va encaisser le site, avec un système de démultiplication des environnements en fonction des plages horaires. « Nous utilisons ce même principe pour les matchs de l'Euro, en y ajoutant un paramétrage spécifique de DynamoDB (base de données NoSQL d'AWS, NDLR) », précise le spécialiste. Une partie du processus est aujourd'hui outillé, les responsables de la chaîne renseignant les audiences attendues dans un calendrier Google. Le 25 juin au soir et le lendemain (lors des matchs de poules), Bedrock Streaming avait ainsi prévu de multiplier par quatre l'infrastructure technique de son site par rapport au niveau standard. « Le passage à l'échelle est automatique et pris en charge par un petit développement en Go, disponible sur notre GitHub, précise Jean-Yves Camier. A l'avenir, nous aimerions intégrer cette programmation directement dans le back-office ». Grâce à ce principe, M6+ peut encaisser les quelques millions d'utilisateurs qui affluent lors des matchs.

Valentin Chabrier, ingénieur DevOps chez Bedrock Streaming, et Jean-Yves Camier, Tech Lead & Manager au sein de la même entité, qui compte environ 400 personnes. (Photo : D.R.)

Au-delà du passage à l'échelle des environnements cloud, ce type d'événements souligne également les limites intrinsèques des applications. Une raison qui a poussé Bedrock Streaming à s'intéresser aux tests de charge. « Nous avons effectué de premières expérimentations en ce sens il y a deux ans, mais la solution d'alors s'avérait difficile à exploiter », souligne Jean-Yves Camier. La co-entreprise spécialisée dans le streaming a donc migré vers l'outil de l'éditeur français Gatling en début d'année. « En une semaine, nous avons pu identifier un grand nombre de sujets d'amélioration, reprend l'expert. L'observabilité que procure nativement la solution s'avère très importante dans un environnement de microservices. »

Go pour s'affranchir des limites de PHP

En plus de ces tests basés sur des scénarios bâtis en début d'année et régulièrement mis à jour pour coller de plus en plus aux pratiques des internautes, Bedrock Streaming s'est aussi attaqué à un travail de fond : la réécriture en Go de l'application M6+, pour s'abstraire des limites de PHP (comme l'obligation de mettre en oeuvre un reverse proxy, la répétition des handshake à chaque requête HTTPS, etc.). « Aujourd'hui, les travaux de la migration sont en cours de priorisation, en fonction de la charge supportée par les différents composants », dit Jean-Yves Camier. Un candidat à cette réécriture prioritaire pourrait ainsi être l'API Gateway, un composant PHP ayant lourdement recours à la gestion de cache et touchant aux limites du service dédié d'AWS, Redis.

La solution de test de Gatling devrait d'ailleurs être intégrée à terme à cette stratégie de migration vers le langage Go. « Nous avons redéveloppé un mini-framework Go proposant les mêmes composants que Symfony. Nous essayons de sensibiliser dès le départ les développeurs à la performance, via l'intégration d'outils de benchmarks en Go. L'étape suivante consistera à mener des tests de charge sur chaque service applicatif et à effectuer un suivi de ces performances dans le temps », indique Jean-Yves Camier.