denisovd - Fotolia

Landau-Symbole für das Video Encoding mit AWS High Performance Computing nutzen

Die Idee des ereignisgesteuerten Computings ist im Kontext von AWS sehr mächtig. Das Beispiel Video Encoding zeigt, wie Sie dabei vorgehen können.

Es gibt zwei Dinge, an die IT-Profis bei High Performance Computing denken: Verfügbarkeit und Skalierbarkeit (Geschwindigkeit). Skalierbarkeit gewährleistet, dass eine Architektur eine zu- oder abnehmende Anzahl von Anforderungen bearbeiten kann, ohne an Geschwindigkeit einzubüßen.

Wenn Sie mit High Performance Computing (HPC) vertraut sind, sind Sie wahrscheinlich auch mit Landau-Symbolen beziehungsweise dem O-Symbol (O(n)) vertraut. Das O-Symbol wird in der Informatik zur Beschreibung der Komplexität und damit der Laufzeit eines Algorithmus verwendet. Eingeführt wurde das Symbol durch den deutschen Mathematiker Paul Bachmann im Jahr 1894 in seinem Buch Analytische Zahlentheorie. Später machte der Zahlentheoretiker Edmund Landau davon Gebrauch, weshalb das O-Symbol auch als Landau-Symbol bezeichnet wird.

O(n) wurde ursprünglich in der Informatik genutzt, um die Geschwindigkeit eines Algorithmus bei der Verarbeitung von großen Datenmengen zu bestimmen. In Wirklichkeit ignoriert O(n) die tatsächliche Zeit, die ein Algorithmus oder eine Funktion für seine Ausführung braucht. Stattdessen konzentriert O(n) sich darauf, wie viele Iterationen in einem Datensatz benötigt werden, um die Ergebnisse zu berechnen.

Beispielsweise deutet eine Funktion wie diese dem Entwickler an, dass er die effizienteste Version hat:

for each X

 do Y

done

Aber nicht alle Versionen sind so effizient:

for each X as a

 for each X as b

   do a*b

 done

done

In dem obigen Beispiel iteriert der Code nun über jedes Element in der äußeren Schleife jedes Element in der inneren Schleife, so dass daraus O(n*n) oder O(n2) wird. Dies ist die absolut schlechteste Art, Daten zu verarbeiten, da die Zeit für die Berechnung exponentiell zunimmt.

Das O-Symbol und Parallelverarbeitung

Wenn Entwickler anfangen, mit mehreren Prozessen und Berechnungsinstanzen zu arbeiten, erkennen sie meist auch, wie man einen komplexen Algorithmus aufbrechen kann, was in einer traditionellen Umgebung nicht viel Sinn macht. Nehmen wir zum Beispiel den ursprünglichen Algorithmus, der im Wesentlichen über jedes Element für jedes Element in unserem Datensatz läuft:

for each X as a

 do proc(a)

done

 

// Teile proc (a) in einen neuen Prozess auf,

// der parallel ausgeführt werden kann

 

proc(a):

 for each X as b

 do a*b

done

 

Plötzlich gibt es zwei Algorithmen – beide mit O(n), was die ideale O-Notation ist. Wenn es jedem "proc(a)" Call erlaubt ist, asynchron zu laufen, indem man diese Calls abspaltet und auf einer eigenen Recheninstanz laufen lässt, kann man den Prozess effektiv parallelisieren und den expontiellen Zeit- und Ressourenverbrauch in der Gesamtverarbeitung reduzieren.

AWS HPC mit O(n) und Video-Kodierung

Nach der Ermittlung potenzieller Verarbeitungsbereiche, bei denen Parallelisierung helfen kann, den Gesamtdurchsatz zu erhöhen, schauen wir uns ein reales Beispiel an.

Eine häufige Verwendung für die Amazon Web Services (AWS) ist die Videoverarbeitung. Video Encoding ist heute wesentlich relevanter als früher als AWS mit dem Cloud-Geschäft begann. Heute haben wir, anders als von einigen Jahren, Dutzende von verschiedenen Gerätearten: Desktop-PCs, TV-Geräte, Tablets, Smartphones und viele mehr.

Diese Geräte machen es komplizierter, mit verschiedenen Dateiformaten zu arbeiten. Entwickler müssen heute mit verschiedenen Bandbreiten für unterschiedliche Typen von Netzwerkverbindung, die in AWS High Performance Computing (HPC) eine Rolle spielen, umgehen. Wenn zum Beispiel ein Endnutzer über eine Datenverbindung von 50 Mbps verfügt, kann er leicht ein Video mit 4K-Auflösung streamen. Hat er aber nur eine Mobilfunkverbindung, ist eine niedrigere Auflösung angebracht.

Nehmen wir nun an, ein Entwickler lädt ein Full-4K-Video hoch, und er möchte es in zehn verschiedene Videoformate oder Qualitätsstufen kodieren. Der Algorithmus, der dies ermöglicht, würde in etwa so aussehen:

for each video

 for each format

  encode(video, format)

 done

done

 

Wenn der Entwickler zehn verschiedene Formate hat, würde die O-Notation O(10n) sein. Das ist zweifellos nicht schlecht, aber es wäre besser, die Bearbeitung aufzuspalten und jeden Kodierungsschritt parallel abzuarbeiten:

