Je travaille dans le domaine de l'externalisation, dont le principe de base peut être décrit par l'expression « vendez beaucoup, faites-le vite ». Plus nous le faisons vite, plus nous gagnerons. Et il est souhaitable que tout fonctionne non pas avec des béquilles et de la morve, mais avec un niveau de qualité acceptable. Je vais vous parler de mon expérience lorsqu'il a fallu développer un service promotionnel dans un court laps de temps.
donné: compte root sur AWS, aucune restriction sur le choix de la pile technologique, un backend et un mois pour le développement.
Tâche mettre en œuvre un service promotionnel permettant aux utilisateurs de télécharger une à quatre vidéos d'une durée d'une à quatre secondes, qui sont ensuite intégrées dans la série de vidéos originales.
décision
Créer votre propre service de vélos en si peu de temps n’est pas une bonne idée. De plus, pour que le service puisse faire face à la charge et que chacun reçoive la vidéo tant convoitée, une infrastructure sera nécessaire. Et de préférence pas avec le prix de l'avion. C’est pourquoi 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 couper et de superposer l'audio. Il ne reste plus qu'à écrire un wrapper et à lui donner vie. Nous écrivons un prototype qui assemble deux vidéos, et... le plaisir commence. La bibliothèque est basée sur .NET Core 2, elle doit fonctionner sur n'importe quelle machine virtuelle, on prend donc une instance AWS EC2 et tout fonctionnera
Texte masquénon, ça ne marchera pas
.
Bien que FFmpeg simplifie la tâche, pour une solution vraiment efficace, vous devez créer une instance EC2 et concevoir une infrastructure réseau pour celle-ci, y compris un équilibreur de charge. La simple tâche de déploiement à partir de zéro devient « un peu » plus compliquée et l'infrastructure commence immédiatement à demander de l'argent - chaque heure, le montant du temps d'exécution est retiré du compte client.
Notre service n'implique pas de processus de longue durée, ne nécessite pas de base de données relationnelle volumineuse et s'intègre parfaitement dans une architecture basée sur les événements avec une chaîne d'appels de microservices. La solution se suggère 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.
À propos, malgré l'aversion évidente des développeurs AWS pour .NET, ils prennent en charge .NET Core 2.1 comme environnement d'exécution, 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 un lien S3 vers la vidéo sortante, écrivons via la console AWS, le SDK .NET ou simplement JSON ce que nous voulons faire avec la vidéo et appelons le service. Il implémente lui-même des files d'attente pour traiter les demandes entrantes, télécharge le résultat sur S3 lui-même et, surtout, génère un événement CloudWatch pour chaque changement de statut. Cela nous permet d'implémenter des déclencheurs lambda pour terminer le traitement vidéo.
Voici à quoi ressemble l'architecture finale :
L'ensemble du backend est hébergé dans deux lambdas. Une autre solution concerne la rotation de vidéos verticales, car un tel travail ne peut pas être effectué en un seul passage.
Nous placerons le front sous la forme d'une application SPA écrite en JS et compilée via pug dans un bucket S3 public. Pour télécharger les vidéos elles-mêmes, nous n'avons besoin d'aucun code de serveur - il nous suffit d'ouvrir les points de terminaison REST que S3 nous fournit. La seule chose est de ne pas oublier de configurer les politiques et CORS.
Pièges
- AWS MediaConvert, pour une raison inconnue, n'applique le son qu'à chaque fragment vidéo séparément, mais nous avons besoin d'une chanson joyeuse de l'intégralité de l'économiseur d'écran.
- Les vidéos verticales doivent être traitées séparément. AWS n'aime pas les barres noires et met les rouleaux à 90°.
Patinoire facile
Malgré toute la beauté de Stateless, vous devez garder une trace de ce qui doit être fait avec la vidéo : coller ou ajouter de l'audio à la séquence vidéo terminée. Heureusement, MediaConvert prend en charge la transmission des métadonnées via ses Jobs, et nous pouvons toujours utiliser un simple indicateur du formulaire « isMasterSoundJob », analysant ces métadonnées à tout moment.
Le sans serveur permet parfaitement de travailler avec NoOps - une approche qui suppose qu'il n'est pas nécessaire d'avoir une équipe distincte responsable de l'infrastructure du projet. C'était donc une petite affaire : nous déployons la solution sur AWS sans la participation des administrateurs système, qui ont de toute façon toujours quelque chose à faire.
Et pour accélérer tout cela, nous automatisons autant que possible le script de déploiement sur AWS CloudFormation, vous permettant de déployer avec un seul bouton directement depuis VS. Du coup, un fichier de 200 lignes de code permet de déployer une solution toute faite, même si la syntaxe CloudFormation peut choquer si on n'y est pas habitué.
En tout
Le sans serveur n'est pas une panacée. Mais cela rendra la vie beaucoup plus facile dans des situations comportant trois limites : « ressources limitées – court terme – peu d’argent ».
Caractéristiques des applications adaptées au sans serveur
- sans processus de longue durée. La limite stricte d'API Gateway est de 29 secondes, la limite stricte lambda est de 5 minutes ;
- décrit par l'architecture Event-Driven ;
- se décompose en composants faiblement couplés comme SOA ;
- ne nécessite pas beaucoup de travail avec votre état ;
- écrit en .NET Core. Pour travailler avec le .NET Framework, vous aurez toujours besoin d'au moins Docker avec le runtime approprié.
Avantages de l'approche sans serveur
- réduit les coûts d'infrastructure;
- réduit le coût de livraison de la solution ;
- évolutivité automatique ;
- un développement à la pointe du progrès technologique.
Inconvénients, avec un exemple précis
- Traçage et journalisation distribués - partiellement résolus via AWS X-Ray et AWS CloudWatch ;
- débogage peu pratique ;
- Démarrage à froid lorsqu'il n'y a pas de charge ;
- L'interface hostile aux utilisateurs d'AWS est un problème universel :)
Source: habr.com