Best Practices für Medienarbeitslasten

Auf dieser Seite werden Best Practices für die Verwendung von Cloud Storage für Medienarbeitslasten beschrieben. Diese Arbeitslasten umfassen oft verschiedene Google Cloud Produkte wie Media CDN, Live Stream API, Transcoder API und Video Stitcher API.

Übersicht

Google Cloud bietet Lösungen zur Optimierung der folgenden Arten von Medienarbeitslasten:

  • Medienproduktion: Umfasst Arbeitslasten wie die Postproduktion von Filmen, einschließlich Videobearbeitung, die rechenaufwendig sind und häufig GPUs für Hochleistungscomputing verwenden. Häufig werden in Cloud Storage gespeicherte medienbezogene Daten von Anwendungen verarbeitet, die in der Compute Engine oder der Google Kubernetes Engine ausgeführt werden. Das Ergebnis dieses Prozesses wird dann wieder in Cloud Storage zurückgeschrieben. Für diese Arbeitslasten muss der aggregierte Lese- und Schreibdurchsatz von Cloud Storage auf einen Compute-Cluster mit einer kürzeren GPU-Ruhezeit skaliert werden. Außerdem sind niedrige Lese- und Schreiblatenzen erforderlich, da dies entscheidend zur Reduzierung der Extremwertlatenz beiträgt.
  • Media-Asset-Verwaltung: Umfasst die Organisation Ihrer Media-Assets für eine effiziente Speicherung, Abruf und Nutzung.
  • Bereitstellung und Bereitstellung von Inhalten: Umfasst das Streaming von Medien an Nutzer, einschließlich Video-on-Demand (VoD) und Livestreaming-Diensten. Wenn Nutzer bei der Video-on-Demand-Wiedergabe Inhalte anfordern, die nicht im Content Delivery Network (CDN) im Cache gespeichert sind, werden sie aus den Cloud Storage-Buckets abgerufen. Bei Livestreaming-Anfragen werden die Inhalte gleichzeitig in den Storage-Bucket geschrieben und aus dem CDN gelesen.

Best Practices für Medienarbeitslasten

Best Practices für Medienarbeitslasten finden Sie in den folgenden Abschnitten.

Datenübertragung

Mit dem Storage Transfer Service können Sie mehr als 1 TiB an Rohmediendateien von einer lokalen Quelle wie einer Videokamera oder einem lokalen Speicher in Cloud Storage hochladen. Storage Transfer Service ermöglicht die nahtlose Datenübertragung zwischen Objekt- und Dateispeichersystemen. Wählen Sie für kleinere Übertragungen den Dienst aus, mit dem Sie Daten zu und von Cloud Storage oder zwischen Dateisystemen übertragen möchten.

Bucket-Speicherort

Für Arbeitslasten, die Compute-Ressourcen erfordern, z. B. für die Medienproduktion, sollten Sie Bucket in derselben Region oder in zwei Regionen wie die Compute-Ressourcen erstellen. Mit dieser Methode lässt sich die Leistung optimieren, indem die Lese- und Schreiblatenzen für Ihre Verarbeitungslasten, die Kosten und die Bandbreite gesenkt werden. Weitere Informationen zur Auswahl des Speicherorts für den Bucket finden Sie unter Überlegungen zum Speicherort des Buckets.

Speicherklasse

Je nach Art der Medienarbeitslast sollte eine andere Speicherklasse ausgewählt werden. Die empfohlenen Speicherklassentypen für verschiedene Medienarbeitslasten sind:

  • Für die Verwaltung von Medien-Assets wie Archivvideos sollte die Standardspeicherklasse eines Buckets „Archivspeicher“ sein. Sie können für Objekte mit unterschiedlichen Verfügbarkeits- oder Zugriffsanforderungen eine andere Speicherklasse angeben.
  • Bei Arbeitslasten für die Medienproduktion und die Bereitstellung von Inhalten sollten Sie die Daten im Standardspeicher speichern, da sie häufig aus einem Cloud Storage-Bucket gelesen werden.

