Home Technische Artikel Optimieren des CDN für Live-Streaming
Applications

Optimieren des CDN für Live-Streaming

About The Author

Outline

Die Flash-Menge und dein Live-Stream

Da Streaming-Dienste um eine begrenzte Anzahl von Zuschauern kämpfen und die Aufmerksamkeitsspanne schrumpfen, sind Live-Events, die nachweislich eine treibende Kraft für die Publikumsinteraktion sind, zu einem wichtigen Faktor in der Content-Strategie eines Publishers geworden. Doch so sehr Live-Streaming das Publikum zuverlässig liefern kann, ist das zuverlässige Streamen von Live-Events in großem Maßstab mit einer Reihe von Herausforderungen verbunden. Content Delivery Networks (CDNs) können eine bedarfsgerechte Skalierbarkeit ermöglichen, doch selbst die CDNs müssen für Live-Streaming optimiert werden. Die vielleicht offensichtlichste Herausforderung beim Livestreaming ist die „Flash-Menge“ – dieses Phänomen tritt auf, wenn viele Zuschauer gleichzeitig einen Livestream betreten – hungrig nach dem Start oder der Überstunden-Action. Nach dem typischen Zuschauerverhalten, das wir beim Streamen von mehr als 100.000 Sportveranstaltungen beobachtet haben, stieg die Zuschauerzahl während des NBA-Finalspiels 6 rasch von fast nichts bei Tipoff auf einen Höchststand von 2,04 Millionen Zuschauern im 3. Quartal. Die Zuschauerzahl stieg von weniger als 10.000 Sessions auf über 1 Million in der ersten Stunde und weitere 1,5 Millionen nach der Halbzeit, wobei sich manchmal mehr als 100.000 neue Zuschauer pro Minute summierten. Diese schnelle Skalierung setzt jedes CDN unter Druck. Die Bereitstellung von Live-Videos ist jedoch noch schwieriger. Jede Unterbrechung kann zu einer Unterbrechung der Wiedergabe führen.

Wie dieses Beispiel aus einem aktuellen Live-Event in unserem Netzwerk zeigt, erschwert das „Flash Crowd“-Phänomen die Bereitstellung von Videos über ein CDN als die Bereitstellung von Bytes mit regulärem Inhalt.

In diesem artikel werfen wir einen Blick auf Flash-Massen und andere Herausforderungen und erkunden dann, wie Verizon Media seine langjährige Erfahrung im CDN-Bereich nutzt, um einige der häufigsten Probleme für unsere Kunden zu lösen und es zur richtigen Wahl für die Bereitstellung hochwertiger Live-Events zu machen – egal ob Sport, Konzerte, Politik … oder vielleicht die erste Landung auf dem Mars.

Warum Live Stream Caching anders ist

Die Bereitstellung von Live-Ereignissen über das Internet erfordert die Verwendung eines oder mehrerer ABR-Streaming-Formate (Adaptive Bitrate), wie MPEG-DASH, Apple HLS, Adobe HDS und Microsoft Smooth Streaming. Es stützt sich in der Regel auf Standard-HTTP-Webserver als Ursprünge und CDNs, um den Inhalt skalierbar zu verteilen.

Unser großes globales CDN bei Verizon Media, jetzt Edgio, verfügt über viele POPs und eine Kapazität von mehr als 250 Tbit/s, sodass wir problemlos skalieren können, um große Datenverkehrsspitzen und Flash-Massen bewältigen zu können. Kapazität und Größe sind jedoch nur ein Teil der Gleichung. Besonders wichtig beim Live-Streaming ist, wie gut das CDN mit dem Ursprungsserver und den Clients interagieren kann, während es gleichzeitig für große Zuschauer skaliert wird.

