CDN-Optimierungen für OTT-Traffic - sinnvoll oder überflüssig?

   
Der Inhalt dieses Beitrags wurde uns von Akamai Technologies bereitgestellt.
<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >CDN-Optimierungen für OTT-Traffic - sinnvoll oder überflüssig?</span>

Wenn Sie Ihren Over-the-top Content in ein Content Delivery Network integriert haben, haben Sie dort wahrscheinlich die Standardeinstellungen übernommen. Und warum auch nicht?

Eine Standardmedienkonfiguration des CDN-Anbieters ist zunächst so konzipiert, dass kurze und auf HTTP basierende Segmentauslieferungen ohne größeren Aufwand möglich sind. Es beseitigt den ursprünglichen Engpass Ihrer Konnektivität und liefert Ihren Content mit einigen hundert Mb/s bis hin zu mehreren Gb/s zu Ihren Kunden aus, wodurch sich Ihr Service für den Endbenutzer verbessert. Verstehen Sie aber auch, was genau diese Standardkonfiguration bewirkt und wie Sie sie auf Ihren aktuellen Anwendungsfall hin optimieren könnten?

 

blog-content-akamai-ott-cdn01

 

Was erhält man genau mit einer Standard-Konfiguration? Hier ein Blick auf einige Details der meist chunk-basierten Bereitstellung über HTTP oder HTTPS

  • Spezielle TCP-Settings: Der direkte TCP-Verkehr zwischen Server und Client reagiert in der Regel sehr empfindlich auf Engpässe in einem permanent überlasteten Netz. Die Anzahl der TCP-Pakete einer bestimmten Anforderung steigt nach dem ersten Handshake langsam an. Wann immer Pakete aufgrund von Engpässen in der Mitte der Route ausfallen, halbiert sich die Anzahl der Pakete pro Anforderung sofort und wird langsam wieder hochgefahren. [Den theoretisch möglichen Durchsatz im Rahmen einer TCP-Kommunikation kann man gut hier mit dem TCP Throughput Calculator berechnen]. Dies erhöht die Zuverlässigkeit der Daten, allerdings auf Kosten des Durchsatzes. Die Standardmedienkonfiguration verwendet benutzerdefinierte TCP-Einstellungen, die speziell für das adaptive Streaming über persistente HTTP-Verbindungen entwickelt wurden, um die TCP-Verbindungszeiten zu reduzieren und einen schnelleren Hochlauf und schnellere oder geeignetere TCP-Timeouts zu ermöglichen.
  • Verbessertes Routing zurück zum Server: Wenn Sie eine Verbindung für die Anfrage vom Client zum Server bereitstellen, werden die Verkehrswege im Netz in der Regel auf die niedrigste Anzahl von Hops gesetzt - immer abhängig von Netzwerk-Peering-Routinen. Dies ist jedoch nicht immer der schnellste Weg, da Datenengpässe nicht berücksichtigt werden. Akamai-Medienkonfigurationen prüfen hingegen alternative Routen zur nächsten Cache-Ebene oder zum nächsten Cache-Ursprung und leiten die Anfragen je nach Last und Traffic weiter, wobei langsame Hops umgangen werden, die normalerweise durch überlastetes Peering zwischen Netzwerken über das Internet verursacht werden. Manchmal ist der schnellste Weg von A nach B über C!
  • Cache-Einstellungen für spezifische Streaming-Formate: Die CDN-Medienkonfiguration ist nicht nur eine reine Skalierungserweiterung für Ihre Origin-Infrastruktur. Sie wurde entwickelt, um die Caching-Einstellungen speziell für das von Ihnen verwendete Streaming-Format so einzustellen, dass sie den Edge-Cache möglichst effizient nutzen und den Datenverkehr auf den von Ihnen betriebenen Ursprung reduzieren, auch wenn Sie diese Einstellungen oder Inhaltstypen dort nicht selbst konfigurieren.
  • Tiered Distribution: Alle Medienkonfigurationen werden mit einer solchen stufenweisen Distributions-Architektur geliefert. Regional eingesetzte Edge-Caches ohne zwischengespeicherte oder abgelaufene Objekte werden dabei mittels einer gemeinsamen, übergeordneten Schicht oder einem Edge-Peer überprüft, bevor sie zum Origin zurückkehren, was die Belastung reduziert. Diese abgestufte Verteilungsarchitektur ist abgestimmt auf Ihre regional-spezifische Kundenstruktur.
  • Media Mapping: Edge-Cache-Server und übergeordnete Distributions-Schichten können in sogenannten "Maps" zusammengefasst werden. Diese Maps bestimmen, wie der Verkehr über spezifische Verhaltensmuster geleitet wird. Media Mapping kann dabei auch geografisch spezifiziert sein - wie z.B. auf die Verteilung des lokalen (Landes-)Verkehrs oder des weltweiten Verkehrs - oder auch die Art der Inhalte, wie z.B. Video-on-Demand, Live-Streams oder sogar anspruchsvollem "Event"-Streaming. Der Traffic über Ihre Medienkonfiguration wird also  speziell über eine individualisierte Media-Map und nicht über eine generische HTTP(S)-Web-Traffic-Map bereitgestellt, was den Durchsatz und die Zuverlässigkeit deutlich verbessert. Die Server, die bestimmten Mappings zugeordnet sind, können den Lese-/Schreibzugriff auf den Arbeitsspeicher priorisieren, während Server in anderen Mappings hingegen auf die Lesegeschwindigkeit von persistenten Speichern optimiert sind. Wiederum andere Mappings können ein Gleichgewicht zwischen beiden Verfahren bieten oder eine verbesserte Edge-Peer-Konnektivität gegenüber einer übergeordneten Konnektivitätsebene bevorzugen. Es lohnt sich hier immer wieder einen Blick darauf zu werfen, ob sich Ihre Bedürfnisse seit der Einführung des Dienstes geändert haben.

