Wir beschleunigen Internetanfragen und schlafen ruhig

Netflix — der Marktführer im Bereich Streaming — ist ein Unternehmen, das diesen Sektor geschaffen und aktiv weiterentwickelt hat. Netflix ist nicht nur für sein umfangreiches Katalogangebot an Filmen und Serien bekannt, die nahezu von jedem Ort auf der Welt und mit jedem Gerät mit Bildschirm verfügbar sind, sondern auch für seine zuverlässige Infrastruktur und einzigartige Ingenieurskultur.

Ein anschauliches Beispiel für Netflix' Ansatz zur Entwicklung und Unterstützung komplexer Systeme wurde auf der DevOops 2019 vorgestellt von Sergei Fedorov — Direktor für Entwicklung bei Netflix. Absolvent der Fakultät VMT der NNSU benannt nach Lobatschewski, ist Sergei einer der ersten Ingenieure im Open Connect — CDN-Team bei Netflix. Er hat Systeme zur Überwachung und Analyse von Videodaten aufgebaut, den beliebten Dienst zur Messung der Internetgeschwindigkeit FAST.com gestartet und arbeitet seit einigen Jahren an der Optimierung von Internetanfragen, damit die Netflix-App für die Nutzer so schnell wie möglich funktioniert.

Der Vortrag erhielt beste Bewertungen von den Teilnehmern der Konferenz, und wir haben eine Textversion für Sie vorbereitet.

Im Vortrag erklärte Sergei ausführlich

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

Die Antworten auf diese Fragen sind nicht nur für diejenigen wichtig, die in großen Unternehmen arbeiten.

Die vorgestellten Prinzipien und Techniken sollten von jedem gekannt und praktiziert werden, der Internetprodukte entwickelt und unterstützt.

Als nächstes folgt das Narrativ aus der Sicht des Sprechers.

Die Bedeutung der Internetgeschwindigkeit

Die Geschwindigkeit von Internetanfragen steht in direktem Zusammenhang mit dem Geschäft. Betrachten wir den Bereich E-Commerce: Das Unternehmen Amazon gab 2009 an, dass eine Verzögerung von 100 ms zu einem Verlust von 1 % der Verkäufe führt.Immer mehr mobile Geräte und damit auch mobile Webseiten und Anwendungen kommen auf den Markt. Wenn Ihre Seite länger als 3 Sekunden zum Laden benötigt, verlieren Sie etwa die Hälfte der Nutzer. Seit

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

ab. abgeschlossen eine Kabelverbindung 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 für 1 ms Verringerung der Verzögerung!

Laut Forschung, die Verbindungsgeschwindigkeit über 5 Mbit/s hat keinen direkten Einfluss mehr auf die Ladegeschwindigkeit einer typischen Webseite. Es gibt jedoch eine lineare Abhängigkeit zwischen der Verzögerung der Verbindung und der Ladegeschwindigkeit der Seite:

Netflix ist jedoch kein typisches Produkt. Der Einfluss von Verzögerung und Geschwindigkeit auf die Nutzer ist ein aktives Analyse- und Entwicklungsfeld. Es gibt die App-Ladung und die Content-Auswahl, die von der Verzögerung abhängt, aber auch das Laden statischer Elemente und das Streaming hängen von der Verbindungsgeschwindigkeit ab. Die Analyse und Optimierung der Schlüsselfaktoren, die die Servicequalität für den Nutzer beeinflussen, ist ein aktives Entwicklungsfeld mehrerer Teams bei Netflix. Eine der Aufgaben besteht darin, die Verzögerung von Anfragen zwischen Netflix-Geräten und der Cloud-Infrastruktur zu reduzieren.

In diesem Bericht konzentrieren wir uns auf die Verringerung der Verzögerung (latency) am Beispiel der Netflix-Infrastruktur. Wir betrachten aus einer praktischen Perspektive, wie man an die Prozesse des Designs, der Entwicklung und des Betriebs komplexer verteilter Systeme herangeht und Zeit für Innovationen und Ergebnisse aufwendet, und nicht für die Diagnose von Betriebsproblemen und Störungen.

Innerhalb von Netflix

Tausende verschiedener Geräte unterstützen die Netflix-Anwendungen. Ihre Entwicklung übernimmt vier verschiedene Teams, die unterschiedliche Versionen des Clients für Android, iOS, TV und Webbrowser erstellen. Außerdem investieren wir viel Zeit und Mühe in die Verbesserung und Personalisierung der Benutzeroberfläche. Zu diesem Zweck führen wir Hunderte A/B-Tests parallel durch.

