Wie wir CDN MegaFon.TV geholfen haben, die Weltmeisterschaft 2018 nicht zu erreichen

2016 haben wir darüber gesprochen, wie MegaFon.TV mit allen fertig wurde, die die neue Staffel von Game of Thrones sehen wollten. Die Entwicklung des Dienstes hat hier nicht aufgehört, und bis Mitte 2017 mussten wir uns mehrmals mit Lasten befassen. In diesem Beitrag werden wir erzählen, wie uns dieses schnelle Wachstum dazu inspiriert hat, den Ansatz zur Organisation von CDN radikal zu ändern, und wie dieser neue Ansatz bei der Weltmeisterschaft getestet wurde.

Kurz über MegaFon.TV

MegaFon.TV ist ein OTT-Dienst zum Anzeigen verschiedener Videoinhalte - Filme, Fernsehsendungen, Fernsehkanäle und aufgezeichnete Programme. Über MegaFon.TV kann auf praktisch jedes Gerät zugegriffen werden: auf Handys und Tablets mit iOS und Android, auf Smart-TVs von LG, Samsung, Philips, Panasonic mit unterschiedlichen Erscheinungsjahren und einem ganzen Betriebssystem-Zoo (Apple TV, Android TV) Desktop-Browser unter Windows, MacOS, Linux, in mobilen Browsern unter iOS und Android und sogar auf exotischen Geräten wie STB und Android-Projektoren für Kinder. Es gibt praktisch keine Einschränkungen für Geräte - nur die Verfügbarkeit des Internets mit einer Bandbreite von 700 Kbit / s ist wichtig. Über die Organisation des Supports für so viele Geräte wird es in Zukunft einen separaten Artikel geben.
Die meisten Nutzer des Dienstes sind MegaFon-Abonnenten. Dies erklärt sich aus profitablen (und meist sogar kostenlosen) Angeboten, die im Tarifplan des Abonnenten enthalten sind. Wir stellen zwar auch einen deutlichen Anstieg der Nutzer anderer Betreiber fest. Entsprechend dieser Verteilung werden 80% des MegaFon.TV-Verkehrs innerhalb des MegaFon-Netzwerks verbraucht.

Architektonisch wurden Inhalte seit dem Start des Dienstes über CDN verbreitet. Wir haben einen separaten Beitrag , der der Arbeit dieses CDN gewidmet ist. Darin sprachen wir darüber, wie wir den Spitzenverkehr bewältigen konnten, der Ende 2016 während der Veröffentlichung der neuen Staffel von Game of Thrones zum Dienst ging. In diesem Beitrag werden wir über die Weiterentwicklung von MegaFon.TV und über neue Abenteuer sprechen, die zusammen mit der Weltmeisterschaft 2018 in den Dienst gestellt wurden.

Servicewachstum. Und Probleme

Im Vergleich zu den Ereignissen aus dem letzten Beitrag hat die Zahl der Megafon.TV-Nutzer bis Ende 2017 um ein Vielfaches zugenommen, Filme und Serien sind ebenfalls um eine Größenordnung größer geworden. Neue Funktionen wurden gestartet, neue Pakete erschienen, die "im Abonnement" verfügbar sind. Die Verkehrsspitzen seit dem „Game of Thrones“, die wir heute jeden Tag sehen, haben den Anteil der Filme und Fernsehsendungen am Gesamtstrom stetig erhöht.

Gleichzeitig begannen Probleme mit der Umverteilung des Verkehrs. Unsere Überwachung, die so konfiguriert ist, dass Chunks für verschiedene Arten von Datenverkehr in verschiedenen Formaten heruntergeladen werden, führte zunehmend zu Fehlern beim Herunterladen von Video-Chunks nach Zeitüberschreitung. Im MegaFon.TV-Dienst beträgt die Länge des Blocks 8 Sekunden. Wenn der Block innerhalb von 8 Sekunden keine Zeit zum Laden hat, können Fehler auftreten.

Es wurde erwartet, dass die Spitze der Fehler zu den am stärksten ausgelasteten Stunden auftritt. Wie sollte sich dies auf Benutzer auswirken? Zumindest konnten sie eine Verschlechterung der Videoqualität beobachten. Aufgrund einer ausreichend großen Anzahl von Profilen mit mehreren Bitraten ist dies mit bloßem Auge nicht immer erkennbar. Im schlimmsten Fall friert das Video ein.

