VT2021 CDN fiche

Netflix Cosmos

• Guillaume Vacherias (guillaume.vacherias@etu.univ-grenoble-alpes.fr)
• Eric Herqué (eric.herque@etu.univ-grenoble-alpes.fr)

C'est quoi ?

Netflix Cosmos est une plateforme qui fournis des microservices avec des workflow asynchrone et des fonctions serverless.
workflow asynchrone
Utilisé pour séparer les requêtes d’une tâche. Implémentation : Un message-queue et un service qui lit les messages de cette queue et réagit à la requête associé.

serverless
Modèle de cloud qui permet au fournisseur de serveur d’allouer dynamiquement des ressources selon la demande du client. Les développeurs d’application serverless n’auront pas à gérer les configurations, fault tolerance, VM, mémoire physique… Lorsque l’application n’est pas utilisé les ressources sont automatiquement désalloué.

Origine et objectif

Il existe plusieurs génération de plateforme qui précéde Netflix Cosmos.
1er génération
Un système permettant de traiter les media files provenant des partenaires et des studios de netflix. Il permet aux clients d’effectuer la lecture de ses fichiers sur tous les appareils.

2e génération
Ajout de la fonctionnalité de scalabilité (qualité vidéo…)

3e génération
Reloaded plateforme qui se focalise sur le traitement de vidéo/audio. Traitement est fait par pipeline. La plateforme est construite avec une architecture monolithic ce qui rend le déploiement de nouvelle fonctionnalités compliqué.

Architecture Monolitique VS Architecture Microservice

L'architecture monolitique ne permet pas la scalabilité de l'application. De plus, elle requiert beaucoup trop d'expertise sur la connaissance du code.
La solution au problème est donc de créer une nouvelle plateforme avec une architecture simialaire à l'architecture microservice. La plateforme est nommé Netflix Cosmos. Cosmos Plateform est basé sur le workflow-driven (une méthode d’approche qui permet de définir les besoins du système selon les évenements que le workflow client génére) et fourni des microservice médiacentrique.
Les principaux points que Cosmos veut couvrir sont :
- Observalibility : built-in, traving, monitoring ...
- Modularity : Fournir des fonctionnalités modulable (compile-time & run-time modularity)
- Productivity : Outil pour exécution de tests, générateur de code, interface de commande
- Deliery : Système de livraison continue.

Microservice VS Cosmos Service

Le service Cosmos est similaire à un microservice

Micorservice

Un microservice est une API avec un statless business logic qui s’ajuste selon le nombre de requête effecuté sur cette API. L’application est structuré de façon à regrouper plusieurs services. Chaque services ont leurs propre base de données et peuvent être déployer indépendament des autres. De plus tous les services peuvent communiquer entre eux.

Business logic
détermine comment les données sont créés, stockés et changé. Une couche qui permet les transactions avec la base de donnée.

Cosmos Service

Principe

Reprend le même concept de ségrégation entre données et dépendances du microservice mais rajoute d’autres étapes dont les fonctions serveless asynchrone.

L'image ci-dessous résume les différentes étapes du traitement de la requête d'encodage vidéo :

Les fonctions serveless asynchrone sont packagé dans des dockers images et chaque fonctions ont leurs propre dépendance binaire (exemple : debian packages).

Séparation entre plateforme et application

Le business logic est séparé entre la plateforme API et l’application. La plateforme API fourni une abstraction qui permet aux développeurs de ne pas se soucier des problèmes d’application en concurrence. Par exemple, le service de l’encodage de vidéo est séparer par 3 composant qui sont scale-agnostic: API, Workflow et Fonction. Chacun de ces composants sont gérés par des systèmes scale-aware sous jacents pour traiter les problèmes de parallélisme.

Ces 3 systèmes sous-jacent communiquent entre-eux de façon asynchrone via un message queue nommé TimeStone. Chaque système sous-jacent adresse une partie du service fournis ce qui facilite le déploiement en continue et la rédaction de tests.

Optimus

Prend en charge la couche API, qui permet le mapping entre les requêtes clients aux business logic

Plato

C'est une couche d’orchestration du workflow (Rule Engine). Un workflow rule continent un ensemble d’instruction du workflow qui permet d’exécuter les fonctions responsable au service demandé.

Plato est un framework qui permet au développeur de définir domain logic et orchestrer les différents services. Les développeurs d’un service défini les règles de leurs workflow écrit en EMIRAX (Domain Specific Language basé sur Apache Groovy). Un règle est composé de 4 parties :
- Statement : Prédicat
- Action : Action à exécuter. Lors de la phase Action les fonction de la couche Stratum vont être invoqués
- Reaction : Exécute la suite d’instruction après que la fonction de la couche Stratum ait fini son exécution
- Error : Handler lorsqu’une erreur est survenu pendant l’exécution d’un workflow

