Best Practices für Media-Arbeitslasten

Mit Cloud Storage können Sie Audio- und Video-Assets speichern und bereitstellen, während Sie die Streaming-Leistung optimieren, die Wiedergabelatenz minimieren und die Kosten verwalten. Zur Unterstützung von Medienworkflows können Sie Cloud Storage inGoogle Cloud -Produkte wie Media CDN, Live Stream API, Transcoder API und Video Stitcher API einbinden. In diesem Dokument werden die Best Practices für die Verwendung von Cloud Storage für Medienarbeitslasten beschrieben.

Übersicht über Medienarbeitslasten

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

  • Medienproduktion: Umfasst Arbeitslasten wie die Postproduktion von Filmen, einschließlich Videobearbeitung, die rechenintensiv sind und häufig GPUs für Hochleistungs-Computing verwenden. Häufig werden medienbezogene 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. Diese Arbeitslasten erfordern eine Skalierung des aggregierten Lese- und Schreibdurchsatzes von Cloud Storage zu einem Compute-Cluster mit einer geringeren GPU-Inaktivitätszeit. Außerdem sind niedrige Lese- und Schreiblatenzen erforderlich, da dies entscheidend ist, um die Extremwertlatenz zu reduzieren.
  • Media Asset Management: Umfasst die Organisation Ihrer Media-Assets für eine effiziente Speicherung, Abfrage und Nutzung.
  • Bereitstellung und Verteilung von Inhalten: Umfasst das Streaming von Medien an Nutzer, einschließlich Video-on-Demand- (VoD) und Livestreaming-Diensten. Wenn Nutzer während des VoD-Streamings 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 wird der Inhalt in den Storage-Bucket geschrieben und gleichzeitig aus dem CDN gelesen.

Best Practices für Medienarbeitslasten

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

Datenübertragung

Verwenden Sie den Storage Transfer Service, um mehr als 1 TiB Rohmediendateien von 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 Sie Daten zu und von Cloud Storage oder zwischen Dateisystemen übertragen möchten, je nach Übertragungsszenario.

Bucket-Standort

Für Arbeitslasten, die Rechenressourcen erfordern, z. B. Medienproduktion, sollten Sie Buckets in derselben Region oder in denselben Dual-Regionen wie die Rechenressourcen erstellen. Mit dieser Methode können Sie die Leistung optimieren, indem Sie die Lese- und Schreiblatenzen für Ihre Verarbeitungslasten, die Kosten und die Bandbreite reduzieren. Weitere Informationen zur Auswahl des Bucket-Standorts finden Sie unter Überlegungen zum Bucket-Standort.

Speicherklasse

Je nach Art der Medienarbeitslast unterscheidet sich die Speicherklasse, die Sie auswählen sollten. Die empfohlenen Speicherklassentypen für verschiedene Medienarbeitslasten sind:

  • Für die Verwaltung von Medien-Assets wie Archivvideos sollte die Standardspeicherklasse eines Buckets „Archive Storage“ 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 werden Daten häufig aus einem Cloud Storage-Bucket gelesen. Daher sollten Sie die Daten in Standard Storage speichern.

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 Verwaltung des Objektlebenszyklus können Sie den Datenlebenszyklus verwalten. Dazu gehört das Festlegen einer Gültigkeitsdauer (TTL) für Objekte, das Aufbewahren nicht aktueller Objektversionen und das Downgraden 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 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 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 Zwischenspeichern während der Wiedergabe eines Videos im Videoplayer des Endnutzers zu vermeiden. Bei diesen Arbeitslasten müssen auch Lesevorgänge skaliert werden, um eine große Anzahl gleichzeitiger Zuschauer zu berücksichtigen. 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 Nutzererfahrung, da das CDN Inhalte zwischenspeichert, indem es die Latenz reduziert und die Bandbreiteneffizienz erhöht. Mit einem CDN können Sie die Gesamtbetriebskosten (TCO) senken, indem Sie die Bandbreitenkosten reduzieren, die Ressourcenauslastung optimieren und die Leistung verbessern. Mit Media CDN können Sie die Gesamtbetriebskosten für die Bereitstellung der Inhalte für Endnutzer senken, da die Kosten für das Cache-Füllen für Media CDN null sind. Sie können Media CDN als Quelle für andere Drittanbieter-CDNs verwenden. Bei anderen CDNs können Sie die TCO ebenfalls senken, wenn Sie Inhalte aus diesem Media CDN-Cache statt vom Ursprung bereitstellen.

