Best Practices für Media-Arbeitslasten

Auf dieser Seite werden die Best Practices für die Verwendung von Cloud Storage für Media-Arbeitslasten 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 Media-Arbeitslasten:

  • Medienproduktion: Umfasst Arbeitslasten wie die Postproduktion von Filmen, einschließlich Videoschnitt, die rechenintensiv sind und oft GPUs für Hochleistungs-Computing verwenden. Häufig werden medienspezifische Daten, die in Cloud Storage gespeichert sind, von Anwendungen verarbeitet, die in Compute Engine oder Google Kubernetes Engine ausgeführt werden. Die Ausgabe dieses Prozesses wird in Cloud Storage zurückgeschrieben. Für diese Arbeitslasten muss der aggregierte Lese- und Schreibdurchsatz von Cloud Storage auf einen Compute-Cluster mit einer geringeren GPU-Leerlaufzeit skaliert werden. Außerdem sind niedrige Latenzen beim Lesen und Schreiben erforderlich, da dies entscheidend für die Reduzierung der Tail-Latenz ist.
  • Verwaltung von Media-Assets: Umfasst das Organisieren Ihrer Media-Assets für eine effiziente Speicherung, den Abruf und die Verwendung.
  • Bereitstellung und Verteilung von Inhalten: Umfasst das Streamen von Medien für Nutzer, einschließlich Video-on-Demand- (VoD) und Livestreaming-Dienste. Wenn Nutzer bei VoD Inhalte anfordern, die nicht im Content Delivery Network (CDN) im Cache gespeichert sind, werden die Inhalte 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 Media-Arbeitslasten

Best Practices für Media-Arbeitslasten finden Sie in den folgenden Abschnitten.

Datenübertragung

Verwenden Sie Storage Transfer Service, um mehr als 1 TiB an Rohmediendateien aus einer lokalen Quelle wie einer Videokamera oder einem lokalen Speicher in Cloud Storage hochzuladen. Storage Transfer Service ermöglicht eine nahtlose Datenübertragung zwischen Objekt- und Dateispeichersystemen. Wählen Sie für kleinere Übertragungen den Dienst aus, mit dem Daten je nach Übertragungsszenario in Cloud Storage und aus Cloud Storage oder zwischen Dateisystemen übertragen werden.

Bucket-Standort

Für Arbeitslasten, die Compute-Ressourcen erfordern, z. B. für die Medienproduktion, sollten Sie Buckets in derselben Region oder in Dual-Regionen wie die Compute-Ressourcen erstellen. Diese Methode trägt dazu bei, die Leistung zu optimieren, indem die Latenzen beim Lesen und Schreiben für Ihre Verarbeitungsarbeitslasten, Kosten und Bandbreite reduziert werden. Weitere Informationen zur Auswahl des Bucket-Standorts finden Sie unter Überlegungen zum Bucket-Standort.

Speicherklasse

Je nach Art der Media-Arbeitslast unterscheidet sich die Speicherklasse, die Sie auswählen sollten. Die empfohlenen Speicherklassen für verschiedene Media-Arbeitslasten sind wie folgt:

  • Für die Verwaltung von Media-Assets wie Archivvideos sollte die Standardspeicherklasse eines Buckets „Archivspeicher“ sein. Sie können für Objekte, die unterschiedliche Verfügbarkeits- oder Zugriffsanforderungen haben, eine andere Speicherklasse angeben.
  • Für Arbeitslasten zur Medienproduktion und Inhaltsbereitstellung, bei denen Daten häufig aus einem Cloud Storage-Bucket gelesen werden, sollten Sie die Daten im Standard Storage speichern.

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

Verwaltung des Datenlebenszyklus

Für die Verwaltung Ihrer Media-Assets sollten Sie den Objektlebenszyklus für Ihre Buckets verwalten, indem Sie eine Lebenszykluskonfiguration definieren. Mit der Funktion zur Verwaltung des Objektlebenszyklus können Sie den Datenlebenszyklus verwalten, einschließlich des Festlegens einer Gültigkeitsdauer (Time to Live, TTL) für Objekte, der Aufbewahrung nicht aktueller Objektversionen und des Downgrades der Speicherklassen von Objekten zur Kostensenkung.

Wenn Datenzugriffsmuster 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 Funktion „Autoclass“ für Ihren Bucket festlegen. Mit Autoclass verschiebt Cloud Storage Daten, auf die nicht häufig zugegriffen wird, automatisch in kältere Speicherklassen.

Best Practices für Arbeitslasten zur Bereitstellung und Verteilung von Inhalten

