Netflix ist der Marktführer auf dem Internetfernsehmarkt – das Unternehmen, das dieses Segment geschaffen hat und es aktiv weiterentwickelt. Netflix ist nicht nur für seinen umfangreichen Katalog an Filmen und Fernsehserien bekannt, die aus fast jedem Winkel der Welt und auf jedem Gerät mit Display verfügbar sind, sondern auch für seine zuverlässige Infrastruktur und einzigartige Ingenieurskultur.
Ein klares Beispiel für den Netflix-Ansatz zur Entwicklung und Unterstützung komplexer Systeme wurde auf der DevOops 2019 vorgestellt - Entwicklungsdirektor bei Netflix. Absolvent der Fakultät für Computermathematik und Mathematik der Staatlichen Universität Nischni Nowgorod. Lobachevsky, Sergey, einer der ersten Ingenieure im Open Connect – CDN-Team bei Netflix. Er baute Systeme zur Überwachung und Analyse von Videodaten, startete den beliebten Dienst zur Bewertung der Internetverbindungsgeschwindigkeit FAST.com und arbeitet seit einigen Jahren daran, Internetanfragen zu optimieren, damit die Netflix-Anwendung für Benutzer so schnell wie möglich funktioniert.
Der Bericht erhielt die besten Kritiken von Konferenzteilnehmern und wir haben eine Textversion für Sie vorbereitet.
In seinem Bericht äußerte sich Sergej ausführlich
- darüber, was die Verzögerung von Internetanfragen zwischen Client und Server beeinflusst;
- wie kann man diese Verzögerung reduzieren?
- wie man fehlertolerante Systeme entwirft, wartet und überwacht;
- wie man in kurzer Zeit und mit minimalem Risiko für das Unternehmen Ergebnisse erzielt;
- wie man Ergebnisse analysiert und aus Fehlern lernt.
Antworten auf diese Fragen brauchen nicht nur diejenigen, die in großen Konzernen arbeiten.
Die vorgestellten Prinzipien und Techniken sollten jedem bekannt sein und praktiziert werden, der Internetprodukte entwickelt und unterstützt.
Als nächstes folgt die Erzählung aus der Perspektive des Sprechers.
Die Bedeutung der Internetgeschwindigkeit
Die Geschwindigkeit von Internetanfragen steht in direktem Zusammenhang mit dem Geschäft. Denken Sie an die Einkaufsbranche: Amazon im Jahr 2009 dass eine Verzögerung von 100 ms zu einem Umsatzverlust von 1 % führt.
Es gibt immer mehr mobile Geräte, gefolgt von mobilen Websites und Anwendungen. Wenn das Laden Ihrer Seite länger als 3 Sekunden dauert, verlieren Sie etwa die Hälfte Ihrer Nutzer. MIT Google berücksichtigt die Ladegeschwindigkeit Ihrer Seite in den Suchergebnissen: Je schneller die Seite, desto höher ist ihre Position bei Google.
Die Verbindungsgeschwindigkeit ist auch in Finanzinstituten wichtig, wo die Latenz von entscheidender Bedeutung ist. Im Jahr 2015 Hibernia Networks ein 400-Millionen-Dollar-Kabel zwischen New York und London, um die Latenz zwischen den Städten um 6 ms zu reduzieren. Stellen Sie sich 66 Millionen US-Dollar für eine Latenzreduzierung um 1 ms vor!
Согласно Verbindungsgeschwindigkeiten über 5 Mbit/s wirken sich nicht mehr direkt auf die Ladegeschwindigkeit einer typischen Website aus. Es besteht jedoch ein linearer Zusammenhang zwischen Verbindungslatenz und Seitenladegeschwindigkeit:
Allerdings ist Netflix kein typisches Produkt. Der Einfluss von Latenz und Geschwindigkeit auf den Benutzer ist ein aktiver Bereich der Analyse und Entwicklung. Das Laden von Anwendungen und die Auswahl von Inhalten hängen von der Latenz ab, aber das Laden statischer Elemente und das Streaming hängen auch von der Verbindungsgeschwindigkeit ab. Die Analyse und Optimierung der Schlüsselfaktoren, die das Benutzererlebnis beeinflussen, ist für mehrere Teams bei Netflix ein aktiver Entwicklungsbereich. Eines der Ziele besteht darin, die Latenz von Anfragen zwischen Netflix-Geräten und der Cloud-Infrastruktur zu reduzieren.
Im Bericht konzentrieren wir uns speziell auf die Reduzierung der Latenz am Beispiel der Netflix-Infrastruktur. Betrachten wir aus praktischer Sicht, wie wir die Prozesse des Entwurfs, der Entwicklung und des Betriebs komplexer verteilter Systeme angehen und Zeit für Innovation und Ergebnisse aufwenden können, anstatt Betriebsprobleme und Ausfälle zu diagnostizieren.
In Netflix
Tausende verschiedene Geräte unterstützen Netflix-Apps. Sie werden von vier verschiedenen Teams entwickelt, die separate Versionen des Clients für Android, iOS, TV und Webbrowser erstellen. Und wir investieren viel Mühe in die Verbesserung und Personalisierung des Benutzererlebnisses. Dazu führen wir Hunderte von A/B-Tests parallel durch.
Die Personalisierung wird durch Hunderte von Microservices in der AWS-Cloud unterstützt und bietet personalisierte Benutzerdaten, Abfrageversand, Telemetrie, Big Data und Codierung. Die Verkehrsvisualisierung sieht folgendermaßen aus:
Auf der linken Seite befindet sich der Einstiegspunkt, und dann wird der Datenverkehr 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 an den Endbenutzer liefert – Videos, Bilder, Client-Code usw. Das CDN befindet sich auf benutzerdefinierten Servern (OCA – Open Connect Appliance). Im Inneren befinden sich Arrays von SSD- und HDD-Laufwerken, auf denen optimiertes FreeBSD mit NGINX und einer Reihe von Diensten läuft. Wir entwerfen und optimieren Hardware- und Softwarekomponenten, damit ein solcher CDN-Server möglichst viele Daten an Benutzer senden kann.
Die „Wand“ dieser Server am Internet-Verkehrsaustauschpunkt (Internet eXchange - IX) sieht folgendermaßen aus:
Internet Exchange bietet Internetdienstanbietern und Inhaltsanbietern die Möglichkeit, sich miteinander zu „verbinden“, um Daten direkter im Internet auszutauschen. Weltweit gibt es etwa 70–80 Internet-Austauschpunkte, an denen unsere Server installiert sind. Wir installieren und warten sie selbstständig:
Darüber hinaus stellen wir Internetprovidern auch Server direkt zur Verfügung, die diese in ihrem Netzwerk installieren und so die Lokalisierung des Netflix-Verkehrs und die Qualität des Streamings für Benutzer verbessern:
Eine Reihe von AWS-Diensten ist für die Weiterleitung von Videoanfragen von Clients an CDN-Server sowie für die Konfiguration der Server selbst verantwortlich – Aktualisierung von Inhalten, Programmcode, Einstellungen usw. Für Letzteres haben wir auch ein Backbone-Netzwerk aufgebaut, das Server in Internet Exchange-Punkten mit AWS verbindet. Das Backbone-Netzwerk ist ein globales Netzwerk aus Glasfaserkabeln und Routern, das wir je nach Bedarf entwerfen und konfigurieren können.
Auf Unsere CDN-Infrastruktur liefert etwa ⅛ des weltweiten Internetverkehrs zu Spitzenzeiten und ⅓ des Verkehrs in Nordamerika, wo Netflix am längsten existiert. Beeindruckende Zahlen, aber für mich ist eine der erstaunlichsten Errungenschaften, dass das gesamte CDN-System von einem Team von weniger als 150 Leuten entwickelt und gewartet wird.
Ursprünglich war die CDN-Infrastruktur für die Bereitstellung von Videodaten konzipiert. Mit der Zeit haben wir jedoch erkannt, dass wir damit auch dynamische Anfragen von Kunden in der AWS-Cloud optimieren können.
Über Internetbeschleunigung
Heute verfügt Netflix über drei AWS-Regionen und die Latenz von Anfragen an die Cloud hängt davon ab, wie weit der Kunde von der nächstgelegenen Region entfernt ist. Gleichzeitig verfügen wir über viele CDN-Server, die zur Bereitstellung statischer Inhalte verwendet werden. Gibt es eine Möglichkeit, dieses Framework zu verwenden, um dynamische Abfragen zu beschleunigen? Allerdings ist es leider nicht möglich, diese Anfragen zwischenzuspeichern – APIs sind personalisiert und jedes Ergebnis ist einzigartig.
Lassen Sie uns einen Proxy auf dem CDN-Server erstellen und damit beginnen, Datenverkehr darüber zu senden. Wird es schneller sein?
Materiel
Erinnern wir uns daran, wie Netzwerkprotokolle funktionieren. Heutzutage verwendet der meiste Datenverkehr im Internet HTTPs, das von den Protokollen der unteren Schicht TCP und TLS abhängt. Damit ein Client eine Verbindung zum Server herstellen kann, führt er einen Handshake durch. Um eine sichere Verbindung herzustellen, muss der Client dreimal Nachrichten mit dem Server austauschen und mindestens ein weiteres Mal, um Daten zu übertragen. Bei einer Latenz pro Roundtrip (RTT) von 100 ms würden wir 400 ms brauchen, um das erste Datenbit zu empfangen:
Wenn wir die Zertifikate auf dem CDN-Server platzieren, kann die Handshake-Zeit zwischen Client und Server erheblich verkürzt werden, wenn das CDN näher ist. Nehmen wir an, die Latenz zum CDN-Server beträgt 30 ms. Dann dauert es 220 ms, bis das erste Bit empfangen wird:
Aber die Vorteile enden hier noch nicht. Sobald eine Verbindung hergestellt wurde, vergrößert TCP das Überlastungsfenster (die Menge an Informationen, die es parallel über diese Verbindung übertragen kann). Wenn ein Datenpaket verloren geht, reduzieren klassische Implementierungen des TCP-Protokolls (wie TCP New Reno) das offene „Fenster“ um die Hälfte. Das Wachstum des Überlastungsfensters und die Geschwindigkeit seiner Wiederherstellung nach einem Verlust hängen wiederum von der Verzögerung (RTT) zum Server ab. Wenn diese Verbindung nur bis zum CDN-Server reicht, erfolgt die Wiederherstellung schneller. Gleichzeitig ist Paketverlust ein Standardphänomen, insbesondere bei drahtlosen Netzwerken.
Insbesondere zu Spitzenzeiten kann die Internetbandbreite aufgrund des Datenverkehrs der Benutzer reduziert sein, was zu Staus führen kann. Allerdings gibt es im Internet keine Möglichkeit, einigen Anfragen Vorrang vor anderen einzuräumen. Geben Sie beispielsweise kleinen und latenzempfindlichen Anfragen Vorrang vor „schweren“ Datenströmen, die das Netzwerk belasten. In unserem Fall können wir dies jedoch aufgrund unseres eigenen Backbone-Netzwerks auf einem Teil des Anforderungspfads – zwischen dem CDN und der Cloud – tun und es vollständig konfigurieren. Sie können sicherstellen, dass kleine und latenzempfindliche Pakete priorisiert werden und große Datenströme etwas später erfolgen. Je näher das CDN am Kunden ist, desto höher ist die Effizienz.
Auch Protokolle auf Anwendungsebene (OSI Level 7) haben einen Einfluss auf die Latenz. Neue Protokolle wie HTTP/2 optimieren die Leistung paralleler Anfragen. Allerdings gibt es bei uns Netflix-Clients mit älteren Geräten, die die neuen Protokolle nicht unterstützen. Nicht alle Clients können aktualisiert oder optimal konfiguriert werden. Gleichzeitig besteht zwischen dem CDN-Proxy und der Cloud die vollständige Kontrolle und die Möglichkeit, neue, optimale Protokolle und Einstellungen zu nutzen. Der ineffektive Teil alter Protokolle funktioniert nur zwischen dem Client und dem CDN-Server. Darüber hinaus können wir Multiplex-Anfragen für eine bereits bestehende Verbindung zwischen dem CDN und der Cloud stellen und so die Verbindungsauslastung auf TCP-Ebene verbessern:
Wir messen
Obwohl die Theorie Verbesserungen verspricht, beeilen wir uns nicht, das System sofort in Produktion zu bringen. Stattdessen müssen wir zunächst beweisen, dass die Idee in der Praxis funktioniert. Dazu müssen Sie mehrere Fragen beantworten:
- Geschwindigkeit: Wird ein Proxy schneller sein?
- Zuverlässigkeit: Wird es öfter kaputt gehen?
- Komplexität: Wie integriert man Anwendungen?
- Kosten: Wie viel kostet die Bereitstellung zusätzlicher Infrastruktur?
Lassen Sie uns unseren Ansatz zur Bewertung des ersten Punktes im Detail betrachten. Der Rest wird auf ähnliche Weise gehandhabt.
Um die Geschwindigkeit von Anfragen zu analysieren, möchten wir Daten für alle Benutzer erhalten, ohne viel Zeit für die Entwicklung aufzuwenden und ohne die Produktion zu unterbrechen. Hierfür gibt es mehrere Ansätze:
- RUM oder passive Anforderungsmessung. Wir messen die Ausführungszeit aktueller Anfragen von Benutzern und stellen eine vollständige Benutzerabdeckung sicher. Der Nachteil besteht darin, dass das Signal aufgrund vieler Faktoren nicht sehr stabil ist, beispielsweise aufgrund unterschiedlicher Anforderungsgrößen, Verarbeitungszeit auf Server und Client. Darüber hinaus können Sie eine neue Konfiguration nicht ohne Auswirkungen auf die Produktion testen.
- Labortests. Spezielle Server und Infrastruktur, die Clients simulieren. Mit ihrer Hilfe führen wir die notwendigen Tests durch. So erhalten wir die volle Kontrolle über die Messergebnisse und ein klares Signal. Es gibt jedoch keine vollständige Abdeckung der Geräte und Benutzerstandorte (insbesondere bei einem weltweiten Service und Support für Tausende von Gerätemodellen).
Wie können Sie die Vorteile beider Methoden kombinieren?
Unser Team hat eine Lösung gefunden. Wir haben einen kleinen Codeabschnitt – ein Beispiel – geschrieben, den wir in unsere Anwendung eingebaut haben. Mit Sonden können wir von unseren Geräten aus vollständig kontrollierte Netzwerktests durchführen. Es funktioniert so:
- Kurz nach dem Laden der Anwendung und Abschluss der ersten Aktivität führen wir unsere Tests aus.
- Der Client stellt eine Anfrage an den Server und erhält ein „Rezept“ für den Test. Das Rezept ist eine Liste von URLs, an die eine HTTP(s)-Anfrage gestellt werden muss. Darüber hinaus konfiguriert das Rezept Anforderungsparameter: Verzögerungen zwischen Anforderungen, Menge der angeforderten Daten, HTTP(s)-Header usw. Gleichzeitig können wir mehrere unterschiedliche Rezepte parallel testen – bei der Anforderung einer Konfiguration legen wir nach dem Zufallsprinzip fest, welches Rezept ausgegeben wird.
- Die Startzeit des Probe wird so ausgewählt, dass kein Konflikt mit der aktiven Nutzung von Netzwerkressourcen auf dem Client entsteht. Im Wesentlichen wird die Zeit ausgewählt, in der der Client nicht aktiv ist.
- Nach Erhalt des Rezepts stellt der Client parallel Anfragen an jede der URLs. Die Anfrage an jede der Adressen kann wiederholt werden – die sogenannte. „Impulse“. Beim ersten Impuls messen wir, wie lange es gedauert hat, eine Verbindung herzustellen und Daten herunterzuladen. Beim zweiten Impuls messen wir die Zeit, die zum Laden von Daten über eine bereits bestehende Verbindung benötigt wird. Vor dem dritten können wir eine Verzögerung einstellen und die Geschwindigkeit messen, mit der eine erneute Verbindung hergestellt wird usw.
Während des Tests messen wir alle Parameter, die das Gerät erreichen kann:
- DNS-Anfragezeit;
- Zeit für den TCP-Verbindungsaufbau;
- Zeit für den TLS-Verbindungsaufbau;
- Zeitpunkt des Empfangs des ersten Datenbytes;
- Gesamtladezeit;
- Status-Ergebniscode.
- Nachdem alle Impulse abgeschlossen sind, lädt die Probe alle Messungen zur Analyse.
Die Kernpunkte sind minimale Abhängigkeit von der Logik auf dem Client, Datenverarbeitung auf dem Server und die Messung paralleler Anfragen. Dadurch sind wir in der Lage, den Einfluss verschiedener Faktoren auf die Abfrageleistung 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 Abfrageleistung als nützlich erwiesen. Derzeit verfügen wir über 14 aktive Rezepte, mehr als 6000 Proben pro Sekunde, den Empfang von Daten aus allen Teilen der Erde und eine vollständige Geräteabdeckung. Wenn Netflix einen ähnlichen Dienst von einem Drittanbieter kaufen würde, würde das Millionen von Dollar pro Jahr kosten und die Abdeckung wäre deutlich schlechter.
Testtheorie in der Praxis: Prototyp
Mit einem solchen System konnten wir die Wirksamkeit von CDN-Proxys hinsichtlich der Anforderungslatenz bewerten. Jetzt benötigen Sie:
- Erstellen Sie einen Proxy-Prototyp.
- Platzieren Sie den Prototyp auf einem CDN.
- Bestimmen Sie, wie Clients an einen Proxy auf einem bestimmten CDN-Server weitergeleitet werden.
- Vergleichen Sie die Leistung mit Anfragen in AWS ohne Proxy.
Die Aufgabe besteht darin, die Wirksamkeit der vorgeschlagenen Lösung so schnell wie möglich zu bewerten. Aufgrund der Verfügbarkeit guter Netzwerkbibliotheken haben wir uns für die Implementierung des Prototyps für Go entschieden. Auf jedem CDN-Server haben wir den Prototyp-Proxy als statische Binärdatei installiert, um Abhängigkeiten zu minimieren und die Integration zu vereinfachen. In der ersten Implementierung haben wir so weit wie möglich Standardkomponenten und geringfügige Modifikationen für HTTP/2-Verbindungspooling und Anforderungsmultiplexing verwendet.
Für den Ausgleich zwischen den AWS-Regionen haben wir eine geografische DNS-Datenbank verwendet, dieselbe, die auch für den Ausgleich der Clients verwendet wird. Um einen CDN-Server für den Client auszuwählen, verwenden wir TCP Anycast für Server in Internet Exchange (IX). Bei dieser Option verwenden wir eine IP-Adresse für alle CDN-Server und der Client wird an den CDN-Server mit der geringsten Anzahl an IP-Hops weitergeleitet. Bei CDN-Servern, die von Internetprovidern (ISPs) installiert werden, haben wir keine Kontrolle über den Router, um TCP Anycast zu konfigurieren, daher verwenden wir , das Kunden für Video-Streaming an Internetanbieter weiterleitet.
Wir haben also drei Arten von Anforderungspfaden: zur Cloud über das offene Internet, über einen CDN-Server in IX oder über einen CDN-Server bei einem Internetanbieter. Unser Ziel ist es zu verstehen, welcher Weg besser ist und welche Vorteile ein Proxy im Vergleich zur Art und Weise hat, wie Anfragen an die Produktion gesendet werden. Dazu verwenden wir ein Probenahmesystem wie folgt:
Jeder der Pfade wird zu einem separaten Ziel, und wir schauen uns die Zeit an, die wir haben. Zur Analyse kombinieren wir die Proxy-Ergebnisse in einer Gruppe (wählen Sie die beste Zeit zwischen IX- und ISP-Proxys aus) und vergleichen sie mit der Zeit von Anfragen an die Cloud ohne Proxy:
Wie Sie sehen, waren die Ergebnisse gemischt – in den meisten Fällen sorgt der Proxy für eine gute Beschleunigung, es gibt aber auch genügend Kunden, bei denen sich die Situation deutlich verschlechtern wird.
Infolgedessen haben wir mehrere wichtige Dinge getan:
- Wir haben die erwartete Leistung von Anfragen von Clients an die Cloud über einen CDN-Proxy bewertet.
- Wir haben Daten von echten Kunden und von allen Arten von Geräten erhalten.
- Wir stellten fest, dass die Theorie nicht zu 100 % bestätigt war und das ursprüngliche Angebot mit einem CDN-Proxy für uns nicht funktionieren würde.
- Wir sind kein Risiko eingegangen – wir haben die Produktionskonfigurationen für Kunden nicht geändert.
- Nichts war kaputt.
Prototyp 2.0
Also zurück ans Zeichenbrett und den Vorgang noch einmal wiederholen.
Die Idee ist, dass wir statt eines 100-prozentigen Proxys den schnellsten Pfad für jeden Client ermitteln und Anfragen dorthin senden – das heißt, wir führen das durch, was man Client-Steuerung nennt.
Wie kann man das umsetzen? Wir können auf der Serverseite keine Logik verwenden, weil... Das Ziel besteht darin, eine Verbindung zu diesem Server herzustellen. Es muss eine Möglichkeit geben, dies auf dem Client zu tun. Und das im Idealfall mit einem Minimum an komplexer Logik, um das Problem der Integration mit einer großen Anzahl von Client-Plattformen nicht zu lösen.
Die Antwort ist die Verwendung von DNS. In unserem Fall verfügen wir über eine eigene DNS-Infrastruktur und können eine Domänenzone einrichten, für die unsere Server autoritär sind. Es funktioniert so:
- Der Client stellt mithilfe eines Hosts, beispielsweise api.netflix.xom, eine Anfrage an den DNS-Server.
- Die Anfrage kommt auf unserem DNS-Server an
- Der DNS-Server weiß, welcher Pfad für diesen Client am schnellsten ist und vergibt die entsprechende IP-Adresse.
Die Lösung weist eine zusätzliche Komplexität auf: Autoritäre DNS-Anbieter sehen die IP-Adresse des Clients nicht und können nur die IP-Adresse des rekursiven Resolvers lesen, den der Client verwendet.
Infolgedessen muss unser autoritärer Resolver eine Entscheidung nicht für einen einzelnen Client, sondern für eine Gruppe von Clients auf der Grundlage des rekursiven Resolvers treffen.
Zur Lösung verwenden wir dieselben Stichproben, aggregieren die Messergebnisse von Clients für jeden der rekursiven Resolver und entscheiden, wohin diese Gruppe von ihnen gesendet werden soll – ein Proxy über IX mit TCP Anycast, über einen ISP-Proxy oder direkt in die Cloud.
Wir erhalten das folgende System:
Das daraus resultierende DNS-Steuerungsmodell ermöglicht es Ihnen, Clients basierend auf historischen Beobachtungen der Geschwindigkeit der Verbindungen von Clients zur Cloud zu leiten.
Auch hier stellt sich die Frage, wie effektiv dieser Ansatz funktionieren wird. Zur Beantwortung nutzen wir erneut unser Sondensystem. Daher konfigurieren wir die Presenter-Konfiguration, bei der eines der Ziele der Richtung der DNS-Steuerung folgt, das andere direkt in die Cloud geht (aktuelle Produktion).
Als Ergebnis vergleichen wir die Ergebnisse und erhalten eine Einschätzung der Wirksamkeit:
Dadurch haben wir einige wichtige Dinge gelernt:
- Wir haben die erwartete Leistung von Anfragen von Clients an die Cloud mithilfe von DNS Steering bewertet.
- Wir haben Daten von echten Kunden und von allen Arten von Geräten erhalten.
- Die Wirksamkeit der vorgeschlagenen Idee wurde nachgewiesen.
- Wir sind kein Risiko eingegangen – wir haben die Produktionskonfigurationen für Kunden nicht geändert.
- Nichts war kaputt.
Nun zum schwierigen Teil: Wir bringen es in Produktion
Der einfache Teil ist nun vorbei – es gibt einen funktionierenden Prototyp. Der schwierige Teil besteht nun darin, eine Lösung für den gesamten Netflix-Verkehr auf den Markt zu bringen, die für 150 Millionen Benutzer, Tausende von Geräten, Hunderte von Mikrodiensten und ein sich ständig änderndes Produkt und eine sich ständig ändernde Infrastruktur bereitgestellt wird. Netflix-Server empfangen Millionen von Anfragen pro Sekunde und es ist leicht, den Dienst durch unachtsames Handeln zu unterbrechen. Gleichzeitig wollen wir den Datenverkehr dynamisch über Tausende von CDN-Servern im Internet leiten, wo sich ständig und im ungünstigsten Moment etwas ändert und kaputt geht.
Und bei all dem verfügt das Team über drei Ingenieure, die für die Entwicklung, Bereitstellung und den vollständigen Support des Systems verantwortlich sind.
Daher werden wir weiterhin über erholsamen und gesunden Schlaf sprechen.
Wie kann man die Entwicklung fortsetzen und nicht die ganze Zeit mit dem Support verbringen? Unser Ansatz basiert auf 3 Prinzipien:
- Wir reduzieren das mögliche Ausmaß von Pannen (Explosionsradius).
- Wir bereiten uns auf Überraschungen vor – wir gehen davon aus, dass trotz Tests und persönlicher Erfahrung etwas kaputt geht.
- Graceful Degradation – wenn etwas nicht richtig funktioniert, sollte es automatisch behoben werden, auch wenn nicht auf die effizienteste Weise.
Es stellte sich heraus, dass wir in unserem Fall mit dieser Herangehensweise an das Problem eine einfache und effektive Lösung finden und die Systemunterstützung erheblich vereinfachen können. Wir erkannten, dass wir dem Client einen kleinen Code hinzufügen und ihn auf Netzwerkanforderungsfehler überwachen könnten, die durch Verbindungsprobleme verursacht wurden. Bei Netzwerkfehlern greifen wir direkt auf die Cloud zurück. Diese Lösung erfordert für die Kundenteams keinen großen Aufwand, reduziert aber das Risiko unerwarteter Ausfälle und Überraschungen für uns erheblich.
Selbstverständlich verfolgen wir trotz des Rückgriffs dennoch eine klare Disziplin bei der Entwicklung:
- Beispieltest.
- A/B-Tests oder Canaries.
- Progressiver Rollout.
Anhand von Mustern wurde die Vorgehensweise beschrieben – Änderungen werden zunächst anhand eines maßgeschneiderten Rezepts getestet.
Für Canary-Tests benötigen wir vergleichbare Serverpaare, auf denen wir vergleichen können, wie das System vor und nach den Änderungen funktioniert. Dazu wählen wir aus unseren zahlreichen CDN-Sites Serverpaare aus, die vergleichbaren Datenverkehr empfangen:
Anschließend installieren wir den Build mit den Änderungen auf dem Canary-Server. Um die Ergebnisse auszuwerten, betreiben wir ein System, das etwa 100–150 Metriken mit einer Stichprobe von Kontrollservern vergleicht:
Wenn die Canary-Tests erfolgreich sind, veröffentlichen wir sie schrittweise und in Wellen. Wir aktualisieren die Server an jedem Standort nicht gleichzeitig – der Verlust eines gesamten Standorts aufgrund von Problemen hat größere Auswirkungen auf den Dienst für Benutzer als der Verlust der gleichen Anzahl von Servern an verschiedenen Standorten.
Im Allgemeinen hängen die Wirksamkeit und Sicherheit dieses Ansatzes von der Quantität und Qualität der gesammelten Kennzahlen ab. Für unser Abfragebeschleunigungssystem sammeln wir Metriken aus allen möglichen Komponenten:
- von Kunden – Anzahl der Sitzungen und Anfragen, Fallback-Raten;
- Proxy – Statistiken über die Anzahl und den Zeitpunkt der Anfragen;
- DNS – Anzahl und Ergebnisse der Anfragen;
- Cloud Edge – Anzahl und Zeit für die Bearbeitung von Anfragen in der Cloud.
All dies wird in einer einzigen Pipeline gesammelt und je nach Bedarf entscheiden wir, welche Metriken an Echtzeitanalysen und welche an Elasticsearch oder Big Data für detailliertere Diagnosen gesendet werden.
Wir überwachen
In unserem Fall nehmen wir Änderungen am kritischen Pfad der Anforderungen zwischen Client und Server vor. Gleichzeitig ist die Anzahl unterschiedlicher Komponenten auf dem Client, auf dem Server und auf dem Weg durch das Internet enorm. Änderungen auf dem Client und dem Server treten ständig auf – während der Arbeit Dutzender Teams und natürlicher Veränderungen im Ökosystem. Wir stecken in der Mitte – bei der Diagnose von Problemen besteht eine gute Chance, dass wir einbezogen werden. Daher müssen wir genau verstehen, wie wir Metriken definieren, sammeln und analysieren, um Probleme schnell zu isolieren.
Im Idealfall vollständiger Zugriff auf alle Arten von Metriken und Filtern in Echtzeit. Da es jedoch viele Kennzahlen gibt, stellt sich die Frage nach den Kosten. In unserem Fall trennen wir Metriken und Entwicklungstools wie folgt:
Zur Erkennung und Triage von Problemen nutzen wir unser eigenes Open-Source-Echtzeitsystem и - zur Visualisierung. Es speichert aggregierte Metriken im Speicher, ist zuverlässig und lässt sich in das Warnsystem integrieren. Zur Lokalisierung und Diagnose haben wir Zugriff auf Protokolle von Elasticsearch und Kibana. Zur statistischen Analyse und Modellierung nutzen wir Big Data und Visualisierung in Tableau.
Es scheint, dass dieser Ansatz sehr schwierig zu handhaben ist. Durch die hierarchische Organisation von Metriken und Tools können wir jedoch ein Problem schnell analysieren, die Art des Problems bestimmen und dann einen Drilldown zu detaillierten Metriken durchführen. Im Allgemeinen verbringen wir etwa 1–2 Minuten damit, die Ursache der Störung zu ermitteln. Danach arbeiten wir mit einem speziellen Team an der Diagnose – von mehreren zehn Minuten bis zu mehreren Stunden.
Auch wenn die Diagnose schnell gestellt wird, möchten wir nicht, dass dies häufig vorkommt. Im Idealfall erhalten wir nur dann eine kritische Warnung, wenn es erhebliche Auswirkungen auf den Service gibt. Für unser Abfragebeschleunigungssystem haben wir nur zwei Benachrichtigungen, die Folgendes benachrichtigen:
- Client-Fallback-Prozentsatz – Bewertung des Kundenverhaltens;
- Prozentuale Sondenfehler – Stabilitätsdaten von Netzwerkkomponenten.
Diese kritischen Warnungen überwachen, ob das System für die Mehrheit der Benutzer funktioniert. Wir untersuchen, wie viele Clients einen Fallback nutzten, wenn sie keine Anforderungsbeschleunigung erhalten konnten. Wir erhalten durchschnittlich weniger als eine kritische Warnung pro Woche, obwohl im System eine Menge Änderungen vorgenommen werden. Warum reicht uns das?
- Es gibt einen Client-Fallback, wenn unser Proxy nicht funktioniert.
- Es gibt ein automatisches Lenksystem, das auf Probleme reagiert.
Weitere Details zu Letzterem. Unser Testsystem und das System zur automatischen Ermittlung des optimalen Pfades für Anfragen vom Kunden in die Cloud ermöglichen es uns, einige Probleme automatisch zu bewältigen.
Kehren wir zu unserer Beispielkonfiguration und den drei Pfadkategorien zurück. Neben der Ladezeit können wir auch die Tatsache der Lieferung selbst betrachten. Wenn es nicht möglich war, die Daten zu laden, können wir durch Betrachtung der Ergebnisse entlang verschiedener Pfade feststellen, wo und was kaputt gegangen ist und ob wir das Problem automatisch beheben können, indem wir den Anforderungspfad ändern.
Beispiele:
Dieser Prozess kann automatisiert werden. Integrieren Sie es in das Lenksystem. Und bringen Sie ihm bei, auf Leistungs- und Zuverlässigkeitsprobleme zu reagieren. Wenn etwas kaputt geht, reagieren Sie, wenn es eine bessere Option gibt. Gleichzeitig ist eine sofortige Reaktion durch den Rückgriff auf Kunden nicht entscheidend.
Somit lassen sich die Grundsätze der Systemunterstützung wie folgt formulieren:
- Verringerung des Ausmaßes von Ausfällen;
- Sammeln von Metriken;
- Wir reparieren Störungen automatisch, wenn wir können;
- Wenn dies nicht möglich ist, benachrichtigen wir Sie;
- Wir arbeiten an Dashboards und Triage-Tools für eine schnelle Reaktion.
Gewonnene Erkenntnisse
Das Schreiben eines Prototyps nimmt nicht viel Zeit in Anspruch. In unserem Fall war es nach 4 Monaten fertig. Damit erhielten wir neue Metriken und 10 Monate nach Entwicklungsbeginn den ersten Produktionsverkehr. Dann begann die mühsame und sehr schwierige Arbeit: das System schrittweise zu produktivisieren und zu skalieren, den Hauptverkehr zu migrieren und aus Fehlern zu lernen. Allerdings wird dieser effektive Prozess nicht linear verlaufen – trotz aller Bemühungen lässt sich nicht alles vorhersagen. Es ist viel effektiver, schnell zu iterieren und auf neue Daten zu reagieren.
Aufgrund unserer Erfahrung können wir Folgendes empfehlen:
- Vertraue nicht deiner Intuition.
Trotz der großen Erfahrung unserer Teammitglieder hat uns unsere Intuition ständig im Stich gelassen. Beispielsweise haben wir die erwartete Beschleunigung durch die Verwendung eines CDN-Proxys oder das Verhalten von TCP Anycast falsch vorhergesagt.
- Holen Sie sich Daten aus der Produktion.
Es ist wichtig, so schnell wie möglich Zugriff auf zumindest eine kleine Menge an Produktionsdaten zu erhalten. Es ist nahezu unmöglich, die Anzahl der einzelnen Fälle, Konfigurationen und Einstellungen unter Laborbedingungen zu ermitteln. Durch den schnellen Zugriff auf die Ergebnisse können Sie potenzielle Probleme schnell erkennen und in der Systemarchitektur berücksichtigen.
- Befolgen Sie nicht die Ratschläge und Ergebnisse anderer – sammeln Sie Ihre eigenen Daten.
Befolgen Sie die Grundsätze zum Sammeln und Analysieren von Daten, akzeptieren Sie jedoch nicht blind die Ergebnisse und Aussagen anderer Personen. Nur Sie können genau wissen, was für Ihre Benutzer funktioniert. Ihre Systeme und Ihre Kunden können sich erheblich von denen anderer Unternehmen unterscheiden. Glücklicherweise sind mittlerweile Analysetools verfügbar und einfach zu verwenden. Die Ergebnisse, die Sie erhalten, entsprechen möglicherweise nicht den Behauptungen von Netflix, Facebook, Akamai und anderen Unternehmen. In unserem Fall unterscheidet sich die Leistung von TLS, HTTP2 oder Statistiken zu DNS-Anfragen von den Ergebnissen von Facebook, Uber, Akamai – weil wir unterschiedliche Geräte, Clients und Datenflüsse haben.
- Verfolgen Sie Modetrends nicht unnötig und bewerten Sie die Wirksamkeit.
Fangen Sie einfach an. Es ist besser, in kurzer Zeit ein einfaches, funktionierendes System zu erstellen, als viel Zeit in die Entwicklung von Komponenten zu investieren, die Sie nicht benötigen. Lösen Sie wichtige Aufgaben und Probleme basierend auf Ihren Messungen und Ergebnissen.
- Machen Sie sich bereit für neue Anwendungen.
So wie es schwierig ist, alle Probleme vorherzusagen, ist es auch schwierig, die Vorteile und Anwendungen im Voraus vorherzusagen. Lassen Sie sich von Startups inspirieren – ihrer Fähigkeit, sich an die Bedingungen der Kunden anzupassen. In Ihrem Fall entdecken Sie möglicherweise neue Probleme und deren Lösungen. In unserem Projekt haben wir uns zum Ziel gesetzt, die Anfragelatenz zu reduzieren. Bei der Analyse und den Diskussionen haben wir jedoch festgestellt, dass wir auch Proxy-Server verwenden können:
- um den Datenverkehr über die AWS-Regionen auszugleichen und die Kosten zu senken;
- um die CDN-Stabilität zu modellieren;
- um DNS zu konfigurieren;
- um TLS/TCP zu konfigurieren.
Abschluss
In dem Bericht habe ich beschrieben, wie Netflix das Problem der Beschleunigung von Internetanfragen zwischen Clients und der Cloud löst. Wie wir mithilfe eines Stichprobensystems Daten von Kunden sammeln und die gesammelten historischen Daten verwenden, um Produktionsanfragen von Kunden über den schnellsten Weg im Internet weiterzuleiten. Wie wir die Prinzipien von Netzwerkprotokollen, unserer CDN-Infrastruktur, unserem Backbone-Netzwerk und unseren DNS-Servern nutzen, um diese Aufgabe zu erfüllen.
Unsere Lösung ist jedoch nur ein Beispiel dafür, wie wir bei Netflix ein solches System implementiert haben. Was bei uns funktioniert hat. Der angewandte Teil meines Berichts für Sie sind die Grundsätze der Entwicklung und Unterstützung, denen wir folgen und die gute Ergebnisse erzielen.
Unsere Lösung des Problems passt möglicherweise nicht zu Ihnen. Die Theorie und die Designprinzipien bleiben jedoch bestehen, auch wenn Sie nicht über eine eigene CDN-Infrastruktur verfügen oder diese sich erheblich von unserer unterscheidet.
Auch die Geschwindigkeit der Geschäftsanfragen bleibt wichtig. Und selbst für einen einfachen Dienst müssen Sie eine Wahl treffen: zwischen Cloud-Anbietern, Serverstandort, CDN- und DNS-Anbietern. Ihre Wahl beeinflusst die Effektivität von Internetabfragen für Ihre Kunden. Und es ist wichtig, dass Sie diesen Einfluss messen und verstehen.
Beginnen Sie mit einfachen Lösungen und achten Sie darauf, wie Sie das Produkt ändern. Lernen Sie nach und nach und verbessern Sie das System basierend auf den Daten Ihrer Kunden, Ihrer Infrastruktur und Ihres Unternehmens. Bedenken Sie die Möglichkeit unerwarteter Ausfälle während des Designprozesses. Und dann können Sie Ihren Entwicklungsprozess beschleunigen, die Lösungseffizienz verbessern, unnötigen Supportaufwand vermeiden und ruhig schlafen.
Dieses Jahr im Online-Format. Sie können einem der Väter von DevOps, John Willis selbst, Fragen stellen!
Source: habr.com