Comment Molotov a bâti un datacenter qui ne tombe pas en panne
Diffusant depuis 2016 la télé sur tous les appareils numériques des Français, Molotov a passé trois ans à concevoir une infrastructure qui encode en permanence 170 chaînes dans 30 formats.
Trois ans. C’est le temps qu’il a fallu à l’équipe de Molotov pour mettre au point l’infrastructure qui lui permet de diffuser sur tous les équipements numériques français 170 chaînes de télévision à plusieurs centaines de milliers d’utilisateurs en même temps.
« Le premier enjeu est de parvenir à encoder en temps réel chaque chaîne dans une trentaine de formats normés, qui sont adaptés aux différentes bandes passantes des appareils et des connexions Internet de nos utilisateurs. Nous nous sommes fixés comme cahier des charges de tolérer trois minutes entre le moment où nous recevons le flux d’une chaîne et celui où nous le diffusons. Le défi, surtout, est de permettre aux téléspectateurs de passer d’une chaîne à l’autre en moins de 200 millisecondes », lance, sans perdre de temps, Alexandre Ouicher, directeur technique de Molotov. Il est à la tête d’une équipe de 40 personnes, soit rien de moins que la moitié du personnel qu’embauche le diffuseur.
Disponible pour le public sous la forme d’une app pour appareils mobiles, pour Mac ou PC et pour les box TV comme les média-centers, Molotov entend depuis 2016 réinventer la télévision. Fini le zapping incrémental d’une chaîne à l’autre avec les boutons de la télécommande. L’interface du diffuseur présente tous les programmes sur un kaléidoscope : par chaîne, par thème ou par tendance du moment, ce qui est en cours de diffusion, ce qu’on peut revoir, ce qui va arriver, ce que l’on peut épingler pour ne pas le rater.
Cette offre est gratuite. Les abonnés payants ont la possibilité de passer d’un appareil à l’autre et d’enregistrer les programmes : Molotov les conservera sans limite de temps, tant que les utilisateurs n’auront pas fait de ménage dans leur liste. Comme tout diffuseur, Molotov commercialise en option des bouquets thématiques, comme OCS ou Ciné+.
244 machines physiques dans 11 baies racks
Si la moitié du personnel travaille pour la direction technique, c’est parce que Molotov est d’abord une usine numérique géante. Son datacenter, constitué de 244 équipements informatiques, répartis sur 11 armoires rack, produit en permanence des milliers de flux vidéo transformés au bon format.
Là, des développeurs affinent régulièrement les algorithmes – ils automatisent même des procédures pour maintenir l’activité en cas d’incident. A côté, des ingénieurs scrutent sur des courbes le moindre ralentissement ; comme toutes les applications sont conçues comme des microservices, même s’il s’agit en pratique de 240 machines virtuelles, ils rééquilibrent les charges de travail au gré du succès des émissions. Plus loin, enfin, cinq personnes se chargent de maintenir l’informatique dans un état opérationnel.
Les flux vidéo sont relayés au plus proche des utilisateurs par des CDN, à savoir des serveurs de cache que des prestataires dédiés installent dans les datacenters des fournisseurs d’accès. Cependant, si ces serveurs de cache épongent les sauts des spectateurs sur la barre de progression des émissions en cours de visionnage, encore faut-il qu’ils puissent accéder en amont à toute la panoplie des flux possibles.
« Nous stockons toutes les vidéos que nous diffusons, pour que les spectateurs puissent redémarrer au début d’une émission, bien entendu, mais aussi parce que nous leur proposons d’épingler des émissions afin qu’ils puissent les regarder en différé. Il nous fallait donc du stockage très capacitif, évolutif et rapide en lecture », indique le directeur technique.
Selon les informations que LeMagIT a pu obtenir, les données stockées à date, flux en cours et enregistrements confondus, représentent environ 6 Po. Cette taille augmenterait d’une année sur l’autre de 25 à 30 %.
« Nous devions mettre en place un front office qui supporte la connexion simultanée de centaines de milliers d’utilisateurs ».
Alexandre OuicherDirecteur technique, Molotov
« Enfin, nous devions mettre en place un front office qui supporte la connexion simultanée de centaines de milliers d’utilisateurs ». Cette partie du service correspond à la base de données qui alimente l’interface que les utilisateurs manipulent depuis leurs terminaux. Elle maintient les différentes présentations des programmes, authentifie les utilisateurs et prend en compte leurs actions : choix de l’émission à regarder, enregistrement d’une autre, etc.
Dell EMC pour des serveurs plug’n’play
En 2013, pour définir l’infrastructure qui lui permettra d’assurer son service trois ans plus tard, Molotov appelle à l’aide un spécialiste de ces problématiques : l’ESN Iguane Solutions. Fondée en 2000 par Benjamin Bejbaum, qui créera Dailymotion quelques années plus tard dans les mêmes locaux, Iguane Solutions a notamment à son palmarès le lancement technique de Deezer, la plateforme de musique en ligne française qui rivalise avec l’américain Spotify.
Le prestataire conseille à Molotov de bâtir son infrastructure sur des matériels Dell EMC. « Notre idée était de limiter le nombre de modèles différents pour simplifier son administration et supporter la croissance de l’activité en pouvant ajouter très simplement et très rapidement de nouvelles briques. Iguane a fait le choix de Dell EMC car les serveurs sont plug'n'play. Il n’y a même plus besoin de vis pour les fixer, on les glisse sur des rails », justifie Cédric Le Moan, COO d’Iguane Solutions.
« Par ailleurs, les machines Dell EMC sont équipées de contrôleurs iDRac qui remontent sur une console centrale toutes les informations des serveurs et depuis laquelle il est possible de prendre la main sur les machines », ajoute-t-il en argumentant que l’enjeu pour une infrastructure importante comme celle de Molotov est de ne surtout pas de tomber dans le piège de l’administration informatique chronophage.
Des serveurs rack 2U uniquement pour les nœuds qui encodent les flux
Pour l’encodage des flux, Molotov achète des serveurs PowerEdge R700. Leur avantage est d’être livrées dans des boîtiers 2U, avec suffisamment d’espace pour les équiper de cartes GPU, lesquelles sont idéales pour effectuer les calculs liés à la conversion des vidéos aux bons formats.
« L’option initialement retenue était d’utiliser des transcodeurs vidéo professionnels à part, mais elle n’était pas satisfaisante. Les cartes GPU nous donnent plus de souplesse sur le développement applicatif. Iguane nous a aidés à faire des maquettes pour évaluer de quel nombre de GPU, dans combien de serveurs, nos applications avaient besoin pour traiter quelle quantité de flux », raconte Alexandre Ouicher. Il refuse de dévoiler le détail des R700 aujourd’hui déployés, avançant que cela fait partie du secret industriel.
Les connexions des utilisateurs sont quant à elles gérées par des serveurs R400. Ils sont équivalents aux R700 si ce n’est qu’ils sont fournis dans des boîtiers 1U et ne permettent pas l’ajout de GPU. La fonction de ces R400 étant d’être des frontaux qui exécutent des applications liées à des bases de données, seule la quantité de RAM – qui conditionne le nombre de VMs – et la connectique réseau sont importantes.
Du stockage objet Scality pour un minimum de latence
La partie de son infrastructure sur laquelle Alexandre Ouicher insiste le plus est le stockage. Molotov a fait le choix de tiroirs de disques (JBODs) ND1400 qui peuvent contenir 12 disques durs de 14 To chacun. Ils sont reliés à des serveurs PowerEdge R640. Ces machines bi-processeurs en boîtier 1U sont équipées de deux cartes Fiber Channel, chacune capable de piloter 8 JBODs (soit un maximum de 16 JBODs par serveur).
« Nous ajoutons du stockage ou des ressources trois fois par an, sachant que nous n’allons jamais au-delà de 8 JBODs par serveur, pour des questions de sécurité ».
Alexandre OuicherMolotov
« Cette partie de l’infrastructure doit être particulièrement évolutive. L’avantage des R640 est que qu’il est simple d’ajouter des barrettes de RAM, voire de changer les processeurs, afin d’avoir toujours avoir assez de puissance pour piloter une capacité qui ne cesse de croître. Nous ajoutons du stockage ou des ressources trois fois par an, sachant que nous n’allons jamais au-delà de 8 JBODs par serveur, pour des questions de sécurité », décrit-il.
Sur le plan logiciel, il s’agit de stockage objet, géré depuis les serveurs R640 par le système Ring de Scality. L’intérêt de Ring est d’être particulièrement adapté au cas d’usage de Molotov : il est le système qui souffre de la latence la moins importante dans un contexte où les écritures sont plus nombreuses que les lectures. En effet, Molotov se doit d’emmagasiner en permanence les flux de toutes les chaînes, dans tous les formats, mais les téléspectateurs ne les consomment pas tous systématiquement. Les lectures sont uniquement les flux à renvoyer vers les CDNs.
« Ajoutons que Scality Ring nous permet de perdre jusqu’à 30 % des JBODs sans perdre de données. Pour optimiser notre stockage, nous ne faisons pas de déduplication. En revanche, nous devons reconstruire régulièrement l’index de Scality », indique Alexandre Ouicher. Il se refuse à entrer dans les détails, mais explique que, pour limiter l’explosion des données du fait d’utilisateurs qui ne font pas le ménage dans les vidéos qu’ils souhaitent conserver, l’équipe de Molotov réorganise, voire ré-encode les fichiers les plus anciens.
Youbora, Datadog, ELK, Grafana et des scripts Python pour éviter les incidents
L’infrastructure de Molotov est surveillée de plusieurs façons. Il y a d’abord un monitoring métier avec la console spécialisée dans les flux vidéos Youbora, laquelle est capable de faire le lien entre l’activité du datacenter et l’expérience utilisateur. Les applications qui s’exécutent étant conçues comme des microservices, leur charge est indiquée par Datadog. Ensuite, tous les indicateurs métiers et techniques, logs systèmes compris, sont croisés au sein d’une plateforme ELK d’Elastic. L’ensemble est visualisé par l’équipe technique depuis l’environnement graphique et Open source Grafana.
Si un écueil technique se fait jour, l’équipe de techniciens s’efforce d’écrire des scripts Python qui permettront de l’éviter à l’avenir. Parmi les écueils ainsi traités, Molotov cite l’expiration chronique des certificats SSL.
Grâce à cette surveillance des services, la sécurité naturelle du stockage objet et la qualité des matériels, Molotov n’aurait, depuis 2016, jamais connu de panne. « Les seuls problèmes notables dont nous avons souffert sont des incidents réseaux du côté Internet. Mais cela n’a jamais été catastrophique, car tout passe par les CDNs », dit Alexandre Ouicher.
Selon lui, l’infrastructure de Molotov ne pose pas de difficulté d’administration. Iguane Solutions effectue les gestes de proximité, principalement l’ajout régulier de ressources, car les machines sont hébergées dans son datacenter. Molotov s’occupe des opérations d’administration système. Parmi celles-ci, la charge de la sauvegarde est allégée au regard de la taille des données en production. Et pour cause : seules les bases de données liées à l’activité des utilisateurs et au catalogue des émissions disponible sont protégées. Le reste du stockage – les vidéos – est par nature une sauvegarde.
Pour approfondir sur Continuité d’activité, Sécurité physique