Das Live-Traffic-Profil ist einzigartig und unterscheidet sich deutlich von allem anderen, selbst von VOD, da der Encoder während Live-Events ständig neue Mediensegmente (typischerweise 2–10 Sekunden) auf dem Ursprungsserver veröffentlicht und das CDN diese neu veröffentlichten Inhalte immer abruft und über das Netzwerk verbreitet. Dieser Vorgang dauert nicht Null, daher kann eine gewisse Latenz nicht vermieden werden. Es ist jedoch entscheidend, dass das CDN extrem effizient und intelligent ist, um den Cache zu füllen und Client-Anfragen während und, was noch wichtiger ist, vor dem Starten des Cache-Füllprozesses zu bearbeiten. Idealerweise sollte das CDN in der Lage sein, die Last auf dem Ursprungsserver auf ein absolutes Minimum zu beschränken und gleichzeitig zu vermeiden, dass der gesamten Medien-Pipeline zu viel zusätzliche Latenz hinzugefügt wird. Dadurch wird sichergestellt, dass Endbenutzer auf Clientseite eine reibungslose und kontinuierliche Wiedergabe genießen.

Unser CDN verfügt über eine breite Palette von Funktionen, mit denen wir die Entlastung des Ursprungs maximieren und die Benutzererfahrung vor, während und nach Abschluss eines Cache-Füllprozesses verbessern können.

Live Stream Cache-Optimierungen

Wie in der folgenden Grafik dargestellt, nutzt unsere Medienplattform eine Reihe von optimierbaren Optimierungen, um eine schnelle und zuverlässige Bereitstellung von Live-Streaming zu erreichen. In den folgenden Abschnitten erklären wir, warum sie wichtig sind und wie sie funktionieren.

Ursprungsschild

In erster Linie ist Origin Shield eine zusätzliche Caching-Schicht zwischen den CDN-Edge-Servern und dem Ursprung. Wir erstellen einen virtuellen Ursprung in einem der POPs, der wiederum alle Anfragen von allen anderen POP-Standorten verwaltet. Wenn ein CDN-Edge-Server eine Anforderung von einem Benutzer erhält und die Anforderung aus dem Cache nicht erfüllen kann, ruft der Edge-Server das Objekt aus dem Shield POP ab, anstatt direkt vom Ursprung des Kunden abzuziehen. Als globales CDN bieten wir Kunden die Möglichkeit, einen einzelnen POP als Schild oder einen POP pro Region (USA, EU, Asien usw.) zuzuordnen.

Origin Shield hilft uns, den Ursprungsserver bei großen Datenverkehrsspitzen und Flash-Menschenmengen zu schützen. Es reicht jedoch möglicherweise nicht aus, sich mit dem einzigartigen Verkehrsprofil von Live-Streaming auseinanderzusetzen.

Partielle Cache-Freigabe

Beim Live-Streaming ist es ein typisches Muster, dass mehrere Clients ein Segment des Streams anfordern, das sich noch nicht im Cache befindet. Es gibt mehrere Möglichkeiten, wie ein CDN diese Anfragen bearbeiten kann. Erstens kann die IT-Abteilung mehrere Anforderungen zur gleichzeitigen Cache-Füllung an den Ursprung senden (eine pro Anforderung jedes neuen Clients), wodurch Latenzzeiten minimiert und die Benutzererfahrung optimiert wird. Eine zweite Option besteht darin, eine einzelne Anforderung zum Befüllen des Cache zu senden, die den ersten Client ohne Verzögerung bedient, die anderen jedoch warten lassen, bis die vollständige Datei in den Cache geladen ist (diese Methode zielt darauf ab, die Belastung des Ursprungs zu minimieren).

Leider stellt keine dieser Optionen eine besonders gute Lösung dar.

Stattdessen schafft unser Ansatz ein Gleichgewicht zwischen diesen beiden Optionen, da eine einzelne Cache-Füllung, die bereits im Einsatz ist, von mehreren Clients gemeinsam genutzt werden kann, die denselben Inhalt anfordern, der sich bereits teilweise im Cache befindet. Die partielle Cache-Freigabe ermöglicht es anderen Clients, eine bereits vorhandene Cache-Füllung zu verlassen, sodass der Videoinhalt gleichzeitig an mehrere Clients gesendet werden kann, sobald er in den Cache geladen wird. Das Ergebnis: Kürzere Startzeiten, geringere Latenz und geringere Auslastung des Ursprungs.

Wartezeit Für Cachefüllung

