Wir beschleunigen Internet-Anfragen und schlafen ruhig.

Netflix – der Marktführer im Bereich Online-Streaming – ist ein Unternehmen, das dieses Segment maßgeblich geprägt hat und kontinuierlich weiterentwickelt. Netflix ist nicht nur für sein umfangreiches Katalogangebot an Filmen und Serien bekannt, das von nahezu jedem Ort der Welt und auf jedem Bildschirm verfügbar ist, sondern auch für seine zuverlässige Infrastruktur und die einzigartige Ingenieurkultur.

Ein anschauliches Beispiel für den Ansatz von Netflix zur Entwicklung und Wartung komplexer Systeme wurde auf der DevOops 2019 präsentiert von Sergej Fedorov – Entwicklungsdirektor bei Netflix. Als Absolvent der Fakultät für Angewandte Mathematik und Informatik an der Lobatschewski-Universität in Nischni Nowgorod war Sergej einer der ersten Ingenieure im Open Connect – dem CDN-Team von Netflix. Er hat Systeme zur Überwachung und Analyse von Videodaten aufgebaut, den beliebten Dienst zur Bewertung der Internetgeschwindigkeit FAST.com ins Leben gerufen und arbeitet seit mehreren Jahren an der Optimierung von Internetanfragen, um sicherzustellen, dass die Netflix-App so schnell wie möglich für die Nutzer funktioniert.

Der Vortrag erhielt hervorragende Rückmeldungen von den Konferenzteilnehmern, und wir haben eine schriftliche Version für Sie vorbereitet.

In dem Vortrag erläuterte Sergej detailliert

• was die Verzögerung von Internetanfragen zwischen Client und Server beeinflusst;
• wie man diese Verzögerung reduzieren kann;
• wie man fehlertolerante Systeme entwirft, unterstützt und überwacht;
• wie man in kurzer Zeit Ergebnisse mit minimalem Risiko für das Unternehmen erzielt;
• wie man Ergebnisse analysiert und aus Fehlern lernt.

Die Antworten auf diese Fragen sind nicht nur für Menschen in großen Unternehmen wichtig.

Die vorgestellten Prinzipien und Techniken sollten von jedem, der Internetprodukte entwickelt und pflegt, gekannt und angewendet werden.

Nun folgt die Erzählung aus der Perspektive des Sprechers.

Die Bedeutung der Internetgeschwindigkeit

Die Geschwindigkeit von Internetanfragen ist direkt mit dem Geschäft verbunden. Betrachten wir den Bereich des Online-Shoppings: Das Unternehmen Amazon erklärte 2009, dass eine Verzögerung von 100 ms zu einem Verlust von 1 % der Verkäufe führt.Es gibt immer mehr mobile Geräte, und damit auch mobile Websites und Anwendungen. Wenn Ihre Seite länger als 3 Sekunden zum Laden benötigt, verlieren Sie etwa die Hälfte der Nutzer. Ab

Juli 2018 berücksichtigt Google die Ladegeschwindigkeit Ihrer Seite in den Suchergebnissen: Je schneller die Seite, desto höher ihr Rang bei Google. Die Geschwindigkeit der Verbindung ist auch in Finanzinstituten wichtig, wo Verzögerungen kritisch sind. Im Jahr 2015 hat das Unternehmen Hibernia Networks

abgeschlossen beendet eine Kabelverlegung zwischen New York und London für 400 Millionen Dollar, um die Verzögerung zwischen den Städten um 6 ms zu reduzieren. Stellen Sie sich vor, 66 Millionen Dollar pro 1 ms Verzögerungsreduktion!

Laut einer Studie, bei einer Verbindungsrate von über 5 Mbit/s hat die Geschwindigkeit keinen direkten Einfluss mehr auf die Ladegeschwindigkeit einer typischen Webseite. Allerdings gibt es eine lineare Abhängigkeit zwischen der Verbindungslatenz und der Ladegeschwindigkeit der Seite:

Netflix ist jedoch kein Standardprodukt. Die Auswirkungen von Latenz und Geschwindigkeit auf den Nutzer sind ein aktives Forschungs- und Entwicklungsfeld. Es gibt App-Ladezeiten und Content-Auswahl, die von der Latenz abhängen, aber das Laden statischer Elemente und das Streaming hängen ebenfalls von der Verbindungsgeschwindigkeit ab. Die Analyse und Optimierung der Schlüsselfaktoren, die die Servicequalität für den Nutzer beeinflussen, sind aktive Entwicklungsbereiche mehrerer Teams bei Netflix. Eine der Aufgaben besteht darin, die Anfragen zwischen den Netflix-Geräten und der Cloud-Infrastruktur zu reduzieren.

In diesem Bericht konzentrieren wir uns speziell auf die Reduzierung der Latenz am Beispiel der Netflix-Infrastruktur. Wir betrachten aus praktischer Sicht, wie wir die Prozesse des Designs, der Entwicklung und des Betriebs komplexer verteilter Systeme angehen können, um Zeit für Innovationen und Ergebnisse zu haben, anstatt für die Diagnose von Betriebsproblemen und Ausfällen.