Sowohl bei VoD- als auch bei Livestreaming-Arbeitslasten besteht das Ziel darin, Wiedergabefehler, Verzögerungen beim Start der Wiedergabe oder Pufferung zu vermeiden, während ein Video auf dem Videoplayer des Endnutzers wiedergegeben wird. Für diese Arbeitslasten ist auch eine Skalierung der Lesevorgänge erforderlich, um einer großen Anzahl gleichzeitiger Zuschauer Rechnung zu tragen. In allen Fällen sollten Lesevorgänge des Kundentraffics über ein CDN erfolgen.

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

CDN effektiv nutzen

Die Verwendung eines Content Delivery Network (CDN) vor dem Cloud Storage-Bucket verbessert die Endnutzererfahrung, da das CDN Inhalte im Cache speichert, wodurch die Latenz reduziert und die Bandbreiteneffizienz erhöht wird. Mit einem CDN können Sie die Gesamtbetriebskosten senken, indem Sie die Bandbreitenkosten reduzieren, die Ressourcennutzung optimieren und die Leistung verbessern. Durch die Verwendung von Media CDN können Sie die Gesamtbetriebskosten für die Bereitstellung von Inhalten für Endnutzer senken, da die Kosten für die Cache-Füllung für Media CDN null betragen. Sie können Media CDN als Quelle für andere CDNs von Drittanbietern verwenden. Auch bei anderen CDNs können Sie die Gesamtbetriebskosten senken, wenn Sie Inhalte aus diesem Media CDN-Cache anstelle der Quelle bereitstellen.

Wenn Sie ein CDN eines Drittanbieters verwenden, ermöglicht CDN Interconnect ausgewählten Anbietern, an verschiedenen Standorten direkte Peering-Links mit dem Edge Netzwerk von Google aufzubauen. Ihr Netzwerktraffic, der von Google Cloud über eine dieser Verbindungen ü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 Sie beim Einrichten eines CDN konfigurieren können:

Ursprungsschildstandort auswählen

Der Ursprungsschildstandort ist ein Cache zwischen dem CDN und Cloud Storage. Wenn Sie in Ihrem CDN den Ursprungsschildstandort auswählen können, folgen Sie den CDN-Richtlinien dazu, ob es empfehlenswert ist, den Ursprungsschildstandort näher an der Region Ihres Cloud Storage-Bucket oder an dem Standort zu wählen, an dem sich der Endnutzertraffic konzentriert. Ein Ursprungsschild ist eine Schutzmaßnahme, die Ihren Ursprungsserver vor Überlastung schützt. CDNs mit Ursprungsschild helfen, die Ursprungsentlastung zu erhöhen, indem sie einen zusätzlichen Cache zwischen der Quelle und dem CDN hinzufügen. Media CDN bietet beispielsweise eine deutlich abgestufte Edge-Infrastruktur, die so konzipiert ist, dass die Cache-Füllung wenn möglich aktiv minimiert wird.

Anfragen zusammenführen aktivieren

Achten Sie darauf, dass die Anfrageminimierung für Ihr CDN aktiviert ist. Durch das Zusammenführen mehrerer Anfragen zu einer einzigen Anfrage werden die Kosten für Vorgänge der Cloud Storage-Speicherklasse B reduziert. CDNs haben verteilte Caches, die weltweit bereitgestellt werden, bieten aber eine Möglichkeit, mehrere Endnutzeranfragen zu einer einzigen Anfrage an die Quelle zusammenzuführen. Media CDN führt beispielsweise mehrere nutzergesteuerte Cache-Füllanfragen für denselben Cache-Schlüssel aktiv zu einer einzigen Ursprungsanfrage pro Edge-Knoten zusammen, wodurch die Anzahl der Anfragen an die Buckets reduziert wird.

Wiederholungsverhalten im CDN konfigurieren

Konfigurieren Sie die Wiederholung für alle Serverprobleme mit dem HTTP-Antwortcode 5xx (502, 503, 504) in Ihrem CDN. CDNs unterstützen Ursprungs-Wiederholungsversuche, sodass nicht erfolgreiche Anfragen an die Quelle wiederholt werden können. Bei den meisten CDNs können Sie die Anzahl der Wiederholungen für die aktuelle Quelle angeben. Informationen zum Wiederholen von Ursprungsanfragen in Media CDN finden Sie unter Ursprungsanfragen wiederholen.

