Serverless-Ansatz für die schnelle Entwicklung eines Video-Services

Ich arbeite im Outsourcing, wo das Hauptprinzip mit dem Satz "Verkauf viel, mach schnell" beschrieben werden kann. Je schneller wir arbeiten, desto mehr verdienen wir. Dabei sollte alles stabil und von akzeptabler Qualität sein. Ich möchte von meinen Erfahrungen berichten, als es darum ging, einen Promo-Service in kurzer Zeit zu entwickeln.

Gegeben: Ein Root-Account bei AWS, keine Einschränkungen bei der Auswahl des Technologie-Stacks, ein Backend-Entwickler und ein Monat für die Entwicklung.

Aufgabe: Einen Promo-Service zu realisieren, bei dem Nutzer von einem bis zu vier Videos mit einer Länge von jeweils ein bis vier Sekunden hochladen, die dann in den Original-Videoinhalt eingebettet werden, ist die Aufgabe.

Lösung

Einen eigenen Service in so kurzer Zeit zu entwickeln, ist eine riskante Sache. Damit der Service die Last bewältigen kann und alle Interessierten ihr gewünschtes Video erhalten, benötigen wir die passende Infrastruktur. Und idealerweise sollte sie nicht mit einem Preis wie für ein Flugticket daherkommen. Daher orientieren wir uns sofort an fertigen Lösungen mit minimaler Anpassung.

Die Standardlösung für die Arbeit mit Videos ist FFmpeg, ein plattformübergreifendes Konsolen-Tool, das es ermöglicht, Videos zu schneiden und Tonspuren hinzuzufügen. Der nächste Schritt besteht darin, eine Wrapper-Anwendung zu erstellen und diese zum Leben zu erwecken. Wir entwickeln einen Prototyp, der zwei Videos zusammenfügt, und dann beginnt das eigentliche Abenteuer. Die Bibliothek läuft auf .NET Core 2 und muss in jeder virtuellen Maschine funktionieren, also nehmen wir eine AWS EC2-Instanz, und alles wird funktionieren.

Versteckter Textnein, es wird nicht funktionieren
.
Obwohl FFmpeg die Aufgabe erleichtert, ist es für eine wirklich funktionierende Lösung notwendig, eine EC2-Instanz zu erstellen und die Netzwerkinfrastruktur zu entwerfen, einschließlich eines Load Balancers. Die einfache Aufgabe, von Grund auf neu zu deployen, wird „ein wenig“ komplizierter, und die Infrastruktur beginnt sofort Geld zu kosten – jede Stunde wird ein Betrag vom Kundenkonto für die Laufzeit abgezogen.

Unser Service sieht keine langlaufenden Prozesse vor, erfordert keine umfangreiche und schwere relationale Datenbank und passt hervorragend in eine eventbasierte Architektur mit einer Kette von Microservices. Die Lösung liegt auf der Hand – wir können auf EC2 verzichten und eine echte serverless Anwendung realisieren, ähnlich den Standard-Image Resizern auf AWS Lambda.

Übrigens unterstützen die Entwickler von AWS trotz ihrer offensichtlichen Abneigung gegen .NET .NET Core 2.1 als Runtime, was eine vollständige Palette an Entwicklungsmöglichkeiten bietet.

Das Sahnehäubchen ist, dass AWS einen eigenen Dienst für die Verarbeitung von Videodateien bereitstellt – AWS Elemental MediaConvert.

Die Funktionsweise ist unglaublich einfach: Wir nehmen den S3-Link zum Ausgangsvideo, geben über die AWS Console, das .NET SDK oder einfach JSON an, was wir mit dem Video machen möchten, und rufen den Dienst auf. Er kümmert sich um die Verarbeitung der eingehenden Anfragen, lädt das Ergebnis selbst in S3 hoch und, was am wichtigsten ist, generiert für jede Statusänderung ein CloudWatch-Ereignis. Dies ermöglicht es uns, Lambda-Trigger für den Abschluss der Videoverarbeitung einzurichten.

So könnte die endgültige Architektur aussehen.

Der gesamte Backend-Bereich wird in zwei Lambdas untergebracht. Eine weitere dient der Rotation von vertikalen Videos, da diese Aufgabe nicht in einem Durchgang erledigt werden kann.

Die Front in Form einer SPA-Anwendung, die in JS geschrieben und über Pug kompiliert wurde, wird in einem öffentlichen S3-Bucket bereitgestellt. Zum Hochladen der Videos benötigen wir keinen serverseitigen Code — es reicht aus, die REST-Endpunkte zu öffnen, die uns S3 bietet. Einzig zu beachten ist, dass wir die Richtlinien und CORS konfigurieren müssen.

Herausforderungen

• Aus unerfindlichen Gründen fügt AWS MediaConvert den Ton nur zu jedem Videoabschnitt einzeln hinzu, während wir das gesamte fröhliche Lied aus dem Intro benötigen.
• Vertikale Videos müssen gesondert bearbeitet werden. AWS mag keine schwarzen Balken und dreht die Clips um 90°.

Einfache Lösung

Trotz der Schönheit von Stateless ist es notwendig zu verfolgen, was mit dem Video gemacht werden muss: ob es zusammengefügt oder der Ton über das bereits vorhandene Videomaterial gelegt werden soll. Glücklicherweise unterstützt MediaConvert die Übertragung von Metadaten über seine Jobs, und wir können immer einfach ein Flag wie „isMasterSoundJob“ anwenden, indem wir diese Metadaten zu jedem Zeitpunkt analysieren.

Serverless ermöglicht ein effektives NoOps-Arbeitsmodell, bei dem keine separate Infrastruktur-Teams erforderlich sind. Daher lag es nur noch an der Implementierung einer Lösung auf AWS, ohne dass Systemadministratoren, die immer beschäftigt sind, eingebunden werden müssen.
Um diesen Prozess zu beschleunigen, automatisieren wir das Deployment mit einem Skript über AWS CloudFormation, das ein Deployment auf Knopfdruck direkt aus Visual Studio ermöglicht. Am Ende ermöglicht eine 200-zeilige Datei die Bereitstellung einer vollständigen Lösung, obwohl die Syntax von CloudFormation anfangs schockierend sein kann.

Gesamt

Serverless ist keine universelle Lösung. Es erleichtert jedoch das Leben in Situationen mit drei Einschränkungen: „begrenzte Ressourcen – knappe Zeit – wenig Geld.“

Eigenschaften von Anwendungen, die für Serverless geeignet sind

• keine lang laufenden Prozesse. Harte Begrenzung des API Gateways – 29 Sekunden, harte Begrenzung der Lambda-Funktionen – 5 Minuten;
• wird durch eine ereignisgetriebene Architektur beschrieben;
• wird in lose gekoppelte Komponenten, ähnlich wie SOA, zerlegt;
• erfordert keine umfangreiche Arbeit mit dem eigenen Status;
• geschrieben in .NET Core. Für die Arbeit mit .NET Framework wird weiterhin mindestens Docker mit der entsprechenden Runtime benötigt.

Vorteile des Serverless-Ansatzes

• senkt die Infrastrukturkosten;
• senkt die Lieferkosten der Lösung;
• automatische Skalierbarkeit;
• Entwicklung an der Spitze des technischen Fortschritts.

Nachteile, am konkreten Beispiel

• Verteiltes Tracing und Logging – teilweise durch AWS X-Ray und AWS CloudWatch gelöst;
• umständliches Debugging;
• Cold Start bei fehlender Last;
• Benutzerunfreundliche AWS-Oberfläche – ein allgemeines Problem 🙂

Quelle: habr.com