blog-content-akamai-ott-cdn02

Prima, bis hierher also alles in Ordnung! Warum also dennoch einen genaueren Blick auf die Konfiguration werfen?

  • Wenn Sie Ihre Medienkonfiguration seit einiger Zeit nicht mehr überprüft haben, werden Sie bei einem erneuten Blick höchstwahrscheinlich einige Änderungen an den Self-Service-Optionen sehen. Dabei geht es vor allem um die Feinabstimmung auf Ihre genauen Bedürfnisse. Dabei gilt insbesondere: Entwickeln Sie ein möglichst tiefes Verständnis für den Ursprung Ihrer Daten und der benötigten Nutzerverteilung. Selbst wenn Sie seit dem Start Ihres Projektes schon zu bspw. kleineren Fragmenten oder einer höheren Auflösung übergegangen sind, können die aus diesem Verständnis gewachsenen Erkenntnisse Ihre Leistung signifikant verbessern. Wenn Sie beispielsweise die Latenzzeiten durch Reduzierung der Fragmentlängen optimiert haben: Haben Sie danach auch die TCP-Verbindungs-Timeouts, die Retry-Einstellungen oder die Peer-Request-Timeouts optimiert in Bezug auf diese Fragmentlängen?
     
  • Ein weiteres Beispiel für den lohnenswerten Blick ins Detail: Die Bitraten-Leiter - das Bereitstellen mehrerer Bitraten und Auflösungen - kann schnell dazu führen, dass Ihre TCP-Einstellungen angepasst werden müssen, um die optimale Leistung zu erzielen. Wenn Sie Ihren Publikumsstandort ursprünglich auf unbekannt oder global eingestellt haben und tatsächlich aber ein regionales Publikum bedienen, verbessert die richtige Konfiguration die Cache-Fähigkeit und Leistung. Zusätzlich können Sie Long-Tail-Inhalte auf eine andere Cache-Konfiguration verschieben, so dass diese Inhalte weniger wahrscheinlich durch anderen, kurzlebigeren Cache-Traffic beeinflusst werden.
  • Jetzt, da Sie Ihre Konfiguration also auf eine angemessenere Publikumserwartung  abgestimmt, den richtigen Origin ausgewählt haben, Ihre Content-Strategie optimiert und sogar Ihre neueste Encoding-Konfiguration und die Fragmentgröße angepasst haben - was muss noch getan werden? Für die meisten OTT-Kunden wird diese Out-of-the-Box-Konfiguration mit praxisgerechtem Self-Tuning gut sein, selbst wenn sie Hunderte von Gb/s linearen Simulcast-Verkehrs bedienen. Das CDN übernimmt die Skalierung, verbessert den Durchsatz zum Ursprung im Gegensatz zu Direktverbindungen, mildert DDoS-Angriffe und bietet sogar zusätzliche Funktionen wie Authentifizierung oder Logikregeln für Edge-Server. Die üblichen CDN-Funktionen wie Logik zur Erkennung des Origin-Zustands, Optionen für Ursprungs-Failover und Wiederholungsversuche sowie die dynamische Konstruktion von Response-Objekten wie Manifesten können zusätzlich zu den Standardeinstellungen durch Self-Service hinzugefügt werden.