Die Personalisierung wird durch hunderte von Microservices in der AWS-Cloud unterstützt, die personalisierte Daten für den Nutzer, die Anfragenverwaltung, Telemetrie, Big Data und Encoding bereitstellen. Die Visualisierung des Traffics sieht folgendermaßen aus:

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

Links befindet sich der Einstiegspunkt, dann wird der Traffic auf mehrere Hundert Microservices verteilt, die von verschiedenen Backend-Teams unterstützt werden.

Ein weiterer wichtiger Bestandteil unserer Infrastruktur ist das Open Connect CDN, das statische Inhalte – Videos, Bilder, Client-Code usw. – bis zum Endbenutzer liefert. Das CDN befindet sich auf maßgeschneiderten Servern (OCA – Open Connect Appliance). Darin befinden sich SSD- und HDD-Speichermodule, die von einem optimierten FreeBSD-Betriebssystem mit NGINX und einer Reihe von Diensten verwaltet werden. Wir entwerfen und optimieren die Hardware- und Softwarekomponenten so, dass ein solcher CDN-Server möglichst viele Daten an die Benutzer senden kann.

Die „Wand“ aus diesen Servern an einem Internet-Traffic-Austauschpunkt (Internet eXchange – IX) sieht so aus:

Der Internet Exchange ermöglicht es Internetanbietern und Inhaltanbietern, sich direkt miteinander zu verbinden, um Daten im Internet effizienter auszutauschen. Weltweit gibt es rund 70-80 Internet Exchange-Punkte, an denen unsere Server installiert sind, und wir sind selbst für deren Installation und Wartung verantwortlich:

Darüber hinaus stellen wir Server auch direkt Internetanbietern zur Verfügung, die sie in ihr Netzwerk integrieren, um die Lokalisierung des Netflix-Traffics und die Streaming-Qualität für die Benutzer zu verbessern:

Eine Sammlung von AWS-Diensten verantwortet die Verteilung von Videoanfragen von Clients an die CDN-Server sowie die Konfiguration der Server selbst – Aktualisierung von Inhalten, Programmcode, Einstellungen usw. Für letzteres haben wir ebenfalls ein Backbone-Netzwerk aufgebaut, das die Server an den Internet Exchange-Punkten mit AWS verbindet. Das Backbone-Netzwerk ist ein globales Netzwerk von Glasfaserkabeln und Routern, das wir entsprechend unseren Anforderungen entwerfen und konfigurieren können.

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

Ursprünglich war die CDN-Infrastruktur zur Lieferung von Videodaten konzipiert. Im Laufe der Zeit haben wir jedoch erkannt, dass wir sie auch zur Optimierung dynamischer Anfragen von Clients an die AWS-Cloud nutzen können.

Über die Beschleunigung des Internets

Heute hat Netflix 3 AWS-Regionen, und die Latenz der Anfragen an die Cloud hängt davon ab, wie weit der Kunde von der nächstgelegenen Region entfernt ist. Dafür haben wir zahlreiche CDN-Server, die zur Auslieferung von statischen Inhalten verwendet werden. Kann man diese Infrastruktur nutzen, um dynamische Anfragen zu beschleunigen? Leider können diese Anfragen nicht zwischengespeichert werden, da die APIs personalisiert sind und jedes Ergebnis einzigartig ist.

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

Technische Grundlagen

Erinnern wir uns, wie Netzwerkprotokolle funktionieren. Heute nutzt der größte Teil des Internetverkehrs HTTPS, das von den unteren Protokollen TCP und TLS abhängt. Um eine Verbindung vom Client zum Server herzustellen, führt der Client eine Handshake durch, und um eine sichere Verbindung einzurichten, muss der Client mindestens dreimal Nachrichten mit dem Server austauschen und noch mindestens einmal, um Daten zu übertragen. Bei einer Verzögerung von 100 ms pro Austausch (RTT) benötigen wir 400 ms, um das erste Bit Daten zu erhalten:

Wenn die Zertifikate auf dem CDN-Server platziert werden, können wir die Zeit für das "Handshake" zwischen dem Client und dem Server erheblich verkürzen, wenn das CDN näher ist. Angenommen, die Verzögerung bis zum CDN-Server beträgt 30 ms. Dann brauchen wir für den Erhalt des ersten Bits bereits 220 ms:

Doch die Vorteile enden hier nicht. Nachdem die Verbindung hergestellt ist, erhöht TCP das Congestion Window (die Menge an Informationen, die es gleichzeitig über diese Verbindung übertragen kann). Wenn ein Datenpaket verloren geht, verringern klassische Implementierungen des TCP-Protokolls (wie TCP New Reno) das offene "Fenster" um die Hälfte. Das Wachstum des Congestion Windows und die Geschwindigkeit seiner Wiederherstellung nach einem Verlust hängen erneut von der Verzögerung (RTT) zum Server ab. Wenn diese Verbindung nur bis zum CDN-Server führt, wird die Wiederherstellung schneller sein. Der Verlust von Paketen ist dabei ein gängiges Phänomen, insbesondere bei drahtlosen Netzwerken.