Es gibt ein Intervall zwischen dem Zeitpunkt, zu dem der Client die Videodatei anfordert, und dem Zeitpunkt, zu dem sie in den CDN-POP geladen wird. Dieser Zeitpunkt ist sehr klein (er kann in nur wenigen Millisekunden geschehen), aber die Live-Streaming-Flash-Menge macht ihn zu einer sehr großen Herausforderung, da er aus Hunderten oder sogar Tausenden von Anfragen bestehen könnte. In diesem Fall wäre die oben beschriebene Funktion zur teilweisen Cache-Freigabe noch nicht gestartet worden. In der Regel wird dies als Eckfall betrachtet, aber es ist wahrscheinlicher, dass es beim Live-Streaming aufgrund von Flash-Massen auftritt. Zu diesem kritischen Zeitpunkt könnte das CDN den Ursprung überfordern, indem es zu viele Anfragen gleichzeitig weiterleitet.

Mehrere Anforderungen für dieselbe Datei werden gepoolt, um dieses Problem zu vermeiden, und nur eine einzelne Anforderung wird an den Ursprung gestellt. Cache Fill Wait Time ist ein virtueller Warteraum, um die Entlastung des Ursprungs zu verbessern und mit Flash-Massen fertig zu werden. Wenn die HTTP-Antwortheader für die einzelne Anforderung eintreffen und diese Anforderung beginnt, die Datei vom Ursprung zu empfangen, kann der Cache dann mit allen wartenden Benutzern im Pool gemeinsam genutzt werden. Die tatsächliche „Wartezeit“ (Millisekunden) ist in hohem Maße konfigurierbar und kann auf der Grundlage spezifischer Ursprungsfähigkeiten und Kundenanforderungen angepasst werden.

Untergeordnete Anforderung für Fehlschlag erstellen

Wenn mehrere Benutzer dieselben nicht zwischengespeicherten Inhalte anfordern, wie oben erläutert, besteht die Gefahr, dass sich der erste Client auf einem langsamen Gerät befindet, z. B. einem Smartphone mit einer 3G-Verbindung. Dies schadet allen anderen Clients, da ein Cache normalerweise mit der Geschwindigkeit gefüllt wird, mit der der Client den Inhalt aufnehmen kann. Um dieses Szenario zu vermeiden, können wir die Cache-Füllung vom potenziell langsamen/fehlgeschlagenen ersten Client und die Füllung vom Ursprung schneller (mit unserer maximalen Geschwindigkeit) entkoppeln. Diese Funktion ist auch zuverlässiger, da die Cache-Füllung jetzt auch dann fortgesetzt wird, wenn der anfängliche Client die Verbindung abbricht oder wenn die Verbindung unterbrochen wird. Wir beschreiben dieses Verhalten als untergeordnete Anforderung für Miss Diese Funktion löst auch eine Cache-Füllung für den gesamten Inhalt aus und erfüllt verschiedene Anforderungen im Bytebereich mit nur einem Trip zum Ursprungsserver. Spawn Sub-Request for Miss and Cache Fill Wait Time ergänzen sich gegenseitig in ihrer Verwendung und arbeiten zusammen, um das Live-Streaming zu beschleunigen und Kennzahlen wie die Videozeit bis zum Start und das Repuffering zu verbessern.

Weitere Live Streaming CDN-Optimierungen

Hot Filing
Da die Zuschauerzahl eines Live-Streams schnell zunimmt, werden die Cache-Server, die zuvor die Last bei 500 Zuschauern problemlos bewältigten, plötzlich überfordert, wenn sich die Zuschauerzahl innerhalb weniger Minuten verdreifacht oder vervierfacht. Darüber hinaus können sich die Zuschauer auf ein bestimmtes geografisches Gebiet konzentrieren, in der Regel für ein beliebtes sportliches oder politisches Ereignis. Bei vielen Live-Sportübertragungen oder -Meisterschaften dürfte die Zuschauerkonzentration in den Märkten um die teilnehmenden Teams deutlich höher sein.

In diesem Fall müssen Live-Stream-Segmente schnell auf andere Server innerhalb der betroffenen Pops repliziert werden, um die Last zu verteilen.