Innerhalb von Netflix

Tausende verschiedener Geräte unterstützen die Netflix-Anwendungen. Ihre Entwicklung erfolgt durch vier verschiedene Teams, die separate Client-Versionen für Android, iOS, TV und Webbrowser erstellen. Wir investieren viel Energie in die Verbesserung und Personalisierung der Benutzeroberfläche. Dazu führen wir parallel Hunderte von A/B-Tests durch.

Die Personalisierung wird durch hunderte von Mikrodiensten in der AWS-Cloud unterstützt, die personalisierte Daten für den Nutzer bereitstellen, Anfragen verwalten, Telemetrie, Big Data und Encodierung durchführen. Die Visualisierung des Datenverkehrs sieht so aus:

Link zum Video mit Demo (6:04-6:23)

Links befindet sich der Einstiegspunkt, von dem aus der Datenverkehr auf mehrere Hundert Mikrodienste verteilt wird, die von verschiedenen Backend-Teams unterstützt werden.

Ein weiterer wichtiger Bestandteil unserer Infrastruktur ist das Open Connect CDN, das statische Inhalte wie Videos, Bilder und Code für Kunden bis zum Endbenutzer liefert. Das CDN ist auf maßgeschneiderten Servern (OCA - Open Connect Appliance) untergebracht. Innerhalb dieser Server befinden sich SSD- und HDD-Speicherplatten, die von einem optimierten FreeBSD-Betriebssystem, NGINX und einer Reihe von Diensten verwaltet werden. Wir entwerfen und optimieren die Hardware- und Softwarekomponenten so, dass der CDN-Server möglichst viele Daten an die Benutzer übertragen kann.

Die „Wand“ aus diesen Servern am Internet-Datenaustauschpunkt (Internet eXchange - IX) sieht folgendermaßen aus:

Internet Exchanges ermöglichen Internetanbietern und Content-Anbietern, sich miteinander zu „verbinden“, um Daten direkter im Internet auszutauschen. Weltweit gibt es etwa 70-80 Internet Exchange-Punkte, an denen unsere Server installiert sind, und wir kümmern uns selbst um deren Installation und Wartung:

Darüber hinaus bieten wir auch Server direkt an Internetanbieter an, die diese in ihr Netzwerk integrieren, um die Lokalisierung des Netflix-Traffics zu verbessern und die Streaming-Qualität für die Benutzer zu erhöhen:

Das AWS-Service-Paket ist verantwortlich für die Verwaltung von Videoanfragen von Kunden zu den CDN-Servern sowie für die Konfiguration der Server selbst – dazu gehören die Aktualisierung von Inhalten, Programmcode, Einstellungen usw. Zu diesem Zweck haben wir auch ein Backbone-Netzwerk aufgebaut, das die Server an Internet Exchange-Punkten mit AWS verbindet. Das Backbone-Netzwerk ist ein globales Netzwerk aus Glasfaserkabeln und Routern, die wir gemäß unseren Bedürfnissen gestalten und konfigurieren können.

Nach Bewertungen von Sandvine, unsere CDN-Infrastruktur liefert zu Spitzenzeiten etwa ⅛ des weltweiten Internetverkehrs und ⅓ des Verkehrs in Nordamerika, wo Netflix am längsten aktiv ist. Beeindruckende Zahlen, aber für mich ist eine der bemerkenswertesten Leistungen, dass das gesamte CDN-System von einem Team von weniger als 150 Personen entwickelt und gewartet wird.

Ursprünglich wurde die CDN-Infrastruktur für die Bereitstellung von Videodaten konzipiert. Im Laufe der Zeit haben wir jedoch erkannt, dass wir sie auch zur Optimierung dynamischer Anfragen von Kunden in die AWS-Cloud nutzen können.

Über die Beschleunigung des Internets

Heute hat Netflix 3 AWS-Regionen, und die Verzögerung bei den Anfragen an die Cloud hängt davon ab, wie weit der Kunde von der nächstgelegenen Region entfernt ist. Dabei verfügen wir über zahlreiche CDN-Server, die für die Auslieferung statischer Inhalte genutzt werden. Gibt es eine Möglichkeit, diese Infrastruktur zu nutzen, um dynamische Anfragen zu beschleunigen? Das Caching dieser Anfragen ist leider nicht möglich, da die APIs personalisiert sind und jedes Ergebnis einzigartig ist.

Lassen Sie uns ein Proxy auf dem CDN-Server einrichten und den Traffic darüber leiten. Wird das schneller sein?

Technische Grundlagen

Erinnern wir uns, wie Netzprotokolle funktionieren. Heute nutzt der Großteil des Internetverkehrs HTTPs, das von den darunter liegenden Protokollen TCP und TLS abhängt. Damit sich ein Client mit einem Server verbindet, muss er einen Handshake durchführen, und um eine gesicherte Verbindung herzustellen, muss der Client mindestens dreimal Nachrichten mit dem Server austauschen und mindestens einmal zusätzlich, um Daten zu übertragen. Bei einer Verzögerung von 100 ms pro Austausch (RTT) benötigen wir 400 ms, um das erste Datenbit zu erhalten:

