Podle akademiotoelektronik, 19/03/2023

Comment Bedrock Streaming supervise 6Play et Salto

Bedrock Streaming est née sous le giron de M6 et est présentée comme une filiale technologique du groupe de télévision. En mars 2020, M6 décide d’ouvrir le capital de cette entité. Le groupe allemand RTL (lui-même majoritairement détenu par Bertelsmann) acquiert alors la moitié de Bedrock Streaming, avant que d’autres investisseurs ne le rejoignent.

L’équipe technique de Bedrock Streaming, basée à Lyon, rassemble près de 300 collaborateurs.

« Notre métier c’est de développer des plateformes de streaming pour les groupes de télévision, c’est-à-dire des infrastructures pour des applications d’advertising/VOD (des plateformes de vidéo à la demande gratuite, mais comprenant de la publicité NDLR) et SVOD (où l’accès aux contenus est payant NDLR) », déclare Olivier Mansour, CTO adjoint de Bedrock Streaming.

Les clients de cette joint-venture entre M6 et RTL sont principalement européens. Bedrock Streaming opère deux services vidéo importants en France : 6Play, propriété de M6, et Salto, la co-entreprise TF1/France TV/M6. Bedrock Streaming a également des clients en Belgique (RTL Belgique), en Croatie (RTL Croatie), en Hongrie (RTL Hongrie) et aux Pays-Bas (Videoland).

« Notre but est d’apporter aux acteurs locaux une technologie comparable aux fournisseurs comme Netflix, Amazon, Hulu, Disney ou d’autres. De nous battre dans la cour des grands sur la partie technique », affirme Olivier Mansour.

Ces plateformes vidéo doivent être robustes. Bedrock Streaming dessert pas moins de 50 millions d’utilisateurs au total. Les plateformes peuvent héberger du contenu vidéo à la demande, des rediffusions, mais aussi des flux TV en direct.

Disposer de la bonne architecture est important, mais encore faut-il pouvoir la surveiller. « Souvent, nos clients s’adressent à nous après avoir essayé eux-mêmes de développer une plateforme de streaming : ils sont à la recherche de la stabilité, c’est notre promesse », avance l’adjoint au directeur technique.

Les défis de Bedrock Streaming

Avant de « jouer dans la cour des grands », et de s’appeler Bedrock Streaming, la filiale a opéré dès 2008 la plateforme M6 Replay hébergée dans le data center parisien de M6. « À l’époque, la problématique pour le groupe M6 était d’assurer une rentabilité économique. Nous faisions beaucoup de choses nous-même », se remémore-t-il. « Pour le monitoring, nous avions déployé une stack ELK couplée à Grafana et Statd ».

Cette pile technologique servait également à superviser les back-end et les front-end applicatifs.

Au début des années 2010, cette approche était perçue comme innovante. « Nous mettions déjà ce que l’on nomme aujourd’hui observabilité au cœur de nos pratiques de développement », considère-t-il. « Nous avions pour doctrine “tout ce qui n’est pas observable n’existe pas” ».

Aussi, les outils de supervision du marché étaient à la fois chers et reposait sur des modèles économiques complexes, selon le CTO adjoint. « On ne voyait pas d’équilibre économique. Nous n’étions pas encore dans un cloud public, mais notre infrastructure était déjà virtualisée et gérée à l’aide d’hyperviseurs VMware, entre autres. À l’époque de M6 Replay, la tarification dépendait du nombre de serveurs, du nombre de CPU. Nous n’arrivions pas trop à comprendre comment cela fonctionnait », explique-t-il.

Bedrock est elle-même passée d’un modèle économique BtoC à un autre BtoBtoC. « Là, tout a changé. Nous étions une équipe de 20 développeurs au total pour opérer M6 Replay. Il a fallu multiplier les effectifs pour répondre aux objectifs de croissance », affirme Olivier Mansour. « Nous avons aussi compris que notre stack existante n’allait pas nous suivre. En ajoutant des clients, même si notre plateforme continuait à bien se comporter pendant des événements importants, notre monitoring tombait ».