Die Bandbreite des Internets kann insbesondere zu Stoßzeiten durch den Nutzerverkehr abnehmen, was zu "Staus" führen kann. Dabei gibt es im Internet keine Möglichkeit, einzelnen Anfragen Prioritäten gegenüber anderen zuzuweisen. Zum Beispiel können kleine, latenzempfindliche Anfragen nicht im Vergleich zu "schweren" Datenströmen, die die Netzwerkauslastung erhöhen, priorisiert werden. In unserem Fall ermöglicht uns jedoch das Vorhandensein eines eigenen Backbone-Netzes, dies auf einem Teil des Anfragewegs zu tun – zwischen dem CDN und der Cloud, und wir können es vollständig konfigurieren. Es ist möglich, kleinere und latenzempfindliche Pakete zu priorisieren, während große Datenströme etwas später übertragen werden. Je näher das CDN am Kunden ist, desto effizienter wird es.

Auch die Anwendungsschicht-Protokolle (OSI-Ebene 7) haben Einfluss auf die Latenz. Neue Protokolle wie HTTP/2 ermöglichen eine Optimierung der Performance paralleler Anfragen. Allerdings haben wir bei Netflix auch Kunden mit älteren Geräten, die keine neuen Protokolle unterstützen. Nicht alle Kunden können aktualisiert oder optimal konfiguriert werden. Zwischen dem CDN-Proxy und der Cloud haben wir jedoch die volle Kontrolle und die Möglichkeit, neue, optimale Protokolle und Einstellungen zu verwenden. Der ineffiziente Teil mit den alten Protokollen wird nur zwischen dem Kunden und dem CDN-Server aktiv sein. Darüber hinaus können wir Multiplex-Anfragen über eine bereits etablierte Verbindung zwischen dem CDN und der Cloud durchführen, was die Auslastung der Verbindung auf TCP-Ebene verbessert:

Messen

Obwohl die Theorie Verbesserungen verspricht, springen wir nicht sofort dazu, das System in die Produktion zu bringen. Stattdessen müssen wir zuerst nachweisen, dass die Idee in der Praxis funktionieren wird. Dazu müssen wir einige Fragen beantworten:

• Geschwindigkeit: Wird der Proxy schneller sein?
• Zuverlässigkeit: Wird er häufiger ausfallen?
• Komplexität: Wie integriert man es mit Anwendungen?
• Kosten: Wie hoch sind die Kosten für den Einsatz zusätzlicher Infrastruktur?

Betrachten wir unseren Ansatz zur Bewertung des ersten Punkts etwas genauer. Die anderen Punkte werden auf ähnliche Weise behandelt.

Für die Analyse der Anfragengeschwindigkeit wollen wir Daten von allen Nutzern erhalten, ohne viel Zeit in die Entwicklung zu investieren und ohne die Produktionsumgebung zu gefährden. Dafür gibt es mehrere Ansätze:

1. RUM oder passive Messung von Anfragen. Wir messen die Ausführungszeit aktueller Anfragen von Benutzern und gewährleisten eine vollständige Abdeckung der Nutzer. Nachteil ist ein nicht sehr stabiler Signal aufgrund vieler Faktoren, wie beispielsweise durch unterschiedliche Anfragen, Bearbeitungszeiten auf dem Server und Client. Zudem kann eine neue Konfiguration nicht ohne Effekte im Produktionsbetrieb getestet werden.
2. Labortests. Spezielle Server und Infrastruktur, die Clients simulieren. Mit ihrer Hilfe führen wir die notwendigen Tests durch. So erhalten wir die vollständige Kontrolle über die Messergebnisse und ein klares Signal. Aber es gibt keine vollständige Abdeckung der Geräte und Standorte der Benutzer (besonders bei einem weltweiten Service und der Unterstützung von Tausenden von Gerätemodellen).

Wie können die Vorteile beider Methoden kombiniert werden?

Unser Team fand eine Lösung. Wir schrieben ein kleines Stück Code – eine Probe –, die wir in unsere Anwendung eingebaut haben. Die Proben ermöglichen es uns, vollständig kontrollierte Netzwerktests von unseren Geräten aus durchzuführen. Es funktioniert folgendermaßen:

