Best Practices für Medienarbeitslasten

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: Dazu gehören Arbeitslasten wie die Postproduktion von Filmen, einschließlich Videobearbeitung, die rechenintensiv sind und oft GPUs für High-Performance Computing verwenden. Häufig werden mediabezogene Daten, die sich in Cloud Storage befinden, von Anwendungen verarbeitet, die in Compute Engine oder Google Kubernetes Engine ausgeführt werden. Die Ausgabe dieses Prozesses wird dann wieder in Cloud Storage geschrieben. 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 Lese- und Schreiblatenzen erforderlich, da dies entscheidend für die Reduzierung der Extremwertlatenz ist.
  • Media-Asset-Management: Hierbei werden Ihre Media-Assets für eine effiziente Speicherung, den Abruf und die Nutzung organisiert.
  • Bereitstellung und Verteilung von Inhalten: Dazu gehört das Streamen von Medien an Nutzer, einschließlich Video-on-Demand- (VoD) und Livestreaming-Diensten. Bei VoD wird der Inhalt, wenn Nutzer Inhalte anfordern, die nicht im CDN (Content Delivery Network) zwischengespeichert sind, aus den Cloud Storage-Buckets abgerufen. Bei Livestreaming-Anfragen werden die Inhalte gleichzeitig in den Storage-Bucket geschrieben und vom 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. Mit Storage Transfer Service können Daten nahtlos zwischen Objekt- und Dateispeichersystemen verschoben werden. Wählen Sie für kleinere Übertragungen den Dienst aus, mit dem Sie je nach Übertragungsszenario Daten in Cloud Storage und aus Cloud Storage übertragen oder Daten zwischen Dateisystemen übertragen können.

Bucket-Standort

Für Arbeitslasten, die Rechenressourcen erfordern, z. B. die Medienproduktion, sollten Sie Buckets in derselben Region oder in Dual-Regionen wie die Rechenressourcen erstellen. Mit dieser Methode lässt sich die Leistung optimieren, indem die Latenzzeiten für Lese- und Schreibvorgänge für Ihre Verarbeitungslasten, Kosten und Bandbreite gesenkt werden. Weitere Informationen zur Auswahl des Bucket-Standorts finden Sie unter Überlegungen zum Bucket-Standort.

Speicherklasse

Je nach Art der Media-Arbeitslast sollten Sie eine andere Storage-Klasse auswählen. Die empfohlenen Speicherklassen für verschiedene Media-Arbeitslasten sind:

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

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

Verwaltung des Datenlebenszyklus

Zur 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, des Aufbewahrens nicht aktueller Objektversionen und des Downgrades von Speicherklassen von Objekten, um Kosten zu senken.

Wenn Datenzugriffsmuster vorhersehbar sind, können Sie die Lebenszykluskonfiguration für einen Bucket festlegen. Wenn die Zugriffsmuster für Ihre Daten unbekannt oder unvorhersehbar sind, können Sie die Autoclass-Funktion für Ihren Bucket festlegen. Mit Autoclass verschiebt Cloud Storage Daten, auf die nicht häufig zugegriffen wird, automatisch in niedrigere Speicherklassen.

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

Bei VoD- und Livestreaming-Arbeitslasten ist das Ziel, Wiedergabefehler, Verzögerungen beim Start der Wiedergabe oder Pufferung während der Wiedergabe eines Videos auf dem Videoplayer des Endnutzers zu vermeiden. Diese Arbeitslasten erfordern auch die Skalierung von Lesevorgängen, um einer großen Anzahl gleichzeitiger Zuschauer gerecht zu werden. In allen Fällen sollte der Kunden-Traffic über ein CDN geleitet werden.

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. Dadurch wird die Latenz verringert und die Bandbreiteneffizienz erhöht. Mit einem CDN können Sie die Gesamtbetriebskosten senken, indem Sie Bandbreitenkosten reduzieren, die Ressourcennutzung optimieren und die Leistung verbessern. Mit Media CDN können Sie die Gesamtbetriebskosten für die Bereitstellung von Inhalten für Endnutzer senken, da die Kosten für das Auffüllen des Media CDN-Cache null sind. 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 des Ursprungs bereitstellen.

Wenn Sie ein Drittanbieter-CDN 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 zugelassenen Anbieter finden Sie unter Von Google zugelassene Dienstanbieter.

Im Folgenden sind die Optionen aufgeführt, die Sie beim Einrichten eines CDN konfigurieren können:

