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.

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