Nun können wir anfangen, uns die Key Performance Indikatoren anzusehen, die Sie mit dem Ausbau Ihres Services festgelegt haben und Ihre Konfiguration auf diese KPIs abstimmen. Fragen dazu könnten sein: Ist Ihre Origin-Architektur besonders empfindlich gegenüber Lastspitzen? Möchten Sie Ihre Origin-Load noch weiter reduzieren? Haben Sie einen KPI rund um das Auftreten von Buffering im Client? Eine der Fragen, die wir normalerweise bekommen, wenn wir eine Feinabstimmung einer Konfiguration für eine bestimmte Lösung vorschlagen, ist: "Warum tut sie das nicht bereits?". Nun, die Antwort kann oft komplex sein, aber sie läuft darauf hinaus, kundenspezifische Geschäftsziele umzusetzen, die nicht immer miteinander vergleichbar sind. Eine Standard-Medienkonfiguration bietet ein ausgewogenes Verhältnis von Zuverlässigkeit, Leistung und Entlastung. In erster Linie ist sie dabei skalierbar ausgelegt. Wenn Sie nun beginnen, zugunsten eines dieser Ziele zu optimieren, geht dies oft auf Kosten eines der anderen - letztendlich ist es das Verständnis Ihres Geschäftsprozesses, das uns ermöglicht, die wirklich richtige Lösung anzubieten.

Eine der Optimierungen, die wir beispielsweise vornehmen können, ist Arbeit an der mittleren Schicht im Modell der Tiered Distribution. Die Konfiguration misst dabei ständig den Response-Durchsatz für eine Weiterleitungsanfrage an einen übergeordneten Benutzer. Wenn dieser bestimmte Durchsatzschwellen unterschreitet, öffnet er eine gleichzeitige, weitere Verbindung. Das Objekt wird dann von derjenigen Verbindung ausgeliefert, die zuerst antwortet. Es können dabei sogar Objektrückmeldungen aus partiellen byte range requests über getrennte Routen berücksichtigt werden. Das ist gut, um die Verzögerungen auf der mittleren Ebene zu reduzieren - insbesondere bei Netzbetreibern, die über das öffentliche Internet peeren. Das Verfahren verbessert KPIs, die auf Pufferung basieren, dies jedoch zu Lasten des Origins, der nun mehr Datenvolumen verarbeiten muss.

Wenn generelle Entlastung Ihr Hauptziel ist (z.B. weil Sie Ihre Origin-Struktur nicht dynamisch skalieren können oder empfindlich sind gegenüber Kosten durch Nachfragespitzen), können wir prüfen, ob die Traffic-Verteilung von der Einführung einer zusätzlichen Cache-Tier-Architektur oder zusätzlicher Peer-Anfragen profitieren würde. Zusätzliche, übergeordnete Tier-Schichten können mehr Entlastung bieten, insbesondere wenn das Publikum geografisch weiter verbreitet ist. Zusätzliche Ebenen führen jedoch auch zusätzliche Hops ein - etwas, das Sie vermeiden möchten, wenn die Vermeidung jeglichen Bufferings oder extrem niedrige Latenz Ihr wichtigster KPI ist. Das CDN kann Spitzen bereits "at the edge" glätten, indem es Anfragen in die Warteschlange stellt, während eine Weiterleitungsobjektanforderung "im Anflug" ist.

 