Die Suche nach dem Problem begann. Fast sofort wurde klar, dass auf den EDGE-Servern von CDN ein Kickback-Fehler auftritt. Hier müssen wir einen kleinen Exkurs machen und erklären, wie die Server mit Live- und VOD-Verkehr arbeiten. Das Schema ist etwas anders. Ein Benutzer, der für Inhalte (eine Wiedergabeliste oder einen Block) zum EDGE-Server kommt, erhält Inhalte von dort, wenn sich Inhalte im Cache befinden. Andernfalls sucht der EDGE-Server nach Inhalten in Origin und lädt den Hauptkanal. Zusammen mit einer Wiedergabeliste oder einem Block wird der Header Cache-Control: max-age angegeben, der dem EDGE-Server mitteilt, wie viel diese oder jene Inhaltseinheit zwischengespeichert werden soll. Der Unterschied zwischen LIVE und VOD liegt in der Zeit, die zum Zwischenspeichern von Chunks benötigt wird. Für Live-Chunks wird eine kurze Caching-Zeit festgelegt, normalerweise von 30 Sekunden bis zu mehreren Minuten - dies ist auf die kurze Relevanzzeit von Live-Inhalten zurückzuführen. Dieser Cache wird im RAM gespeichert, da Sie ständig Chunks geben und den Cache neu schreiben müssen. Für VOD-Chunks wird mehr Zeit festgelegt, von mehreren Stunden bis zu Wochen und sogar Monaten - abhängig von der Größe der Inhaltsbibliothek und der Verteilung ihrer Ansichten unter den Benutzern. Wiedergabelisten werden normalerweise in nicht mehr als zwei Sekunden zwischengespeichert, oder sie werden überhaupt nicht zwischengespeichert. Es ist klarstellbar, dass es sich nur um den sogenannten PULL-Modus von CDN handelt, in dem unsere Server gearbeitet haben. Die Verwendung des PUSH-Modus wäre in unserem Fall nicht völlig gerechtfertigt.

Aber zurück zum Finden des Problems. Wie wir bereits bemerkt haben, haben alle Server gleichzeitig an der Rückgabe beider Arten von Inhalten gearbeitet. Gleichzeitig hatten die Server selbst eine andere Konfiguration. Infolgedessen wurden einige Maschinen mit IOPS überlastet. Chunks hatten aufgrund der geringen Leistung, Menge, des Datenträgervolumens und der großen Inhaltsbibliothek keine Zeit zum Schreiben / Lesen. Auf der anderen Seite versagten leistungsfähigere Computer, die mehr Verkehr erhielten, bei der CPU-Auslastung. CPU-Ressourcen wurden für die Wartung von SSL-Verkehr und über https gelieferten Chunks aufgewendet, während IOPS auf Festplatten kaum 35% erreichte.

Was benötigt wurde, war ein Schema, das es bei minimalen Kosten ermöglichen würde, die verfügbaren Kapazitäten optimal zu nutzen. Darüber hinaus sollte sechs Monate später die Weltmeisterschaft beginnen, und nach vorläufigen Berechnungen hätten sich die Spitzen im Live-Verkehr sechsmal erhöhen sollen ...

Neuer Ansatz für CDN

Nachdem wir das Problem analysiert hatten, beschlossen wir, VOD und Live-Verkehr nach verschiedenen PADs zu trennen, die aus Servern mit unterschiedlichen Konfigurationen bestehen. Erstellen Sie außerdem eine Funktion für die Verkehrsverteilung und deren Verteilung auf verschiedene Servergruppen. Insgesamt gab es drei solcher Gruppen:

• Server mit einer großen Anzahl von Hochleistungsfestplatten, die sich am besten zum Zwischenspeichern von VOD-Inhalten eignen. Tatsächlich wären SSD-RI-Festplatten mit maximaler Kapazität am besten geeignet, aber es gab keine, und es würde zu viel Budget erfordern, um die richtige Menge zu kaufen. Am Ende wurde beschlossen, das Beste zu verwenden, das verfügbar war. Jeder Server enthielt acht 1 TB 10k SAS-Festplatten in RAID5. Von diesen Servern wurde VOD_PAD kompiliert.
  
