Serverloser Ansatz für die schnelle Entwicklung eines funktionierenden Videodienstes

Ich arbeite im Outsourcing, wo das Grundprinzip mit dem Satz „Viel verkaufen, schnell machen“ beschrieben werden kann. Je schneller wir es tun, desto mehr werden wir verdienen. Und es ist wünschenswert, dass alles nicht auf Krücken und Rotz funktioniert, sondern in akzeptabler Qualität. Ich erzähle Ihnen von meinen Erfahrungen, als es darum ging, in kurzer Zeit einen Werbedienst zu entwickeln.

Mai: Root-Konto auf AWS, keine Einschränkungen bei der Wahl des Technologie-Stacks, ein Backend und einen Monat für die Entwicklung.

Problem: einen Werbedienst implementieren, bei dem Benutzer ein bis vier Videos mit einer Dauer von einer bis vier Sekunden hochladen, die dann in die Originalvideoserie eingebettet werden.

Lösung

In so kurzer Zeit einen eigenen Fahrradservice zu schreiben, ist keine gute Idee. Damit der Dienst der Belastung gewachsen ist und jeder das begehrte Video erhalten kann, ist darüber hinaus Infrastruktur erforderlich. Und am besten nicht mit dem Preisschild aus dem Flugzeug. Daher konzentrieren wir uns sofort auf vorgefertigte Lösungen mit minimaler Anpassung.

Die Standardlösung für die Arbeit mit Video ist FFmpeg, ein plattformübergreifendes Konsolendienstprogramm, mit dem Sie mithilfe von Argumenten Audio schneiden und überspielen können. Jetzt müssen Sie nur noch einen Wrapper schreiben und ihn zum Leben erwecken. Wir schreiben einen Prototyp, der zwei Videos zusammenfügt, und ... der Spaß beginnt. Die Bibliothek basiert auf .NET Core 2, sie sollte auf jeder virtuellen Maschine laufen, also nehmen wir eine AWS EC2-Instanz und alles wird funktionieren

Versteckter Textnein, das wird nicht funktionieren
.
Obwohl FFmpeg die Aufgabe vereinfacht, müssen Sie für eine wirklich funktionierende Lösung eine EC2-Instanz erstellen und eine Netzwerkinfrastruktur dafür entwerfen, einschließlich eines Load Balancers. Die einfache Aufgabe der Bereitstellung von Grund auf wird „etwas“ komplizierter und die Infrastruktur beginnt sofort, Geld zu verlangen – jede Stunde wird der Betrag für die Laufzeit vom Kundenkonto abgebucht.

Unser Service beinhaltet keine lang laufenden Prozesse, erfordert keine große und umfangreiche relationale Datenbank und passt perfekt in eine ereignisbasierte Architektur mit einer Kette von Microservice-Aufrufen. Die Lösung liegt auf der Hand: Wir können EC2 aufgeben und eine echte serverlose Anwendung implementieren, wie den standardmäßigen Image Resizer auf Basis von AWS Lambda.

Übrigens unterstützen AWS-Entwickler trotz der offensichtlichen Abneigung gegenüber .NET .NET Core 2.1 als Laufzeitumgebung, was eine breite Palette an Entwicklungsmöglichkeiten bietet.

Und das Sahnehäubchen: AWS bietet einen separaten Dienst für die Arbeit mit Videodateien an – AWS Elemental MediaConvert.

Der Kern der Arbeit ist unglaublich einfach: Wir nehmen einen S3-Link zum ausgehenden Video, schreiben über AWS Console, .NET SDK oder einfach JSON, was wir mit dem Video machen wollen und rufen den Dienst auf. Es selbst implementiert Warteschlangen zur Verarbeitung eingehender Anfragen, lädt das Ergebnis in S3 selbst hoch und generiert vor allem ein CloudWatch-Ereignis für jede Statusänderung. Dadurch können wir Lambda-Trigger implementieren, um die Videoverarbeitung abzuschließen.

So sieht die endgültige Architektur aus:

Das gesamte Backend ist in zwei Lambdas untergebracht. Eine andere Möglichkeit ist das Drehen vertikaler Videos, da diese Arbeit nicht in einem Durchgang erledigt werden kann.

Wir werden die Front in Form einer in JS geschriebenen und per pug kompilierten SPA-Anwendung in einem öffentlichen S3-Bucket platzieren. Um die Videos selbst herunterzuladen, benötigen wir keinen Servercode – wir müssen lediglich die REST-Endpunkte öffnen, die uns S3 bereitstellt. Vergessen Sie nur nicht, Richtlinien und CORS zu konfigurieren.

Fallstricke

• Aus unbekannten Gründen wendet AWS MediaConvert den Ton nur auf jedes Videofragment einzeln an, wir benötigen jedoch einen fröhlichen Song aus dem gesamten Bildschirmschoner.
• Vertikale Videos müssen separat verarbeitet werden. AWS mag keine schwarzen Balken und stellt die Rollen auf 90°.

Einfache Eislaufbahn

Trotz aller Schönheit von Stateless müssen Sie im Auge behalten, was mit dem Video gemacht werden muss: Kleben Sie die fertige Videosequenz zusammen oder fügen Sie Audio hinzu. Glücklicherweise unterstützt MediaConvert die Weitergabe von Metadaten über seine Jobs, und wir können jederzeit ein einfaches Flag der Form „isMasterSoundJob“ verwenden, um diese Metadaten jederzeit zu analysieren.

Serverless ermöglicht perfekt die Arbeit mit NoOps – ein Ansatz, der davon ausgeht, dass kein separates Team für die Projektinfrastruktur verantwortlich ist. Daher war es eine Kleinigkeit – wir stellen die Lösung auf AWS bereit, ohne die Beteiligung von Systemadministratoren, die sowieso immer etwas zu tun haben.
Und um dies alles zu beschleunigen, automatisieren wir das Bereitstellungsskript so weit wie möglich auf AWS CloudFormation, sodass Sie die Bereitstellung mit einem Knopfdruck direkt von VS aus durchführen können. Dadurch können Sie mit einer Datei mit 200 Codezeilen eine fertige Lösung einführen, obwohl die CloudFormation-Syntax schockierend sein kann, wenn Sie damit nicht vertraut sind.

Insgesamt

Serverlos ist kein Allheilmittel. Aber es wird das Leben in Situationen mit drei Grenzen viel einfacher machen: „begrenzte Ressourcen – kurzfristig – wenig Geld“.

Merkmale von Anwendungen, die für Serverless geeignet sind

• ohne lang laufende Prozesse. Das harte Limit für API Gateway beträgt 29 Sekunden, das harte Limit für Lambda beträgt 5 Minuten.
• beschrieben durch ereignisgesteuerte Architektur;
• zerfällt in lose gekoppelte Komponenten wie SOA;
• erfordert nicht viel Arbeit mit Ihrer Erkrankung;
• geschrieben in .NET Core. Um mit dem .NET Framework arbeiten zu können, benötigen Sie weiterhin mindestens Docker mit der entsprechenden Runtime.

Vorteile des serverlosen Ansatzes

• reduziert die Infrastrukturkosten;
• reduziert die Kosten für die Bereitstellung der Lösung;
• automatische Skalierbarkeit;
• Entwicklung auf dem neuesten Stand des technischen Fortschritts.

Nachteile, mit einem konkreten Beispiel

• Verteilte Ablaufverfolgung und Protokollierung – teilweise gelöst durch AWS X-Ray und AWS CloudWatch;
• unbequemes Debuggen;
• Kaltstart ohne Last;
• Die benutzerfeindliche Schnittstelle von AWS ist ein universelles Problem :)

Source: habr.com