Wenn wir Zertifikate auf einem CDN-Server platzieren, können wir die "Handshake"-Zeit zwischen Client und Server erheblich verkürzen, insbesondere wenn sich das CDN näher befindet. Angenommen, die Verzögerung zum CDN-Server beträgt 30 ms. Dann benötigt der erste Bit bereits 220 ms:

Aber die Vorteile enden hier nicht. Nachdem die Verbindung hergestellt wurde, erhöht TCP das Congestion Window (die Menge an Informationen, die es über diese Verbindung gleichzeitig übertragen kann). Wenn ein Datenpaket verloren geht, reduzieren klassische Implementierungen des TCP-Protokolls (wie TCP New Reno) das geöffnete "Fenster" um die Hälfte. Das Wachstum des Congestion Windows und die Geschwindigkeit seiner Wiederherstellung nach dem Verlust hängen wieder von der Verzögerung (RTT) zum Server ab. Wenn diese Verbindung nur zu einem CDN-Server führt, wird die Wiederherstellung schneller sein. Paketverluste sind dabei ein normales Phänomen, insbesondere in drahtlosen Netzwerken.

Die Internetbandbreite kann insbesondere während der Stoßzeiten aufgrund des Nutzertraffics sinken, was zu "Staus" führen kann. Dabei gibt es im Internet keine Möglichkeit, bestimmten Anfragen Priorität gegenüber anderen zu geben. Beispielsweise ist es nicht möglich, kleinvolumige und latenzempfindliche Anfragen im Vergleich zu "schweren" Datenströmen, die das Netzwerk belasten, zu priorisieren. Bei uns ermöglicht jedoch das Vorhandensein eines eigenen Backbone-Netzes, dies teilweise im Verlauf der Anfrage — zwischen dem CDN und der Cloud — zu realisieren, und wir können es vollständig konfigurieren. So kann sichergestellt werden, dass kleine und latenzabhängige Pakete bevorzugt behandelt werden, während große Datenströme etwas später verarbeitet werden. Je näher das CDN am Kunden ist, desto effektiver wird der Prozess.

Ein weiterer Einfluss auf die Latenz sind die Protokolle der Anwendungs-EBene (OSI Level 7). Neue Protokolle wie HTTP/2 ermöglichen eine Optimierung der Leistung parallel ablaufender Anfragen. Allerdings haben wir bei Netflix Kunden mit älteren Geräten, die diese neuen Protokolle nicht unterstützen. Nicht alle Kunden können aktualisiert oder optimal konfiguriert werden. Dabei besteht zwischen dem CDN-Proxy und der Cloud vollständige Kontrolle und die Möglichkeit, neue, optimale Protokolle und Einstellungen zu verwenden. Der ineffiziente Teil mit alten Protokollen wirkt sich lediglich zwischen dem Client und dem CDN-Server aus. Darüber hinaus können wir Multiplex-Anfragen über die bereits bestehende Verbindung zwischen dem CDN und der Cloud durchführen, was die Auslastung der Verbindung auf TCP-Ebene verbessert.

Wir messen

Obwohl die Theorie Verbesserungen verspricht, stürzen wir uns nicht sofort darauf, das System in die Produktion zu bringen. Stattdessen müssen wir zunächst nachweisen, dass die Idee in der Praxis funktioniert. Dazu müssen wir einige Fragen beantworten:

• Geschwindigkeit: Wird der Proxy schneller sein?
• Zuverlässigkeit: Wird er häufiger ausfallen?
• Komplexität: Wie integrieren wir es mit Anwendungen?
• Kosten: Was kostet der Einsatz zusätzlicher Infrastruktur?

Lassen Sie uns unseren Ansatz zur Bewertung des ersten Punkts im Detail betrachten. Die anderen werden auf ähnliche Weise behandelt.

Für die Analyse der Anfrageschnelligkeit möchten wir Daten von allen Nutzern erhalten, ohne viel Zeit für die Entwicklung aufzuwenden und ohne den Produktionsbetrieb zu stören. Dafür gibt es mehrere Ansätze:

1. RUM oder passives Messen von Anfragen. Wir messen die Ausführungszeit aktueller Anfragen von Nutzern und gewährleisten eine umfassende Abdeckung. Nachteil ist, dass das Signal nicht sehr stabil ist, da zahlreiche Faktoren Einfluss nehmen, wie die unterschiedlichen Größten der Anfragen und die Verarbeitungszeit auf Server und Client. Außerdem kann eine neue Konfiguration nicht getestet werden, ohne Auswirkungen auf die Produktion zu haben.
2. Labortests. Spezielle Server und Infrastruktur, die Clients simulieren. Damit führen wir die notwendigen Tests durch. So erhalten wir vollständige Kontrolle über die Messergebnisse und ein klares Signal. Aber wir haben keine vollständige Abdeckung der Geräte und Standorte der Nutzer (insbesondere bei einem Service weltweit und der Unterstützung von Tausenden von Geräten).

Wie können wir die Vorteile beider Methoden kombinieren?