Weitere Informationen zur Auswahl der Speicherklasse für Ihren Bucket finden Sie unter Speicherklasse.

Verwaltung des Datenlebenszyklus

Zur Verwaltung Ihrer Medien-Assets sollten Sie den Objektlebenszyklus für Ihre Buckets verwalten, indem Sie eine Lebenszykluskonfiguration definieren. Mit der Funktion Verwaltung des Objektlebenszyklus können Sie den Datenlebenszyklus verwalten, z. B. eine Gültigkeitsdauer (TTL) für Objekte festlegen, nicht aktuelle Objektversionen aufbewahren und Speicherklassen von Objekten downgraden, um Kosten zu senken.

Wenn die Zugriffsmuster für Daten vorhersehbar sind, können Sie die Lebenszykluskonfiguration für einen Bucket festlegen. Bei unbekannten oder unvorhersehbaren Zugriffsmustern für Ihre Daten können Sie die Autoclass-Funktion für Ihren Bucket festlegen. Mit Autoclass werden in Cloud Storage Daten, auf die nicht häufig zugegriffen wird, automatisch in weniger aktive Speicherklassen verschoben.

Best Practices für Arbeitslasten beim Bereitstellen und Verteilen von Inhalten

Sowohl bei VoD- als auch bei Livestreaming-Arbeitslasten ist es das Ziel, Wiedergabefehler, Verzögerungen beim Start der Wiedergabe oder Pufferung zu vermeiden, wenn ein Video im Videoplayer des Endnutzers wiedergegeben wird. Bei diesen Arbeitslasten müssen Lesevorgänge auch skaliert werden, um eine große Anzahl gleichzeitiger Betrachter zu berücksichtigen. In allen Fällen sollten Kunden-Traffic-Lesungen über ein CDN erfolgen.

Best Practices für Arbeitslasten für die Bereitstellung und Verteilung von Inhalten finden Sie in den folgenden Abschnitten.

CDN effektiv nutzen

Wenn Sie ein Content Delivery Network (CDN) vor dem Cloud Storage-Bucket verwenden, wird die Nutzerfreundlichkeit verbessert, da das CDN Inhalte im Cache speichert, indem es die Latenz verringert und die Bandbreiteneffizienz erhöht. Mit einem CDN können Sie die Gesamtbetriebskosten senken, indem Sie die Bandbreitenkosten reduzieren, die Ressourcennutzung optimieren und die Leistung verbessern. Mit Media CDN lassen sich die Gesamtkosten für die Bereitstellung von Inhalten für Endnutzer senken, da die Kosten für das Cache-Ausfüllen bei Media CDN null sind. Du kannst Media CDN als Quelle für andere CDNs von Drittanbietern verwenden. Bei anderen CDNs lassen sich die Gesamtbetriebskosten ebenfalls senken, wenn Inhalte aus diesem Media CDN-Cache statt aus der Quelle bereitgestellt werden.

Wenn Sie ein CDN eines Drittanbieters verwenden, können ausgewählte Anbieter mit CDN Interconnect an verschiedenen Standorten direkte Peering-Links mit dem Edge-Netzwerk von Google herstellen. Ihr Netzwerktraffic, der über eine dieser Verbindungen von Google Cloudübertragen wird, profitiert von der direkten Konnektivität zu den unterstützten CDN-Anbietern und wird automatisch mit reduzierten Preisen abgerechnet. Eine Liste der genehmigten Anbieter finden Sie unter Von Google genehmigte Dienstanbieter.

Im Folgenden sind die Optionen aufgeführt, die beim Einrichten eines CDN konfiguriert werden müssen:

Ort des Herkunftslogos auswählen