Hot Filing ist der Prozess der automatischen Erkennung und Replikation extrem beliebter Inhalte, wie z. B. Live-Stream-Segmente, auf mehreren Cache-Servern in einem POP, um großen Anforderungen gerecht zu werden. Dies ist eine gängige Praxis in Netzwerken zur Inhaltsbereitstellung, aber die Geschwindigkeit, mit der diese Verbreitung stattfinden kann, ist letztlich entscheidend. Dies ist ein Bereich, der für Edgio ständig im Mittelpunkt steht. Kürzlich haben wir unsere Replikationsgeschwindigkeit von 5 Sekunden auf etwa 1 bis 2 Sekunden gesenkt. Neben Livestreams können wir auch andere Inhalte, wie z. B. Werbung, in einem Livestream hochladen.

Kapazität und Bandbreite
Kapazität und Bandbreite beziehen sich auf die zusätzliche Kapazität, die zur Erfüllung der unvorhersehbaren Anforderungen von Livestreams erforderlich ist. So wie es keinen Ersatz für Kubikzentimeter für Muskelautos gibt, gibt es keinen Ersatz für Bandbreite mit CDNs. Um diese und andere Strategien zur Cacheoptimierung ins Spiel zu bringen, muss das Netzwerk über die Kapazität und Bandbreite verfügen, um großangelegte Live-Streams verarbeiten zu können und gleichzeitig die Belastung anderer Benutzer auszugleichen.

Derzeit sind mehr als 80 % der Inhalte in unserem Netzwerk Video, wobei ein Großteil des Datenverkehrs auf Livestreams entfällt. Wir haben über 125.000 verwaltete Live-Events in unserem Netzwerk bereitgestellt. Und da sich die Qualität der Inhalte und die wachsende Popularität von Livestreams weiter verbessern, sind wir auf dem besten Weg, bis Ende 2019 eine Netzwerkkapazität von 100 Tbit/s zu erreichen. Unser Netzwerk verfügt über mehr als 140 globale POPs und 5.000 Verbindungen oder Verbindungen auf der letzten Meile.

Alles Funktioniert Zusammen

Die hohen Anforderungen an Livestreaming bringen Ihre Technologie an die Grenzen. Für die Bereitstellung eines reibungslosen Streams an Tausende oder sogar Millionen von Personen sind spezielle Caching-Konfigurationen erforderlich. Die Kombination aus Origin Shield, partieller Cache-Freigabe, Wartezeit für Cache-Füllung, Spawn Sub Request for Miss und Hot Filing sind leistungsstarke Funktionen, die auf Ihre einzigartige Infrastruktur und Anforderungen für Live-Streaming zugeschnitten werden können. Sie versetzen unser CDN in die Lage, die bestmögliche Leistung für Live-Streaming-Ereignisse zu liefern, unabhängig davon, ob sich das Objekt bereits im Cache befindet, ob es sich nur teilweise im Cache befindet oder ob die Cache-Füllung noch nicht gestartet wurde und noch aussteht – und selbst dann, wenn die Anfrage tatsächlich die Anfrage des ersten Kunden nach einem einzigartigen Inhalt ist.

Das CDN ist ein wesentlicher Bestandteil der Live-Video-Infrastruktur. Das verteilte Serversystem stellt Ihren Benutzern Inhalte zur Verfügung, da es sowohl geografische Standorte als auch Netzwerkstandorte und den Ursprung selbst berücksichtigt, um Inhalte auf die schnellste und zuverlässigste Weise bereitzustellen. Die Techniken zur Optimierung des CDN für die Live-Bereitstellung unterscheiden sich jedoch erheblich von anderen Anwendungen, die ebenfalls von einem CDN profitieren, einschließlich Video-on-Demand (VOD). Mit den richtigen Cache-Optimierungen und viel Spielraum ist das CDN in der Lage, die Schwankungen und Variabilität zu bewältigen, die beim Live-Streaming inhärent sind.

Unser CDN bietet ausgereifte, bewährte Funktionen zur Inhaltsverteilung und Optimierungen, die die Belastung des Ursprungsservers minimieren und gleichzeitig Live-Streams an Zuschauer in großem Maßstab bereitstellen. Unsere Live-Video-Caching-Optimierungen, von denen viele auf individuelle Kunden abgestimmt werden können, schützen gemeinsam die Anforderungen von Zuschauern vor Überlastung Ihrer Videoinfrastruktur.