Approche sans serveur pour le développement rapide d'un service vidéo fonctionnel

Je travaille dans l'externalisation, où le principe principal peut être décrit avec la phrase "vendez beaucoup, faites-le vite". Plus nous faisons vite, plus nous gagnons. Et, il est souhaitable que tout ne fonctionne pas avec des béquilles et de la morve, mais avec un niveau de qualité acceptable. Je raconterai mon expérience quand en peu de temps il a fallu développer un service promotionnel.

Compte tenu: compte root sur AWS, aucune restriction sur le choix de la pile technologique, un back-end et un mois pour le développement.

Objectif: mettre en place un service promotionnel où les utilisateurs mettent en ligne de une à quatre vidéos d'une durée de une à quatre secondes, qui sont ensuite intégrées dans la séquence vidéo d'origine. Autrement dit, nous remplaçons des fragments de la vidéo d'origine (économiseur d'écran de série) par des fragments personnalisés. Fonction Killer - la possibilité d'envoyer votre nom, qui sous la forme d'un beau texte recouvre le fragment vidéo correspondant. De plus, l'utilisateur peut télécharger une vidéo de 4 à 30 secondes, et du côté service, elle sera coupée à 4 secondes.

Solution

Écrire votre service de vélo dans un délai si serré est une idée. De plus, pour que le service puisse faire face aux charges et à tous ceux qui souhaitent recevoir la vidéo convoitée, l'infrastructure sera nécessaire. Et de préférence pas avec une étiquette de prix de l'avion. Par conséquent, nous nous concentrons immédiatement sur des solutions prêtes à l'emploi avec une personnalisation minimale.

La solution standard pour travailler avec la vidéo est FFmpeg, un utilitaire de console multiplateforme qui, grâce à des arguments, vous permet de découper et de superposer le son. La petite chose est d'écrire un wrapper et de le mettre en pratique. Nous écrivons un prototype qui rassemble deux vidéos, et ... le plaisir commence. La bibliothèque sur .NET Core 2 devrait tourner sur n'importe quelle machine virtuelle, nous prenons donc l'instance AWS EC2 et tout fonctionnera


FFmpeg, bien que cela simplifie la tâche, mais pour une solution vraiment fonctionnelle, vous devez créer une instance EC2, concevoir une infrastructure réseau pour elle, y compris l'équilibreur de charge. La tâche simple de déploiement à partir de zéro est «un peu» compliquée et l'infrastructure commence à exiger de l'argent immédiatement - le montant pour l'exécution est retiré du compte du client toutes les heures.

Notre service n'implique pas de processus de longue durée, ne nécessite pas de base de données relationnelle volumineuse et audacieuse et s'intègre parfaitement dans l'architecture événementielle avec une chaîne d'appels de microservices. La solution se propose d'elle-même: nous pouvons abandonner EC2 et implémenter une véritable application sans serveur, comme le Image Resizer standard basé sur AWS Lambda.

Soit dit en passant, malgré l'aversion évidente des développeurs AWS pour .NET, ils prennent en charge .NET Core 2.1 en tant qu'exécution, ce qui offre une gamme complète d'opportunités de développement.

Et la cerise sur le gâteau - AWS fournit un service distinct pour travailler avec des fichiers vidéo - AWS Elemental MediaConvert.

L'essence du travail est incroyablement simple: nous prenons le lien S3 vers la vidéo sortante, via la console AWS, le SDK .NET ou tout simplement JSON, écrivons ce que nous voulons faire avec la vidéo et appelons le service. Il implémente lui-même les files d'attente pour le traitement des demandes entrantes, il décharge le résultat dans S3 et, surtout, génère un événement CloudWatch pour chaque changement d'état. Cela nous permet d'implémenter des déclencheurs lambda pour terminer le traitement vidéo.


La version finale de l'architecture ressemble à ceci

L'ensemble du backend est placé dans deux lambdas. Un autre concerne la rotation de vidéos verticales, car un tel travail ne peut pas être effectué en une seule fois.

La superposition de texte a été effectuée en rendant une image transparente à la volée conformément à la résolution vidéo. La bibliothèque SixLabors.ImageSharp est parfaite à cet effet, et les problèmes de fuite de mémoire contournent élégamment le cycle de vie lambda.

L'avant sous la forme d'une application SPA écrite en JS et compilée via pug sera placée dans le panier public S3. Pour télécharger les vidéos elles-mêmes, nous n'avons pas besoin de code de serveur - il suffit d'ouvrir les points de terminaison REST que S3 nous offre. La seule chose - n'oubliez pas de configurer les politiques et CORS.

Pièges

• AWS MediaConvert, pour une raison inconnue, n'impose le son qu'à chaque clip vidéo individuellement, et nous avons besoin d'une chanson fervente de tout l'économiseur d'écran.
• les vidéos verticales doivent être traitées séparément. AWS n'aime pas les bandes noires et place les rouleaux à 90 °.

Patinoire facile

Malgré la beauté de Stateless, vous devez garder une trace de ce qui doit être fait avec la vidéo: coller ou superposer le son sur une séquence vidéo déjà terminée. Heureusement, MediaConvert prend en charge le transfert de métadonnées via son Job, et nous pouvons toujours appliquer un indicateur simple comme «isMasterSoundJob», en analysant ces métadonnées à tout moment.

Sans serveur permet à NoOps de fonctionner correctement - une approche qui suppose la nécessité d'une équipe distincte responsable de l'infrastructure du projet. Par conséquent, c'était une petite affaire - nous déployons la solution sur AWS sans la participation des administrateurs système, qui ont toujours quelque chose à faire.
Et pour accélérer le tout, nous automatisons autant que possible le script de déploiement vers AWS CloudFormation, vous permettant de déployer un bouton directement à partir de VS. En conséquence, un fichier avec 200 lignes de code vous permet de déployer une solution prête à l'emploi, bien que la syntaxe CloudFormation puisse être choquante par habitude.

Total

Sans serveur n'est pas une panacée. Mais cela facilitera grandement la vie dans des situations à trois limites: "ressources limitées - peu de temps - peu d'argent".

Caractéristiques des applications adaptées à Serverless

• sans processus de longue durée. Hard Gateway API Gateway - 29 secondes, hard limit lambda - 15 minutes;
• décrit par l'architecture événementielle;
• se décompose en composants faiblement couplés par type de SOA;
• ne nécessite pas beaucoup de travail avec son état;
• écrit en .NET Core. Pour travailler avec .NET Framework, vous aurez toujours besoin d'au moins un Docker avec le runtime approprié.

Avantages d'une approche sans serveur

• réduit les coûts d'infrastructure;
• réduit le coût de livraison d'une solution;
• Évolutivité automatique
• développement à la pointe du progrès technologique.

Inconvénients, sur un exemple concret

• Suivi et journalisation distribués - partiellement résolus via AWS X-Ray et AWS CloudWatch;
• débogage gênant;
• Démarrage à froid en l'absence de charge;
• L'interface hostile à l'utilisateur AWS est un problème universel :)