Entwicklung komplexer Media-Workflows in der Cloud mit Amazon Web Services
Zur Kostenreduktion wird zunehmend nach Möglichkeiten gesucht, Media-Workflows von On-Premise-Installation in die Cloud zu verschieben, da hier die Notwendigkeit der Investition, Installation und Wartung von klassischer IT-Infrastruktur entfallen und nur On-Demand-Kosten entstehen. Die Amazon Web Services Cloud bietet dazu unter anderem fertige Medien-Services an. Diese Services sind jedoch nicht trivial zu konfigurieren, geschweige denn zu komplexen Workflows zu kombinieren. Das Produkt PORTAL bietet Lösungen für die Konfiguration und den Betrieb von komplexen Media-Workflows in der AWS Cloud. Es werden ausgewählte Workflows mit ihrer Infrastruktur, ihrer Konfiguration und Bedienung im Betrieb vorgestellt.
1 Vorstellung LOGIC
LOGIC ist ein deutsches Unternehmen für Systemarchitektur im Bereich der professionellen Bewegtbild-Verarbeitung. Neben dem Vertrieb von Hardware für Fernseh-Infrastruktur und Produktion, bewegt sich LOGIC hauptsächlich in den zwei Geschäftsfeldern der Migration von klassischen SDI-Infrastrukturen hin zu IP-basierten Infrastrukturen von öffentlich-rechtlichen und privaten Rundfunkanstalten, sowie die Entwicklung von Media-Workflows für Medienproduktionen in der Amazon Web Services (AWS) Cloud. LOGIC ist europaweit für die Beratung und den Verkauf von AWS zertifiziert. Darüber hinaus ist LOGIC in Deutschland von AWS für den öffentlichen Sektor zertifiziert und nimmt sich daher unter anderem Kunden des öffentlich-rechtlichen Rundfunks an. Seit 2018 bietet LOGIC das eigene Framework PORTAL an. Es vermittelt unter anderem Methoden für agiles Projektmanagement und bietet ein User-Interface zur simplen Fernsteuerung von mitunter komplexen Media-Workflows, die in der AWS Cloud betrieben werden.
2 Das PORTAL User-Interface zur Fernsteuerung von Media-Workflows in der AWS Cloud
PORTAL ist ein Javascript-basiertes User-Interface für Webbrowser, welches es Usern ermöglicht, komplexe Media-Workflows mit wenigen und übersichtlich angeordneten Bedienelementen zu steuern. Hierbei werden über das AWS Application Programming Interface (API)-Gateway, welches via RESTful- oder Websocket-APIs mit den APIs der einzelnen AWS Services kommuniziert, Befehle zum Erstellen, Veröffentlichen, Warten, Überwachen oder Sichern von Funktionen der entsprechenden Services können so abgesetzt bzw. Informationen empfangen werden. Die integrierte Benutzerverwaltung bedient sich des zentralen AWS Identity and Access Management (IAM)-Services und ermöglicht hier feingliedrige Zugriffskontrolle und Berechtigungen. Usern kann hierbei über verschiedene Rollen der für die Anwendung benötigte Zugriff ermöglicht bzw. eingeschränkt werden. Mit Hilfe von AWS Cognito können diese Funktionen nativ in Webanwendungen implementiert werden. Zusätzlich ermöglicht AWS Cognito die Einbindung von Single Sign On (SSO) mit OpenID Connect, damit man sich mit Zugangsdaten anderer Anbieter wie Microsoft, Github oder Facebook einloggen kann. Die einzelnen Media-Workflows sind in PORTAL als Module integriert und können nach Bedarf gebucht werden.
3 AWS Cloud-basierte Media-Workflows
Die AWS Cloud bietet viele Services, mit deren Hilfe man komplexe Media-Workflows entwickeln kann, ohne dabei alle Aspekte von Grund auf neu zu entwickeln – man kann sich auf die Entwicklung des Workflows konzentrieren. Im Folgenden werden einige, bei weitem nicht alle, Services vorgestellt, die bei der Entwicklung von Media-Workflows essentiell oder hilfreich sind. Diese Services werden redundant und für die Anwendung unsichtbar über mehrere AWS-Rechenzentren hinweg angeboten. Rechenzentren werden von AWS als Availability Zones (AZ) bezeichnet, wovon immer mindestens zwei pro AWS Region vorhanden sind.
3.1 Datenspeicherung
Eine der wichtigsten Ressourcen bei jedweder Art von IT-Anwendung ist die Speicherung von Daten. Dabei gibt es verschiedene Anforderungen. Eine Datenbank kommt zum Beispiel dann zum Einsatz, wenn verschiedene Datenpunkte zu einem Datensatz zusammengefasst werden sollen, der eine Verarbeitung durch eine unbestimmte Anzahl Instanzen, egal ob Mensch oder Maschine, ermöglichen soll. Dabei gilt eine Datenbank auch als persistenter Speicher, jedoch sind Datenbanken üblicherweise nicht für große Datenmengen vorgesehen, wie sie zum Beispiel bei Videodateien auftreten. Für solch große Datenmengen werden Block-Datenspeicher verwendet. Diese weisen einen größeren Datendurchsatz auf, sind allerdings nicht besonders gut geeignet, um viele parallele Ein- und Ausgabe-Operationen zu verarbeiten. In der konventionellen IT werden Festplatten, die in Servern betrieben werden und das Betriebssystem und dessen Konfiguration vorhalten, als persistent betrachtet. Dies ändert sich aber bei der Betrachtung von Cloud-Infrastrukturen. Cloud-Infrastrukturen verfolgen das Wegwerf-Konzept, d.h. dass Server-Systeme so geplant werden sollten, dass durch Terminierung und Provisionierung von Server-Systemen keine Datenverluste entstehen. Dieser Ansatz ist nötig, um eine große Skalierbarkeit zu erreichen. AWS stellt mit dem DynamoDB Service eine Serverless-NoSQL-Schlüssel-Wert-Datenbank zur Verfügung. Der Service bietet unter anderem Hochverfügbarkeit, integrierte Sicherheit, kontinuierliche Backups und automatische Replikation über mehrere Regionen hinweg. Als Massenspeicher bietet AWS den Simple Storage Service (S3) an. Hierbei handelt es sich nicht um einen Netzwerkspeicher im herkömmlichen Sinn, der auf Dateisystemen basiert, sondern um einen Objekt-Speicher. Auf den ersten Blick ist der Unterschied nicht evident, wird jedoch dann sichtbar, wenn man Watchfolder-Services entwickeln möchte. Denn anders als bei Dateisystemen kennt S3 keine Ordner-Strukturen, sondern benutzt das Konzept der Pre- und Suffixe, was bei der Entwicklung ein Umdenken erfordert. Für die Speicherung von Betriebssystemen und deren Konfiguration sind in der AWS Cloud Elastic Block Store (EBS) Laufwerke vorgesehen, die Partitionen auf SSD-Festplatten entsprechen und für die Verwendung in virtuellen Servern vorgesehen sind.
3.2 Netzwerk Services
Moderne IT-Anwendungen benötigen in den meisten Fällen eine Netzwerk-Infrastruktur, die die Kommunikation zwischen verschiedenen Teilsystemen ermöglicht. Der Virtual Private Cloud (VPC) AWS Service bietet die Möglichkeit, vollständige Netzwerk-Umgebungen zu erstellen, die in der Lage sind, über verschiedene AZs oder AWS-Regionen hinweg miteinander zu kommunizieren. Dabei werden bekannte klassische Netzwerk-Elemente wie Router, NAT Gateways oder Load Balancer zur Verfügung gestellt. Services können dadurch sowohl in privaten Subnetzen als auch im öffentlichen Internet bereitgestellt werden. Man kann solche Services mit Elastic-IP-Adressen, wobei es sich um öffentliche IP-Adressen aus dem AWS-Pool handelt, erreichbar machen und ebenfalls bei einem DNS-Registrar mit Hilfe von AWS Route 53 hinterlegen. Ein registrierter DNS-Eintrag ist auch eine Voraussetzung, um eine verschlüsselte Kommunikation über SSL/TLS bereitzustellen, was mit dem AWS Certificate Manager (ACM)-Service ermöglicht werden kann. Eine Auslieferung an viele Endgeräte kann über den AWS CloudFront-Service erfolgen. CloudFront ist ein Content-Delivery-Network (CDN)-Service von AWS.
3.3 Virtuelle Server mit AWS Elastic Compute Cloud
AWS Elastic Compute Cloud (EC2) bietet die Möglichkeit, virtuelle Server bereitzustellen. Die Art der Server-Anwendung ist hierbei irrelevant. EC2-Instanzen verfügen über mindestens ein EBS-Laufwerk und sind in VPCs untergebracht. Es werden ARM-, AMD- und Intel-Prozessoren mit unterschiedlicher Anzahl von CPU-Kernen und dazu passenden Arbeitsspeichergrößen angeboten, auf denen Linux, aber auch Windows-Betriebssysteme laufen können. Es können sogar Desktop-Betriebssysteme mit Unterstützung von Grafikkarten benutzt werden. Eine Netzwerkanbindung ist mit bis zu 400 GBit/s möglich. Diese Server-Instanzen werden entweder On-Demand oder für Dauerbetrieb gebucht.
3.4 Serverless Anwendungen
Ein weiterer Ansatz, um die Skalierbarkeit von Web-Services zu erhöhen, ist die Entwicklung von Serverless-Infrastrukturen. D.h. Server-Instanzen werden nicht explizit angelegt, stattdessen werden Services als Container ausgeführt und eine Logik innerhalb der Cloud wählt dann bei Bedarf die passenden Hardware-Ressourcen. Container, wie zum Beispiel Docker, sind beim Start immer wieder in einem initialen Zustand. Persistente Daten und Konfigurationen müssen von Speicherorten außerhalb des Containers bezogen werden. Neben vieler anderer Vorteile entfällt bei Containern die Notwendigkeit eines auf die Hardware abgestimmten Betriebssystems und sie können auf beliebigen Servern, sofern die CPU-Architektur übereinstimmt, ausgeführt werden. Web-Services, die auf diese Art angeboten werden, können auch als Infrastructure as Code (IaC) ausgeführt werden. Man kann also mit vorgefertigten Rezepten komplette Infrastrukturen aufsetzen. Dies ist im Prinzip auch mit Server-Anwendungen möglich, aber durch die erforderliche Hardware-Abstimmung komplexer. AWS bietet mit seinem Lambda-Service eine Lösung für kurzlebige Ausführungen an, mit dem die verschiedensten Aufgaben bearbeitet werden können. Es lassen sich durch bestimmte Auslöser anderer Services Lambda Ausführungen starten, die dann zum Beispiel einen Dateitransfer ausführen. Dieser Service wird nur On-Demand, mit stark eingeschränkten Ressourcen provisioniert und nach Beendigung wieder terminiert. Mit AWS CloudFormation kann man innerhalb der AWS Cloud-Infrastruktur als Code erzeugen und nach Bedarf Services provisionieren, ausführen, Fehler bei der Erzeugung abfangen und Infrastrukturen auch wieder terminieren.
3.5 Hilfreiche Werkzeuge
Neben den eigentlichen Services werden auch Werkzeuge benötigt, die dabei helfen Services innerhalb der AWS Cloud untereinander zu verbinden oder zu überwachen. Für eine Machine-to-Machine-Kommunikation bietet AWS den Simple Queue Service (SQS) und für Push-Benachrichtigungen an User den Simple Notification Service (SNS). Zur Überwachung von Services gibt es zum einen den Service CloudTrail und zum anderen den Service CloudWatch.
3.6 Media Services
Die wichtigsten im Folgenden kurz erläuterten Media Services umfassen:
AWS Elemental MediaConnect – Live-Stream Empfänger und Signalverteiler
AWS Elemental MediaLive – Echtzeit-Enkodierer für Live-Streams
AWS Elemental MediaPackage – Origin Server und Just-in-time Packager für Live Streams und VOD
AWS Elemental MediaConvert – File-to-File-Transcoder
Die ersten drei Services können für 24x7-Live-Streaming als auch für Live-Streams von Veranstaltungen (Events) nur zeitweise genutzt werden.
3.6.1 AWS Elemental MediaConnect
AWS Elemental MediaConnect (EMX) ist eine Art Signalverteiler, der verschiedene Live-Streaming-Protokolle versteht und in andere Protokolle übersetzen kann. Live-Streams können mit geringer Latenz komprimiert und unkomprimiert übertragen werden. Dabei können sich die Quellen und Senken sowohl innerhalb als auch außerhalb der AWS Cloud befinden. Für Endpunkte außerhalb der AWS Cloud ist die verfügbare Bandbreite dabei abhängig von der Anbindung an AWS – entweder über das öffentliche Internet oder über dedizierte Anbindungen von gemanagten Netzwerken. EMX kann weltweit sichere Verbindungen über das AWS-Backbone bereitstellen.
3.6.2 AWS Elemental MediaLive
AWS Elemental MediaLive (EML) kann aus dem zugelieferten Eingangssignal viele verschiedene Ausgangssignale in den gewünschten Auflösungen, Frame-, Bitraten und mit dem gewünschten Codec erzeugen. Dabei können auch die für die Auslieferung an Viewer gedachte adaptive Bitraten (ABR) Sets ausgegeben werden. ABR-Sets enthalten Video und Audio in verschiedenen Auflösungen und Bitraten. Damit ist es (mobilen) Endgeräten möglich, abhängig von der Empfangslage, ein Video ohne puffern und ruckeln zu empfangen und abzuspielen. MediaLive kann u. a. CDNs zuspielen (PUSH) oder andere Dienste als sogenannte Origin-Server nutzen. Das Eingangssignal kann von einem Kontributions-Encoder mit verschiedenen Protokollen direkt an EML gesendet werden oder vorher von EMX in ein unterstütztes Protokoll übersetzt werden.
3.6.3 AWS Elemental MediaPackage
AWS Elemental MediaPackage (EMP) ist ein Origin Server und Just-in-Time-Paketierer für Live-Streams und VOD mit Zusatzfunktionen. EMP kann ein ABR-Set von EML oder anderen Encodern als HLS ABR-Set empfangen und diesen optional gefiltert, verzögert, mit DRM versehen als Origin-Server u.a. im Format HLS oder MPEG-DASH für CDNs zum Abruf bereithalten. Es wird nur das ingestierte Format gespeichert und andere Formate werden Just-in-Time bei Abfrage erzeugt. Zudem ist es möglich, aus einem Live-Stream nur Ausschnitte zu exportieren und für VOD zu nutzen.
3.6.4 AWS Elemental MediaConvert
AWS Elemental MediaConvert (EMC) ist für dateibasiertes Transcoding vorgesehen und kann eine Vielzahl von Codecs mit verschiedensten Parametrisierungen en- und dekodieren. Der Service arbeitet in Jobs, die bestimmte Input-Files verarbeiten.
4 Beschreibung der Workflows
In den folgenden Abschnitten stellen wir zwei Workflows vor, mit denen eine redundante Zulieferung realisiert werden kann und Highlight-Clips aus Live-Streams erzeugt werden können.
4.1 Easystream
Das Blockschaltbild in Abbildung 1 zeigt den Aufbau der Cloud Infrastruktur für einen voll redundanten Live-Streaming Workflow ohne Single-Point-of-Failure. Es werden zwei Encoder On-Premise benötigt, deren Eingangssignale synchron sein sollten. Diese senden an je einen EMX-Flow in unterschiedlichen AZ. Das Protokoll SRT ist eines von mehreren möglichen Protokollen. Der EML-Channel besteht aus zwei redundanten Pipelines, die in unterschiedlichen AZs laufen und jeweils von einem EMX-Flow gespeist werden. Das Prozessing in der Cloud erfolgt also in unterschiedlichen Rechenzentren. Die Outputs der beiden EML-Pipelines speisen einen EMP-Kanal, der als Origin-Server dient und den Content zum Abruf bereithält. Der Content kann ausgeliefert werden, solange wenigstens einer der Eingänge einspeist. Damit sind folgende Havariefälle abgedeckt:
Ausfall eines On-Premise Encoder oder dessen Internetverbindung
Ausfall eines EMX Flows
Ausfall einer EML Pipeline
Fällt Encoder A aus, wird am Ende der Kette der Content von Encoder B ausgeliefert. Probleme mit Encoder A können währenddessen behoben werden. Ist Encoder A repariert und liefert wieder Content aus, wird weiterhin der Content von Encoder B ausgeliefert, falls zuerst Encoder B ausfiele natürlich umgekehrt.
Abbildung 2 zeigt eine Media-Pipeline, bei der die Ressourcen in der AWS Cloud nicht redundant sind und dadurch geringere Kosten verursachen. Jedoch ist eine Redundanz bei den On-Premise Encodern vorgesehen. Hier im Beispiel wird das Protokoll RIST (Reliable Internet Streaming) verwendet. Bei diesem Protokoll ist es im EMX-Flow möglich, eine zweite Quelle als Backup der ersten anzugeben. Weitere Möglichkeiten der Redundanz am Eingang von EML durch ein sogenanntes Input Failover Pair sind im User Guide (https://docs.aws.amazon.com/medialive/ latest/ug/automatic-input-failover.html) beschrieben. Die Media-Pipeline wird noch einfacher, indem On-Premise AWS Elemental LINK HD bzw. UHD verwendet werden. Der Betrieb von Elemental LINK vor-Ort erfordert lediglich Strom, eine Internetverbindung mit einer Datenrate, die die Qualität der Videoübertragung nicht zu stark einschränkt, und einer SDI- oder HDMI-Signalquelle. Zwecks Redundanz kann man auch zwei Elemental-LINK-Geräte logisch zu einem Eingangssignal für einen Standard-EML-Kanal zusammenfassen. Das UI von PORTAL ist bewusst schlicht gehalten, um die Handhabung von komplexen Workflows einfach bedienbar zu machen. PORTAL.easystream gibt dem Benutzer ein einfaches UI zum Starten und Stoppen der Media-Pipeline für Live-Streaming. Beim Start oder Stopp der Pipeline aus dem UI werden beide EMX-Flows und der EML-Channel gestartet bzw. gestoppt. In EMP wird der Abruf des Content aktiviert bzw. deaktiviert. Starten und Stoppen ist sehr wichtig, da der Hauptanteil der Kosten während der Laufzeit der Media-Pipeline anfällt. Sobald die Media-Pipeline läuft, kann man das Ausgangssignal sehen. In der aktuellen Version bietet PORTAL.easystream die Möglichkeit, mit einem Elemental-LINK oder einem SRT-Encoder als Quelle die Pipeline zu bauen und den Output zu erzeugen. Die Handhabung unterscheidet sich etwas, da man dem SRT-Encoder noch den Entrypoint und gegebenenfalls die Video- und Audio-PIDs des MPEG-Transportstroms mitgeben muss. Um sicherzustellen, dass sich nur gewünschte Encoder mit EMX verbindet, ist es ratsam, im UI den IP-Adressbereich der Encoder in einer Whitelist einzutragen. Der ElementalLINK hingegen wird direkt mit dem EML-Channel verknüpft und bedarf keiner weiteren Einstellungen. Sind die Einstellungen einmal gemacht, kann jeder Operator die Media-Pipeline aus dem UI starten und stoppen.
Sobald die Pipeline läuft, kann das Signal in PORTAL abgerufen und auf Ton- und Bildqualität geprüft werden.
4.2 Clip und Multiclip
Das Blockschaltbild in Abbildung 4 zeigt den Aufbau der Cloud-Infrastruktur für einen Workflow, der aus mehreren Live-Streams Highlight-Clips erstellen und diese zum Beispiel NLE-Schnitt-Systemen oder VOD-Plattformen zur Verfügung stellen kann.
Im UI in Abbildung 5 markiert ein User, unter anderem mit Hilfe der Zeitanzeige, IN und OUT eines Ausschnitts, benennt und exportiert diesen und alle weiteren gewünschten Ausschnitte. Diese Assets werden dann automatisch den Adobe Premiere-Workstations in der AWS-Cloud, an denen die Cutter bereits an einer Zusammenfassung arbeiten, zur Verfügung gestellt.
Für den abgebildeten PORTAL.clip Workflow wird ein AWS Elemental-LINK oder ein SRT-Encoder genutzt, um ein SDI-Signal kodiert in die AWS-Cloud zu streamen. Beim Einsatz eines SRT-Encoders empfängt ein EMX-Flow als SRT-Listener das Signal des Encoders, der sich entsprechend im SRT-CallerMode befindet, in der AWS Cloud und leitet es an den EML-Channel weiter. Der EMX-Flow ist zwangsläufig als SRT-Listener und der Encoder als SRT-Caller konfiguriert. Über den Flow wird das Signal anschließend als Eingangssignal einem EML-Channel hinzugefügt. Ein Elemental-LINK liefert direkt das Eingangssignal für einen EML-Channel. Anders als der SRT-Encoder kann der Elemental-LINK-Encoder direkt als Eingangssignal für einen EML-Channel verwendet werden. EML enkodiert dann mit den eingestellten Parametern. Der hier vorgestellte Workflow benutzt einen EMP-Ausgang, um aus dem segmentierten LS-Stream Video-on-Demand-Clips als MPEG-Transportstrom mit dazugehöriger m3u8-Manifest-Datei zu erzeugen. Dafür muss der Operator innerhalb des UI nur zu der entsprechenden Stelle innerhalb des Streams springen und kann dort mit Hilfe der Mark-In- und Mark-Out-Buttons oder einer UTC-Timecode-Eingabe die Länge des Clips festlegen. In einem sogenannten Harvest-Job exportiert EMP die entsprechenden Segmentdateien aus dem Stream und speichert sie mit den Manifest-Dateien in einem S3-Bucket. Eine Lambda-Funktion fügt die einzelnen Segmente zu einem Clip zusammen und speichert diesen in einem weiteren S3-Bucket. Die NLE-Schnitt-Systeme sind auf einer EC2-Instanz installiert und der Benutzer greift von seinem lokalen Rechner per Fernzugriff mit geringer Latenz per NiceDCV darauf zu. Die 3rd-Party-Software Tiger Bridge kopiert die vorher zusammengefügten Clips vom S3-Bucket in den EBS-Speicher der EC2-Schnittplatzrechner und die Cutter können die Clips dann als Assets im Projekt ihres NLE-Schnitt-Systems nutzen.
Wenn mehrere Kameraperspektiven, wie es zum Beispiel bei Sportveranstaltungen üblich ist, zur Verfügung stehen, gibt es den in Abbildung 6 dargestellten PORTAL. multiclip-Workflow. Damit exportiert EMP die Ausschnitte von Mark IN bis Mark OUT aus bis zu sechs Signalen.
5 Fazit
Die Palette der von AWS angebotenen Dienste, vor allem auch der Helfer-Dienste, ermöglicht es, sehr versatile Workflows aufzusetzen. Dabei steigen der Komplexitätsgrad und damit auch der Entwicklungsaufwand erheblich, aber bringen auch den Vorteil, die Workflows als IaC ausrollen zu können. Die Nutzung der AWS-Services verursacht Kosten und insbesondere bei 24x7-Betrieb können diese erheblich sein. Das User-Interface PORTAL vereinfacht Starten und Stoppen der von LOGIC entwickelten Workflows, sodass die Ressourcen nicht überflüssig laufen müssen. Bisherige Anwender sehen automatische Zeitsteuerung als nicht erforderlich an, insbesondere ist das Ende des jeweiligen Events in der Regel variabel – ist halt Live.