1. Kurz nach dem Laden der Anwendung und dem Abschluss der Anfangsaktivitäten starten wir unsere Proben.
2. Der Client sendet eine Anfrage an den Server und erhält ein "Rezept" für den Test. Das Rezept besteht aus einer Liste von URLs, an die HTTP(s)-Anfragen gesendet werden sollen. Darüber hinaus konfiguriert das Rezept die Parameter der Anfragen: Verzögerungen zwischen den Anfragen, das Volumen der angeforderten Daten, HTTP(s)-Headers usw. Dabei können wir parallel mehrere unterschiedliche Rezepte testen – bei der Anfrage zur Konfiguration wird zufällig bestimmt, welches Rezept ausgegeben wird.
3. Die Startzeit der Probe wird so gewählt, dass sie nicht mit der aktiven Nutzung von Netzwerkressourcen beim Client in Konflikt steht. Im Wesentlichen wird ein Zeitpunkt gewählt, an dem der Client inaktiv ist.
4. Nach Erhalt des Rezepts sendet der Client Anfragen an jede der URLs parallel. Die Anfrage an jede Adresse kann wiederholt werden – sogenannte „Impulse“. Bei der ersten Messung erfassen wir, wie viel Zeit für den Verbindungsaufbau und den Download der Daten benötigt wurde. Bei der zweiten Messung erfassen wir die Zeit für den Daten-Download über die bereits hergestellte Verbindung. Vor der dritten Messung können wir eine Verzögerung einfügen und die Geschwindigkeit des erneuten Verbindungsaufbaus messen usw.

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

   • die Zeit der DNS-Anfrage;
   • die Zeit zum Herstellen einer TCP-Verbindung;
   • die Zeit zum Herstellen einer TLS-Verbindung;
   • die Zeit bis zum Empfang des ersten Datenbytes;
   • die gesamte Ladezeit;
   • Statuscode des Ergebnisses.
5. Nach Abschluss aller Pulses lädt die Probe die Ergebnisse aller Messungen zur Analyse hoch.

Wesentliche Punkte sind die minimale Abhängigkeit von Logik auf der Client-Seite, die Datenverarbeitung auf dem Server und die Messung paralleler Anfragen. Dadurch erhalten wir die Möglichkeit, den Einfluss verschiedener, die Leistungsfähigkeit der Anfragen beeinflussender Faktoren zu isolieren und zu testen, sie innerhalb eines Rezepts zu variieren und Ergebnisse von echten Kunden zu erhalten.

Diese Infrastruktur hat sich als nützlich erwiesen, nicht nur zur Analyse der Anfrageleistung. Derzeit haben wir 14 aktive Rezepte, mehr als 6000 Proben pro Sekunde, die Daten aus allen Teilen der Erde sammeln und eine umfassende Abdeckung von Geräten bieten. Würde Netflix einen solchen Dienst von Drittanbietern kaufen, würde er Millionen Dollar pro Jahr kosten, bei weitaus schlechterer Abdeckung.

Wir überprüfen die Theorie in der Praxis: Prototyp

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

• einen Proxy-Prototyp erstellen;
• den Prototyp im CDN bereitstellen;
• bestimmen, wie man Clients zu einem Proxy auf einem bestimmten CDN-Server leitet;
• die Leistung mit Anfragen in AWS ohne Proxy vergleichen.

Die Aufgabe besteht darin, die Effizienz der vorgeschlagenen Lösung so schnell wie möglich zu bewerten. Für die Umsetzung des Prototyps haben wir Go gewählt, dank der verfügbaren guten Netzwerkbibliotheken. Auf jedem CDN-Server haben wir den Proxy-Prototyp als statisches Binärformat installiert, um Abhängigkeiten zu minimieren und die Integration zu vereinfachen. In der ersten Implementierung haben wir weitestgehend standardisierte Komponenten und kleine Modifikationen für HTTP/2-Verbindungs-Pooling und Anfrage-Multiplexing verwendet.

Um die Last zwischen den AWS-Regionen zu verteilen, haben wir eine geografische DNS-Datenbank verwendet, die auch zur Lastverteilung der Clients genutzt wird. Um einen CDN-Server für den Client auszuwählen, nutzen wir TCP Anycast für Server im Internet Exchange (IX). In diesem Fall verwenden wir eine IP-Adresse für alle CDN-Server, wobei der Client zum CDN-Server mit der geringsten Anzahl an IP-Hops geleitet wird. Bei den CDN-Servern, die bei Internetanbietern (ISP) eingerichtet sind, haben wir keine Kontrolle über den Router zur Konfiguration von TCP Anycast, daher verwenden wir die gleiche Logik, nach der die Clients zu den Internet-Anbietern für das Video-Streaming geleitet werden.