for each video

  encode_all(video)

done

encode_all(video):

 for each format

   encode(video, format)

 done

 

Dieser Algorithmus reduziert nicht nur das gesamte O-Symbol und die Geschwindigkeit der Verarbeitung, der Entwickler kann auch leicht neue Dateiformate hinzufügen, indem er den "encode_all" Trigger einfach entsprechend ergänzt. Möchte der Entwickler dies für AWS HPC ausbauen, kann er einen Amazon Simple Notification Service (SNS) verwenden, um Ereignisse bekannt zu machen, wenn ein neues Video kodiert werden muss. Dies ermöglicht es dann Endanwendern, den Dienst zu abonnieren. Der Entwickler kann damit neue Kodierungsarten nach Bedarf hinzufügen, ohne vorhandenen Code modifizieren zu müssen.

Diese Idee des ereignisgesteuerten Computing ist im Kontext von AWS sehr mächtig, es ähnelt dem Beobachter-Muster im traditionellen Computing. Werfen wir nun einen Blick darauf, wie diese Art Muster funktionieren.

Ereignisgesteuertes Computing ermöglicht es Amazon SNS, Informationen an Warteschlangen weiterzuleiten, welche die EC2-Instanzen entsprechend ändern.

BU: Ereignisgesteuertes Computing ermöglicht es Amazon SNS, Informationen an Warteschlangen weiterzuleiten, welche die EC2-Instanzen entsprechend ändern.

AWS HPC und ereignisgesteuerte Verarbeitung

Sobald ein Video an SNS zur Verarbeitung übergeben wird, sendet der Service für jeden gewünschten Output-Typ automatisch eine Meldung an jede Warteschlange im Amazon Simple Queue Service (SQS). Diese Meldung würde wahrscheinlich nur einen Link zu dem Originalvideo in Amazon Simple Storage Service (S3) enthalten, das der Entwickler konvertieren möchte. Er hätte dann für jede SQS-Warteschlange eine ganze Reihe von EC2-Instanzen (Elastic Compute Cloud), um diese Nachrichten zu verarbeiten und sie in einer einzigen Aktion zu konvertieren – Aktion bedeutet in diesem Fall, das Video in ein geeignetes Format zu kodieren und auf S3 hochzuladen.

Um die Skalierbarkeit korrekt zu behandeln, sollte eine Auto-Scaling-Gruppe jede EC2-Instanz regeln, die automatisch an Größe zunimmt, wenn die Anzahl der zu verarbeitenden SQS-Nachrichten einen definierten Schwellenwert überschreitet. Dies ermöglicht es dem Entwickler, die Anzahl der Server bei Lastspitzen – also mehr Uploads - automatisch hoch- und dann automatisch wieder nach unten zu skalieren.

Das Hinzufügen eines neuen Videoformats erfordert in dieser Architektur ein paar einfache Schritte: Fügen Sie eine neue SQS-Warteschlange hinzu, richten Sie eine neue Auto-Scaling-Gruppe mit EC2-Instanzen ein, um die Warteschlange zu verarbeiten und abonnieren Sie die Warteschlange für das SNS Topic, das aufgerufen wird, wenn ein neues Video hochgeladen wird. Die neue Warteschlange wird anfangen, Nachrichten für Verarbeitungsanforderungen von Videos zu empfangen, und alle neu eingereichten Videos werden automatisch in das neue Format codiert.

Der Vorteil: Wenn eine Formatcodierung fehlschlägt – beispielsweise eine ganze EC2-Instanz-Gruppe funktioniert nicht mehr – hat dies keinen Einfluss auf die anderen Formate. Wenn etwa ein 1.080-Pixel-Videoformat nicht richtig kodiert wird, kann der Entwickler auf das 780-Pixel-Format zurückgreifen, bis das Codierungsformat wieder funktioniert. Da der Entwickler darüber hinaus diese SQS-Anfragen in eine Warteschlange einordnet, werden sie automatisch verarbeitet, sobald der Encoder wieder arbeitet, und er wird die Videos, die während der Aktualisierung oder der Fehlerbehebung dieser Kodierungsgruppe nicht bearbeitet wurden, nachträglich bearbeiten.

AWS HPC beginnt oft mit Modellierungsprozessen von O(n). Diese stellen fest, wann eine Anwendung in mehrere Prozesse aufgeteilt werden kann, um die Gesamtleistung zu verbessern. Alles, was in mehrere Prozesse aufgeteilt werden kann, ist in der Regel vorzuziehen. Aber vergessen Sie nicht, dass ein Prozess insgesamt immer etwas langsamer wird, wenn er in mehrere Teile aufgeteilt wird. Wenn Sie allerdings Ihre Prozesse skalieren müssen, um einen hohen Durchsatz zu erhalten, ist das ein guter Weg.

Mehr zum Thema AWS:

Die wichtigsten AWS- und Drittanbieter-Tools für Big Data Analytics im Überblick.

Netzwerk-Sicherheitsmaßnahmen für AWS-Cloud-Ressourcen.

Die neuen AWS-Instanztypen X1 und t2.nano im Überblick.

AWS Kosten-Management-Tools von Amazon und Drittanbietern im Überblick.

Die richtige Strategie für die Replikation zwischen AWS-Sites.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Februar 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Cloud-Anwendungen

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close