Personalisierte Fernseherlebnisse auf 1:1-Ebene verändern das Fernseherlebnis. Statt einer Einheitsgröße erhalten Zuschauer zielgerichtete und hochrelevante Werbung, maßgeschneiderte Inhalte, Empfehlungen für neue Programme und präzise DRM-/Blackout-Verwaltung, die alle auf Gerätetyp, Standort, Verlauf, demografische Daten und andere Daten Ihrer Zuschauer basieren.
Aber die Skalierung personalisierter Videostreams für Millionen von Zuschauern, insbesondere für Live-Programme wie Sport, ist fast genauso schwierig wie das Spielen im Baseball-Zyklus. Die Zuschauer können wild schwingen und sich bei wichtigen Momenten wie Anpfiff, Überstunden und bei Nahkämpfen um Hunderttausende von Zuschauern erhöhen. Angenommen, Ihre Infrastruktur zur Unterstützung der Personalisierung ist nicht anpassungsfähig und skalierbar genug. In diesem Fall ist Ihr personalisiertes Erlebnis vorbei und Ihr gesamtes Unternehmen könnte in der Welt von OTT gefährdet sein.
Die zentrale Rolle des Manifest-Servers bei der Personalisierung
Die OTT-Personalisierung hängt von der Leistung des Manifest-Servers ab, um eine eindeutige Wiedergabeliste mit Inhalten, Anzeigen und Wiedergabeanweisungen zu erstellen. Der Manifest-Server muss mit den folgenden Abhängigkeiten kämpfen:
- Ad-Server-Latenz – die Kommunikation mit Ad-Servern kann die Latenz erhöhen, die in den Workflow einbezogen werden muss, insbesondere wenn mehrere Hops betroffen sind.
- Monetarisierung/Berichterstellung – sobald die Anzeige wiedergegeben ist, muss ein Beacon an den/die Anzeigenserver gesendet werden, um den Eindruck der Anzeige zu messen und die Monetarisierung zu ermöglichen.
- Zustandslose Aspekte des Internets – damit personalisierte Manifeste skalierbar funktionieren, muss der Status über mehrere Anfragen für jeden Zuschauer hinweg beibehalten werden.
- DRM/Authentication – der Manifestserver muss die digitale Rechteverwaltung (DRM), Verschlüsselung auf Sitzungsebene und Authentifizierung im Auge behalten.
- Blackout-/Inhaltsrechte und -Beschränkungen – je nach Standort eines Benutzers können Streaming-Inhalte verschiedenen Blackout-Regeln unterliegen, die alle präzise verwaltet werden müssen.
- Inhaltsempfehlungen – Online-Zuschauer erwarten, dass Sie sie kennen und Ihre Empfehlungen personalisieren, um sie bei der Suche und Suche zu unterstützen.
- Inhaltslokalisierung – bei wichtigen Ereignissen ist es wichtig, den Benutzern die entsprechenden regionalen Variationen, einschließlich Audiospuren, Untertiteln und Untertiteln, zur Verfügung zu stellen.
Personalisieren von Streams in Echtzeit
Wie in Teil 1 dieser Blogreihe beschrieben, wird ein Live- oder VOD-Feed von unserer Slicer-Softwareanwendung aufgenommen, codiert und verpackt. Werbegrenzen können eingefügt werden, damit Inhaltseigentümer das Erlebnis des Zuschauers anpassen können. Wenn Werbeanzeigen aufgenommen werden, werden sie auch über einen Slicer verarbeitet, der in der Cloud läuft, um ein Fernseherlebnis zu ermöglichen, das eher an die Broadcast erinnert.
Wenn der Slicer mit der Aufnahme des Live- oder VOD-Streams beginnt, kommuniziert er kontinuierlich mit unserer Backend-Infrastruktur und hält die Datenbank über die verfügbaren Segmente auf dem Laufenden. Manifest-Server verwenden diese Daten, um die Benutzererfahrung für jeden Betrachter zu personalisieren. Wenn ein Player einen Stream anfordert, bestimmt der Manifestserver, welche Video- und Audiosegmente in der Manifestdatei aufgelistet werden sollen, die als Wiedergabeliste fungiert. Die Möglichkeit, das Manifest dynamisch zu ändern oder auf Benutzerebene anzupassen, ermöglicht es, das Anzeigeerlebnis individuell anzupassen. Im Falle von Live-Videos wird alle paar Sekunden ein neues Manifest angefordert, sodass Anpassungen dynamisch von Manifest-Servern angewendet werden können, wenn sich die Anzeigebedingungen ändern.
Die zentrale Rolle des Manifest-Servers bei der Personalisierung von Videostreams
Wie oben gezeigt, steht im Mittelpunkt der Manifest Personalisierung die Kommunikation. Bei den meisten OTT-Geschäftsanforderungen bedeutet dies die Kommunikation mit Anzeigenservern, um zielgerichtete, personalisierte Anzeigen in Echtzeit bereitzustellen. Individuelle Daten, einschließlich IP-Adresse, Standort und Gerätetyp eines Zuschauers – im Wesentlichen alle Informationen, die wir erfassen können, ohne dabei strenge Regeln und Vorschriften für personenbezogene Daten einzuhalten – werden dem Anzeigenentscheidungssystem zur Verfügung gestellt. Die daraus resultierende Lösung ist robust genug, um zu erfahren, was für einen Zuschauer relevant ist, wenn er Werbung während Livestreams bereitstellt. Das System ist auch robust genug, um Herausforderungen wie Blackout-Beschränkungen und Inhaltsrechte pro Benutzer zu bewältigen und gleichzeitig wichtige Personalisierungsfunktionen wie Inhaltsempfehlungen und andere Lokalisierungen zu unterstützen.
Erstellung einer skalierbaren Manifest-Infrastruktur
In unserer Videoplattform ist der Manifest-Server für die Erstellung eines benutzerdefinierten Streaming-Manifests für jeden Zuschauer verantwortlich. Sie muss sich auch mit anderen oben genannten Anforderungen, wie inhaltlichen Einschränkungen und Empfehlungen, bewusst sein. Bei diesem Modell senden wir einen integrierten Stream, was bedeutet, dass es keine Probleme mit dem Pufferrad gibt, während Kunden darauf warten, dass Anzeigen mitten im Stream geladen werden.
Um ein ausfallsicheres Manifest-Bereitstellungssystem aufzubauen, halten wir Cluster von Manifest-Servern in der Cloud, die über verschiedene geografische Regionen rund um den Globus verteilt sind. In den USA sind diese Server beispielsweise in fünf Regionen im ganzen Land unterteilt. Wenn eine Anfrage für einen neuen Stream von einem US-amerikanischen Spieler eingeht, wird diese Anfrage zufällig an eine der US-Zonen weitergeleitet.
Die Herausforderung „donnernde Herde“
Dies mag nicht intuitiv erscheinen, aber es wird getan, um kaskadierende Fehlermodi zu verhindern. Die Mehrheit der US-Zuschauer ist im Osten des Landes angesiedelt. Wenn wir sie alle in die Zone umleiten würden, die ihnen am nächsten ist und unser Cloud-Anbieter in dieser Region einen Ausfall erlitten hätte, würde dies bei der Mehrheit unserer Zuschauer der Fall sein. Wenn all diese Zuschauer den Stream auffrischen und wir die Zuschauer nun in ihre nächstgelegene gesunde Zone leiten, würden wir ein Problem mit der „donnernden Herde“ erleben, bei dem alle Zuschauer aus der gescheiterten Zone nun in die nächstnächste Zone hineinlaufen. Der daraus resultierende unerwartete Anstieg des Datenverkehrs könnte möglicherweise zu einem sekundären Ausfall führen, bis unsere Systeme in der neuen Zone skaliert werden können, um den zusätzlichen Bedarf zu decken.
Stattdessen hilft die willkürliche Verteilung unserer US-Zuschauer, die Auswirkungen eines anfänglichen Ausfalls zu mildern und ermöglicht es uns, den Failover-Datenverkehr gleichmäßig auf die übrigen funktionsfähigen Zonen zu verteilen.
In unserer Streaming-Plattform verteilen wir die manifeste Serverlast auf Zonen. Dies verhindert eine Überlastung bestimmter Zonen bei Überspannungen des Publikums, insbesondere wenn Zuschauer während des Failovers plötzlich in eine benachbarte Zone verschoben werden.
Jede unserer Zonen verfügt über einen separaten Datenspeicher zur Speicherung der zugehörigen Sitzungsdaten. Sobald ein Viewer an eine Zone weitergeleitet wurde, erstellen wir eine Sitzung für diesen Viewer und speichern sie im Sitzungscluster der Zone. Die Sitzung besteht aus einer Reihe von Daten über den Viewer und den vom Kunden bereitgestellten Parametern, wie er die Sitzung für diesen Viewer anpassen möchte. Um die Herausforderung zu meistern, die durch die statuslose Natur des Internets entsteht, erstellen die Manifest-Server URLs für jede Session, die in dem Manifest enthalten ist, das an den Player zurückgegeben wird. Nachfolgende Anfragen vom Player werden direkt an die Zone weitergeleitet, in der die Sitzung des Zuschauers erstellt und gespeichert wurde (anstatt zufällig an eine der anderen Zonen weitergeleitet).
Wie in den drei folgenden Diagrammen dargestellt, können verschiedene Veranstaltungen je nach Größe des Publikums und ob das Publikum lokal oder geografisch verteilt ist, viele unterschiedliche Anforderungen erfüllen. Werfen Sie einen Blick auf die drei Beispiele, die die Infrastrukturprobleme veranschaulichen, denen Fernsehsender bei der Unterstützung von Live-Veranstaltungen gegenüberstehen.
Im ersten Szenario finden wir einen Food-Food-Wettbewerb statt (ja, wir haben einen davon live gestreamt), da er eine verteilte, aber kleine Zuschauergröße darstellt. Vielleicht wird der Tag kommen, an dem Lebensmittelwettbewerbe zum Mainstream werden, aber im Moment bleiben sie ein Nischenevent, das kleine Zuschauerzahlen in einer weiten Region anzieht. Die Belastung des Manifest-Servers kann problemlos über mehrere Zonen und Manifest-Server-Cluster verteilt werden. Hier wird der Wert der Personalisierung deutlich, da es einfach ist, Werbung einzufügen, die für jede Region geeignet ist, und auch Rechte und Blackouts verwalten zu können.
Das Szenario ändert sich erheblich für die Texas State Football Championship, wo eine große Anzahl von Zuschauern in derselben Region ist. Wir behandeln das auf verschiedene Arten. Wie oben erläutert, haben wir festgestellt, dass wir Zuschauer Manifest-Servern zuweisen können, die sich in Zonen außerhalb der unmittelbaren Geografie befinden, ohne dass dies das Erlebnis des Zuschauers beeinträchtigt. Darüber hinaus verfügen wir über ein System, das die Zuschauerebene in jeder Zone überwacht und bei Bedarf automatisch Server für die Manifest-Generierung pro Zone hochschalten kann.
Wir können eine Vorskalierung basierend auf der erwarteten Zuschauerzahl für große Veranstaltungen wie das NBA-Finale vornehmen. Dennoch gab es mehrere Ereignisse, bei denen unsere automatischen Skalierungssysteme fast eine Million Zuschauer ohne Vorwärmung bewältigten. Zusätzlich zur Erhöhung der Skalierbarkeit verbessert die Fähigkeit, die Last sofort auf Manifest-Server zu verteilen, und zwar zonenunabhängig, die Zuverlässigkeit und Redundanz im gesamten Netzwerk erheblich.
Spieleranfragen und Werbespots
Eine Reihe von Veränderungen und Trends in der Branche machen die Cloud-Skalierung wichtiger denn je. Ein wichtiger Faktor ist die Verkürzung des Intervalls zwischen den Anfragen des Spielers. Unsere standardmäßige Live-lineare 8-Sekunden-Spieleranfrage wird auf 5 Sekunden verschoben und kann bei Streams, bei denen eine geringe Latenz wichtig ist, alle 2 Sekunden so kurz sein. Dies wirkt sich stark auf die CPU-Auslastung aus, da der Server auf viermal so viele Anfragen reagieren muss (in 2-Sekunden-Intervallen im Vergleich zu 8-Sekunden-Intervallen). Außerdem müssen Blackout- und Inhaltsempfehlungen jetzt häufiger überprüft werden als in der Vergangenheit, um Fehler zu vermeiden.
In ähnlicher Weise wird die Welt der Ad-Tech immer komplexer und anspruchsvoller. Für jede Anzeige, die in einen Stream eingefügt wird, verfügt ein Anzeigenserver über mindestens fünf Beacons, die für Berichtszwecke verwendet werden. Eine serverseitige Anzeigeneinfügungslösung (SSAI) ist erforderlich, um sicherzustellen, dass diese Beacons gesendet werden, damit die Kunden von ihren Werbetreibenden bezahlt werden. Während fünf Signalleuchten das Minimum sind, kann es noch viel mehr geben. Tatsächlich haben wir Fälle gesehen, in denen eine einzelne Anzeige über 30 bis 100 Beacons berichten kann.
Darüber hinaus werden komplexe Netzwerke von Ad-Servern in den Kampagnen unserer Kunden immer häufiger eingesetzt. Mehrere Ad-Network-Hops können Latenzprobleme verursachen. Netzwerk Nr. 1 könnte beispielsweise sagen: „Hier ist die Liste der Anzeigen in dieser Pause“, nur um festzustellen, dass Werbung Nr. 2 in dieser Pause eine Anfrage an ein anderes Netzwerk erfordert. Ad #3 führt zwei weitere Hopfen ein und so weiter.
Im obigen Beispiel können Werbeunterbrechungen die CPU-Auslastung verdoppeln oder verdreifachen. Bei Anfragen von Live-Video-Playern kann dieser Faktor um 10 bis 30 % erhöht werden.
Looking Ahead – Mikroservices und Skalierbarkeit
Angesichts der zunehmenden Komplexität besteht einer der Schritte, die wir unternommen haben, darin, die verschiedenen Workloads, die zuvor von den Manifest-Servern verarbeitet wurden, in kleinere Microservices zu unterteilen. Der erste Schritt, den wir unternommen haben, besteht darin, die Kommunikation und das Beaconing von Ad-Servern auf ihren eigenen Service zu verlagern, um die Herausforderung der Latenz von Ad-Servern zu bewältigen. Dieser Ad-Proxy-Service bietet mehrere erweiterte Funktionen, die wir in einem demnächst erscheinenden Blogbeitrag ausführlicher besprechen werden.
In Zukunft werden wir weitere Microservices entwickeln, um mehr Arbeit von den Manifest-Servern zu entfernen und einen gezielteren Ansatz für die Skalierbarkeit anzubieten. Demnächst werden wir Zonen von mehreren Cloud-Anbietern hinzufügen, um gegen Ausfälle einzelner Cloud-Anbieter resistent zu sein.
Durch die Kopplung skalierbarer SSAI mit Microservices können wir die Serverkosten, die Struktur unserer Codebasis und andere spezifische Merkmale für den Anzeigenverkehr optimieren. Darüber hinaus können wir mehrere wichtige Herausforderungen meistern, darunter Latenzzeiten für Ad-Server, Einschränkungen bei Blackouts und Monetarisierung. Gleichzeitig kann unser Live-Video-Streaming-Service durch die Verteilung der Verarbeitungslast über mehrere Zonen hinweg breit skaliert werden und wichtige Herausforderungen meistern. So können wir Millionen von zeitgleich personalisierten Streams zuverlässig bereitstellen, ohne unser Bereitstellungsnetzwerk zu belasten.