Der Ursprungs-Shield-Speicherort ist ein Cache zwischen dem CDN und Cloud Storage. Wenn Sie in Ihrem CDN den Speicherort des Ursprungs-Shields auswählen können, folgen Sie den CDN-Richtlinien, um herauszufinden, ob es empfohlen wird, den Speicherort des Ursprungs-Shields näher an der Region Ihres Cloud Storage-Bucket oder dem Ort der Konzentration des Endnutzer-Traffics zu wählen. Ein Ursprungsschutz ist eine Schutzmaßnahme, die Ihren Ursprungsserver vor Überlastung schützt. CDNs mit Ursprungsabschirmung tragen dazu bei, die Auslastung des Ursprungs zu erhöhen, indem ein zusätzlicher Cache zwischen dem Ursprung und dem CDN hinzugefügt wird. Media CDN bietet beispielsweise eine deutlich abgestufte Edge-Infrastruktur, die so konzipiert ist, dass die Cache-Füllung wenn möglich aktiv minimiert wird.

Zusammenführen von Anfragen aktivieren

Prüfen Sie, ob das Zusammenführen von Anfragen für Ihr CDN aktiviert ist. Wenn Sie mehrere Anfragen in eine einzige Anfrage zusammenfassen, werden die Kosten für Cloud Storage-Vorgänge der Klasse B gesenkt. CDNs haben verteilte Caches auf der ganzen Welt, bieten aber die Möglichkeit, mehrere Endnutzeranfragen in einer einzigen Anfrage an den Ursprung zusammenzuführen. Media CDN minimiert beispielsweise aktiv mehrere nutzergesteuerte Cache-Füllanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten und reduziert so die Anzahl der Anfragen an die Buckets.

Wiederholungsprozess für CDN konfigurieren

Konfigurieren Sie die Wiederholung für alle Serverprobleme mit den HTTP-5xx-Antwortcodes 502, 503 und 504 in Ihrem CDN. CDNs unterstützen Ursprungs-Wiederholungsversuche, sodass fehlgeschlagene Anfragen an den Ursprung wiederholt werden können. Bei den meisten CDNs können Sie die Anzahl der Wiederholungen für den aktuellen Ursprung angeben. Informationen zum Wiederholen von Ursprungsanfragen in Media CDN findest du unter Ursprungsanfragen wiederholen.

Standortoptionen für die Bereitstellung von Inhalten

Bei Arbeitslasten, bei denen Daten aus Cloud Storage gelesen werden, die nicht im CDN im Cache gespeichert sind, z. B. beim Bereitstellen und Verteilen von VoD-Inhalten, sollten Sie bei der Auswahl eines Speicherorts für Ihren Bucket die folgenden Faktoren berücksichtigen:

  • Um die Kosten zu optimieren, haben Buckets, die in einer einzelnen Region erstellt wurden, die niedrigsten Speicherkosten.
  • Berücksichtigen Sie Folgendes, um die Verfügbarkeit zu optimieren:
    • Für die meisten Medienarbeitslasten wird die Verwendung von Buckets mit zwei Regionen empfohlen, da Ihre Objekte für eine bessere Verfügbarkeit in zwei Regionen repliziert werden.
    • Für Anwendungsfälle, bei denen die Inhaltsbereitstellung und Analysen mit geografischer Redundanz erforderlich sind, sollten Sie Buckets in mehreren Regionen verwenden, um die höchste Verfügbarkeit zu erreichen.
  • Berücksichtigen Sie Folgendes, um die Latenz zu optimieren und die Netzwerkkosten zu senken:
    • Wähle für VoD die Regionen aus, die den meisten deiner Endnutzer am nächsten sind, oder die Region mit der größten Traffickonzentration.
    • Während des Livestreamings erhalten Buckets Schreibanfragen von Transcodern und Leseanfragen von einem CDN, das die Inhalte im Cache speichert und an Endnutzer verteilt. Für eine bessere Streamingleistung solltest du regionale Buckets auswählen, die sich an demselben Standort wie die für das Transcodieren verwendeten Rechenressourcen befinden.

Videosegmentlänge für Livestreams optimieren

Für Livestreams wird eine Segmentgröße von mindestens zwei Sekunden empfohlen, da kurze Videosegmente empfindlicher auf Long-Tail-Schreiblatenzen reagieren. Long-Tail-Schreiblatenzen beziehen sich auf langsame oder verzögerte Schreibvorgänge für Inhalte, auf die selten zugegriffen wird oder für die nur wenige Anfragen gestellt werden.