Unser Team hat eine Lösung gefunden. Wir haben ein kleines Stück Code — einen Test — geschrieben, das wir in unsere Anwendung integriert haben. Die Tests erlauben es uns, vollständig kontrollierte Netzwerktests von unseren Geräten aus durchzuführen. Das funktioniert folgendermaßen:

1. Kurz nach dem Laden der Anwendung und dem Abschluss der Erstaktivitäten starten wir unsere Tests.
2. Der Kunde sendet eine Anfrage an den Server und erhält das 'Rezept' für den Test. Das Rezept besteht aus einer Liste von URLs, zu denen HTTP(s)-Anfragen gestellt werden müssen. Darüber hinaus konfiguriert das Rezept die Anfrageparameter: Wartezeiten zwischen den Anfragen, die Menge der angeforderten Daten, HTTP(s)-Header usw. Dabei können wir gleichzeitig mehrere verschiedene Rezepte testen — bei der Anfrage zur Konfiguration wird zufällig bestimmt, welches Rezept ausgegeben wird.
3. Die Startzeit des Tests wird so gewählt, dass sie nicht mit der aktiven Nutzung der Netzwerkressourcen des Kunden in Konflikt steht. Im Wesentlichen wird eine Zeit gewählt, in der der Kunde inaktiv ist.
4. Nach Erhalt des Rezepts stellt der Kunde Anfragen an jede der URLs parallel. Eine Anfrage an jede URL kann wiederholt werden – die sogenannten „Pulse“. Beim ersten Pulse messen wir, wie viel Zeit benötigt wird, um eine Verbindung herzustellen und Daten herunterzuladen. Beim zweiten Pulse messen wir die Ladezeit der Daten über die bereits hergestellte Verbindung. Vor dem dritten Pulse können wir eine Verzögerung einfügen und die Geschwindigkeit der erneuten Verbindungsherstellung messen usw.

   Während des Tests messen wir alle Parameter, die das Gerät erfassen kann:

   • Zeit der DNS-Anfrage;
   • Zeit für den Verbindungsaufbau über TCP;
   • Zeit für den Verbindungsaufbau über TLS;
   • Zeit bis zum Erhalt des ersten Datenbytes;
   • Gesamtzeit zum Laden;
   • Statuscode des Ergebnisses.
5. Nach Abschluss aller Pulse lädt die Probe die Ergebnisse aller Messungen für die Analyse hoch.

Die Hauptpunkte sind eine minimale Abhängigkeit von der Logik auf der Client-Seite, die Datenverarbeitung auf dem Server und die Messung parallel laufender Anfragen. Dadurch gewinnen wir die Möglichkeit, die Auswirkungen verschiedener Faktoren, die die Leistung von Anfragen beeinflussen, zu isolieren und zu testen, sie innerhalb eines einzigen Rezepts zu variieren und Ergebnisse von echten Kunden zu erhalten.

Diese Infrastruktur hat sich nicht nur für die Analyse der Anfrageleistung als nützlich erwiesen. Momentan verfügen wir über 14 aktive Rezepte, mehr als 6000 Proben pro Sekunde, die Daten aus allen Ecken der Welt erfassen und dabei vollumfängliche Geräteabdeckung bieten. Wenn Netflix einen solchen Service von Drittanbietern erwerben würde, würde dieser Millionen Dollar pro Jahr kosten, bei deutlich schlechterer Abdeckung.

Wir testen die Theorie in der Praxis: Prototyp

Mit einem solchen System haben wir die Möglichkeit erhalten, die Effizienz von CDN-Proxys hinsichtlich der Anfragelatenz zu bewerten. Jetzt müssen wir:

• einen Prototyp des Proxys erstellen;
• den Prototyp im CDN bereitstellen;
• festlegen, wie Kunden zu Proxys auf einem bestimmten CDN-Server geleitet werden;
• die Leistung mit Anfragen in AWS ohne Proxy vergleichen.

Das Ziel ist es, die Effizienz der vorgeschlagenen Lösung so schnell wie möglich einzuschätzen. Für die Umsetzung des Prototyps haben wir Go gewählt, da es gute Netzwerkbibliotheken bietet. Auf jedem CDN-Server haben wir den Prototyp als statisches Binary installiert, um Abhängigkeiten zu minimieren und die Integration zu vereinfachen. In der ersten Implementierung haben wir möglichst viele Standardkomponenten und kleinere Modifikationen für HTTP/2 Connection Pooling und Request Multiplexing verwendet.

Für die Lastverteilung zwischen AWS-Regionen haben wir eine geografische DNS-Datenbank verwendet, die auch für die Lastverteilung von Clients genutzt wird. Zur Auswahl des CDN-Servers für den Client verwenden wir TCP Anycast für Server im Internet Exchange (IX). In diesem Setup nutzen wir eine einzige IP-Adresse für alle CDN-Server, sodass der Client zu dem CDN-Server mit der geringsten Anzahl an IP-Hops geleitet wird. Auf den CDN-Servern, die bei Internetdienstanbietern (ISP) installiert sind, haben wir jedoch keine Kontrolle über den Router zur Konfiguration von TCP Anycast, deshalb setzen wir die gleiche Logik, nach der die Kunden zu Internetanbietern für Video-Streaming geleitet werden.

