Die Qualität der Videoübertragung hängt davon ab, dass Millionen von Dingen richtig laufen, z. B. die Verwaltung einer ständig schwankenden Arbeitslast oder die Bewältigung von „Flash-Massen“, wenn eine große Anzahl von Zuschauern gleichzeitig einen Stream betritt. Aus diesem Grund erfordert die Bereitstellung eines zuverlässigen, qualitativ hochwertigen Videostreams als Teil eines kostenpflichtigen Dienstes – bei dem Zuschauer ein Fernseherlebnis erwarten – Tools und Kennzahlen, um Leistungsherausforderungen präzise darzustellen, damit Sie wissen, wo und wie Probleme behoben werden können.
CDNs sind eine unverzichtbare Lösung für das Video-Streaming, da sie auf der ganzen Welt Skalierbarkeit bei Bedarf mit geringer Latenz bieten. Zusätzlich zu den Optimierungen, die die Art und Weise verbessern, gleicht das CDN das chaotische Zuwachs der Zielgruppe aus, das mit einem Live-Stream einhergehen kann. Für eine hervorragende Leistung für den Endbenutzer ist eine zusätzliche Ebene an Transparenz, Metriken, Tools und Automatisierung erforderlich.
In diesem Beitrag sehen wir uns Beispiele für aktuelle Leistungsoptimierungen an, die wir für einen großen nordamerikanischen vMVPD-Streaming-Dienst durchgeführt haben. Dazu gehören:
- Kennzahlen, die wir zur Verbesserung/Behebung von Leistungsproblemen verwenden
- Wie Sie Leistung definieren und messen
- Kontinuierliche Optimierungen, die wir zur Verbesserung der Videoleistung durchführen
Autonome Systemnummern: Die Komplexität hinter dem Vorhang
Das moderne Web basiert auf mehreren miteinander verbundenen Schichten von Netzwerken, die als ASNs (autonome Systemnummern) bezeichnet werden. Jede davon besteht aus großen Gruppen von IP-Adressen, die mit CDNs (Content Delivery Networks) gekoppelt sind, um die Überlastung zu reduzieren, indem Inhalte an der Peripherie verfügbar gemacht werden. Wie unten dargestellt, besteht das Internet im Wesentlichen aus einem Netzwerk von Netzen, die jeweils ein eigenes Geschäftsmodell und eine ganz eigene Priorität aufweisen.
Quelle: Research Gate
In Verbindung mit der inhärenten Komplexität der interagierenden ASNs ist ihr Umfang und Umfang allein. Das vizAS-Tool versucht, die Verbindungen zwischen den vielen ASNs auf Länderbasis zu visualisieren. Allein in den USA gibt es beispielsweise 16.979 ASNs und 24.905 Peering-Beziehungen in den Netzwerken. Weltweit gibt es mehr als 90.000 Liefermeldungen.
https://stats.apnic.net/vizas/index.html
Aus unserer Sicht als CDN-Anbieter wird die Komplexität der Verbindung zu Tausenden von ASNs durch die Notwendigkeit verschärft, die Leistungsanforderungen jedes Kunden, das Nutzungsprofil, die Art des Datenverkehrs und viele andere Faktoren zu erfüllen. Ein Dienst wie Twitter hat beispielsweise ein wesentlich anderes Nutzungsprofil oder eine andere Fußfläche als ein Gaming-Unternehmen, das ein umfangreiches Update veröffentlicht. Ebenso hat ein Fernsehveranstalter, der ein Live-Sportereignis streamt, ein anderes Profil als ein On-Demand-Streaming-Dienst. Sogar zwei Live-Streaming-Dienste haben wahrscheinlich unterschiedliche Profile, die jeweils eine maßgeschneiderte Leistungsoptimierung erfordern.
Hinter den Kulissen haben wir eine große Anzahl von Konfigurationseinstellungen, die wir anpassen und anpassen können, um Kunden beim Erreichen ihrer Leistungsziele und -Anforderungen zu unterstützen. Für einige ist die Leistung vielleicht das, was sie von Anfang an erwartet (oder besser) haben, und wir müssen nichts ändern. Andere haben möglicherweise spezifische Ziele, wie schnellere TTFB (Time to First Byte), eine wichtige Metrik für Streaming-Dienste, die angegangen werden müssen.
Angesichts der Komplexität und Größe des Internets ist es nicht möglich, durch „Wackel-a-Mole“- oder „Streuschuss“-Ansätze nützliche und konsistente Leistungsverbesserungen zu erzielen. Echte Vorteile ergeben sich aus einer umfassenden Datenerfassung und intensiven Datenanalyse, um die Ursache eines Problems zu ermitteln oder proaktiv Einblicke in Änderungen der Netzwerkkonfiguration zu erhalten, von denen der Kunde am meisten profitiert.
Bereitstellung von RTT-Einblicken mit Stargazer
Eine der wichtigsten Kennzahlen zur Bestimmung der Netzwerklatenz und des allgemeinen Leistungszustands ist RTT (Round-Trip Time). Dies ist definiert als die Dauer, gemessen in Millisekunden, die ein Paket von der Quelle zum Ziel transportiert und eine Antwort an die Quelle zurückgesendet wird. Es kann zur Diagnose und Verbesserung der Netzwerkleistung über mehrere Vektoren hinweg verwendet werden, einschließlich Überlastung, Hardwareprobleme, Fehlkonfigurationen und Routing-Probleme.
Angesichts der Bedeutung dieser Metrik haben wir ein internes System namens Stargazer aufgebaut, mit dem wir RTT-Daten aus verschiedenen Quellen aggregieren, darunter unsere Sensoren, Daten, die wir von Kunden importieren, und Drittparteien, die auch RTT-Informationen überwachen. Stargazer überwacht ausgehende Antwortzeiten, die an den Client gehen. Andere Datenquellen können BGP-Tabellen (Border Gateway Protocol) von Routern, die Zuordnung von Routern zu geografischen Standorten, RTT-Protokolle für Verbindungen von Clients und Informationen zum Datenverkehrsvolumen umfassen. Zusätzlich kann das System bei Bedarf aktive Sonden wie z. B. Traceroutes und Pings durchführen.
Stargazer ermöglicht es uns, in Verbindung mit anderen von uns entwickelten Tools alle erfassten Daten abzufragen und detaillierte Analysen durchzuführen, die den Weg für kontinuierliche Verbesserungen ebnen. Unsere Netzwerkadministratoren können diese Informationen verwenden, um Probleme zu isolieren und Netzwerkrouten oder -Konfigurationen zu identifizieren, um die Leistung für spezifische Kundenziele und -Anforderungen zu optimieren. Und wie später besprochen wird, ist es auch nützlich, um die Auswirkungen neuer Technologien, wie das BBR-Protokoll (Engpass Bandwidth and Round-Trip Propagation Time), auf die Leistung zu verstehen.
Optimieren eines Ursprungsservers
Um einen besseren Einblick in die Funktionsweise der Leistungsoptimierung in der Praxis zu erhalten, sehen wir uns ein Beispiel an, an dem ein kürzlich hinzugekommener Live-Video-Streaming-Kunde beteiligt ist, der für eine Multi-CDN-Architektur optimiert werden musste. In einer herkömmlichen CDN-Client-Architektur stellt der Client eine Anfrage an einen unserer POPs, und der POP-Cache wird vom Ursprung aus gefüllt, wie unten gezeigt.
Dieser Kunde entschied sich jedoch für eine Multi-CDN-Architektur, um Redundanz und Ausfallsicherheit zu erhöhen und die Leistung potenziell zu steigern. Dies wird durch die in Abbildung 4 dargestellte Origin Shield-Architektur ermöglicht. Origin Shield bietet mehr Kontrolle darüber, wie der Datenverkehr verschiedener Kunden weitergeleitet werden kann, um eine optimale Leistung zu erzielen.
Im Gegensatz zu einer herkömmlichen CDN-Beziehung fließt der gesamte Datenverkehr, einschließlich des Datenverkehrs des zweiten CDN, zur Cache-Füllung an einen unserer POP (AGA) in Atlanta zurück. Der AGA POP dient dann als Ursprungsschild, genauer gesagt als Ursprungsschild, und entlastet damit den Ursprungsserver des Kunden. Der AGA POP wurde aufgrund seines höheren Cache-Trefferverhältnisses und seiner höheren Leistung als der zweite CDN als Ursprungsschild gewählt. Ein großes Problem war jedoch die Optimierung der Leistung zwischen den beiden CDNs.
Der erste Schritt in diesem Prozess bestand darin, die Routen des zweiten CDN nach AGA zu optimieren, wobei es als Ursprungsschild fungierte. Ein sofort offensichtliches Problem war eine schlechte Leistung zwischen den CDNs und eine hohe Anzahl von Verbindungstimeouts, die sich auf TTFB auswirkten. Um die Leistungsprobleme zu untersuchen, haben wir Stargazer verwendet, um eine Traceroute von AGA an das gewünschte Ziel zu senden und die ASNs zu erfassen, die für jeden Hop verwendet werden.
Wie in der nachfolgenden Zusammenfassung dargestellt, wurde eine Traceroute von AGA an eine IP-Adresse im zweiten CDN gesendet, um den Pfad des Clients zu simulieren.
Wir stellten fest, dass mehrere Hopfen innerhalb der ASN 7018 lagen, was nicht die bevorzugte Route war, da es mehr Hopfen gab und mehr Staus aufwies. Mit Stargazer haben wir das Problem schnell bestätigt und die entsprechenden Netzwerkänderungen vorgenommen. Wie die nachfolgende Zusammenfassung der Traceroute zeigt, haben wir nach der Netzwerkänderung die Hop-Anzahl verringert und die RTT durch Umschaltung auf ASN 7922 verbessert, wodurch auch das Problem mit TTFB-Timeouts behoben wurde.
In einem anderen Beispiel haben wir das Stargazer-Tool verwendet, um den besten Ursprungsschildpfad zum Ursprungsserver eines Kunden an der Ostküste zu ermitteln. Um die Belastung der Herkunft eines Kunden effektiv zu verringern und die Lieferleistung zu verbessern, sollte sich der Ursprungsschild POP nahe am Ursprung befinden. Manchmal ist es nicht unbedingt der nächste physische Pop, der am besten funktioniert. Es handelt sich um eine Kombination aus den wenigsten ASNs, der geringsten Überlastung und niedrigen RTT-Zeiten. Wie Sie in der Tabelle vor und nach unten sehen können, zeigte eine Stargazer Traceroute, dass der Wechsel vom NYA (New York) Pop zum DCC (Washington, D.C.) Pop die Hopfenanzahl auf drei reduziert hat, was zu einer allgemeinen Verbesserung der RTT-Leistung führte.
Tiefere Analyse mit Sweeper Fish
Mit mehr als 7.000 Interconnects und über 300 POPs in unserem CDN weltweit gibt es zahlreiche Optimierungsarbeiten. Damit wir nicht bei Aufgaben, die vielleicht keinen großen Unterschied machen, die Räder drehen, brauchten wir eine effiziente Methode, um die von unseren operativen Teams ergriffenen Maßnahmen zu priorisieren. Dieses Bedürfnis führte zur Entwicklung eines Begleitwerkzeugs zu Stargazer namens Sweeper Fish, das die Stellen bewertet, an denen Probleme bestehen, und es uns ermöglicht, sie auf priorisierte Weise aufzublasen.
Sweeper Fish ist auch nützlich, um festzustellen, ob eine Route überlastet ist und ob sie wahrscheinlich Probleme verursacht. Zurück zum Multi-CDN-Beispiel: Wir haben Sweeper Fish verwendet, um herauszufinden, welche Routen überlastet waren. Zu diesem Zweck hat Sweeper Fish das Delta zwischen dem 25. Und 75. Perzentil für RUM (Real User Measurement) für alle Kunden über alle Pfade zum AGA POP gemessen, wobei der Schwerpunkt auf dem Weg des zweiten CDN zu uns, ASN7922, lag. Die Standardabweichung für den gesamten Verkehr über diese ASN ist unten dargestellt.
Wir haben auch bestätigt, dass die vorherige Konfiguration über ASN7018 nicht der richtige Weg war. Die Analyse von Sweeper Fish ergab, dass der IQR (Interquartile Range) aufgrund von Überlastung auf dieser Route auf 20-60 bis Millisekunden angestiegen ist (siehe Abbildung 9). IQR, auch Midspread oder Middle 50 % genannt, bietet eine nützliche Möglichkeit, Routenprobleme schnell zu analysieren und zu kennzeichnen. Je niedriger der IQR, desto besser.
Im Gegensatz dazu lag der AGA POP konstant zwischen 10-22 Millisekunden auf der Strecke, die wir letztendlich verwendeten, ASN7922, wie unten gezeigt. Durch den Vergleich verschiedener Liefermeldungen können wir mit Sweeper Fish die beste und am wenigsten überlastete Route auswählen und/oder Probleme für die Behebung identifizieren.
TCP-Optimierung
Überlastung führt auch dazu, dass Pakete gelöscht und erneut übertragen werden. Dies tritt auf, wenn die Pfade zwischen den Pops weit entfernt sind und der TCP-Algorithmus nicht optimiert ist. Da AGA der Ursprung unseres Beispiels war, war es möglich, dass entfernte Pops, die AGA erreichten, dieses Problem hatten. Obwohl über viele Pops verteilt, ermöglichten uns die aggregierten CDN-Protokolle unten, Problembereiche zu identifizieren, wie in den Feldern angegeben.
Abbildung 11. Aggregierte Serverprotokolle identifizieren schnell Problembereiche, in denen Pakete gelöscht und erneut übertragen werden.
BBR wird ausgewertet
Engpass Bandwidth and Round-Trip Propagation Time (BBR) ist ein alternativer TCP-Engpasskontrollalgorithmus, der von Google entwickelt wurde und nun an Traktion gewinnt. Es unterscheidet sich von verlustbasierten Engpasskontrollalgorithmen wie dem allgegenwärtigen TCP-Cubic und führt ein anderes Betriebsparadigma ein. Es aktualisiert kontinuierlich, wie viele Daten im Flug sein können, basierend auf der minimalen RTT, die die Sitzung bisher gesehen hat, um eine Pufferaufblähung zu vermeiden.
Unsere Analyse ergab, dass BBR nützlich für die Verbesserung der RTT-Leistung ist, aber nicht eine universelle Lösung bietet. Es gibt Zeiten, in denen Sie es verwenden möchten, und andere, wenn Sie es nicht tun Stargazer hilft uns zu bestimmen, wann wir es verwenden möchten, indem wir das konsistente Profil von RTTs zu Zielen über Zeiträume hinweg verfolgen. Auf diese Weise können wir die besten Stellen für die Anwendung von BBR bestimmen, um die Anzahl der erneuten Übertragungen zu reduzieren und die Durchflusskontrolle zu verbessern.
Basierend auf der Analyse, die in den folgenden Tabellen gezeigt wird, kamen wir zu dem Schluss, dass die Umstellung auf BBR die Leistung des AGA POP auf das zweite CDN und den Kundenstamm geringfügig verbessern würde. Der erste Satz von Diagrammen zeigt, dass der Wechsel von TCP-Cubic zu TCP BBR zu einer Verringerung der erneuten Übertragungen führte, während der zweite Satz von Diagrammen zeigt, dass die Änderung von BBR einen leichten Anstieg des durchschnittlichen Durchsatzes bewirkt hat.
Abbildung 12. In diesem Beispiel führte der Wechsel von TCP-Cubic zu TCP BBR zu einer Verringerung der erneuten Übertragungen
Abbildung 13. In diesem Beispiel reduzierte der Wechsel zu BBR für die Flusssteuerung von TCP-Cubic für AGA POP die erneuten Übertragungen und einen leicht verbesserten durchschnittlichen Durchsatz.
Schlussfolgerung
Das Internet ist riesig und komplex – es ist im Wesentlichen ein Netzwerk von Netzen. Für Edgecast, jetzt Edgio, wäre eine Optimierung der Leistung für Kundenanwendungsfälle fast unmöglich, ohne detaillierte Analysen, um Einblicke in Problembereiche zu gewinnen und mögliche Konfigurationsänderungen zu testen. Um die Leistung für unsere Kunden zu verbessern, haben wir eine Reihe robuster Tools entwickelt, mit denen wir RTTs kontinuierlich überwachen können, damit wir schnell und effizient Verbesserungen in unserem gesamten Netzwerk vornehmen können. Für einen Live-Video-Streaming-Service haben wir Möglichkeiten gefunden, die Leistung für die individuellen Anforderungen zu optimieren und gleichzeitig die Verwendung von BBR für ihre Anwendung zu bewerten. Das Ergebnis war eine leistungsstarke Streaming-Lösung, die zwei CDNs nutzt. Und wir sind noch nicht fertig. Da die Netzwerküberlastung weiter zunimmt, werden wir unser Netzwerk immer weiter optimieren, um sicherzustellen, dass unsere Kunden und ihre Kunden das bestmögliche Online-Erlebnis genießen.
