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 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 Latenzen für Lese- und Schreibvorgänge 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

Mit Storage Transfer Service können Sie mehr als 1 TiB an Rohmediendateien aus einer lokalen Quelle wie einer Videokamera oder einem lokalen Speicher in Cloud Storage hochladen. Storage Transfer Service ermöglicht eine nahtlose Datenübertragung zwischen Objekt- und Dateispeichersystemen. Bei kleineren Übertragungen können Sie den Dienst auswählen, mit dem Daten in Cloud Storage und aus Cloud Storage übertragen oder zwischen Dateisystemen verschoben werden sollen.

Bucket-Standort

Für Arbeitslasten, die Compute-Ressourcen erfordern, z. B. für die Medienproduktion, sollten Sie Buckets in derselben Region oder Dual-Region wie die Compute-Ressourcen erstellen. Diese Methode trägt dazu bei, die Leistung zu optimieren, indem die Latenzen für Lese- und Schreibvorgänge für Ihre Verarbeitungsworkloads, 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 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 „Archive Storage“ sein. Sie können eine andere Speicherklasse für Objekte angeben, die unterschiedliche Verfügbarkeits- oder Zugriffsanforderungen haben.
  • 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

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, 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 niedrigere 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 eine große Anzahl gleichzeitiger Zuschauer zu berücksichtigen. In allen Fällen sollten Lesevorgänge für Kundentraffic ü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 sind. Sie können Media CDN als Quelle für andere CDNs von Drittanbietern verwenden. Auch bei anderen CDNs können Sie die TCO senken, wenn Sie Inhalte aus diesem Media CDN-Cache anstelle des Ursprungs 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 einzurichten. Ihr Netzwerkverkehr, der Google Cloudüber einen dieser Links ausgeht, profitiert von der direkten Konnektivität zu unterstützten CDN-Anbietern und wird automatisch zu einem reduzierten Preis 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 Standort für den Ursprungsschutz ist ein Cache zwischen dem CDN und Cloud Storage. Wenn Sie in Ihrem CDN den Standort für den Ursprungsschutz auswählen können, folgen Sie den CDN-Richtlinien, ob es empfehlenswert ist, den Ursprungsschutz näher an der Region Ihres Cloud Storage-Bucket oder am Standort mit der höchsten Konzentration Ihres Endnutzertraffics zu wählen. Ein Ursprungsschutz ist eine Schutzmaßnahme, die Ihren Ursprungsserver vor Überlastung schützt. CDNs mit Ursprungsschutz tragen dazu bei, die Ursprungsentlastung zu erhöhen, indem sie einen zusätzlichen Cache zwischen dem Ursprung 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 Anfragenminimierung für Ihr CDN aktiviert ist. Durch das Zusammenführen mehrerer Anfragen zu einer einzigen Anfrage werden die Betriebskosten für Vorgänge der Cloud Storage-Klasse B reduziert. CDNs verfügen über verteilte Caches auf der ganzen Welt, bieten aber eine Möglichkeit, mehrere Endnutzeranfragen zu einer einzigen Anfrage an den Ursprung zusammenzuführen. Media CDN minimiert beispielsweise aktiv mehrere nutzergesteuerte Cache-Füllungsanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten. Dadurch wird die Anzahl der Anfragen an die Buckets reduziert.

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 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 Verteilung von Inhalten

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 wird die Verwendung von 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 Georedundanz erfordern, verwenden Sie Buckets in einer Multiregion, 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 die Region mit der höchsten Konzentration des Traffics.
    • Beim Livestreaming erhalten 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 wählen Sie regionale Buckets aus, die sich am selben Standort wie die für die Transcodierung verwendeten Compute-Ressourcen befinden.

Länge von Videosegmenten für Livestreams optimieren

Für Livestreams beträgt die empfohlene Mindestsegmentgröße zwei Sekunden, da kurze Videosegmente empfindlicher auf lange Tail-Latenzen beim Schreiben reagieren. Longtail-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 räumliche 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 (QPS) 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 verringert wird.

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

QPS zum Ursprung schätzen

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

QPS beobachten und Skalierungsfehler beheben

Sie sollten die QPS beobachten und alle Skalierungsfehler beheben. Weitere Informationen finden Sie unter Übersicht zum Monitoring in Cloud Storage . Um die Lese- und Schreibanfragen zu beobachten, sehen Sie sich in der Google Cloud Consoledas Diagramm Gesamtzahl der Lese-/Auflistungs-/GET-Anfragenbzw. das Diagramm Gesamtzahl der Schreibanfragenan. Wenn Sie die QPS für Buckets schneller skalieren als in den im vorherigen Abschnitt genannten Richtlinien für die 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 QPS skalieren, nachdem Sie die QPS zum Ursprung geschätzt haben.

QPS-Skalierung für Ihren Bucket implementieren, indem Sie Ihren Bucket 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 zu Ihrem Bucket, der der erwarteten maximalen QPS entspricht, die der Ursprungsserver des CDN für das Event erhalten wird, zuzüglich eines zusätzlichen Puffers von 50 %, der die erwartete Cache-Trefferrate Ihres CDN berücksichtigt. Wenn Sie beispielsweise die QPS zu Ihrem Ursprung auf 10.000 geschätzt haben, sollte Ihr simulierter Traffic 15.000 Anfragen pro Sekunde umfassen, um Ihren Ursprung auf das Event vorzubereiten.

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

Gehen Sie beim Generieren dieses simulierten Traffics schrittweise vor. 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 Event 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 verdoppeln, beginnend mit 5.000 Anfragen pro Sekunde, 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 schrittweise auf den Ausgangswert. Wenn Ihr Ursprungsserver mehrstündige Lücken zwischen den Livestream-Events aufweist, empfehlen wir, vor jedem Event Traffic zu simulieren.

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

Cloud Storage-Buckets mit aktiviertem hierarchischem Namespace bieten im Vergleich zu Buckets ohne HNS bis zu achtmal so viele anfängliche QPS. 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.

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

Bei der QPS-Skalierung 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. Mit vollständig zufälligen Namen erzielen Sie die beste Lastverteilung. Wenn Sie jedoch sequenzielle Zahlen oder Zeitstempel als Teil Ihrer Objektnamen verwenden möchten, fügen Sie den Objektnamen eine Zufälligkeit hinzu, indem Sie vor der Sequenznummer oder dem Zeitstempel einen Hashwert hinzufügen. Wenn der ursprüngliche Objektname beispielsweise my-bucket/2016-05-10-12-00-00/file1 lautet, können Sie den MD5-Hash des ursprünglichen Objektnamens berechnen und die ersten sechs Zeichen des Hashs als Präfix zum Objektnamen 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 QPS 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