En outre, l’accroissement du nombre de clients et la progression de M6 Replay devenu entretemps 6Play exigeaient une transition vers le cloud. Cette migration vers AWS, doublée d’un passage sur Kubernetes, a commencé en 2017 et est largement documentée dans un livre – « Le plan Copenhague » – écrit par Pascal Martin, ingénieur principal chez Bedrock Streaming.

Dès 2019, l’équipe IT s’est posé la question du monitoring. « En dehors des pratiques commerciales et des exigences purement techniques, le choix de notre fournisseur cloud était conditionné par le fait que nous devions passer de 20 à 300 développeurs. C’est un peu la même approche qui a influencé le choix d’une nouvelle plateforme de monitoring », assure Olivier Mansour.

Bedrock Streaming a évalué les solutions d’Elastic, de Datadog, de Splunk ou encore de New Relic. « Il y avait plus d’appétence pour Splunk et Datadog du côté des Ops, tandis que les développeurs back-end préféraient Elastic, mais tous ces systèmes répondaient bien à nos besoins assez limités à l’époque », estime le CTO adjoint. Alors, comment se décider ? « Nous avons mis en regard notre objectif de croissance important. Nous avons choisi un outil relativement connu des développeurs postulants et disposant de la couverture fonctionnelle la plus large possible ».

Mais cette évaluation ne s’est pas faite en un jour. « Nous avons longuement cherché une société disponible pour nous accompagner réellement », indique Olivier Mansour.

C’est finalement New Relic qui a été choisi en 2020. « Ce travail semble long, car nous étions en même temps en train d’embarquer nos nouveaux clients, de développer notre système multitenant, multi-instance », explique le responsable technique. « Mais dès que nous avons lancé les POC, New Relic a rapidement compris notre démarche visant à explorer en profondeur leur plateforme. Ils ont su nous accompagner ».

Bedrock Streaming souhaitait également évaluer le coût d’implémentation de la solution d’observabilité, « ce qui n’est pas évident », souligne Olivier Mansour.

« Dans l’instance qui fait tourner Salto, vous avez 75 microservices différents. Il fallait que l’on évalue l’effort de connecter l’agent New Relic à chacun des microservices. Ce qui nous a beaucoup aidés, c’est que nous utilisons Terraform pour l’infrastructure as code et que New Relic propose des solutions pour implanter son agent depuis cet outil », explique le directeur technique adjoint. « Dès le départ, les ingénieurs de New Relic nous ont enseigné les bonnes pratiques pour le faire ».

Un déploiement propulsé par l’infrastructure as code

Une fois la méthode assimilée, Bedrock Streaming a mis en place en interne un système de squelette pouvant rapidement s’étendre à tous ses projets. « Après avoir effectué les bons tests, il “suffit” pour les équipes d’appliquer ce squelette, de libeller correctement leur projet et de le déployer ».

« Chez Bedrock, une équipe est composée de 6 à 8 personnes et gère trois à quatre microservices. Après avoir placé l’agent dans le code terraform, l’équipe déploie ses propres tableaux de bord et les alertes pour superviser la bonne santé des éléments en production. Ce n’est pas très différent de ce que nous avions historiquement, mais les pratiques n’étaient pas homogènes », déclare le responsable.

Une instrumentalisation exhaustive, comme celle voulue par Bedrock Streaming, prend du temps. « Nous avons mis six à neuf mois pour déployer New Relic sur toutes les ressources back-end », témoigne Olivier Mansour.

« En un peu moins d’un an, nous avons pratiquement terminé le monitoring, mais nous n’avons pas terminé le logging. C’est aussi parce que nous ne voulions pas ralentir les projets en cours », rappelle-t-il.

« J’ai tout de même discuté avec notre direction pour assurer un niveau d’observabilité suffisant en prévision de période de pics sur nos plateformes de streaming, notamment lors de certains événements sportifs. Pour faire ces tests de charge, nous avions besoin d’une observabilité complète de notre plateforme cloud. Désormais, nous pouvons suivre les requêtes de tous les microservices du front end jusqu’au système de stockage ».