Die physische Entfernung zwischen dem Speicherort des Buckets und dem Wiedergabestandort des Endnutzers wirkt sich auf die Übertragungszeit aus. Wenn sich Ihre Endnutzer weit vom Speicherort des Buckets entfernt befinden, empfehlen wir eine längere Videosegmentgröße.

Für eine optimale Wiedergabe wird empfohlen, die Wiederholstrategie zu verwenden und für Schreibvorgänge auf den Transcodern eine Absicherung anzufordern, um Long-Tail-Latenzen von mehr als zwei Sekunden bei Schreibvorgängen in Cloud Storage zu vermeiden und mit längeren Pufferzeiten von etwa zehn Sekunden zu experimentieren.

Anzahl der Abfragen pro Sekunde schrittweise erhöhen

Cloud Storage-Buckets haben eine anfängliche I/O-Kapazität von 1.000 Objektschreibvorgängen pro Sekunde und 5.000 Objektlesevorgängen pro Sekunde. Bei Livestream-Arbeitslasten sollten Sie Ihre Anfragen schrittweise skalieren. Beginnen Sie mit 1.000 Schreib- und 5.000 Leseanfragen pro Sekunde und verdoppeln Sie die Anforderungsrate alle 20 Minuten. Mit dieser Methode kann Cloud Storage die Last auf mehrere Server verteilen und die Verfügbarkeit und Latenz des Buckets verbessern, da die Wahrscheinlichkeit von Wiedergabeproblemen sinkt.

Bei einem Livestream mit höherer QPS-Anzahl solltest du die Skalierung für deinen Bucket implementieren. Dazu kannst du entweder den Bucket vorwärmen oder den hierarchischen Namespace für den Bucket aktivieren. Bevor Sie das Bucket skalieren, sollten Sie die folgenden Aufgaben ausführen:

Abfragen pro Sekunde zum Ursprung schätzen

Angenommen, bei einem Livestream mit einer Million Zuschauern erhält das CDN eine Million QPS. Angenommen, Ihr CDN hat eine Cache-Trefferquote von 99,0%, beträgt der resultierende Traffic zu Cloud Storage 1%. Die Anzahl der Abfragen pro Sekunde entspricht 1% der Gesamtzahl der Zuschauer (eine Million), also 10.000 Abfragen pro Sekunde. Dieser Wert ist höher als die ursprüngliche I/O-Kapazität.

QPS überwachen und Skalierungsfehler beheben

Sie sollten die Abfragen pro Sekunde überwachen und alle Skalierungsfehler beheben. Weitere Informationen finden Sie unter Übersicht über das Monitoring in Cloud Storage . Um die Lese- und Schreibanfragen im Blick zu behalten, sehen Sie sich in der Google Cloud Console die Diagramme Anzahl der Lese-/Liste-/Get-Anfragen insgesamt und Anzahl der Schreibanfragen insgesamt an. Wenn Sie die Abfragen pro Sekunde für Bucket schneller als gemäß den im vorherigen Abschnitt genannten Richtlinien für die Steigerung skalieren, kann der Fehler 429 Zu viele Anfragen auftreten. Weitere Informationen zum Beheben des Fehlers 429 (Zu viele Anfragen)

In den folgenden Abschnitten wird beschrieben, wie Sie Ihren Bucket für eine höhere QPS skalieren, nachdem Sie die QPS für den Ursprung geschätzt haben.

QPS-Skalierung für Ihren Bucket implementieren, indem Sie ihn vorwärmen

Du kannst den Skalierungsvorgang vor einem Livestream beschleunigen, indem du deinen Bucket vorwärmst. Generiere vor dem Livestreaming-Ereignis synthetischen Traffic für deinen Bucket, der der erwarteten maximalen QPS entspricht, die der Ursprungsserver des CDNs für das Ereignis erhalten wird, plus einem zusätzlichen Puffer von 50 %, der die erwartete Cache-Trefferrate deines CDNs berücksichtigt. Wenn Sie beispielsweise die Anzahl der Abfragen pro Sekunde für Ihren Ursprung auf 10.000 geschätzt haben, sollte der simulierte Traffic auf 15.000 Anfragen pro Sekunde ausgerichtet sein, um Ihren Ursprung auf das Ereignis vorzubereiten.