Wenn Sie ein CDN eines Drittanbieters verwenden, können ausgewählte Anbieter mit CDN Interconnect an verschiedenen Standorten direkte Peering-Verbindungen zum Edge-Netzwerk von Google herstellen. Der Netzwerkverkehr, der von Google Cloudüber eine dieser Verbindungen ausgeht, profitiert von der direkten Verbindung zu unterstützten CDN-Anbietern und wird automatisch zu 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:

Standort des Origin Shield auswählen

Der Origin Shield-Standort ist ein Cache zwischen dem CDN und Cloud Storage. Wenn Sie in Ihrem CDN den Standort des Origin Shield auswählen können, folgen Sie den CDN-Richtlinien, um zu entscheiden, ob es empfehlenswert ist, den Origin Shield näher an der Region Ihres Cloud Storage-Bucket oder am Standort der Traffic-Konzentration Ihrer Endnutzer zu platzieren. Ein Origin Shield ist eine Schutzmaßnahme, die Ihren Ursprungsserver vor Überlastung schützt. CDNs mit Ursprungsabschirmung tragen dazu bei, die Ursprungsauslagerung 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ührung von Anfragen aktivieren

Achten Sie darauf, dass die Minimierung von Anfragen für Ihr CDN aktiviert ist. Durch das Minimieren mehrerer Anfragen in eine einzelne Anfrage werden die Kosten für Cloud Storage-Vorgänge der Klasse B reduziert. CDNs haben weltweit verteilte Caches, bieten aber eine Möglichkeit, mehrere Endnutzeranfragen in einer einzigen Anfrage an den Ursprung 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.

Wiederholungsverhalten im 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 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, die Daten aus Cloud Storage lesen, die nicht im CDN im Cache gespeichert sind, z. B. bei der 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 werden, die niedrigsten Speicherkosten.
  • Beachten Sie Folgendes, um die Verfügbarkeit zu optimieren:
    • Für die meisten Medienarbeitslasten wird die Verwendung von biregionalen Buckets empfohlen, da Ihre Objekte in zwei Regionen repliziert werden, um die Verfügbarkeit zu verbessern.
    • Für Anwendungsfälle, die Inhaltsbereitstellung und Analysen mit Georedundanz erfordern, verwenden Sie Buckets in Multiregionen, um die höchste Verfügbarkeit zu erreichen.
  • Beachten 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 die Inhalte im Cache speichert und an Endnutzer verteilt. Wählen Sie für eine verbesserte Streaming-Leistung regionale Buckets aus, die sich am selben Standort wie die für die Transcodierung verwendeten Rechenressourcen befinden.

Länge der Videosegmente für Livestreams optimieren

Für Livestreams wird eine minimale Segmentgröße von zwei Sekunden empfohlen, da kurze Videosegmente empfindlicher auf Longtail-Schreiblatenzen reagieren. Longtail-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 vorliegen.

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

Damit Zuschauer die bestmögliche Erfahrung haben, wird empfohlen, die Wiederholungsstrategie und die Anfrageabsicherung für Schreibvorgänge auf den Transcodern zu verwenden, um Longtail-Latenzen von mehr als zwei Sekunden für Schreibvorgänge in Cloud Storage zu minimieren und mit längeren Pufferzeiten von etwa zehn Sekunden zu experimentieren.

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 und die Verfügbarkeit und Latenz Ihres Buckets verbessern, indem die Wahrscheinlichkeit von Wiedergabeproblemen verringert wird.

Für ein Livestream-Ereignis mit höheren QPS sollten Sie die Skalierung für Ihren Bucket implementieren, indem Sie entweder Ihren Bucket vorwä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:

Abfragen pro Sekunde zum Ursprung schätzen

Angenommen, bei einem Livestream mit einer Million Zuschauern empfängt das CDN eine Million Abfragen pro Sekunde. Wenn Ihr CDN eine Cache-Trefferquote 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 im Blick behalten und Fehler bei der Skalierung beheben. Weitere Informationen finden Sie unter Monitoring in Cloud Storage . Wenn Sie die Lese- und Schreibanfragen überwachen möchten, sehen Sie sich in der Google Cloud Console das Diagramm Gesamtzahl der Lese-/Listen-/Get-Anfragen bzw. das Diagramm Gesamtzahl der Schreibanfragen an. Wenn Sie die Abfragen pro Sekunde für Buckets schneller skalieren, als in den im vorherigen Abschnitt genannten Richtlinien für die Hochskalierung angegeben, kann der Fehler 429 Too many requests auftreten. Fehler „429 Too many requests“ beheben

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

QPS-Skalierung für Ihren Bucket durch Vorwärmen des Buckets implementieren

Sie können den Skalierungsprozess vor einem Livestreaming-Ereignis beschleunigen, indem Sie Ihren Bucket vorwä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 erhalten wird, zuzüglich eines zusätzlichen Puffers von 50 %, der die erwartete Cache-Trefferquote Ihres CDN berücksichtigt. Wenn Sie beispielsweise die Abfragen pro Sekunde für Ihren Ursprung auf 10.000 geschätzt haben, sollte Ihr simulierter Traffic 15.000 Anfragen pro Sekunde erreichen, um Ihren Ursprung auf das Ereignis vorzubereiten.

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

Wenn Sie diesen simulierten Traffic generieren, sollten Sie einen schrittweisen Skalierungsansatz verfolgen. Beginnen Sie mit 5.000 Anfragen pro Sekunde und erhöhen Sie die Anzahl schrittweise, bis Sie Ihr Ziel erreichen. Planen Sie vor dem Ereignis 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 anfänglich 5.000 Anfragen pro Sekunde verdoppeln, dauert dies etwa 30 Minuten.

Der Ursprungsserver behält die Kapazität bei, bis der Traffic konsistent ist. Die Kapazität des Ursprungsservers nimmt innerhalb von 24 Stunden allmählich auf das Ausgangsniveau ab. Wenn zwischen den Livestream-Ereignissen auf Ihrem Ursprungsserver mehrere Stunden vergehen, 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 bis zu achtmal mehr anfängliche Abfragen pro Sekunde als Buckets ohne HNS. Die höheren anfänglichen Abfragen pro Sekunde erleichtern die Skalierung datenintensiver Arbeitslasten und sorgen für einen höheren Durchsatz. Informationen zu Einschränkungen in Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Einschränkungen.

Vermeiden Sie sequenzielle Namen für Videosegmente, um die Abfragen pro Sekunde zu skalieren.

Bei der QPS-Skalierung werden Anfragen auf mehrere Server verteilt. Wenn alle Objekte ein nicht randomisiertes oder sequenzielles Präfix verwenden, kann es jedoch zu Leistungsengpässen kommen. Die beste Lastverteilung erzielen Sie, wenn Sie vollständig zufällige Namen anstelle von sequenziellen Namen verwenden. Wenn Sie jedoch fortlaufende Nummern oder Zeitstempel als Teil Ihrer Objektnamen verwenden möchten, sollten Sie die Objektnamen zufällig gestalten, indem Sie vor der Sequenznummer oder dem Zeitstempel einen Hashwert hinzufü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 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 die sequenzielle Benennung von Videosegmenten nicht vermeiden können, verwenden Sie Buckets mit aktiviertem hierarchischen Namespace, um eine höhere Anzahl von Abfragen pro Sekunde zu erzielen.

Unterschiedliche Buckets für jeden Livestream 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. Wenn Sie für jeden Livestream einen anderen Bucket verwenden, werden große Ausreißerlatenzen aufgrund von Skalierungsverzögerungen reduziert.

Nächste Schritte