Wir haben also drei Arten von Verbindungen zu untersuchen: über das öffentliche Internet in die Cloud, über einen CDN-Server im IX oder über einen CDN-Server beim Internetdienstanbieter. Unser Ziel ist es herauszufinden, welcher Weg der beste ist und welchen Vorteil ein Proxy im Vergleich zur direkten Umleitung von Anfragen in die Produktion bietet. Dazu nutzen wir ein Testsystem wie folgt:

Jeder der Wege wird zu einem separaten Ziel, und wir beobachten die erreichte Zeit. Für die Analyse fassen wir die Proxy-Ergebnisse in einer Gruppe zusammen (wählen die beste Zeit zwischen IX und ISP Proxy) und vergleichen diese mit der Zeit der Anfragen in die Cloud ohne Proxy:

Wie zu sehen ist, sind die Ergebnisse zwiespältig – in den meisten Fällen bietet der Proxy eine gute Beschleunigung, jedoch gibt es auch eine signifikante Anzahl von Kunden, bei denen sich die Situation erheblich verschlechtert.

Zusammenfassend haben wir einige wichtige Punkte festgestellt:

1. Wir haben die erwartete Leistung von Anfragen der Kunden in die Cloud über einen CDN-Proxy bewertet.
2. Wir haben Daten von echten Kunden von sämtlichen Gerätetypen gesammelt.
3. Wir haben erkannt, dass die Theorie nicht zu 100 % bestätigt wurde und unser ursprünglicher Vorschlag mit dem CDN-Proxy für uns nicht funktionieren wird.
4. Wir haben kein Risiko eingegangen – keine Produktionskonfigurationen für unsere Kunden geändert.
5. Nichts ist kaputtgegangen.

Prototyp 2.0

Also, zurück an die Zeichentafel und den Prozess erneut durchlaufen.

Die Idee ist, anstelle von 100 % Proxy für jeden Kunden den schnellsten Weg zu bestimmen und die Anfragen dorthin zu leiten – das, was man Client-Steering nennt.

Wie setzen wir das um? Wir können die Logik nicht auf der Serverseite verwenden, da das Ziel ist, mit diesem Server zu verbinden. Wir müssen irgendwie das auf der Clientseite erledigen. Und idealerweise mit minimalem Aufwand an komplexer Logik, um nicht die Integration mit einer Vielzahl von Kundenplattformen zu verwalten.

Die Antwort ist die Verwendung von DNS. In unserem Fall verfügen wir über unsere eigene DNS-Infrastruktur und können eine Domainzone einrichten, für die unsere Server autoritativ sind. So funktioniert das:

1. Der Kunde sendet eine Anfrage an den DNS-Server unter Verwendung des Hosts, z. B. api.netflix.com.
2. Die Anfrage erreicht unseren DNS-Server.
3. Der DNS-Server weiß, welcher Weg für diesen Kunden der schnellste ist und gibt die entsprechende IP-Adresse aus.

Die Lösung bringt eine zusätzliche Komplexität mit sich: autoritative DNS-Anbieter sehen nicht die IP-Adresse des Kunden und können nur die IP-Adresse des rekursiven Resolvers berücksichtigen, den der Kunde verwendet.

Letztendlich muss unser autoritativer Resolver Entscheidungen nicht für einen einzelnen Kunden treffen, sondern für eine Gruppe von Kunden basierend auf dem rekursiven Resolver.

Für die Lösung verwenden wir dieselben Proben, aggregieren die Messergebnisse von Kunden für jeden der rekursiven Resolver und entscheiden, wohin wir diese Gruppe leiten – über ein Proxy über IX mit TCP Anycast, über ISP-Proxy oder direkt in die Cloud.

Wir erhalten ein solches System:

Das resultierende Modell für DNS Steering ermöglicht es, die Kunden basierend auf historischen Beobachtungen der Verbindungsgeschwindigkeiten von Kunden zur Cloud zu leiten.

Nochmals die Frage – wie effektiv wird ein solcher Ansatz sein? Um dies zu beantworten, verwenden wir erneut unser Proben-System. Daher konfigurieren wir eine Recency-Umgebung, in der eines der Ziele dem DNS Steering folgt, während das andere direkt in die Cloud geht (aktuelles Produktionssystem).

Schließlich vergleichen wir die Ergebnisse und erhalten eine Bewertung der Effektivität:

Dabei haben wir einige wichtige Erkenntnisse gewonnen:

1. Wir haben die erwartete Leistungsfähigkeit von Anfragen von Kunden an die Cloud mit DNS Steering bewertet.
2. Wir haben Daten von echten Kunden von sämtlichen Gerätetypen gesammelt.
3. Wir haben die Effektivität der vorgeschlagenen Idee nachgewiesen.
4. Wir haben kein Risiko eingegangen – keine Produktionskonfigurationen für unsere Kunden geändert.
5. Nichts ist kaputtgegangen.

Jetzt wird es ernst — wir gehen live.