blog-content-akamai-ott-cdn03

 

Häufig angefragte Objekte können andere Objekte während geringer Nachfrage aus dem Edge-Cache-Speicher herausdrängen. Manchmal ist diese Cache-Verdrängung unvermeidlich, auch wenn sich das Objekt innerhalb seiner TTL befindet, da die Kapazität der Edges begrenzt ist. Da CDNs immer mehr Kapazität schaffen, werden sie aber dennoch über andere Streaming-Ebenen verteilt. Große Kunden mit hohem Traffic-Bedarf können sogar kundenspezifisches Mappings anfordern, die speziell auf ihre Zielgruppen und ihren Herkunftsort zugeschnitten sind. Sie können dies sogar bis zu einer verwalteten oder lizenzierten CDN-Bereitstellung skalieren, die dedizierte Computer für den Datenverkehr anbietet. Selbst ohne ein dediziertes Managed CDN (MCDN) kann das Verständnis rund um Beliebtheit Ihrer Inhalte (Long Tail, VOD etc.) bei der Auswahl einer Delivery Map helfen, bei der Sie mehr Chancen auf effiziente Cache-Treffer haben und Objekte nicht mit kurzlebigen Inhalten um den Cache Footprint konkurrieren.

Andere Optimierungen wären bspw. Überprüfungen nicht offensichtlicher Edge Peers auf das Vorhandensein von Objekten, bevor diese Anfrage an einen übergeordneten Cache weitergeleitet wird, Optimierung von Wiederholungsversuchen bei fehlgeschlagenen Aktionen, Verwaltung von Zugriffen auf das selbe Objekt oder den selben Response Code in Form von Warteschlangen auf Edge Servern, Manipulieren von Cache-Keys, Konsolidieren oder Verbreitern des Cache-Footprints, Bereitstellen  alternativer Mappings etc. - alle bergen dabei ein gewisses Maß an Kompromissen. Sie begünstigen entweder Leistung, Zuverlässigkeit oder Entlastung des Origins, meist auf Kosten der anderen Komponenten. Wenn Ihre Geschäftsziele jedoch in einem bestimmten Bereich stärker gewichtet werden müssen: Wir können Ihnen helfen, der Konfiguration einen Schub in die richtige Richtung zu geben, indem wir mit Professional Services Consultants zusammenarbeiten und sicherstellen, dass wir Ihre KPIs verstehen.

Weitere Anpassungen unter der Haube können vorgenommen werden, wenn Sie entweder mit sehr niedriger Latenzzeit arbeiten oder extreme VR/UHD-Bitraten überschreiten und eine spezielle Abstimmung wie z.B. Objektvorabruf benötigen, um die Leistung zu maximieren oder als Pufferzone für Zuverlässigkeit anzubieten. Wenn Ihr OTT-Traffic beginnt, Tb/s zu erreichen, können selbst die kleinsten Optimierungen - wie das Hinzufügen oder Reduzieren einer Sekunde in TCP-Wiederholungs- oder Timeout-Einstellungen - einen spürbaren Einfluss auf die Gesamtperformance und wichtige operative KPIs haben.

Akamai Technologies

Wir danken Akamai Technologies für die freundliche Bereitstellung der Inhalte.

Quelle des Original-Beitrags:
https://blogs.akamai.com/2019/03/cdn-tuning-for-ott---why-doesnt-it-already-do-that.html

Akamai Technologies
Amazon Web Services
Aspera, an IBM Company
Bitmovin
IABM
SRT Alliance
Wowza Media Systems
Zendesk