Wir haben also drei Arten von Pfaden für die Anforderung: in die Cloud über das offene Internet, über einen CDN-Server im IX oder über einen CDN-Server, der beim Internetanbieter lokalisiert ist. Unser Ziel ist es zu verstehen, welcher Pfad der beste ist und welchen Nutzen eine Proxy-Lösung im Vergleich zu den Anforderungen im Produktionsbetrieb bringt. Dazu verwenden wir ein Probesystem wie folgt:

Jeder dieser Pfade wird ein separater Zielort, und wir betrachten die Zeit, die wir erhalten haben. Für die Analyse fassen wir die Proxy-Ergebnisse in einer Gruppe zusammen (wir wählen die beste Zeit zwischen IX- und ISP-Proxy) und vergleichen sie mit den Zeiten für Anforderungen in die Cloud ohne Proxy:

Wie zu sehen ist, sind die Ergebnisse uneindeutig – in den meisten Fällen bietet der Proxy eine gute Beschleunigung, aber es gibt auch genügend Clients, bei denen sich die Situation erheblich verschlechtert.

Insgesamt haben wir einige wichtige Dinge getan:

1. Wir haben die erwartete Leistung der Anfragen von Clients in die Cloud über den CDN-Proxy bewertet.
2. Wir haben Daten von echten Clients aus allen Gerätetypen erhalten.
3. Wir haben erkannt, dass die Theorie nicht zu 100% bestätigt wurde und das ursprüngliche Angebot mit dem CDN-Proxy für uns nicht funktioniert.
4. Wir haben kein Risiko eingegangen – die Produktionskonfigurationen für die Clients nicht geändert.
5. Nichts kaputt gemacht.

Prototyp 2.0

Lassen Sie uns also zurück an den Zeichenbrett und den Prozess von neuem beginnen.

Die Idee ist, anstelle von 100% Proxy für jeden Client den schnellsten Pfad zu bestimmen und die Anfragen dorthin zu leiten – das heißt, wir werden das tun, was man Client-Steering nennt.

Wie setzt man das um? Wir können keine serverseitige Logik verwenden, da das Ziel darin besteht, eine Verbindung zu diesem Server herzustellen. Es muss auf irgendeine Weise auf der Clientseite implementiert werden. Ideal wäre es, dies mit minimaler komplexer Logik zu tun, um das Integrationsproblem mit einer Vielzahl von Client-Plattformen zu vermeiden.

Die Antwort ist die Verwendung von DNS. In unserem Fall verfügen wir über unsere eigene DNS-Infrastruktur, und wir können die Domainzone so konfigurieren, dass unsere Server autoritativ sind. So funktioniert es:

1. Der Client sendet eine Anfrage an den DNS-Server unter Verwendung eines Hosts, beispielsweise api.netflix.xom.
2. Die Anfrage gelangt zu unserem DNS-Server.
3. Der DNS-Server kennt den schnellsten Weg für diesen Client und gibt die entsprechende IP-Adresse aus.

In der Lösung gibt es eine zusätzliche Schwierigkeit: Autoritative DNS-Anbieter sehen die IP-Adresse des Clients nicht und können nur die IP-Adresse des rekursiven Resolvers berücksichtigen, den der Client verwendet.

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

Zur Lösung verwenden wir die gleichen Proben, aggregieren die Messresultate von Clients für jeden der rekursiven Resolver und entscheiden dann, wohin wir diese Gruppe leiten — über ein Proxy über IX mit Hilfe von TCP Anycast, über ISP-Proxy oder direkt in die Cloud.

Wir erhalten ein solches System:

Das erhaltene Modell des DNS-Managements ermöglicht es, Clients basierend auf historischen Beobachtungen der Verbindungsraten von Clients zur Cloud zu leiten.

Wiederum stellt sich die Frage — wie effektiv wird dieser Ansatz funktionieren? Um dies zu beantworten, verwenden wir erneut unser System von Proben. Daher konfigurieren wir die kürzliche Konfiguration, in der eines der Ziele den Anweisungen des DNS-Managements folgt, das andere direkt in die Cloud (aktueller Produktionsstand) geht.

Letztendlich vergleichen wir die Ergebnisse und erhalten eine Bewertung der Effizienz:

Letztendlich haben wir einige wichtige Dinge festgestellt:

1. Wir haben die erwartete Leistung von Anfragen von Clients zur Cloud unter Verwendung von DNS-Management bewertet.
2. Wir haben Daten von echten Clients aus allen Gerätetypen erhalten.
3. Wir haben die Effizienz des vorgeschlagenen Konzepts nachgewiesen.
4. Wir haben kein Risiko eingegangen – die Produktionskonfigurationen für die Clients nicht geändert.
5. Nichts kaputt gemacht.

Jetzt zu dem Komplexen — wir starten in der Produktion.