Das Einfachste liegt nun hinter uns — wir haben einen funktionierenden Prototypen. Der herausfordernde Teil besteht jetzt darin, die Lösung für den gesamten Netflix-Verkehr bereitzustellen, sie auf 150 Millionen Nutzern, Tausenden von Geräten, Hunderten von Mikrodiensten und einer ständig wechselnden Produkt- und Infrastruktur zu implementieren. Auf die Netflix-Server treffen Millionen von Anfragen pro Sekunde ein, und man kann den Dienst mit einer unvorsichtigen Handlung leicht zum Erliegen bringen. Gleichzeitig möchten wir den Datenverkehr dynamisch über Tausende von CDN-Servern leiten, im Internet, wo sich ständig etwas ändert und bricht, oft im ungünstigsten Moment.

Und dabei besteht das Team aus nur drei Ingenieuren, die für die Entwicklung, Bereitstellung und vollständige Unterstützung des Systems verantwortlich sind.

Deshalb werden wir nun über ruhigen und gesunden Schlaf sprechen.

Wie können wir die Entwicklung fortsetzen, ohne die ganze Zeit mit Support beschäftigt zu sein? Unser Ansatz basiert auf drei Prinzipien:

1. Wir reduzieren den potenziellen Umfang von Fehlfunktionen (blast radius).
2. Wir bereiten uns auf Überraschungen vor – wir erwarten, dass etwas kaputtgeht, trotz Tests und persönlicher Erfahrung.
3. Sanfte Degradation – wenn etwas nicht richtig funktioniert, sollte es automatisch repariert werden, auch wenn es nicht die effizienteste Methode ist.

Es hat sich herausgestellt, dass wir in diesem Fall, mit diesem Ansatz für das Problem, eine einfache und effektive Lösung finden und die Systemunterstützung erheblich vereinfachen können. Wir haben erkannt, dass wir einen kleinen Code-Schnipsel in den Client einfügen und die Fehler bei Netzwerk-Anfragen, die durch Verbindungsprobleme verursacht werden, überwachen können. Bei Netzwerkfehlern führen wir ein Fallback direkt in die Cloud durch. Diese Lösung erfordert keinen erheblichen Aufwand für die Client-Teams, reduziert jedoch das Risiko unerwarteter Ausfälle und Überraschungen für uns erheblich.

Selbstverständlich folgen wir trotz des Fallbacks während der Entwicklung einer klaren Disziplin:

1. Probentest.
2. A/B-Tests oder Canaries.
3. Progressiver Rollout.

Bei den Proben wurde der Ansatz beschrieben – Änderungen werden zunächst durch ein eingerichtetes Rezept getestet.

Für das Canary-Testing benötigen wir vergleichbare Serverpaare, auf denen wir das System vor und nach den Änderungen vergleichen können. Dazu wählen wir aus unseren zahlreichen CDN-Standorten Paare von Servern aus, die vergleichbaren Traffic erhalten:

Anschließend installieren wir die Version mit den Änderungen auf den Canary-Servern. Zur Bewertung der Ergebnisse setzen wir ein System ein, das etwa 100-150 Metriken mit einer Stichprobe von Kontroll-Servern vergleicht:

Wenn das Canary-Testing erfolgreich ist, führen wir die Veröffentlichung schrittweise in Wellen durch. Auf jedem der Standorte aktualisieren wir die Server nicht gleichzeitig – der Verlust einer gesamten Website bei Problemen hat einen größeren Einfluss auf den Service für die Nutzer als der Verlust derselben Anzahl von Servern an unterschiedlichen Standorten.

Insgesamt hängt die Effizienz und Sicherheit dieses Ansatzes von der Anzahl und Qualität der gesammelten Metriken ab. Für unser System zur Beschleunigung von Anfragen sammeln wir Metriken von allen möglichen Komponenten:

• von den Clients – Anzahl der Sessions und Anfragen, Fallback-Raten;
• von Proxys – Statistik über die Anzahl und Dauer der Anfragen;
• von DNS – Anzahl und Ergebnisse der Anfragen;
• Cloud-Edge — Anzahl und Bearbeitungszeit von Anfragen in der Cloud.

All dies wird in einem einheitlichen Pipeline zusammengeführt, und je nach Bedarf entscheiden wir, welche Metriken für die Echtzeitanalyse gesendet werden und welche nach Elasticsearch oder Big Data für eine detailliertere Diagnostik gehen.

Wir überwachen

In unserem Fall nehmen wir Änderungen auf dem kritischen Anfragenweg zwischen dem Kunden und dem Server vor. Dabei ist die Anzahl der verschiedenen Komponenten auf dem Client, dem Server und dem Weg über das Internet enorm. Änderungen auf dem Client und Server geschehen ständig — während das Team an verschiedenen Projekten arbeitet und infolge natürlicher Veränderungen im Ökosystem. Wir befinden uns in der Mitte — bei der Problemdiagnose besteht eine hohe Wahrscheinlichkeit, dass wir involviert sind. Daher müssen wir klar verstehen, wie wir Metriken zur schnellen Lokalisierung von Problemen definieren, sammeln und analysieren.