Standortoptionen für die Inhaltsverteilung

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

  • Zur Kostenoptimierung haben Buckets, die in einer einzelnen Region erstellt wurden, die niedrigsten Speicherkosten.
  • Zur Optimierung der Verfügbarkeit sollten Sie Folgendes berücksichtigen:
    • Für die meisten Media-Arbeitslasten werden Buckets mit zwei Regionen empfohlen, da Ihre Objekte in zwei Regionen repliziert werden, um die Verfügbarkeit zu verbessern.
    • Für Anwendungsfälle, die die Bereitstellung von Inhalten und Analysen mit geografischer Redundanz erfordern, verwenden Sie Buckets in mehreren Regionen, um die höchste Verfügbarkeit zu erzielen.
  • Zur Optimierung der Latenz und zur Reduzierung der Netzwerkkosten sollten Sie Folgendes berücksichtigen:
    • Wählen Sie für VoD Regionen aus, die sich in der Nähe der meisten Endnutzer befinden oder in denen der Traffic am stärksten konzentriert ist.
    • Beim Livestreaming empfangen Buckets Schreibanfragen von Transcodern und Leseanfragen von einem CDN, das die Inhalte im Cache speichert und an Endnutzer verteilt. Für eine verbesserte Streaming-Leistung sollten Sie regionale Buckets auswählen, die sich am selben Standort wie die für die Transcodierung verwendeten Compute-Ressourcen befinden.

Videosegmentlänge für Livestreams optimieren

Für Livestreams beträgt die empfohlene Mindestsegmentgröße zwei Sekunden, da Kurzvideosegmente empfindlicher auf Longtail-Schreiblatenzen reagieren. Lange Schreiblatenzen beziehen sich auf langsame oder verzögerte Schreibvorgänge für Inhalte, auf die selten zugegriffen wird oder die ein geringes Anfragevolumen haben.

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

Um Zuschauern die bestmögliche Erfahrung zu bieten, empfiehlt es sich, die Wiederholungsstrategie und die Anfragenabsicherung für Schreibvorgänge auf den Transcodern zu verwenden, um lange Tail-Latenzen von mehr als zwei Sekunden für Schreibvorgänge in Cloud Storage zu vermeiden und längere Pufferzeiten von etwa zehn Sekunden zu testen.

Abfragen pro Sekunde schrittweise erhöhen

Cloud Storage-Buckets haben eine anfängliche E/A-Kapazität von 1.000 Objektschreibvorgängen pro Sekunde und 5.000 Objektlesevorgängen pro Sekunde. Für Livestream-Arbeitslasten sollten Sie Ihre Anfragen schrittweise skalieren. Beginnen Sie mit 1.000 Schreibvorgängen pro Sekunde und 5.000 Lesevorgängen 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 Ihres Buckets verbessern, indem die Wahrscheinlichkeit von Wiedergabeproblemen reduziert wird.

Für eine Livestream-Veranstaltung mit einer höheren Anzahl von Abfragen pro Sekunde sollten Sie die Skalierung für Ihren Bucket implementieren, indem Sie entweder Ihren Bucket vorab aufwärmen oder indem Sie den hierarchischen Namespace aktivieren für Ihren Bucket. Bevor Sie die Skalierung für Ihren Bucket implementieren, sollten Sie die folgenden Aufgaben ausführen:

Abfragen pro Sekunde zur Quelle schätzen

Angenommen, bei einem Livestream mit einer Million Zuschauern erhält das CDN eine Million Abfragen pro Sekunde. Wenn Ihr CDN eine Cache-Trefferrate von 99,0 % hat, beträgt der resultierende Traffic zu Cloud Storage 1%. Die Abfragen pro Sekunde betragen 1% der Gesamtzahl der Zuschauer (eine Million), was 10.000 Abfragen pro Sekunde entspricht. Dieser Wert ist höher als die anfängliche E/A-Kapazität.

Abfragen pro Sekunde überwachen und Skalierungsfehler beheben

Sie sollten die Abfragen pro Sekunde überwachen und Skalierungsfehler beheben. Weitere Informationen finden Sie unter Übersicht über das Monitoring in Cloud Storage . Um die Lese- und Schreibanfragen zu überwachen, sehen Sie sich in der Google Cloud Console das Diagramm Gesamtzahl der Lese-/Listen-/Abrufanfragen bzw. das Diagramm Gesamtzahl der Schreibanfragen an. Wenn Sie die Abfragen pro Sekunde für Buckets schneller skalieren als in den im vorherigen Abschnitt beschriebenen Richtlinien für die schrittweise Erhöhung angegeben, kann der Fehler 429 Too many requests auftreten. Informationen zum Beheben des Fehlers „429 Too many requests“