Standort für den Ursprungsschutz auswählen

Der Origin Shield-Standort ist ein Cache zwischen dem CDN und Cloud Storage. Wenn Sie den Speicherort des Ursprungsschilds in Ihrem CDN auswählen können, folgen Sie den CDN-Richtlinien, um zu entscheiden, ob es empfehlenswert ist, den Ursprungsschild näher an der Region Ihres Cloud Storage-Bucket oder an dem Ort zu platzieren, an dem sich der Traffic Ihrer Endnutzer konzentriert. Ein Ursprungsschild ist eine Schutzmaßnahme, die Ihren Ursprungsserver vor Überlastung schützt. CDNs mit Ursprungsabschirmung tragen dazu bei, die Ursprungslast zu verringern, indem ein zusätzlicher Cache zwischen dem Ursprung und dem CDN eingefü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 die Funktion zum Zusammenfassen von Anfragen für Ihr CDN aktiviert ist. Wenn Sie mehrere Anfragen in einer einzigen Anfrage zusammenfassen, werden die Kosten für Vorgänge der Klasse B in Cloud Storage gesenkt. CDNs haben verteilte Caches, die weltweit bereitgestellt werden, bieten aber die Möglichkeit, mehrere Endnutzeranfragen in einer einzigen Anfrage an den Ursprungsserver zusammenzufassen. Media CDN minimiert beispielsweise aktiv mehrere nutzergesteuerte Cache-Füllanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten. Dadurch wird die Anzahl der Anfragen an die Buckets reduziert.

Wiederholungsprozess im CDN konfigurieren

Konfigurieren Sie Wiederholungen für alle Serverprobleme mit dem HTTP 5xx-Antwortcode – 502, 503, 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 Wiederholungsversuche für den aktuellen Ursprung angeben. Informationen zum Wiederholen von Ursprungsanfragen in Media CDN finden Sie unter Ursprungsanfragen wiederholen.

Standortoptionen für die Bereitstellung von Inhalten

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

  • Um die Kosten zu optimieren, haben Buckets, die in einer einzelnen Region erstellt werden, die niedrigsten Speicherkosten.
  • Berücksichtigen Sie Folgendes, um die Verfügbarkeit zu optimieren:
    • Für die meisten Media-Arbeitslasten wird die Verwendung von Dual-Region-Buckets empfohlen, da Ihre Objekte in zwei Regionen repliziert werden, um eine bessere Verfügbarkeit zu erzielen.
    • Für Anwendungsfälle, die die Bereitstellung von Inhalten und Analysen mit Georedundanz erfordern, sollten Sie Buckets in Multiregionen verwenden, um die höchste Verfügbarkeit zu erzielen.
  • Berücksichtigen Sie Folgendes, um die Latenz zu optimieren und die Netzwerkkosten zu senken:
    • Wählen Sie für VoD die Regionen aus, die den meisten Ihrer Endnutzer am nächsten sind, oder die Region mit der höchsten Traffic-Konzentration.
    • Während des Livestreamings erhalten Buckets Schreibanfragen von Transcodern und Leseanfragen von einem CDN, das den Inhalt für Endnutzer zwischenspeichert und verteilt. Für eine bessere Streaming-Leistung sollten Sie regionale Buckets auswählen, die sich am selben Standort wie die für die Transcodierung verwendeten Rechenressourcen befinden.

Länge von Videosegmenten für Livestreams optimieren

Für Livestreams beträgt die niedrigste empfohlene Segmentgröße zwei Sekunden, da kurze Videosegmente anfälliger für Schreiblatenzen sind. Die Langzeit-Schreiblatenz bezieht sich auf langsame oder verzögerte Schreibvorgänge für Inhalte, auf die selten zugegriffen wird oder die nur wenige Anfragen erhalten.

Die räumliche Entfernung zwischen dem Speicherort des Buckets 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 Nutzererfahrung zu bieten, empfehlen wir, die Wiederholungsstrategie und die Anforderungsabsicherung für Schreibvorgänge auf den Transcodern zu verwenden, um Latenzen von mehr als zwei Sekunden für Schreibvorgänge in Cloud Storage zu minimieren. Außerdem sollten Sie mit längeren Pufferzeiten von etwa zehn Sekunden experimentieren.

Anzahl der 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. Bei 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. Dadurch werden die Verfügbarkeit und Latenz Ihres Buckets verbessert, da die Wahrscheinlichkeit von Wiedergabeproblemen sinkt.