Idealerweise haben wir vollständigen Zugriff auf alle Arten von Metriken und Filtern in Echtzeit. Aber es gibt so viele Metriken, dass die Kostenfrage aufkommt. In unserem Fall gliedern wir Metriken und Entwicklungstools wie folgt:

Zur Problemerkennung und -analyse verwenden wir unser eigenes Echtzeitsystem mit offenem Quellcode. Atlas und Lumen — zur Visualisierung. Es speichert aggregierte Metriken im Speicher, ist zuverlässig und integriert sich mit dem Alarmsystem. Für die Lokalisierung und Diagnose haben wir Zugriff auf Logs mit Elasticsearch und Kibana. Für statistische Analysen und Modellierungen setzen wir Big Data und Visualisierungen in Tableau ein.

Es scheint, dass es mit diesem Ansatz sehr schwierig zu arbeiten ist. Doch bei einer hierarchischen Organisation der Metriken und Tools können wir Probleme schnell analysieren, den Typ des Problems bestimmen und dann – in die detaillierten Metriken eintauchen. Um die Ursache eines Ausfalls zu identifizieren, benötigen wir im Durchschnitt etwa 1-2 Minuten. Danach arbeiten wir mit einem speziellen Team an der Diagnose – von mehreren Minuten bis hin zu einigen Stunden.

Selbst wenn die Diagnose schnell erfolgt, möchten wir, dass dies nicht häufig geschieht. Im Idealfall erhalten wir einen kritischen Alarm nur, wenn es erhebliche Auswirkungen auf den Service gibt. Für unser Anfragesystem haben wir lediglich 2 Alarme, die Benachrichtigungen auslösen:

• Prozentsatz des Client Fallback – Bewertung des Kundenverhaltens;
• Prozentsatz der Probe-Fehler – Daten zur Stabilität der Netzkomponenten.

Diese kritischen Warnungen überwachen, ob das System für die meisten Nutzer funktioniert. Wir beobachten, wie viele Kunden auf den Fallback zurückgegriffen haben, falls sie keine Beschleunigung der Anfragen erhalten konnten. Im Durchschnitt haben wir weniger als eine kritische Warnung pro Woche, obwohl im System viele Änderungen stattfinden. Warum reicht uns das aus?

1. Es gibt einen Kunden-Fallback für den Fall, dass unser Proxy nicht funktioniert.
2. Es gibt ein automatisches Steuerungssystem, das auf Probleme reagiert.

Dazu mehr im Detail. Unser System für Tests und das automatisierte System zur Bestimmung des optimalen Pfads für Anfragen vom Kunden in die Cloud ermöglichen es, automatisch mit bestimmten Problemen umzugehen.

Lassen Sie uns zu unserer Konfiguration der Tests und den drei Kategorien von Pfaden zurückkehren. Neben der Ladezeit können wir auch auf die tatsächliche Zustellung achten. Wenn das Laden von Daten nicht erfolgreich war, können wir anhand der Ergebnisse über verschiedene Pfade bestimmen, wo und was kaputt gegangen ist, und ob wir dies automatisch beheben können, indem wir den Anfragereise ändern.

Beispiele:

Dieser Prozess kann automatisiert werden. In das Steering-System integriert werden. Und ihm beigebracht werden, auf Probleme mit der Performance und Zuverlässigkeit zu reagieren. Wenn etwas anfängt, fehlerhaft zu sein – sofort handeln, wenn es eine bessere Option gibt. Dabei ist eine sofortige Reaktion nicht kritisch, dank Fallback auf den Clients.

Die Prinzipien zur Unterstützung des Systems können wie folgt formuliert werden:

• wir reduzieren das Ausmaß von Fehlern;
• wir sammeln Metriken;
• wir beheben automatisch Fehler, wenn möglich;
• wenn nicht, benachrichtigen wir;
• wir arbeiten an Dashboards und einem Triage-Toolset für schnelle Reaktionen.

Erlernte Lektionen

Für die Erstellung eines Prototyps wird nicht viel Zeit benötigt. In unserem Fall war er bereits nach 4 Monaten bereit. Mit ihm erhielten wir neue Metriken, und nach 10 Monaten ab Beginn der Entwicklung hatten wir den ersten Produktionsverkehr. Dann begann die mühsame und sehr komplexe Arbeit: das Produkt schrittweise zu entwickeln und zu skalieren, den Hauptverkehr zu migrieren und aus Fehlern zu lernen. Dieser effektive Prozess wird dabei nicht linear sein – trotz aller Bemühungen kann man nicht alles vorhersehen. Viel effektiver ist es, schnell zu iterieren und auf neue Daten zu reagieren.

Basierend auf unserer Erfahrung empfehlen wir Folgendes:

1. Vertrauen Sie nicht Ihrer Intuition.

   Unsere Intuition hat uns immer wieder im Stich gelassen, trotz der umfangreichen Erfahrung der Teammitglieder. Zum Beispiel haben wir die erwartete Beschleunigung durch die Nutzung eines CDN-Proxys oder das Verhalten von TCP Anycast falsch vorhergesagt.

