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 ?

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

Les 3 générations suivent une architecture monolithique.
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

C’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. 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.