Mediakwest : Pouvez-vous nous détailler les raisons de la création de Quortex ?
Jérôme Viéron : Avec les trois autres fondateurs, Marc Baillavoine, Thierry Trolez et Julien Villeret, nous sommes partis d’un constat très simple. Tous les grands acteurs de l’IT migrent leurs systèmes informatiques dans le cloud. Il y a un secteur où cette tendance reste timide, c’est celui du broadcast.
Nous pensons que cela est dû au fait que les diffuseurs ont voulu transférer directement les workflows et leurs applicatifs qui tournaient sur leurs équipements On Premise (sur site) à l’identique sur des machines virtuelles dans le cloud. Hélas les économies annoncées n’étaient pas au rendez-vous. Un soft monolithique qui tourne dans le cloud coûte plus cher que son usage en interne. D’autre part un encodeur software n’a pas un fonctionnement linéaire. Il consommera 10 % de la ressource machine pour un profil ; si on passe à deux traitements, ce sera 30 % et parfois avec trois profils on risque d’atteindre 90 %. Par sécurité on dimensionne largement la capacité CPU, ce qui augmente d’autant la facture totale sans réellement l’exploiter.
La diffusion OTT exige aussi de démultiplier les versions d’un même contenu pour tenir compte des profils adaptés à chaque catégorie de terminaux, avec des codecs potentiellement différents, des débits variables selon les modes d’accès et aussi un packaging distinct, HLS pour Apple ou bien Dash pour le web ou Windows. Il n’est pas rare de préparer le contenu dans trente versions distinctes, et donc toujours plus de stockage à la fois dans le système de diffusion et dans les CDN (Content Delivery Network). Beaucoup de ces versions ne seront même pas consultées.
Sur certains catalogues de VOD en France, moins de 10 % des contenus dupliqués sont réellement regardés. Avec nos solutions, nous souhaitons ne mettre en ligne que ce qui est vraiment regardé, en profitant au maximum des potentialités techniques apportées par les services de cloud, avec des développements basés sur les microservices fonctionnant en mode sans état ou « stateless » et en exploitant des machines préemptives.
M. : Comment avez-vous adapté ces outils au monde de la vidéo ?
J.V. : Tous nos workflows sont découpés en tâches élémentaires : adaptation de la résolution, compression, sous-titrage, packaging… Pour chacune d’elles, nous créons des microservices que nous développons nous-mêmes ou en reprenant des outils disponibles sur le marché. Le principe de tous nos workflows est le suivant : le fichier vidéo est découpé en « chunks » (tronçons) ou segments de 2, 4 ou 6 secondes. Chacun est traité à chaque étape du WF par un microservice indépendant lancé en mode « stateless ».
Comme c’est un service web, cela permet de le lancer sur n’importe quelle machine, juste à côté ou à l’autre bout du monde, et sur n’importe quel OS ou dans un environnement distinct. Comme il fonctionne en mode « stateless », une requête avec les paramètres nécessaires est envoyée au microservice qui va lancer les ressources nécessaires pour exécuter la tâche qui lui a été affectée. Quand il l’a terminée, il renvoie un message de bonne fin pour enchaîner l’étape suivante du workflow avec un autre microservice. Chaque microservice réalise juste la tâche dont il est chargé et disparaît après.
Avec le mode « stateless », similaire à celui des requêtes http lancées par un navigateur web, le microservice ne renvoie qu’une réponse de bonne exécution sans aucune information sur le déroulement de la tâche ou son environnement de travail. Si le volume des tâches à exécuter augmente soudainement, on peut lancer autant de microservices que nécessaire sans craindre un engorgement, comme dans le cas des applications traditionnelles qui fonctionnent en mode « stateful ». Cela nous offre une scalabilité (ou évolutivité) beaucoup plus facile à gérer. Si on a besoin du même microservice, on le relance à nouveau avec un reset complet et on repart sur des bases saines.
M. : Vous y associez aussi l’intelligence artificielle (IA) et le deep learning.
J.V. : Notre objectif, c’est d’utiliser de manière optimale les ressources offertes par le cloud. L’IA et le deep learning nous servent à apprendre le comportement de nos microservices et en particulier des encodeurs par rapport au contenu. Ainsi, lors des futurs traitements, nous pourrons optimiser le paramétrage de nos outils et améliorer le « load balancing » entre toutes les fonctions : encodage, sous-titrage, packaging, etc. Nous ne le faisons pas en live, mais nous améliorons nos modèles au fur et à mesure lors des mises à jour.
Comme je l’ai expliqué au début, actuellement les plates-formes de diffusion multiplient les versions d’un même programme qu’elles poussent ensuite vers les CDN. Nous préconisons de faire l’inverse et de travailler en mode « pull ». C’est au moment où un spectateur demande une version particulière que nous préparons à la volée la copie du contenu selon les spécifications de son terminal. Le workflow ne se met en route que quand quelqu’un en fait la demande. Si une version d’un programme n’est pas demandée, aucune ressource n’est consommée, ni facturée. Ainsi nous ne préparons que les copies qui sont réellement demandées en mode « just in time ».
M. : Mais cela ne provoque-t-il pas un temps d’attente plus long ?
J.V. : Tout le monde nous pose la question. De manière générale aujourd’hui, sur n’importe quel système, la latence reste dans les mêmes ordres de grandeur. Nous sommes même capables de faire de l’ultra low latency et de diffuser en CMAF (Common Media Application Format). Il n’y a pas d’impact sur la latence et nos solutions offrent des performances du même ordre que les systèmes traditionnels.
M. : Pourquoi votre stratégie, basée entièrement sur le cloud, serait-elle plus économique ?
J.V. : Le ticket d’entrée pour aller sur le cloud n’est pas négligeable et c’est pourquoi les diffuseurs n’y vont pas aussi vite qu’annoncé. Nous pensons aussi que c’est parce que les utilisateurs portent leurs applicatifs monolithiques tels que sur des machines virtuelles. Le coût reste élevé parce qu’il y a du gâchis de ressources machines. Nos workflows reviennent moins chers car nous optimisons les ressources au sens CPU et que nous utilisons aussi des machines préemptives.
Tous les fournisseurs de cloud cherchent à optimiser leurs outils en termes de ressources et d’énergie. Pour cela ils proposent des machines quatre à dix fois moins coûteuses, mais qui en contrepartie peuvent « tomber » ou être stoppées à tout moment. Selon les fournisseurs, ce mode de fonctionnement a des dénominations différentes (Preemptible VM chez Google, Azure Low Priority pour Microsoft ou encore Spot Instances chez AWS) et avec des règles de suspension et de remise en route assez variables. C’est moins robuste qu’une VM classique, mais pour des applications bureautiques ou de gestion, cela est moins critique.
Dans le domaine du streaming, c’est plus problématique, mais avec nos solutions basées sur des microservices en mode « stateless », en cas d’interruption, les tâches accomplies sur une machine qui « tombe » sont très vite redistribuées sur une autre ou sur un cluster distinct. Quand une machine « tombe », on ne s’en rend pas compte.
Notre solution par construction est non seulement plus robuste, mais elle coûte beaucoup moins cher quand on choisit de la faire tourner sur du préemptif. En plus elle est parfaitement « scalable » (évolutive et élastique) car nous pouvons déporter un traitement sur un autre cluster, ou répartir le travail entre un système On Premise (sur site) et appeler les services cloud en complément. Il est également possible de jouer sur la répartition multizones et multirégions d’Amazon par exemple et de profiter des charges de travail variables en jouant sur les décalages horaires.
M. : Tous ces gains de performances et ces optimisations portent uniquement sur la partie diffusion. Sur les CDN vous ne pouvez pas intervenir ?
J.V. : Aujourd’hui, ce qui coûte cher c’est la partie CDN car la facture totale dépend du débit de sortie, du nombre de consultations et aussi du nombre de versions stockées en cache. Contrairement à l’hertzien, plus un programme a du succès sur Internet, plus sa diffusion coûte cher. D’autre part si le service de streaming prépare ses contenus dans le cloud, il paie pour la sortie des contenus de la plate-forme pour les envoyer au CDN. Donc il paie deux fois, et ça, c’est aussi un frein pour aller dans le cloud. Il préfère donc rester sur ses propres installations. Mais la situation est en train de changer. Les fournisseurs de cloud montent leurs propres services de CDN, comme Microsoft Azure, Google ou AWS avec Cloud Front.
Nous pensons chez Quortex que les deux fonctions, plate-forme de streaming et CDN, vont se fondre en une seule, ce qui réduira le coût du double transfert. Notre solution est déjà conçue pour fonctionner comme cela et permet d’anticiper cette évolution et de s’approcher de l’utilisateur avec le mode « edge ». Cela facilite aussi les traitements en étant beaucoup plus proche de l’utilisateur final, de ses demandes et de tenir compte des particularités locales. Avec un lien direct entre la diffusion et le CDN, il devient possible d’affecter plus de ressources pour l’encodage et la préparation des contenus et, du coup, de réduire les débits avec un facteur d’économie plus fort sur le segment du CDN.
POSTFACE
Récemment, les travaux de Quortex ont été récompensés lors du 21e concours d’innovation I-Lab. Au printemps, le groupe M6 a choisi les workflows de Quortex pour sa plate-forme de streaming et en particulier 6Play. Les équipes de Quortex seront présentes à l’IBC 2019.
Article paru pour la première fois dans Mediakwest #33, dans le cadre de notre dossier « Les nouvelles architectures des chaînes de télévision », p.58/60. Abonnez-vous à Mediakwest (5 numéros/an + 1 Hors-Série « Guide du tournage ») pour accéder, dès leur sortie, à nos articles dans leur intégralité.
