Pour préparer l’Euro 2024, Bedrock a industrialisé sa logique de load testing
L’entreprise qui opère notamment les plateformes de streaming de M6 et RTL a littéralement torturé ses solutions pour être sûre de pouvoir encaisser sans broncher les pics d’audience provoqués par l’Euro de football. Ses vastes campagnes de tests, réalisées grâce à la solution Gatling, ont mené à une centaine d’ajustements et de modifications.
Créé il y a plus de 10 ans sous la marque 6Play, Bedrock Streaming s’est au fur et à mesure émancipé de la chaîne pour devenir avec le temps un fournisseur de services de streaming vidéo. Sa technologie en marque blanche supporte la diffusion de contenus pour plusieurs grandes marques de médias. Maintenant co-détenue par M6, RTL et Bertelsman (qui détient RTL), la société gère ainsi les plateformes de streaming de M6 Plus, de Videoland aux Pays-Bas, des déclinaisons de RTL en Belgique, en Croatie, en Hongrie et était également le back-end de feu Salto. En tout, Bedrock compte plus de 35 millions d’utilisateurs sur le vieux continent.
Pour suivre la cadence, Bedrock est progressivement passé, entre 2017 et 2018, d’une infrastructure sur site monolithique à un hébergement complet sur Amazon Web Services, tant pour des questions de flexibilité que de scalabilité. Dans le détail, l’entreprise déploie ses plateformes sur des clusters Kubernetes hébergés sur des instances EC2 en mode spot pour des raisons tarifaires. « Quand nous ne gérions qu’une seule plateforme, il était facile de maîtriser une infrastructure sur site. Le passage à “N” plateforme pour autant de clients différents imposait l’adoption d’infrastructures beaucoup plus volubiles et flexibles, et donc le cloud », indique Jean-Yves Camier, manager et responsable technique de l’équipe DevOps de Bedrock Streaming.
Anticiper la mise à l’échelle
« Pour rappel, nous ne pouvons pas nous appuyer uniquement sur l’auto-scaling proposé par AWS. Les serveurs ne s’allument pas instantanément et il y a toujours un temps de latence. »
Valentin ChabrierIngénieur DevOps, Bedrock Streaming.
La société doit affronter l’enjeu majeur de la mise à l’échelle de ses infrastructures pour encaisser les pics d’activité liés aux programmes phares de ses clients. Dans un précédent article au sujet de l’entreprise, LeMagIT est revenu en détail sur les solutions mises en place par la plateforme pour répondre à cet enjeu. « Pour rappel, nous ne pouvons pas nous appuyer uniquement sur l’auto-scaling proposé par AWS. Les serveurs ne s’allument pas instantanément et il y a toujours un temps de latence. Soit nous acceptions d’avoir un service dégradé pendant les 5 premières minutes, soit nous trouvions d’autres solutions. Et évidemment, garder en permanence une infrastructure surdimensionnée n’en était pas une », explique Valentin Chabrier, ingénieur DevOps chez Bedrock Streaming.
C’est notamment pour l’Euro de football 2020 que Bedrock avait commencé à mettre en place des solutions de pré-scaling. Toutefois, si celles-ci avaient correctement fonctionné à l’époque, Bedrock n’en était pas tout à fait satisfait. Les solutions peinaient en effet à anticiper correctement les pics de charge et la résilience pouvait parfois faire défaut. « Avec encore plus d’utilisateurs et de plateformes pour l’Euro 2024, nous voulions nous assurer d’avoir cette fois-ci une infrastructure béton », raconte Valentin Chabrier. Et pour y arriver, l’équipe s’est lancée dans une vaste campagne de load testing, afin d’éprouver ses plateformes face à tous les scénarios possibles.
Industrialiser les tests de charge avec des scénarios réels
« Début 2024, nous avons commencé à mettre en place une équipe dédiée à la résilience. Celle-ci est composée d’une demi-douzaine de personnes et a engagé plusieurs phases de load test », détaille Valentin Chabrier qui pilote ce projet. « Nous utilisions alors plusieurs outils pour réaliser ces derniers, mais il était difficile de reproduire facilement des scénarios réels ».
Il précise notamment que ces outils, parfois complexes, ne permettaient pas de gérer finement la montée en puissance du nombre de requêtes. « Parfois, nous en avons planifié plusieurs millions, mais celles-ci ne s’échelonnaient pas comme dans le monde réel. Nous pouvions en avoir d’un coup 1 million, puis aucune, puis deux, etc. Cela ne correspond pas à la réalité de la production », explique-t-il.
L’échéance approchant, l’équipe de Bedrock Streaming décide de passer à un outil dédié pour industrialiser ses tests de charge et finit par se rapprocher de l’éditeur français Gatling en février. Une semaine plus tard, l’équipe a pu prendre en main l’outil pour littéralement torturer ses plateformes.
De l’importance de l’observabilité
« Ce qui est intéressant avec Gatling, c’est que nous avons pu mettre en place des scénarios très précis pour tester un maximum de possibilités et de failles », affirme l’ingénieur DevOps. « Nous pouvons gérer très précisément le nombre de connexions sur les plateformes et les actions de chacune d’entre elles afin de reproduire des cas d’usage au plus proche de la réalité », poursuit-il. « Nous pouvions ainsi générer des parcours utilisateurs normaux ou alors insister sur des fonctionnalités spécifiques comme les popups ou certaines redirections ».
« Avec nos précédentes solutions, nous avions du mal à avoir des indicateurs précis sur les réponses de la plateforme aux tests. En outre, nous devions construire nos propres tableaux de bord. »
Valentin ChabrierIngénieur DevOps, Bedrock Streaming
L’équipe s’est organisée pour réaliser deux sessions de tests par semaine. Chaque fois, c’est en moyenne 5 tests avec des protocoles spécifiques qui étaient réalisés.
L’autre grand intérêt de Gatling concernait l’observabilité et la collecte des différentes métriques. « Avec nos précédentes solutions, nous avions du mal à avoir des indicateurs précis sur les réponses de la plateforme aux tests. En outre, nous devions construire nos propres tableaux de bord », explique Jean-Yves Camier. Gatling permet, selon lui, d’avoir une très grande granularité et d’analyser chaque requête dans des tableaux de bord dédiés via des exports dans Prometheus.
Les équipes ont cassé tout ce qu’elles pouvaient… même en production
« Nos campagnes de test ont été couronnées de succès », se félicite Valentin Chabrier. « Nous avons pu tester tout ce qui pouvait l’être et casser tout ce qui pouvait être cassé. Et ce sont clairement des éléments qui auraient pu nous lâcher pendant l’Euro, qui, pour l’instant, se déroule à merveille pour nous », assure-t-il.
Les tests ont surtout mis en évidence des faiblesses liées à l’utilisation massive de PHP dans la plateforme proposée aux diffuseurs.
« Nous nous sommes rendu compte que nous arrivions à la limite de ce qu’il était possible de faire avec ce langage, notamment au niveau de la gestion des caches Redis qui, au bout d’un moment, peinent à encaisser de trop grands nombres de connexions simultanées », illustre Jean-Yves Camier.
« Chaque hausse de connexion liée aux différents scénarios de test nous est facturée par Amazon comme pour des utilisateurs normaux. Et ça peut vite coûter très cher. »
Jean-Yves CamierManager et responsable technique de l’équipe DevOps, Bedrock Streaming
Pour pallier ce problème de montée en charge, ce sont plusieurs modules qui ont été développés directement en Go. En tout, près d’une centaine d’ajustements et de modifications ont été réalisés sur la plateforme à l’issue des phases de test.
En sus de préparer la plateforme, les load tests ont également permis d’entraîner les équipes de Bedrock à répondre aux pannes. N’ayant pas froid aux yeux, l’entreprise a en effet exécuté l’ensemble de ses tests sur ses plateformes en production, exigeant que ses collaborateurs soient réactifs et réparent immédiatement ce qui pouvait être amené à tomber. « Ça n’aurait rimé à rien de réaliser nos tests sur des infrastructures qui ne représentent pas la réalité de la production », estime ainsi Valentin Chabrier.
Il faut toutefois s’acquitter de la rançon de la gloire. Mener de telles campagnes de tests sur des plateformes hébergées sur le cloud public demande de « rallonger » ses budgets. « Chaque hausse de connexion liée aux différents scénarios de test nous est facturée par Amazon comme pour des utilisateurs normaux. Et ça peut vite coûter très cher », rappelle Jean-Yves Camier.
Pour approfondir sur Administration et supervision du Cloud