En cela, le directeur technique adjoint considère que l’agent de New Relic est un avantage.

« Une fois installé, l’agent remonte des données sur les temps de réponse, la latence de communication entre les microservices ou encore les performances de nos bases de données. Si nous observons des temps de réponse dégradés, l’on peut rapidement savoir si l’on a atteint les limites d’un service managé et donc le reconfigurer », indique Olivier Mansour.

Les capacités de la plateforme d’observabilité ne s’arrêtent pas à l’analyse des temps de réponse. Le directeur technique adjoint apprécie la possibilité de superviser les erreurs présentes dans le code.

« Nous obtenons énormément d’informations sur les erreurs. Par exemple, quand nous observons un événement dans lequel New relic a relevé un panel d’erreurs, la plateforme peut nous dire d’où proviennent les défauts dans le code ou dans notre architecture Kubernetes », illustre-t-il.

Ainsi, l’équipe technique de Bedrock Streaming a commencé « par utiliser l’outil d’analyse de causes profondes le plus simple, sans intelligence artificielle. Nous avons obtenu des gains importants avec notre infrastructure réseau sans faire autre chose que d’installer le SDK », assure Olivier Mansour.

Puis, l’APM de New Relic a permis aux équipes de visualiser une couche d’informations standard. « Comme nous avons labellisé les informations, nous pouvons déterminer une santé globale. Si un problème a été remonté par un de nos clients, rapidement nous savons si ce souci est spécifique à une instance ou si le ralentissement est généralisé. Nous n’avions pas cette capacité auparavant », avance-t-il.

Anticiper le mur de connexion provoqué par Top Chef

Car, l’objectif, rappelons-le, est de maintenir en production des applications de vidéo à la demande. « Nous essayons d’estimer le nombre d’utilisateurs de nos plateformes et nous le confrontons à notre système d’autoscaling. Nous voulons que cette montée à l’échelle s’appuie sur les bonnes métriques et qu’elle soit bien liée à l’usage. New Relic nous permet d’agréger des métriques comme le nombre de lancements de vidéos, le nombre d’appels à la navigation dans les pages, etc. Nous pouvons facilement confronter ces informations avec le nombre de pods Kubernetes actifs afin de savoir si nous en faisons trop ou pas assez ».

Mais le système d’autoscaling n’est pas aussi réactif que son nom le laisse l’entendre. « Par exemple, quand le microservice d’authentification est beaucoup sollicité, nous avons l’intuition de préchauffer les services qui affichent le catalogue vidéo », déclare Olivier Mansour.

« Sur 6Play, une bonne partie de l’année, le mercredi à 20 h 30, c’est l’heure de Top Chef. Les gens terminent leur repas avant de se connecter. C’est ce que nous appelons le mur de connexion. Avec chacun de nos clients, nous réglons notre plateforme suivant la saisonnalité de leur trafic afin de préprovisionner des ressources en sus de notre système d’autoscaling moins réactif quand le mur de connexion est soudain », précise-t-il.

Bedrock Streaming s’attelle aussi à employer des méthodes de dégradation gracieuse et des circuit breakers afin d’assurer la continuité de services pour les utilisateurs finaux, ce qui se traduira par l’absence d’une barre d’avancement sur une vidéo ou encore l’impossibilité de reprendre une série en cours de route, mais qui n’empêchera pas le fonctionnement principal des applications VOD et SVOD.

« Ces deux mécanismes sont difficiles à optimiser », avertit Olivier Mansour. « Il faut très précisément comprendre ce qu’il se passe dans la plateforme de streaming : quel microservice est ralenti ? Pourquoi ? Comment ? Pendant combien de temps ? La suite de New Relic nous aide beaucoup en cela ».

Il ne suffit pas de superviser, il faut également prévenir les équipes concernées par une possible détérioration de services.

