Wenn Sie in den letzten fünf Jahren einen Blockbuster-Film gesehen haben, sind Sie wahrscheinlich Zeuge der visuellen Effekte und der Animationsarbeit der außergewöhnlich talentierten Künstler der Method Studios in Melbourne geworden. Unsere Arbeit umfasst Filmgenres, von „Aquaman" und "Terminator: Dunkles Schicksal"To"Jumanji: Das nächste Level" und "John Wick: Kapitel 3 - Parabellum“ und episodische Serien, darunter die mit dem Emmy Award ausgezeichnete „Schlacht der Bastarde“-Folge in der sechsten Staffel von HBOs „Game of Thrones“. Wenn wir über unsere Arbeit nachdenken, ist Disneys „Christopher Robin“ erwies sich angesichts der schieren Leistung, den honigliebenden CG-Co-Star des Films, Winnie-the-Pooh, zum Leben zu erwecken, als eines der denkwürdigsten Unternehmungen. Die Übernahme dieses Projekts führte nicht nur zu einem Gewinn des Asian Academy Creative Award für das Team, sondern markierte auch den Beginn unserer Zusammenarbeit mit AWS.
Den Zuschlag für „Christopher Robin“ im Jahr 2017 zu gewinnen, war aufregend, aber auch einschüchternd, da es eine Herausforderung ist, einen Bären in Voll-CG zu rendern, der oft in Nahaufnahmen zu sehen ist. Wir hatten benutzt Thinkbox-Deadline Software zur Verwaltung unserer Renderfarm für viele Jahre, bevor Thinkbox Software von AWS übernommen wurde. Als wir mit den Vorbereitungen für „Christopher Robin“ begannen, AWS Thinkbox Team unterstützte die Einrichtung eines Proof-of-Concept-Workflows für das Burst-Rendering in die Cloud. Bevor wir anfingen, mussten wir uns überlegen, wie wir unsere Daten den cloudbasierten Renderknoten präsentieren, wo wir die Daten speichern und wie wir cloudbasiertes Computing in unsere vorhandene lokale Farm integrieren.
Wir haben eine Reihe von Optionen in Betracht gezogen, wie Texturen und Geometrien dem präsentiert werden können Amazon Elastic Compute Cloud (Amazon EC2) Instanzen. Der einfachste Ansatz bestand darin, unseren lokalen NFS-Server (Network File System) direkt über unseren zu präsentieren AWS Direktverbindung zu den Amazon EC2 Spot-Flotte in der Region Sydney. Allerdings wollten wir Hunderte von Instanzen nutzen, die Dutzende von Gigabit an Datenverkehr erzeugen würden. Diese Art von Durchsatz über ein virtuelles privates Netzwerk (VPN) zu erreichen, ist eine Herausforderung und im Hinblick auf den ausgehenden Datenverkehr unerschwinglich. Stattdessen haben wir uns für Amazon Elastic File System (Amazon EFS) entschieden, einen Cloud-basierten, verwalteten NFS-Service. Die Einrichtung mit Amazon EFS war einfach, und die Standardkonfiguration konnte zurückskaliert werden, um die Kosten zu minimieren, wenn sie nicht verwendet wurde. Obwohl es sich um einen weniger automatisierten Ansatz handelte, verwendeten wir schließlich die bereitgestellte Durchsatzeinstellung für eine besser vorhersehbare Leistung.
In den Jahren seit „Christopher Robin“ sind die technischen Anforderungen für das Rendern immer anspruchsvoller geworden, daher haben wir unseren Workflow und die Art und Weise, wie wir AWS-Services nutzen, weiter verfeinert. Heutzutage erfordern Projekte, dass Frames mit einer Auflösung von 4.5K gerendert werden, wo sich Cloud-basierter Rechenzugriff mit viel RAM und CPU-Kernen auszahlt. Frames, die möglicherweise Schwierigkeiten beim Rendern mit lokaler Hardware haben, können diese großen Amazon EC2-Instances nutzen, wobei die gesamte Datenverarbeitung mit derselben Deadline-Instance verwaltet wird. Wenn Amazon EC2-Worker online gehen, sind sie dynamisch verfügbar Fristenmonitor neben unserem On-Premises-Farm.
Einer der weniger offensichtlichen Vorteile, die wir beim Einstieg in AWS gefunden haben, ist eine geringere Auswirkung auf den lokalen Speicher. Input/Output (I/O)-Anforderungen aufgrund intensiver Renderaktivitäten können Künstler erheblich beeinträchtigen, da es schwierig ist, produktiv zu bleiben, wenn Ihr Speicher nicht mithalten kann. Die Verlagerung dieser hohen IO-Arbeitslast auf EFS hat die Leistung unserer Künstler geschützt und als Ergebnis die Produktivität und Moral im Studio gesteigert. Neben EFS haben wir einen All-Flash-AWS-Partner hinzugefügt Qumulo Cluster, um die Startzeiten von Anwendungen zu beschleunigen.
Um sicherzustellen, dass die richtigen Daten zum Rendern in die Cloud gelangen und an die Workstations der Künstler zurückkehren, sobald ein Frame fertig gerendert ist, haben wir ein System entwickelt, das programmgesteuert eine Liste abhängiger Assets und Software generiert, die zum Rendern einer bestimmten Aufnahme erforderlich sind. Unser Toolset konnte bereits Abhängigkeiten verfolgen, sodass es nur zwei Wochen dauerte, die grundlegende Infrastruktur und Software aufzubauen. Heute verwenden wir eine Datenbank, um Cloud-Speicherdateien zu verfolgen. Vor dem Übertragen von Daten prüfen wir anhand dieser Datenbank, ob ein Asset synchronisiert werden muss. Alles, was nicht bereits in der Datenbank vorhanden ist, wird der Warteschlange hinzugefügt, die eine Farm von Sync-Workern füttert, die Daten in den/aus dem Cloud-Speicher verschieben. Deadline erfasst alle Fehler, die sich aus fehlenden Assets ergeben, und sendet dann automatisch eine Anfrage zum Abrufen fehlender Dateien. Die fehlgeschlagene Aufgabe wartet dann auf das Eintreffen der Daten und wird fortgesetzt, sobald die Dateien im Cloud-Speicher angekommen sind.
Da wir die Cloud verwenden, um unsere lokale Renderkapazität zu erweitern, mussten wir in der Lage sein, schnell ohne manuellen Eingriff zu skalieren und genauso einfach herunterzuskalieren, damit wir nicht eine Sekunde länger für Ressourcen bezahlen, als wir sie benötigen . Um dies zu erreichen, haben wir Tools entwickelt, um Deadline auf Warteschlangenaufgaben zu überwachen. Wenn unsere lokale Renderkapazität erschöpft ist, können wir jetzt unsere Spot-Flotte problemlos skalieren und innerhalb von Minuten mit dem Rendern in der Cloud beginnen. Sobald keine Aufgaben mehr in der Warteschlange stehen, fährt Deadline ungenutzte Maschinen herunter, sodass wir nur für die in Nutzung befindliche Rechenleistung bezahlen. Wir verfolgen und überwachen die Ausgaben mithilfe von Dashboards und Kostenzuordnungs-Tags. Auf diese Weise haben wir unsere Ausgaben immer im Blick und eine voreingestellte Warnung warnt uns, wenn wir das prognostizierte Budget überschreiten.
Gelegentlich kann es vorkommen, dass unser Asset-Synchronisierungssystem etwas nicht kopiert, das von einem Rendering benötigt wird, also haben wir eine virtuelle Workstation mit einer erstellt Amazon EC2 G4dn (GPU)-Instance die genau wie eine lokale Workstation eingerichtet ist. Jedes Mal, wenn wir ein fehlerhaftes Rendering beheben müssen, stellen wir eine Verbindung zur Cloud-basierten Workstation her und starten eine Szene, als würden wir sie in unserem Studio ausführen, um Probleme schnell zu identifizieren. Wenn ein Rendering auf AWS abgeschlossen ist, werden der fertige Frame oder die Daten wieder vor Ort synchronisiert, damit der Künstler sie überprüfen kann. Um sicherzustellen, dass die Renderings wie erwartet funktionieren, haben wir eine Webanwendung erstellt, die es Künstlern ermöglicht, Frames während des Renderns in der Vorschau anzuzeigen. Wir nutzen alle Metriken aus Amazon CloudWatch und verwenden Sie Grafana-Dashboards, um Amazon EC2-Metriken, Speicher, Bandbreite, Kosten und alles andere, was wir uns vorstellen können, zu verfolgen.
Jetzt, mehr als drei Jahre nach unserer Reise in die Cloud, haben wir gesehen, wie wichtig das Rendering auf AWS für unsere Renderfarm-Strategie ist. Wir haben den Fokus weg von Investitionsinvestitionen oder dem Mieten von Ausrüstung verlagert und konzentrieren uns jetzt auf die Cloud. An diesem Punkt haben wir den Großteil des AWS-Infrastrukturmanagements automatisiert und verbringen viel weniger Zeit mit dem Racking von Servern, der Verwaltung von Firmware-Updates und dem Austausch defekter Hardware. Unser Ziel ist es, die Zeit, die benötigt wird, um einen fertigen Rahmen an die Künstler zurückzusenden, weiter zu verkürzen, damit wir die Messlatte in Bezug auf Qualität und Bearbeitungszeit für Kunden immer höher legen können.
Wie Winnie-the-Pooh Method Melbournes Journey to Cloud Rendering entfachte, wurde auf der veröffentlicht AWS-Medienblog am 20. April 2021. Über den Autor: Jon Stanley ist Head of Systems bei Method Studios in Melbourne, eine Funktion, die er seit 2017 innehat. Mit fast 20 Jahren Erfahrung in der Systemtechnik für VFX- und Postproduktionsstudios hat er auch Zeit bei Iloura, Lipsync Post und Framestore verbracht.
Erfahren Sie mehr
Von Animation und Remote-Produktion bis hin zum Vertrieb, Qumulo für Medien und Unterhaltung
Unbegrenzte Skalierbarkeit und API-Programmierbarkeit, Cloud Q für AWS
Kontakt
Machen Sie eine Probefahrt. Demo von Qumulo in unseren interaktiven Hands-On Labs.
Abonnieren Sie den Qumulo-Blog für Kundengeschichten, technische Einblicke, Branchentrends und Produktneuigkeiten.