• Server mit viel RAM zum Zwischenspeichern aller möglichen Formate für die Bereitstellung von Live-Chunks, mit Prozessoren, die SSL-Verkehr verarbeiten können, und "dicken" Netzwerkschnittstellen. Wir haben die folgende Konfiguration verwendet: 2 Prozessoren mit 8 Kernen / 192 GB RAM / 4 Schnittstellen mit 10 GB. Von diesen Servern wurde EDGE_PAD kompiliert.
  
• Die verbleibende Servergruppe kann den VOD-Verkehr nicht verarbeiten, ist jedoch für kleine Mengen von Live-Inhalten geeignet. Sie können als Reserve verwendet werden. Von den Servern wurde RESERVE_PAD kompiliert.
  

Die Verteilung war wie folgt:

Ein spezielles Logikmodul war für die Auswahl des PAD verantwortlich, von dem der Benutzer Inhalte empfangen sollte. Hier sind seine Aufgaben:

• Analysieren Sie die URL, wenden Sie das obige Schema für jede Stream-Anforderung an und geben Sie das erforderliche PAD aus
  
• Um die Last alle 5 Minuten von den EDGE_PAD-Schnittstellen zu entfernen ( und dies war unser Fehler ), und wenn das Limit erreicht ist, schalten Sie den überschüssigen Verkehr auf RESERVE_PAD. Um die Last zu entlasten, wurde ein kleines Perl-Skript geschrieben, das die folgenden Daten zurückgab:
  - Zeitstempel - Datum und Uhrzeit der Aktualisierung der Ladedaten (im RFC 3339-Format);
  - total_bandwidth - aktuelle Schnittstellenlast (total), Kbps;
  - rx_bandwidth - aktuelle Schnittstellenlast (eingehender Verkehr), Kbit / s;
  - tx_badwidth - aktuelle Schnittstellenlast (ausgehender Verkehr), Kbit / s.
  
• Direkter Datenverkehr im manuellen Modus zu einem PAD- oder Origin-Server in unvorhergesehenen Situationen oder bei Bedarf Arbeiten an einem der PADs. Die Konfiguration befand sich auf dem Server im Yaml-Format und erlaubte es, den gesamten Datenverkehr zum gewünschten PAD oder Datenverkehr gemäß einem der folgenden Parameter zu leiten:
  - Inhaltstyp
  - Verkehrsverschlüsselung
  - Bezahlter Verkehr
  - Gerätetyp
  - Typ der Wiedergabeliste
  - Region
  

Origin-Server sind mit SSD unterbesetzt. Leider ließ HIT_RATE auf VOD-Chunks beim Umschalten des Datenverkehrs auf Origin zu wünschen übrig (ca. 30%), aber sie haben ihre Aufgabe erfüllt, sodass wir keine Probleme mit den Paketierern in CNN festgestellt haben.

Da es nur wenige Server für die EDGE_PAD-Konfiguration gab, wurde beschlossen, sie den Regionen mit dem größten Verkehrsanteil zuzuweisen - Moskau und der Wolga-Region. Mit Hilfe von GeoDNS wurde Verkehr aus den Regionen der Bundesbezirke Wolga und Ural in die Wolga-Region geschickt. Der Moskauer Hub diente dem Rest. Die Idee, Verkehr von Moskau nach Sibirien und in den Fernen Osten zu liefern, hat uns nicht wirklich gefallen, aber insgesamt machen diese Regionen etwa 1/20 des gesamten Verkehrs aus, und die Kanäle von MegaFon erwiesen sich als breit genug für solche Mengen.
Nach der Ausarbeitung des Plans wurden folgende Arbeiten durchgeführt:

• In zwei Wochen entwickelte sich die Funktionalität zum Umschalten von CDN
  
• Es dauerte einen Monat, um EDGE_PAD-Server zu installieren und zu konfigurieren sowie die Kanäle für sie zu erweitern
  
• Es dauerte zwei Wochen, um die aktuelle Servergruppe in zwei Teile aufzuteilen, und weitere zwei Wochen, um Einstellungen auf alle Server im Netzwerk und auf die Serverausrüstung anzuwenden
  
• Und schließlich wurde die Woche mit Tests verbracht (leider nicht unter Last, was sich später auswirkte)
  

Es stellte sich heraus, dass ein Teil der Arbeit parallelisiert wurde, und am Ende dauerte alles sechs Wochen.

Erste Ergebnisse und Zukunftspläne