Das Schwierigste liegt nun hinter uns – es gibt einen funktionierenden Prototyp. Jetzt kommt der schwierige Teil – die Lösung für den gesamten Netflix-Verkehr zu starten, sie für 150 Millionen Nutzer, Tausende von Geräten, Hunderte von Mikrodiensten und eine ständig wechselnde Produkt- und Infrastruktur bereitzustellen. Auf die Netflix-Server kommen Millionen von Anfragen pro Sekunde, und man kann den Dienst leicht durch unvorsichtiges Handeln zum Absturz bringen. Gleichzeitig wollen wir den Verkehr dynamisch über Tausende von CDN-Servern lenken, im Internet, wo sich ständig etwas ändert und kaputtgeht, und das oft im ungünstigsten Moment.

Und bei all dem besteht das Team aus 3 Ingenieuren, die für die Entwicklung, den Rollout und die vollständige Unterstützung des Systems verantwortlich sind.

Daher werden wir jetzt über ruhigen und gesunden Schlaf sprechen.

Wie kann man die Entwicklung fortsetzen und nicht die ganze Zeit mit der Wartung verbringen? Unser Ansatz basiert auf drei Prinzipien:

1. Wir reduzieren den potenziellen Umfang von Ausfällen (blast radius).
2. Wir bereiten uns auf Überraschungen vor – wir gehen davon aus, dass etwas kaputtgeht, trotz Tests und persönlicher Erfahrung.
3. Allmählicher Rückgang (graceful degradation) – wenn etwas nicht funktioniert, sollte es automatisch repariert werden, wenn auch nicht auf die effizienteste Weise.

Es stellte sich heraus, dass wir in unserem Fall mit diesem Ansatz ein einfaches und effektives Lösungsangebot finden und die Unterstützung des Systems erheblich erleichtern können. Wir erkannten, dass wir einen kleinen Code-Schnipsel im Client hinzufügen können, um die Fehler bei Netzwerk-Anfragen, die durch Verbindungsprobleme verursacht werden, zu verfolgen. Bei Netzwerkfehlern führen wir ein Fallback direkt in die Cloud durch. Diese Lösung erfordert keinen großen Aufwand für die Client-Teams, reduziert jedoch erheblich das Risiko unerwarteter Ausfälle und Überraschungen für uns.

Natürlich halten wir trotz des Fallbacks eine klare Disziplin während der Entwicklung ein:

1. Test auf Probe.
2. A/B-Testing oder Canaries.
3. Allmähliche Veröffentlichung (progressive rollout).

Mit den Proben wurde der Ansatz beschrieben – Änderungen werden zunächst mithilfe eines konfigurierten Rezepts getestet.

Für das Canary-Testing müssen wir vergleichbare Serverpaare erhalten, auf denen wir vergleichen können, wie das System vor und nach den Änderungen funktioniert. Dazu ziehen wir aus unseren zahlreichen CDN-Standorten Paare von Servern, die einen vergleichbaren Verkehr erhalten:

Dann stellen wir die Version mit den Änderungen auf den Canary-Server bereit. Um die Ergebnisse zu bewerten, führen wir ein System aus, das etwa 100-150 Metriken mit einer Kontrollgruppe von Servern vergleicht:

Wenn der Canary-Test erfolgreich war, nehmen wir das Release schrittweise und wellenartig vor. Auf jeder Website aktualisieren wir die Server nicht gleichzeitig – der Ausfall einer gesamten Website hat bei Problemen einen größeren Einfluss auf den Service für die Benutzer als der Ausfall desselben Mengen an Servern, aber an verschiedenen 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 aus allen möglichen Komponenten:

• von Clients – Anzahl der Sitzungen und Anfragen, Fallback-Raten;
• Proxy – Statistiken zur Anzahl und Zeit der Anfragen;
• DNS – Anzahl und Ergebnisse von Anfragen;
• Cloud Edge – Anzahl und Zeit zur Bearbeitung von Anfragen in der Cloud.

All dies wird in einer einheitlichen Pipeline gesammelt, und je nach Bedarf entscheiden wir, welche Metriken für die Echtzeitanalyse gesendet werden und welche in Elasticsearch oder Big Data für eine detailliertere Diagnose.

Überwachung

In unserem Fall nehmen wir Änderungen am kritischen Pfad der Anfragen zwischen Client und Server vor. Dabei ist die Anzahl der verschiedenen Komponenten auf dem Client, dem Server und im Internet enorm. Änderungen auf dem Client und Server erfolgen ständig – im Laufe der Arbeit von Dutzenden von Teams und natürlichen Veränderungen im Ökosystem. Wir sind in der Mitte – bei der Diagnose von Problemen besteht eine hohe Wahrscheinlichkeit, dass wir daran beteiligt sind. Daher müssen wir klar verstehen, wie wir Metriken definieren, sammeln und analysieren, um Probleme schnell zu lokalisieren.