2. Sammeln Sie Daten aus der Produktion.

   Es ist wichtig, so schnell wie möglich Zugriff auf zumindest einige Produktionsdaten zu erhalten. Die Anzahl einzigartiger Fälle, Konfigurationen und Einstellungen unter Laborbedingungen ist nahezu unmöglich zu replicieren. Der schnelle Zugang zu Ergebnissen ermöglicht es, potenzielle Probleme früher zu erkennen und diese in die Systemarchitektur einfließen zu lassen.

3. Folgen Sie nicht den Ratschlägen und Ergebnissen anderer – sammeln Sie Ihre eigenen Daten.

   Befolgen Sie die Prinzipien der Datensammlung und -analyse, aber übernehmen Sie nicht blind die Ergebnisse und Behauptungen anderer. Nur Sie können genau wissen, was für Ihre Nutzer funktioniert. Ihre Systeme und Ihre Kunden können sich erheblich von denen anderer Unternehmen unterscheiden. Glücklicherweise sind Analysewerkzeuge heute verfügbar und einfach zu verwenden. Die Ergebnisse, die Sie erhalten, stimmen möglicherweise nicht mit dem überein, was Unternehmen wie Netflix, Facebook, Akamai und andere behaupten. In unserem Fall unterscheiden sich die TLS-Leistung, HTTP2 oder DNS-Abfrage-Statistiken von den Ergebnissen von Facebook, Uber, Akamai – denn wir haben andere Geräte, Kunden und Datenströme.

4. Streben Sie nicht unnötig nach modischen Trends, ohne deren Effektivität zu bewerten.

   Beginnen Sie mit einfachen Lösungen. Es ist besser, ein einfaches funktionierendes System in kurzer Zeit zu schaffen, als viel Zeit mit der Entwicklung von Komponenten zu verschwenden, die Sie nicht benötigen. Fokussieren Sie sich auf die Herausforderungen und Probleme, die anhand Ihrer Messungen und Ergebnisse wichtig sind.

5. Seien Sie offen für neue Anwendungen.

   Ebenso schwierig wie es ist, alle Probleme vorherzusagen, ist es, im Voraus die Vorteile und Anwendungen zu erkennen. Lassen Sie sich von Startups inspirieren – ihre Fähigkeit, sich an die Bedürfnisse der Kunden anzupassen. In Ihrem Fall können Sie neue Probleme und deren Lösungen entdecken. In unserem Projekt hatten wir das Ziel, die Anfragenlatenz zu verringern. Allerdings haben wir während der Analyse und Diskussionen festgestellt, dass wir Proxy-Server auch für folgende Zwecke einsetzen können:

   • um den Traffic über AWS-Regionen zu balancieren und Kosten zu reduzieren;
   • um die Stabilität von CDNs zu modellieren;
   • um die DNS-Konfiguration zu optimieren;
   • um TLS/TCP zu konfigurieren.

Fazit

In meinem Bericht habe ich beschrieben, wie Netflix die Herausforderung meistert, Internetanfragen zwischen Kunden und der Cloud zu beschleunigen. Wie wir Daten durch ein Sampling-System bei den Kunden sammeln und die gesammelten historischen Daten nutzen, um Produktionsanfragen von den Kunden über den schnellsten Weg im Internet zu leiten. Wie wir die Prinzipien der Netzwerkprotokolle, unsere CDN-Infrastruktur, das Backbone-Netzwerk und DNS-Server verwenden, um dieses Ziel zu erreichen.

Unser Ansatz ist ein Beispiel dafür, wie wir bei Netflix ein solches System implementiert haben. Es hat bei uns funktioniert. Der praktische Teil meines Berichts für Sie sind die Prinzipien der Entwicklung und Wartung, denen wir folgen, um gute Ergebnisse zu erzielen.

Unsere Lösung könnte für Sie nicht passen. Dennoch bleiben die Theorien und Entwicklungsmethoden relevant, auch wenn Sie keine eigene CDN-Infrastruktur haben oder wenn Ihre Infrastruktur erheblich von unserer abweicht.

Die Geschwindigkeit der Anfragen hat auch eine entscheidende Bedeutung für das Geschäft. Selbst für einen einfachen Dienst müssen Sie Entscheidungen treffen: zwischen "Cloud"-Anbietern, dem Standort der Server, CDN- und DNS-Anbietern. Ihre Wahl wird die Effektivität der Internetanfragen für Ihre Kunden beeinflussen. Es ist wichtig, diesen Einfluss zu messen und zu verstehen.

Beginnen Sie mit einfachen Lösungen und bedenken Sie, wie Sie Ihr Produkt verändern. Lernen Sie im Prozess und optimieren Sie das System basierend auf den Daten Ihrer Kunden, Ihrer Infrastruktur und Ihres Unternehmens. Denken Sie bei der Planung an die Möglichkeit unerwarteter Ausfälle. So können Sie Ihren Entwicklungsprozess beschleunigen, die Effizienz der Lösung verbessern, unnötige Belastungen für den Support vermeiden und ruhig schlafen.

In diesem Jahr findet die Konferenz vom 6. bis 10. Juli statt im Online-Format. Sie können Fragen an einen der Väter von DevOps, John Willis, stellen!

Quelle: habr.com