In den folgenden Abschnitten wird beschrieben, wie Sie Ihren Bucket für eine höhere Anzahl von Abfragen pro Sekunde skalieren, nachdem Sie die Anzahl der Abfragen pro Sekunde zur Quelle geschätzt haben.

Skalierung der Abfragen pro Sekunde für Ihren Bucket implementieren, indem Sie Ihren Bucket vorab aufwärmen

Sie können den Skalierungsprozess vor einem Livestreaming-Ereignis beschleunigen, indem Sie Ihren Bucket vorab aufwärmen. Generieren Sie vor dem Livestreaming-Ereignis synthetischen Traffic zu Ihrem Bucket, der der erwarteten maximalen Anzahl von Abfragen pro Sekunde entspricht, die der Ursprungsserver des CDN für das Ereignis empfängt, zuzüglich eines zusätzlichen Puffers von 50 %, der die erwartete Cache-Trefferrate Ihres CDN berücksichtigt. Wenn Sie beispielsweise die Anzahl der Abfragen pro Sekunde für Ihre Quelle auf 10.000 geschätzt haben, sollte Ihr simulierter Traffic auf 15.000 Anfragen pro Sekunde ausgerichtet sein, um Ihre Quelle auf das Ereignis vorzubereiten.

Für diesen simulierten Traffic können Sie entweder die Live-Feed-Dateien des vorherigen Ereignisses, z. B. Segmente und Manifest, oder Testdateien verwenden. Achten Sie darauf, dass während des gesamten Aufwärmprozesses unterschiedliche Dateien verwendet werden.

Wenn Sie diesen simulierten Traffic generieren, folgen Sie einem schrittweisen Skalierungsansatz. Beginnen Sie mit 5.000 Anfragen pro Sekunde und erhöhen Sie die Anzahl schrittweise, bis Sie Ihr Ziel erreicht haben. Planen Sie vor dem Ereignis ausreichend Zeit ein, um die geschätzte Last zu erreichen. Wenn Sie beispielsweise 15.000 Anfragen pro Sekunde erreichen möchten und die Last alle 20 Minuten von anfänglich 5.000 Anfragen pro Sekunde verdoppeln, dauert das etwa 30 Minuten.

Der Ursprungsserver behält die Kapazität bei, bis der Traffic konstant ist. Die Kapazität des Ursprungsservers sinkt innerhalb von 24 Stunden allmählich auf den Ausgangswert. Wenn Ihr Ursprungsserver mehrstündige Lücken zwischen den Livestream-Ereignissen aufweist, empfehlen wir, vor jedem Ereignis Traffic zu simulieren.

Buckets mit aktiviertem hierarchischen Namespace für hohe anfängliche Abfragen pro Sekunde verwenden

Cloud Storage-Buckets mit aktiviertem hierarchischem Namespace bieten im Vergleich zu Buckets ohne hierarchischen Namespace bis zu achtmal so viele anfängliche Abfragen pro Sekunde. Die höhere anfängliche Anzahl von Abfragen pro Sekunde 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.

Sequenzielle Namen für Videosegmente vermeiden, um die Anzahl der Abfragen pro Sekunde zu skalieren

Bei der Skalierung der Abfragen pro Sekunde werden Anfragen auf mehrere Server verteilt. Es können jedoch Leistungsengpässe auftreten, wenn alle Objekte ein nicht zufälliges oder sequenzielles Präfix verwenden. Durch die Verwendung von vollkommen zufälligen Namen anstelle von sequenziellen Namen erhalten Sie die beste Lastenverteilung. 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 wird zu my-bucket/2fa764-2016-05-10-12-00-00/file1. Weitere Informationen finden Sie unter Namenskonvention verwenden, um die Last gleichmäßig über die Schlüsselbereiche zu verteilen. Wenn Sie sequenzielle Namen für Videosegmente nicht vermeiden können, verwenden Sie Buckets mit aktiviertem hierarchischem Namespace, um eine höhere Anzahl von Abfragen pro Sekunde zu erzielen.

Für jeden Livestream einen anderen Bucket verwenden

Bei gleichzeitigen Livestreams können Sie die Lese- und Schreiblast effektiv skalieren, ohne die E/A-Limits für den Bucket zu erreichen, wenn Sie für jeden Livestream einen anderen Bucket verwenden. Durch die Verwendung verschiedener Buckets für jeden Livestream werden große Ausreißerlatenzen aufgrund von Skalierungsverzögerungen reduziert.

Nächste Schritte