Ideal ist ein vollständiger Zugang zu allen Arten von Metriken und Filtern in Echtzeit. Aber es gibt sehr viele Metriken, daher stellt sich die Frage der Kosten. In unserem Fall teilen wir Metriken und Entwicklungstools folgendermaßen auf:

Zum Entdecken und zur Priorisierung von Problemen verwenden wir unser eigenes Echtzeitsystem mit offenem Quellcode Atlas und Lumen – für die Visualisierung. Es speichert aggregierte Metriken im Speicher, ist zuverlässig und integriert sich mit der Alarmierungssoftware. Für die Lokalisierung und Diagnose haben wir Zugriff auf Logs mit Elasticsearch und Kibana. Für statistische Analysen und Modellierungen nutzen wir Big Data und Visualisierung in Tableau.

Es scheint, dass es mit diesem Ansatz sehr schwierig ist zu arbeiten. Wenn wir jedoch eine hierarchische Organisation der Metriken und Werkzeuge haben, können wir das Problem schnell analysieren, den Problemtyp bestimmen und dann in die detaillierten Metriken eintauchen. Um die Quelle eines Fehlers zu identifizieren, benötigen wir im Allgemeinen etwa 1-2 Minuten. Danach arbeiten wir mit einem bestimmten Team an der Diagnose – von zehn Minuten bis zu mehreren Stunden.

Selbst wenn die Diagnose schnell erfolgt, möchten wir nicht, dass dies häufig geschieht. Im Idealfall erhalten wir einen kritischen Alarm nur dann, wenn es erhebliche Auswirkungen auf den Dienst gibt. Für unser System zur Beschleunigung von Anfragen gibt es nur 2 Alarme, die benachrichtigen werden:

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

Diese kritischen Alarme überwachen, ob das System für die meisten Nutzer funktioniert. Wir sehen uns an, wie viele Kunden den Fallback genutzt haben, wenn sie die Anfragen nicht beschleunigen konnten. Im Durchschnitt haben wir weniger als 1 kritische Benachrichtigung pro Woche, obwohl es im System eine enorme Anzahl von Änderungen gibt. Warum reicht uns das?

1. Es gibt einen Client-Fallback, falls unser Proxy nicht funktioniert.
2. Es gibt ein automatisches Steuerungssystem, das auf Probleme reagiert.

Zum Letzten mehr Details. Unser Probe-System und das System zur automatischen Bestimmung des optimalen Weges für Anfragen vom Kunden zur Cloud ermöglichen es, automatisch mit einigen Problemen umzugehen.

Kehren wir zu unserer Konfiguration der Proben und den 3 Kategorien von Wegen zurück. Neben der Ladezeit können wir auf das Thema der Lieferung selbst achten. Wenn es nicht möglich ist, Daten zu laden, können wir anhand der Ergebnisse über verschiedene Wege feststellen, wo und was kaputt ist, und ob wir das automatisch beheben können, indem wir den Anfrageweg ändern.

Beispiele:

Dieser Prozess kann automatisiert werden. In das Steuerungssystem integriert werden. Und es dazu bringen, auf Probleme mit der Leistung und Zuverlässigkeit zu reagieren. Wenn etwas anfängt zu brechen – reagieren, wenn es eine bessere Option gibt. Dabei ist eine sofortige Reaktion nicht kritisch, dank des Fallbacks auf den Kunden.

So lassen sich die Prinzipien der Systemunterstützung formulieren:

• Wir minimieren den Umfang der Ausfälle;
• Wir sammeln Metriken;
• Wir beheben Ausfälle automatisch, wenn möglich;
• Wenn nicht, benachrichtigen wir;
• Wir arbeiten an Dashboards und einem Triage-Toolset für schnelle Reaktionen.

Aus den gewonnenen Erkenntnissen

Für die Erstellung eines Prototyps wird nicht viel Zeit benötigt. In unserem Fall war er bereits nach 4 Monaten bereit. Damit 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: die allmähliche Produktivsetzung und Skalierung des Systems, die Migration des Hauptverkehrs und das Lernen aus Fehlern. Dabei wird dieser effiziente Prozess nicht linear verlaufen — trotz aller Anstrengungen kann nicht alles vorhergesehen werden. Weitaus effektiver ist schnelle Iteration und Reaktion auf neue Daten.

Basierend auf unserer Erfahrung können wir Folgendes empfehlen:

1. Vertrauen Sie nicht auf Ihr Bauchgefühl.

   Unser Bauchgefühl hat uns ständig im Stich gelassen, trotz der umfangreichen Erfahrung der Teammitglieder. Zum Beispiel haben wir die erwartete Beschleunigung durch die Nutzung von CDN-Proxys oder das Verhalten von TCP Anycast falsch eingeschätzt.

2. Erhalten Sie Daten aus der Produktion.

   Es ist wichtig, so schnell wie möglich Zugang zu zumindest einer kleinen Menge an Produktionsdaten zu erhalten. Die Anzahl der einzigartigen Fälle, Konfigurationen und Einstellungen unter Laborbedingungen ist praktisch unmöglich zu ermitteln. Schneller Zugang zu Ergebnissen ermöglicht es, schnell von potenziellen Problemen zu erfahren und diese in der Systemarchitektur zu berücksichtigen.

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 Aussagen anderer. Nur Sie können genau wissen, was für Ihre Benutzer funktioniert. Ihre Systeme und Ihre Kunden können sich erheblich von anderen Unternehmen unterscheiden. Glücklicherweise sind die Analysewerkzeuge heutzutage verfügbar und leicht zu bedienen. Ihre Ergebnisse können von dem abweichen, was Netflix, Facebook, Akamai und andere Unternehmen behaupten. In unserem Fall unterscheidet sich die Leistung von TLS, HTTP2 oder die Statistiken zu DNS-Anfragen von den Ergebnissen von Facebook, Uber, Akamai — weil wir andere Geräte, Kunden und Datenströme haben.

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

   Beginnen Sie einfach. Es ist besser, ein einfaches funktionierendes System in kurzer Zeit zu erstellen, als viel Zeit mit der Entwicklung unnötiger Komponenten zu verbringen. Lösen Sie Aufgaben und Probleme, die auf Grundlage Ihrer Messungen und Ergebnisse wichtig sind.

5. Seien Sie bereit für neue Anwendungen.

   So schwierig es ist, alle Probleme vorherzusagen, so schwierig ist es auch, 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 Anfragen zu verzögern. Doch im Verlauf der Analyse und Diskussionen haben wir festgestellt, dass wir Proxy-Server auch einsetzen können:

   • zum Lastenausgleich des Traffics über AWS-Regionen und zur Senkung der Kosten;
   • zur Modellierung der Stabilität von CDN;
   • zur Konfiguration von DNS;
   • zur Konfiguration von TLS/TCP.

Fazit

In meinem Vortrag habe ich beschrieben, wie Netflix das Problem der Beschleunigung von Internetanfragen zwischen Kunden und der Cloud löst. Wie wir Daten durch unser System für Kunden-Probieren sammeln und die gesammelten historischen Daten nutzen, um Produktionsanfragen über den schnellsten Weg im Internet zu leiten. Wie wir die Prinzipien der Netzwerkprotokolle, unsere CDN-Infrastruktur, das Backbone-Netzwerk und DNS-Server nutzen, um dieses Ziel zu erreichen.

Unser Ansatz ist nur ein Beispiel dafür, wie wir bei Netflix ein solches System implementiert haben. Was für uns funktioniert hat. Der praktische Teil meines Vortrags für Sie sind die Entwicklungs- und Unterstützungsprinzipien, denen wir folgen und mit denen wir gute Ergebnisse erzielen.

Unsere Lösung des Problems könnte für Sie nicht geeignet sein. Dennoch bleiben die Theorie und die Entwicklungsprinzipien bestehen, selbst wenn Sie keine eigene CDN-Infrastruktur haben oder sie erheblich von unserer abweicht.

Die Geschwindigkeit der Anfragen bleibt auch für das Geschäft wichtig. Und selbst für einen einfachen Service müssen Sie Entscheidungen treffen: zwischen „Cloud“-Anbietern, dem Standort der Server, CDN- und DNS-Anbietern. Ihre Wahl wird die Effizienz der Internetanfragen für Ihre Kunden beeinflussen. Es ist für Sie wichtig, diesen Einfluss zu messen und zu verstehen.

Beginnen Sie mit einfachen Lösungen, achten Sie darauf, wie Sie das Produkt verändern. Lernen Sie im Prozess und verbessern Sie das System basierend auf Daten von Ihren Kunden, Ihrer Infrastruktur und Ihrem Geschäft. Denken Sie an die Möglichkeit unerwarteter Ausfälle im Entwurfsprozess. Dann können Sie Ihren Entwicklungsprozess beschleunigen, die Effizienz der Lösung verbessern, übermäßige Belastungen des Supports vermeiden und ruhig schlafen.

In diesem Jahr findet die Konferenz vom 6. bis 10. Juli statt. im Online-Format. Es wird möglich sein, einem der Väter von DevOps, John Willis selbst, Fragen zu stellen!

Quelle: habr.com