Nach dem Tuning betrug die Gesamtsystemleistung 250 Gbit / s. Die Lösung mit der Übertragung des VOD-Verkehrs auf separate Server zeigte sofort nach der Einführung in die Produktion ihre Wirksamkeit. Seit Beginn der Weltmeisterschaft gab es keine Probleme mit dem VOD-Verkehr. Aus verschiedenen Gründen musste ich mehrmals den VOD-Verkehr auf Origin umstellen, aber im Prinzip kamen sie auch zurecht. Möglicherweise ist dieses Schema aufgrund der sehr geringen Verwendung des Caches nicht sehr effektiv, da wir SSDs zwingen, Inhalte ständig zu überschreiben. Aber die Schaltung funktioniert.

Was den Live-Verkehr betrifft, so erschienen zu Beginn der Weltmeisterschaft die entsprechenden Mengen, um unsere Entscheidung zu testen. Die Probleme begannen, als wir das zweite Mal mit einer Verkehrsumschaltung konfrontiert waren, als wir während des Spiels zwischen Russland und Ägypten das Limit erreichten. Als die Verkehrsumschaltung funktionierte, floss alles auf das Backup-PAD. In diesen fünf Minuten war die Anzahl der Anfragen (Wachstumskurve) so groß, dass das Backup-CDN vollständig verstopft war und Fehler einfloss. Zur gleichen Zeit wurde das Haupt-PAD während dieser Zeit freigegeben und begann ein wenig untätig zu bleiben:



Daraus wurden 3 Schlussfolgerungen gezogen:

1. Fünf Minuten sind immer noch zu viel. Es wurde beschlossen, die Entladezeit auf 30 Sekunden zu verkürzen. Infolgedessen wuchs der Verkehr auf dem Standby-PAD nicht mehr krampfhaft:
   
   
2. Es ist mindestens erforderlich, Benutzer bei jedem Auslösen des Schalters zwischen PADs zu übertragen. Dies sollte eine zusätzliche reibungslose Umschaltung gewährleisten. Wir haben beschlossen, jedem Benutzer (oder vielmehr dem Gerät) ein Cookie zuzuweisen, nach dem das für die Verteilung zuständige Modul versteht, ob der Benutzer auf dem aktuellen PAD belassen werden soll oder ob ein Wechsel durchgeführt werden soll. Hier kann die Technologie im Ermessen desjenigen liegen, der sie implementiert. Infolgedessen wird der Datenverkehr auf dem Haupt-PAD nicht unterbrochen.
   
3. Der Schwellenwert für das Umschalten wurde zu niedrig eingestellt, wodurch der Verkehr auf dem Backup-PAD wie eine Lawine wuchs. In unserem Fall war dies eine Rückversicherung - wir waren uns nicht ganz sicher, ob wir die richtige Serveroptimierung vorgenommen haben (die Idee wurde übrigens von Habr übernommen). Der Schwellenwert wurde auf die physische Leistung von Netzwerkschnittstellen erhöht.
   

Die Verbesserungen dauerten drei Tage, und bereits beim Spiel zwischen Russland und Kroatien haben wir überprüft, ob unsere Optimierung funktioniert hat. Das Ergebnis hat uns im Allgemeinen gefallen. In seiner Spitze verarbeitete das System gemischten Verkehr mit 215 Gbit / s. Dies war keine theoretische Einschränkung der Systemleistung - wir hatten immer noch einen erheblichen Spielraum. Bei Bedarf können wir jetzt bei Bedarf jedes externe CDN anschließen und überschüssigen Datenverkehr dort "wegwerfen". Ein solches Modell ist gut, wenn Sie nicht jeden Monat solides Geld für die Nutzung des CDN eines anderen bezahlen möchten.

Unsere Pläne beinhalten die Weiterentwicklung von CDN. Zunächst möchte ich das EDGE_PAD-Schema auf alle Bundesbezirke ausweiten - dies wird zu einer geringeren Nutzung der Kanäle führen. Es werden auch VOD_PAD-Redundanzschaltungstests durchgeführt, und einige der Ergebnisse sehen jetzt ziemlich beeindruckend aus.

Im Allgemeinen lässt mich alles, was im letzten Jahr getan wurde, denken, dass das CDN des Dienstes, der Videoinhalte verbreitet, ein Muss ist. Und nicht einmal, weil Sie dadurch viel Geld sparen können, sondern weil das CDN Teil des Dienstes selbst wird, wirkt sich dies direkt auf die Qualität und Funktionalität aus. Unter solchen Umständen ist es zumindest unvernünftig, es in die falschen Hände zu geben.