Cette couche facilite le déploiement d’un workflow, puisque le développeur suffit juste d’écrire et tester son code/règle en local puis ensuite déploie ce workflow rule sur le serveur Plato.

Stratum

Couche serverless regroupant les fonctions asynchrone d’un service spécifique. Exemple : Fonction d’encodage de vidéo

Couches de services

Cosmos prend en charge la décomposition et la superpostions de services. Cela permet d’obtenir une architecture modulable, permettant aux équipes de se concentrer sur leurs spécialités et de contrôler leurs APIs et leur release cycle. Dans Cosmos on retrouve les services d’inspection, d’audio, de texte ou encore de packaging. Ces services sont orchestrés grâce à des services de plus haut niveau. Le plus complexe d’entre eux est le service Tapas, qui assure le lancement sur la plateforme Netflix des ressources video chez les studios.

Quand un nouveau titre arrive d’un studio, cela va trigger le workflow Tapas, comme on peut le voir sur le schéma. Cela va orchestrer différentes requêtes pour performer des inspections, réaliser l’encodage vidéo (plusieurs resolutions/qualités), l’encodage audio (plusieurs qualités et codecs) et générer des sous-titres dans différents langages. En définitive, une simple requête Tapas peut résulter en une centaine de requêtes Cosmos. Le produit de ces requêtes est ensuite packagé pour répondre à différent formats de lecteurs (multiple player formats).

Cet exemple nous montre les répercussions d’une requête d’un service de haut niveau sur les services de bas niveau. En effet comme expliqué précédemment, une requête de haut niveau va résulter en différentes actions. Dans le cas ci-dessus, nous avons une requête qui a pris durée de 24 minutes pour être complétée. Cela est dû au fait qu’elle a nécessité une centaine d’actions impliquant 8 services Cosmos et 9 fonctions Stratum.

Exemple de services

Service d'encodage de vidéo

L’image ci-dessus est une capture d’écran de l’outil d’observabilité Nirvana, où nous pouvons observer en détail une requête dans Cosmos concernant le service d’encodage vidéo. On note différentes étapes :
1. Une API appelle la fonction encoder, incluant la source vidéo et la manière de procéder
2. Dans cet exemple, la vidéo est découpée en 31 morceaux, ce qui implique qu’il y a 31 fonctions d’encodages tournant en parallèle
3. Suite à cela la fonction d’assemblage est invoquée une fois
4. Ensuite c’est au tour de la fonction d’indexage
5. Fini en 8 minutes

Qualité vidéo Netflix à grande échelle

La mesure de la qualité vidéo à grande échelle est un composant important du streaming de Netflix. Ces mesures permettent de mener :
- optimisations de l’encodage vidéo
- comparaisons des codecs vidéo
- amélioration de la qualité d'expérience du client (QoE)

Pour cela, Netflix utilise la métrique VMAF (Video Multimethod Assessment Fusion), issue d’un projet Open-Source, pour mesurer la qualité vidéo à grande échelle.

Video quality as service (VQS)

VQS est un microservice dans Cosmos qui permet de calculer la qualité de la vidéo en streaming.

VQS prend en paramètres 2 vidéos (source, derivative) pour calculer et retourner la qualité perçu de la vidéo derivative.

Comme expliqué précédemment, VQS est un Cosmos Service donc on retrouve les 3 composant qui constitue ce service :

Couche API (Optimus)
L’API VQS est un point de relais qui permet l’envoie de la requête du calcule de VQS et la récupération de cette valeur :

Request measureQuality(Video source, video derivative);
VQS getQuality();

Couche workflow rules (Plato)
Elle définit les étapes de calcule pour la mesure de VQS.
1. Selon la longueur de la vidéo et du temps de latence, VQS workflow va séparer le calcule en chunks.
2. Chaque chunk correspond à un paramètre à envoyer à la couche Stratum pour que cette couche exécute le calcule.
3. Chaque chunk aura un score VMAF.
4. Tout les scores calculer de tous les chunks seront fusioné pour obtenir le mesure VQS.
5. Le résultat sera disponible avec la fonction getQuality().

Couche asynchronous function (Stratum)
Cette couche comporte 2 fonctions asynchrone pour la calcule de la mesure VQS :

VMAF computeChunkQuality(chunk c);
VQS assembleChunk(VMAF vmafC[]);

Illustration des étapes d'un Cosmos VQS :