Für diesen simulierten Traffic kannst du entweder die Livefeeddateien des vorherigen Ereignisses wie Segmente und Manifeste oder Testdateien verwenden. Achten Sie darauf, dass Sie während des Warm-up-Prozesses unterschiedliche Dateien verwenden.

Erhöhen Sie die Anzahl der simulierten Zugriffe nach und nach, beginnend mit 5.000 Anfragen pro Sekunde, bis Sie Ihr Ziel erreichen. Planen Sie vor dem Ereignis genügend Zeit ein, um die geschätzte Auslastung zu erreichen. Wenn Sie beispielsweise 15.000 Anfragen pro Sekunde erreichen möchten, indem Sie die Auslastung alle 20 Minuten von 5.000 Anfragen pro Sekunde verdoppeln, dauert es etwa 30 Minuten.

Der Ursprungsserver hält die Kapazität aufrecht, bis der Traffic konstant ist. Die Kapazität des Ursprungsservers sinkt innerhalb von 24 Stunden allmählich auf das Normalniveau ab. Wenn zwischen den Livestream-Ereignissen auf deinem Ursprungsserver mehrere Stunden Pausen auftreten, empfehlen wir dir, vor jedem Ereignis den Traffic zu simulieren.

Buckets mit aktiviertem hierarchischen Namespace für hohe anfängliche QPS verwenden

Cloud Storage-Buckets mit aktiviertem hierarchischen Namespace bieten bis zu achtmal die anfängliche QPS im Vergleich zu Buckets ohne HNS. Die höhere anfängliche QPS erleichtert die Skalierung datenintensiver Arbeitslasten und sorgt für einen höheren Durchsatz. Informationen zu Einschränkungen in Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Einschränkungen.

Vermeide sequenzielle Namen für Videosegmente, um die Anzahl der Anfragen pro Sekunde zu skalieren

Bei der QPS-Skalierung werden Anfragen auf mehrere Server verteilt. Es kann jedoch zu Leistungsengpässen kommen, wenn alle Objekte ein nicht zufälliges oder sequenzielles Präfix verwenden. Durch vollkommen zufällige Namen anstelle von sequenziellen Namen erhalten Sie die beste Lastverteilung. Falls Sie jedoch eine sequenzielle Nummerierung oder einen Zeitstempel als Teil Ihrer Objektnamen verwenden möchten, führen Sie für Ihre Objektnamen einen Zufallsfaktor ein, indem Sie vor der Sequenznummer oder dem Zeitstempel einen Hash-Wert einfügen. Wenn der ursprüngliche Objektname, den Sie verwenden möchten, beispielsweise my-bucket/2016-05-10-12-00-00/file1 lautet, können Sie den MD5-Hash des ursprünglichen Objektnamens berechnen und dem Objektnamen die ersten sechs Zeichen des Hash als Präfix hinzufügen. Das neue Objekt hat dann den Namen my-bucket/2fa764-2016-05-10-12-00-00/file1.. Weitere Informationen finden Sie unter Namenskonvention verwenden, mit der die Last gleichmäßig über die Schlüsselbereiche verteilt wird. Wenn Sie eine sequenzielle Benennung für Videosegmente nicht vermeiden können, verwenden Sie Buckets mit aktiviertem hierarchischen Namespace, um eine höhere QPS zu erzielen.

Für jeden Livestream unterschiedliche Buckets verwenden

Bei gleichzeitigen Livestreams kannst du die Lese- und Schreiblast effektiv skalieren, ohne die I/O-Limits für den Bucket zu erreichen, wenn du für jeden Livestream einen anderen Bucket verwendest. Wenn du für jeden Livestream unterschiedliche Bucket verwendest, werden große Ausreißerlatenzen aufgrund von Skalierungsverzögerungen reduziert.

Nächste Schritte