« Ce qui a été assez long – et ce qui n’est jamais réellement terminé – c’est la partie alerting », assure Olivier Mansour. « Cela nécessite que l’équipe en charge du microservice se pose les bonnes questions : quel est le niveau de performance acceptable ? Quels sont les impacts sur les produits ? »

Ce ne fut pas la priorité au moment d’adopter la suite d’observabilité. « Notre système existant était très bien configuré, donc dans un premier temps nous n’avons pas activé les alertes dans New Relic, conformément aux conseils de leurs employés », indique le CTO adjoint.

Puis, Bedrock Streaming s’est attelé à mettre un double niveau d’alertes : l’un pour le suivi au quotidien des performances des plateformes de streaming, l’autre pour les problèmes critiques. Le premier envoie des avertissements dans des salles Slack. « C’est devenu un élément très sécurisant de nos mises en production en déploiement continu. Le fait d’avoir New Relic nous a permis d’augmenter cette cadence », explique Olivier Mansour.

Le second informe les personnes en astreinte via PagerDuty et aide à respecter les SLA auprès des clients, selon le CTO adjoint.

Un éditeur « poussé dans ses retranchements »

Tout cela n’aurait pas été possible aussi rapidement sans le concours de l’éditeur, selon Olivier Mansour.

« En général, chez Bedrock Streaming, quand nous faisons appel à un prestataire, nous le poussons rapidement dans ses retranchements. Avec New Relic, nous avons trouvé des bugs dans les agents qui surveillent nos applications, mais nous avons pu avoir accès au code même lorsque certaines portions n’étaient pas encore open source, nous avons pu proposer des patches qui ont été acceptés », se réjouit-il.

Bedrock Streaming utilise encore beaucoup de PHP. « Nous avons pu en discuter avec les ingénieurs de New Relic. Ils ont été à l’écoute et ont été réactifs pour répondre à nos besoins », constate notre interlocuteur.

Le support n’est pas le seul intérêt de cet accompagnement. L’entreprise souhaitait également une aide à la formation. « Nous avons des interlocuteurs en France. Avec eux, nous avons des réunions libres à distance dans lesquelles nos 300 développeurs peuvent rejoindre et poser leurs questions », affirme l’adjoint au directeur technique qui apprécie ce dispositif.

Le déploiement s’est également bien déroulé parce que Bedrock Streaming a désigné un interlocuteur chargé des échanges avec New Relic. « Cette personne connaît très bien notre back-end et a pu orienter l’accompagnement de l’éditeur et des équipes ».

Cela a également permis de sélectionner les bonnes briques pour répondre aux besoins des développeurs.

« Je pense que nous utilisons la moitié des fonctionnalités de New Relic. L’offre est très complète. D’ailleurs, c’est l’une des raisons pour lesquelles le démarrage du projet a été un peu long », remarque Olivier Mansour. « Quand nous avons branché notre premier microservice en environnement de test avec New Relic, nous étions perdus, il y avait beaucoup d’informations. L’accompagnement nous a beaucoup aidés à y voir plus clair ».

Si la suite a su prouver son utilité, New Relic n’a pas pénétré toutes les couches chez Bedrock Streaming. Les équipes infrastructures manipulent un autre outil. Aujourd’hui, 70 personnes en charge des environnements back-end utilisent New Relic, tout comme certaines équipes responsables du front-end et du mobile.

« Au total, 150 développeurs emploient la solution. Nous avons aussi des personnes non techniques qui utilisent la suite. Les invités accèdent aux tableaux de bord, ce qui est suffisant pour nos équipes produits afin de mesurer l’usage des fonctionnalités disponibles depuis nos plateformes de streaming », annonce Olivier Mansour.

« Nous avançons pas à pas en observant finement le coût de la solution : nous payons à la licence et au nombre de gigaoctets ingérés. Les équipes de New Relic sont proactives pour piloter ce coût », ajoute-t-il.

Les prochaines étapes de l’adoption de New Relic chez Bedrock Streaming concerne la supervision des applications mobiles, l’effort continu de dashboarding et l’évaluation de la plateforme par les membres responsables de l’infrastructure.