Bei einem Livestream-Event mit höherem QPS sollten Sie die Skalierung für Ihren Bucket implementieren, indem Sie entweder Ihren Bucket vorab aufwärmen oder den hierarchischen Namespace für Ihren Bucket aktivieren. Bevor Sie die Skalierung für Ihren Bucket implementieren, sollten Sie die folgenden Aufgaben ausführen:

QPS zum Ursprung schätzen

Bei einem Livestream mit einer Million Zuschauern erhält das CDN eine Million QPS. Angenommen, Ihr CDN hat eine Cache-Trefferrate von 99,0 %. Der resultierende Traffic zu Cloud Storage beträgt dann 1%. Die QPS beträgt 1% der Gesamtzahl der Zuschauer (eine Million), also 10.000 QPS. Dieser Wert ist höher als die ursprüngliche E/A-Kapazität.

QPS überwachen und Skalierungsfehler beheben

Sie sollten die Abfragen pro Sekunde im Blick behalten und alle Skalierungsfehler beheben. Weitere Informationen finden Sie unter Cloud Storage-Monitoring – Übersicht . Um die Lese- und Schreibanfragen zu beobachten, sehen Sie sich in der Google Cloud -Konsole das Diagramm Gesamtzahl der Lese-/Listen-/Get-Anfragen bzw. das Diagramm Gesamtzahl der Schreibanfragen an. Wenn Sie die QPS für Buckets schneller skalieren als in den im vorherigen Abschnitt genannten Richtlinien für die Steigerung 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 höhere QPS skalieren, nachdem Sie die QPS zum Ursprung geschätzt haben.

Implementieren Sie die Skalierung der Abfragen pro Sekunde für Ihren Bucket, indem Sie ihn vorab aufwärmen.

Sie können den Skalierungsprozess vor einem Livestreaming-Event beschleunigen, indem Sie Ihren Bucket vorab aufwärmen. Generieren Sie vor dem Livestreaming-Event synthetischen Traffic für Ihren Bucket, der der erwarteten maximalen QPS entspricht, die der Ursprungsserver des CDN für das Event empfangen wird, zuzüglich eines zusätzlichen Puffers von 50 %, der die erwartete Cache-Trefferrate Ihres CDN berücksichtigt. Wenn Sie beispielsweise die QPS für Ihren Ursprung auf 10.000 geschätzt haben, sollten Sie für den simulierten Traffic 15.000 Anfragen pro Sekunde anstreben, um Ihren Ursprung auf das Ereignis vorzubereiten.

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

Gehen Sie beim Generieren dieses simulierten Traffics schrittweise vor. Beginnen Sie mit 5.000 Anfragen pro Sekunde und steigern Sie die Anzahl nach und nach, bis Sie Ihr Ziel erreicht haben. Plane vor dem Event genügend 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 anfangs 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 über 24 Stunden hinweg allmählich auf das Basisniveau. Wenn auf Ihrem Ursprungsserver mehrstündige Lücken zwischen den Livestream-Ereignissen auftreten, empfehlen wir, den Traffic vor jedem Ereignis zu simulieren.

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

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

Sequenzielle Namen für Videosegmente vermeiden, um QPS zu skalieren

Bei der QPS-Skalierung werden Anfragen auf mehrere Server verteilt. Wenn alle Objekte jedoch ein nicht randomisiertes oder sequenzielles Präfix verwenden, können Leistungsengpässe auftreten. Durch vollkommen zufällige Namen erhalten Sie die beste Lastenverteilung. Falls Sie 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 Objektnamen, den Sie verwenden möchten, beispielsweise my-bucket/2016-05-10-12-00-00/file1 ist, 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 die sequenzielle Benennung von Videosegmenten nicht vermeiden können, verwenden Sie Buckets mit aktiviertem hierarchischen Namespace, um höhere QPS zu erzielen.

Für jeden Livestream unterschiedliche Buckets verwenden

Bei gleichzeitigen Livestreams können Sie die Lese- und Schreiblast effektiv skalieren, ohne die IO-Limits für den Bucket zu erreichen, wenn Sie für jeden Livestream einen anderen Bucket verwenden. Wenn Sie für jeden Livestream unterschiedliche Buckets verwenden, werden große Ausreißer bei der Latenz aufgrund von Skalierungsverzögerungen reduziert.

Nächste Schritte