{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Wir beschleunigen Internetanfragen und schlafen ruhig","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix \u2014 der Marktf\u00fchrer im Bereich Streaming \u2014 ist ein Unternehmen, das diesen Sektor geschaffen und aktiv weiterentwickelt hat. Netflix ist nicht nur f\u00fcr sein umfangreiches Katalogangebot an Filmen und Serien bekannt, die nahezu von jedem Ort auf der Welt und mit jedem Ger\u00e4t mit Bildschirm verf\u00fcgbar sind, sondern auch f\u00fcr seine zuverl\u00e4ssige Infrastruktur und einzigartige Ingenieurskultur. <\/p>\n<p>Ein anschauliches Beispiel f\u00fcr Netflix' Ansatz zur Entwicklung und Unterst\u00fctzung komplexer Systeme wurde auf der DevOops 2019 vorgestellt von <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergei Fedorov<\/a><\/noindex> \u2014 Direktor f\u00fcr Entwicklung bei Netflix. Absolvent der Fakult\u00e4t VMT der NNSU benannt nach Lobatschewski, ist Sergei einer der ersten Ingenieure im Open Connect \u2014 CDN-Team bei Netflix. Er hat Systeme zur \u00dcberwachung 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\u00fcr die Nutzer so schnell wie m\u00f6glich funktioniert.<\/p>\n<p>Der Vortrag erhielt beste Bewertungen von den Teilnehmern der Konferenz, und wir haben eine Textversion f\u00fcr Sie vorbereitet.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Im Vortrag erkl\u00e4rte Sergei ausf\u00fchrlich<\/h2>\n<p><\/p>\n<ul>\n<li>was die Verz\u00f6gerung von Internetanfragen zwischen Client und Server beeinflusst;<\/li>\n<li>wie man diese Verz\u00f6gerung verringern kann;<\/li>\n<li>wie man fehlertolerante Systeme entwirft, wartet und \u00fcberwacht;<\/li>\n<li>wie man Ergebnisse in kurzer Zeit und mit minimalem Risiko f\u00fcr das Gesch\u00e4ft erzielt;<\/li>\n<li>wie man Ergebnisse analysiert und aus Fehlern lernt.<\/li>\n<\/ul>\n<p>\nDie Antworten auf diese Fragen sind nicht nur f\u00fcr diejenigen wichtig, die in gro\u00dfen Unternehmen arbeiten. <\/p>\n<p>Die vorgestellten Prinzipien und Techniken sollten von jedem gekannt und praktiziert werden, der Internetprodukte entwickelt und unterst\u00fctzt.<\/p>\n<p><b>Als n\u00e4chstes folgt das Narrativ aus der Sicht des Sprechers.<\/b><\/p>\n<h2>Die Bedeutung der Internetgeschwindigkeit<\/h2>\n<p>\nDie Geschwindigkeit von Internetanfragen steht in direktem Zusammenhang mit dem Gesch\u00e4ft. Betrachten wir den Bereich E-Commerce: Das Unternehmen Amazon gab 2009 an, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">dass eine Verz\u00f6gerung von 100 ms zu einem Verlust von 1 % der Verk\u00e4ufe f\u00fchrt.<\/a><\/noindex>Immer mehr mobile Ger\u00e4te und damit auch mobile Webseiten und Anwendungen kommen auf den Markt. Wenn Ihre Seite l\u00e4nger als 3 Sekunden zum Laden ben\u00f6tigt, verlieren Sie etwa die H\u00e4lfte der Nutzer. Seit<\/p>\n<p>Juli 2018 <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">ber\u00fccksichtigt Google die Ladegeschwindigkeit Ihrer Seite in den Suchergebnissen: Je schneller die Seite, desto h\u00f6her ihre Position bei Google.<\/a><\/noindex> Die Geschwindigkeit der Verbindung ist auch in Finanzinstitutionen wichtig, wo Verz\u00f6gerungen kritisch sind. Im Jahr 2015 schloss das Unternehmen Hibernia Networks<\/p>\n<p>ab. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">abgeschlossen<\/a><\/noindex> eine Kabelverbindung zwischen New York und London f\u00fcr 400 Millionen Dollar, um die Verz\u00f6gerung zwischen den St\u00e4dten um 6 ms zu reduzieren. Stellen Sie sich vor, 66 Millionen Dollar f\u00fcr 1 ms Verringerung der Verz\u00f6gerung!<\/p>\n<p>Laut <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">Forschung<\/a><\/noindex>, die Verbindungsgeschwindigkeit \u00fcber 5 Mbit\/s hat keinen direkten Einfluss mehr auf die Ladegeschwindigkeit einer typischen Webseite. Es gibt jedoch eine lineare Abh\u00e4ngigkeit zwischen der Verz\u00f6gerung der Verbindung und der Ladegeschwindigkeit der Seite:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix ist jedoch kein typisches Produkt. Der Einfluss von Verz\u00f6gerung und Geschwindigkeit auf die Nutzer ist ein aktives Analyse- und Entwicklungsfeld. Es gibt die App-Ladung und die Content-Auswahl, die von der Verz\u00f6gerung abh\u00e4ngt, aber auch das Laden statischer Elemente und das Streaming h\u00e4ngen von der Verbindungsgeschwindigkeit ab. Die Analyse und Optimierung der Schl\u00fcsselfaktoren, die die Servicequalit\u00e4t f\u00fcr den Nutzer beeinflussen, ist ein aktives Entwicklungsfeld mehrerer Teams bei Netflix. Eine der Aufgaben besteht darin, die Verz\u00f6gerung von Anfragen zwischen Netflix-Ger\u00e4ten und der Cloud-Infrastruktur zu reduzieren.<\/p>\n<p>In diesem Bericht konzentrieren wir uns auf die Verringerung der Verz\u00f6gerung (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\u00fcr Innovationen und Ergebnisse aufwendet, und nicht f\u00fcr die Diagnose von Betriebsproblemen und St\u00f6rungen.<\/p>\n<h2>Innerhalb von Netflix<\/h2>\n<p>\nTausende verschiedener Ger\u00e4te unterst\u00fctzen die Netflix-Anwendungen. Ihre Entwicklung \u00fcbernimmt vier verschiedene Teams, die unterschiedliche Versionen des Clients f\u00fcr Android, iOS, TV und Webbrowser erstellen. Au\u00dferdem investieren wir viel Zeit und M\u00fche in die Verbesserung und Personalisierung der Benutzeroberfl\u00e4che. Zu diesem Zweck f\u00fchren wir Hunderte A\/B-Tests parallel durch.<\/p>\n<p>Die Personalisierung wird durch hunderte von Microservices in der AWS-Cloud unterst\u00fctzt, die personalisierte Daten f\u00fcr den Nutzer, die Anfragenverwaltung, Telemetrie, Big Data und Encoding bereitstellen. Die Visualisierung des Traffics sieht folgenderma\u00dfen aus:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link zum Video mit der Demo (6:04-6:23)<\/a><\/noindex><\/p>\n<p>Links befindet sich der Einstiegspunkt, dann wird der Traffic auf mehrere Hundert Microservices verteilt, die von verschiedenen Backend-Teams unterst\u00fctzt werden.<\/p>\n<p>Ein weiterer wichtiger Bestandteil unserer Infrastruktur ist das Open Connect CDN, das statische Inhalte \u2013 Videos, Bilder, Client-Code usw. \u2013 bis zum Endbenutzer liefert. Das CDN befindet sich auf ma\u00dfgeschneiderten Servern (OCA \u2013 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\u00f6glichst viele Daten an die Benutzer senden kann. <\/p>\n<p>Die \u201eWand\u201c aus diesen Servern an einem Internet-Traffic-Austauschpunkt (Internet eXchange \u2013 IX) sieht so aus:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer Internet Exchange erm\u00f6glicht 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\u00fcr deren Installation und Wartung verantwortlich:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDar\u00fcber hinaus stellen wir Server auch direkt Internetanbietern zur Verf\u00fcgung, die sie in ihr Netzwerk integrieren, um die Lokalisierung des Netflix-Traffics und die Streaming-Qualit\u00e4t f\u00fcr die Benutzer zu verbessern:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEine Sammlung von AWS-Diensten verantwortet die Verteilung von Videoanfragen von Clients an die CDN-Server sowie die Konfiguration der Server selbst \u2013 Aktualisierung von Inhalten, Programmcode, Einstellungen usw. F\u00fcr 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\u00f6nnen.<\/p>\n<p>Nach <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">Sch\u00e4tzungen von Sandvine<\/a><\/noindex>, unsere CDN-Infrastruktur liefert zu Spitzenzeiten etwa \u215b des weltweiten Internetverkehrs und \u2153 des Verkehrs in Nordamerika, wo Netflix am l\u00e4ngsten besteht. Beeindruckende Zahlen, aber f\u00fcr mich ist eine der erstaunlichsten Errungenschaften, dass das gesamte CDN-System von einem Team von weniger als 150 Personen entwickelt und gewartet wird.<\/p>\n<p>Urspr\u00fcnglich 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\u00f6nnen.<\/p>\n<h2>\u00dcber die Beschleunigung des Internets<\/h2>\n<p>\nHeute hat Netflix 3 AWS-Regionen, und die Latenz der Anfragen an die Cloud h\u00e4ngt davon ab, wie weit der Kunde von der n\u00e4chstgelegenen Region entfernt ist. Daf\u00fcr 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\u00f6nnen diese Anfragen nicht zwischengespeichert werden, da die APIs personalisiert sind und jedes Ergebnis einzigartig ist.<\/p>\n<p>Lass uns einen Proxy auf dem CDN-Server einrichten und den Traffic dar\u00fcber leiten. Wird das schneller sein?<\/p>\n<h2>Technische Grundlagen<\/h2>\n<p>\nErinnern wir uns, wie Netzwerkprotokolle funktionieren. Heute nutzt der gr\u00f6\u00dfte Teil des Internetverkehrs HTTPS, das von den unteren Protokollen TCP und TLS abh\u00e4ngt. Um eine Verbindung vom Client zum Server herzustellen, f\u00fchrt 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 \u00fcbertragen. Bei einer Verz\u00f6gerung von 100 ms pro Austausch (RTT) ben\u00f6tigen wir 400 ms, um das erste Bit Daten zu erhalten:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWenn die Zertifikate auf dem CDN-Server platziert werden, k\u00f6nnen wir die Zeit f\u00fcr das \"Handshake\" zwischen dem Client und dem Server erheblich verk\u00fcrzen, wenn das CDN n\u00e4her ist. Angenommen, die Verz\u00f6gerung bis zum CDN-Server betr\u00e4gt 30 ms. Dann brauchen wir f\u00fcr den Erhalt des ersten Bits bereits 220 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDoch die Vorteile enden hier nicht. Nachdem die Verbindung hergestellt ist, erh\u00f6ht TCP das Congestion Window (die Menge an Informationen, die es gleichzeitig \u00fcber diese Verbindung \u00fcbertragen kann). Wenn ein Datenpaket verloren geht, verringern klassische Implementierungen des TCP-Protokolls (wie TCP New Reno) das offene \"Fenster\" um die H\u00e4lfte. Das Wachstum des Congestion Windows und die Geschwindigkeit seiner Wiederherstellung nach einem Verlust h\u00e4ngen erneut von der Verz\u00f6gerung (RTT) zum Server ab. Wenn diese Verbindung nur bis zum CDN-Server f\u00fchrt, wird die Wiederherstellung schneller sein. Der Verlust von Paketen ist dabei ein g\u00e4ngiges Ph\u00e4nomen, insbesondere bei drahtlosen Netzwerken.<\/p>\n<p>Die Bandbreite des Internets kann insbesondere zu Sto\u00dfzeiten durch den Nutzerverkehr abnehmen, was zu \"Staus\" f\u00fchren kann. Dabei gibt es im Internet keine M\u00f6glichkeit, einzelnen Anfragen Priorit\u00e4ten gegen\u00fcber anderen zuzuweisen. Zum Beispiel k\u00f6nnen kleine, latenzempfindliche Anfragen nicht im Vergleich zu \"schweren\" Datenstr\u00f6men, die die Netzwerkauslastung erh\u00f6hen, priorisiert werden. In unserem Fall erm\u00f6glicht uns jedoch das Vorhandensein eines eigenen Backbone-Netzes, dies auf einem Teil des Anfragewegs zu tun \u2013 zwischen dem CDN und der Cloud, und wir k\u00f6nnen es vollst\u00e4ndig konfigurieren. Es ist m\u00f6glich, kleinere und latenzempfindliche Pakete zu priorisieren, w\u00e4hrend gro\u00dfe Datenstr\u00f6me etwas sp\u00e4ter \u00fcbertragen werden. Je n\u00e4her das CDN am Kunden ist, desto effizienter wird es.<\/p>\n<p>Auch die Anwendungsschicht-Protokolle (OSI-Ebene 7) haben Einfluss auf die Latenz. Neue Protokolle wie HTTP\/2 erm\u00f6glichen eine Optimierung der Performance paralleler Anfragen. Allerdings haben wir bei Netflix auch Kunden mit \u00e4lteren Ger\u00e4ten, die keine neuen Protokolle unterst\u00fctzen. Nicht alle Kunden k\u00f6nnen aktualisiert oder optimal konfiguriert werden. Zwischen dem CDN-Proxy und der Cloud haben wir jedoch die volle Kontrolle und die M\u00f6glichkeit, 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\u00fcber hinaus k\u00f6nnen wir Multiplex-Anfragen \u00fcber eine bereits etablierte Verbindung zwischen dem CDN und der Cloud durchf\u00fchren, was die Auslastung der Verbindung auf TCP-Ebene verbessert:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Messen<\/h2>\n<p>\nObwohl die Theorie Verbesserungen verspricht, springen wir nicht sofort dazu, das System in die Produktion zu bringen. Stattdessen m\u00fcssen wir zuerst nachweisen, dass die Idee in der Praxis funktionieren wird. Dazu m\u00fcssen wir einige Fragen beantworten:<\/p>\n<ul>\n<li><b>Geschwindigkeit<\/b>: Wird der Proxy schneller sein?<\/li>\n<li><b>Zuverl\u00e4ssigkeit<\/b>: Wird er h\u00e4ufiger ausfallen?<\/li>\n<li><b>Komplexit\u00e4t<\/b>: Wie integriert man es mit Anwendungen?<\/li>\n<li><b>Kosten<\/b>: Wie hoch sind die Kosten f\u00fcr den Einsatz zus\u00e4tzlicher Infrastruktur?<\/li>\n<\/ul>\n<p>\nBetrachten wir unseren Ansatz zur Bewertung des ersten Punkts etwas genauer. Die anderen Punkte werden auf \u00e4hnliche Weise behandelt.<\/p>\n<p>F\u00fcr 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\u00e4hrden. Daf\u00fcr gibt es mehrere Ans\u00e4tze:<\/p>\n<ol>\n<li>RUM oder passive Messung von Anfragen. Wir messen die Ausf\u00fchrungszeit aktueller Anfragen von Benutzern und gew\u00e4hrleisten eine vollst\u00e4ndige 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.<\/li>\n<li>Labortests. Spezielle Server und Infrastruktur, die Clients simulieren. Mit ihrer Hilfe f\u00fchren wir die notwendigen Tests durch. So erhalten wir die vollst\u00e4ndige Kontrolle \u00fcber die Messergebnisse und ein klares Signal. Aber es gibt keine vollst\u00e4ndige Abdeckung der Ger\u00e4te und Standorte der Benutzer (besonders bei einem weltweiten Service und der Unterst\u00fctzung von Tausenden von Ger\u00e4temodellen).<\/li>\n<\/ol>\n<p>\nWie k\u00f6nnen die Vorteile beider Methoden kombiniert werden?<\/p>\n<p>Unser Team fand eine L\u00f6sung. Wir schrieben ein kleines St\u00fcck Code \u2013 eine Probe \u2013, die wir in unsere Anwendung eingebaut haben. Die Proben erm\u00f6glichen es uns, vollst\u00e4ndig kontrollierte Netzwerktests von unseren Ger\u00e4ten aus durchzuf\u00fchren. Es funktioniert folgenderma\u00dfen: <\/p>\n<ol>\n<li>Kurz nach dem Laden der Anwendung und dem Abschluss der Anfangsaktivit\u00e4ten starten wir unsere Proben. <\/li>\n<li>Der Client sendet eine Anfrage an den Server und erh\u00e4lt ein \"Rezept\" f\u00fcr den Test. Das Rezept besteht aus einer Liste von URLs, an die HTTP(s)-Anfragen gesendet werden sollen. Dar\u00fcber hinaus konfiguriert das Rezept die Parameter der Anfragen: Verz\u00f6gerungen zwischen den Anfragen, das Volumen der angeforderten Daten, HTTP(s)-Headers usw. Dabei k\u00f6nnen wir parallel mehrere unterschiedliche Rezepte testen \u2013 bei der Anfrage zur Konfiguration wird zuf\u00e4llig bestimmt, welches Rezept ausgegeben wird. <\/li>\n<li>Die Startzeit der Probe wird so gew\u00e4hlt, dass sie nicht mit der aktiven Nutzung von Netzwerkressourcen beim Client in Konflikt steht. Im Wesentlichen wird ein Zeitpunkt gew\u00e4hlt, an dem der Client inaktiv ist.<\/li>\n<li>Nach Erhalt des Rezepts sendet der Client Anfragen an jede der URLs parallel. Die Anfrage an jede Adresse kann wiederholt werden \u2013 sogenannte \u201eImpulse\u201c. Bei der ersten Messung erfassen wir, wie viel Zeit f\u00fcr den Verbindungsaufbau und den Download der Daten ben\u00f6tigt wurde. Bei der zweiten Messung erfassen wir die Zeit f\u00fcr den Daten-Download \u00fcber die bereits hergestellte Verbindung. Vor der dritten Messung k\u00f6nnen wir eine Verz\u00f6gerung einf\u00fcgen und die Geschwindigkeit des erneuten Verbindungsaufbaus messen usw.\n<p>W\u00e4hrend des Tests messen wir alle Parameter, die das Ger\u00e4t erfassen kann:<\/p>\n<ul>\n<li>die Zeit der DNS-Anfrage;<\/li>\n<li>die Zeit zum Herstellen einer TCP-Verbindung;<\/li>\n<li>die Zeit zum Herstellen einer TLS-Verbindung;<\/li>\n<li>die Zeit bis zum Empfang des ersten Datenbytes;<\/li>\n<li>die gesamte Ladezeit;<\/li>\n<li>Statuscode des Ergebnisses.<\/li>\n<\/ul>\n<\/li>\n<li> Nach Abschluss aller Pulses l\u00e4dt die Probe die Ergebnisse aller Messungen zur Analyse hoch.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWesentliche Punkte sind die minimale Abh\u00e4ngigkeit von Logik auf der Client-Seite, die Datenverarbeitung auf dem Server und die Messung paralleler Anfragen. Dadurch erhalten wir die M\u00f6glichkeit, den Einfluss verschiedener, die Leistungsf\u00e4higkeit der Anfragen beeinflussender Faktoren zu isolieren und zu testen, sie innerhalb eines Rezepts zu variieren und Ergebnisse von echten Kunden zu erhalten.<\/p>\n<p>Diese Infrastruktur hat sich als n\u00fctzlich 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\u00e4ten bieten. W\u00fcrde Netflix einen solchen Dienst von Drittanbietern kaufen, w\u00fcrde er Millionen Dollar pro Jahr kosten, bei weitaus schlechterer Abdeckung.<\/p>\n<h2>Wir \u00fcberpr\u00fcfen die Theorie in der Praxis: Prototyp<\/h2>\n<p>\nMit einem solchen System haben wir die M\u00f6glichkeit erhalten, die Effizienz von CDN-Proxys auf die Anfrageverz\u00f6gerung zu bewerten. Jetzt m\u00fcssen wir:<\/p>\n<ul>\n<li>einen Proxy-Prototyp erstellen;<\/li>\n<li>den Prototyp im CDN bereitstellen;<\/li>\n<li>bestimmen, wie man Clients zu einem Proxy auf einem bestimmten CDN-Server leitet;<\/li>\n<li>die Leistung mit Anfragen in AWS ohne Proxy vergleichen.<\/li>\n<\/ul>\n<p>\nDie Aufgabe besteht darin, die Effizienz der vorgeschlagenen L\u00f6sung so schnell wie m\u00f6glich zu bewerten. F\u00fcr die Umsetzung des Prototyps haben wir Go gew\u00e4hlt, dank der verf\u00fcgbaren guten Netzwerkbibliotheken. Auf jedem CDN-Server haben wir den Proxy-Prototyp als statisches Bin\u00e4rformat installiert, um Abh\u00e4ngigkeiten zu minimieren und die Integration zu vereinfachen. In der ersten Implementierung haben wir weitestgehend standardisierte Komponenten und kleine Modifikationen f\u00fcr HTTP\/2-Verbindungs-Pooling und Anfrage-Multiplexing verwendet.<\/p>\n<p>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\u00fcr den Client auszuw\u00e4hlen, nutzen wir TCP Anycast f\u00fcr Server im Internet Exchange (IX). In diesem Fall verwenden wir eine IP-Adresse f\u00fcr 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 \u00fcber den Router zur Konfiguration von TCP Anycast, daher verwenden wir <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">die gleiche Logik<\/a><\/noindex>, nach der die Clients zu den Internet-Anbietern f\u00fcr das Video-Streaming geleitet werden.<\/p>\n<p>Wir haben also drei Arten von Pfaden f\u00fcr die Anforderung: in die Cloud \u00fcber das offene Internet, \u00fcber einen CDN-Server im IX oder \u00fcber 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\u00f6sung im Vergleich zu den Anforderungen im Produktionsbetrieb bringt. Dazu verwenden wir ein Probesystem wie folgt:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJeder dieser Pfade wird ein separater Zielort, und wir betrachten die Zeit, die wir erhalten haben. F\u00fcr die Analyse fassen wir die Proxy-Ergebnisse in einer Gruppe zusammen (wir w\u00e4hlen die beste Zeit zwischen IX- und ISP-Proxy) und vergleichen sie mit den Zeiten f\u00fcr Anforderungen in die Cloud ohne Proxy:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWie zu sehen ist, sind die Ergebnisse uneindeutig \u2013 in den meisten F\u00e4llen bietet der Proxy eine gute Beschleunigung, aber es gibt auch gen\u00fcgend Clients, bei denen sich die Situation erheblich verschlechtert. <\/p>\n<p>Insgesamt haben wir einige wichtige Dinge getan:<\/p>\n<ol>\n<li>Wir haben die erwartete Leistung der Anfragen von Clients in die Cloud \u00fcber den CDN-Proxy bewertet.<\/li>\n<li>Wir haben Daten von echten Clients aus allen Ger\u00e4tetypen erhalten.<\/li>\n<li>Wir haben erkannt, dass die Theorie nicht zu 100% best\u00e4tigt wurde und das urspr\u00fcngliche Angebot mit dem CDN-Proxy f\u00fcr uns nicht funktioniert.<\/li>\n<li>Wir haben kein Risiko eingegangen \u2013 die Produktionskonfigurationen f\u00fcr die Clients nicht ge\u00e4ndert.<\/li>\n<li>Nichts kaputt gemacht. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prototyp 2.0<\/h2>\n<p>\nLassen Sie uns also zur\u00fcck an den Zeichenbrett und den Prozess von neuem beginnen.<\/p>\n<p>Die Idee ist, anstelle von 100% Proxy f\u00fcr jeden Client den schnellsten Pfad zu bestimmen und die Anfragen dorthin zu leiten \u2013 das hei\u00dft, wir werden das tun, was man Client-Steering nennt.<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWie setzt man das um? Wir k\u00f6nnen 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\u00e4re es, dies mit minimaler komplexer Logik zu tun, um das Integrationsproblem mit einer Vielzahl von Client-Plattformen zu vermeiden. <\/p>\n<p>Die Antwort ist die Verwendung von DNS. In unserem Fall verf\u00fcgen wir \u00fcber unsere eigene DNS-Infrastruktur, und wir k\u00f6nnen die Domainzone so konfigurieren, dass unsere Server autoritativ sind. So funktioniert es:<\/p>\n<ol>\n<li>Der Client sendet eine Anfrage an den DNS-Server unter Verwendung eines Hosts, beispielsweise api.netflix.xom.<\/li>\n<li>Die Anfrage gelangt zu unserem DNS-Server.<\/li>\n<li>Der DNS-Server kennt den schnellsten Weg f\u00fcr diesen Client und gibt die entsprechende IP-Adresse aus. <\/li>\n<\/ol>\n<p>\nIn der L\u00f6sung gibt es eine zus\u00e4tzliche Schwierigkeit: Autoritative DNS-Anbieter sehen die IP-Adresse des Clients nicht und k\u00f6nnen nur die IP-Adresse des rekursiven Resolvers ber\u00fccksichtigen, den der Client verwendet. <\/p>\n<p>Letztendlich muss unser autoritativer Resolver eine Entscheidung nicht f\u00fcr einen einzelnen Client, sondern f\u00fcr eine Gruppe von Clients basierend auf dem rekursiven Resolver treffen. <\/p>\n<p>Zur L\u00f6sung verwenden wir die gleichen Proben, aggregieren die Messresultate von Clients f\u00fcr jeden der rekursiven Resolver und entscheiden dann, wohin wir diese Gruppe leiten \u2014 \u00fcber ein Proxy \u00fcber IX mit Hilfe von TCP Anycast, \u00fcber ISP-Proxy oder direkt in die Cloud.<\/p>\n<p>Wir erhalten ein solches System:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas erhaltene Modell des DNS-Managements erm\u00f6glicht es, Clients basierend auf historischen Beobachtungen der Verbindungsraten von Clients zur Cloud zu leiten. <\/p>\n<p>Wiederum stellt sich die Frage \u2014 wie effektiv wird dieser Ansatz funktionieren? Um dies zu beantworten, verwenden wir erneut unser System von Proben. Daher konfigurieren wir die k\u00fcrzliche Konfiguration, in der eines der Ziele den Anweisungen des DNS-Managements folgt, das andere direkt in die Cloud (aktueller Produktionsstand) geht.<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLetztendlich vergleichen wir die Ergebnisse und erhalten eine Bewertung der Effizienz:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLetztendlich haben wir einige wichtige Dinge festgestellt:<\/p>\n<ol>\n<li>Wir haben die erwartete Leistung von Anfragen von Clients zur Cloud unter Verwendung von DNS-Management bewertet.<\/li>\n<li>Wir haben Daten von echten Clients aus allen Ger\u00e4tetypen erhalten.<\/li>\n<li>Wir haben die Effizienz des vorgeschlagenen Konzepts nachgewiesen.<\/li>\n<li>Wir haben kein Risiko eingegangen \u2013 die Produktionskonfigurationen f\u00fcr die Clients nicht ge\u00e4ndert.<\/li>\n<li>Nichts kaputt gemacht.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Jetzt zu dem Komplexen \u2014 wir starten in der Produktion.<\/h2>\n<p>\nDas Schwierigste liegt nun hinter uns \u2013 es gibt einen funktionierenden Prototyp. Jetzt kommt der schwierige Teil \u2013 die L\u00f6sung f\u00fcr den gesamten Netflix-Verkehr zu starten, sie f\u00fcr 150 Millionen Nutzer, Tausende von Ger\u00e4ten, Hunderte von Mikrodiensten und eine st\u00e4ndig 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 \u00fcber Tausende von CDN-Servern lenken, im Internet, wo sich st\u00e4ndig etwas \u00e4ndert und kaputtgeht, und das oft im ung\u00fcnstigsten Moment. <\/p>\n<p>Und bei all dem besteht das Team aus 3 Ingenieuren, die f\u00fcr die Entwicklung, den Rollout und die vollst\u00e4ndige Unterst\u00fctzung des Systems verantwortlich sind.<\/p>\n<p>Daher werden wir jetzt \u00fcber ruhigen und gesunden Schlaf sprechen.<\/p>\n<p>Wie kann man die Entwicklung fortsetzen und nicht die ganze Zeit mit der Wartung verbringen? Unser Ansatz basiert auf drei Prinzipien:<\/p>\n<ol>\n<li>Wir reduzieren den potenziellen Umfang von Ausf\u00e4llen (blast radius). <\/li>\n<li>Wir bereiten uns auf \u00dcberraschungen vor \u2013 wir gehen davon aus, dass etwas kaputtgeht, trotz Tests und pers\u00f6nlicher Erfahrung.<\/li>\n<li>Allm\u00e4hlicher R\u00fcckgang (graceful degradation) \u2013 wenn etwas nicht funktioniert, sollte es automatisch repariert werden, wenn auch nicht auf die effizienteste Weise.<\/li>\n<\/ol>\n<p>\nEs stellte sich heraus, dass wir in unserem Fall mit diesem Ansatz ein einfaches und effektives L\u00f6sungsangebot finden und die Unterst\u00fctzung des Systems erheblich erleichtern k\u00f6nnen. Wir erkannten, dass wir einen kleinen Code-Schnipsel im Client hinzuf\u00fcgen k\u00f6nnen, um die Fehler bei Netzwerk-Anfragen, die durch Verbindungsprobleme verursacht werden, zu verfolgen. Bei Netzwerkfehlern f\u00fchren wir ein Fallback direkt in die Cloud durch. Diese L\u00f6sung erfordert keinen gro\u00dfen Aufwand f\u00fcr die Client-Teams, reduziert jedoch erheblich das Risiko unerwarteter Ausf\u00e4lle und \u00dcberraschungen f\u00fcr uns.<\/p>\n<p>Nat\u00fcrlich halten wir trotz des Fallbacks eine klare Disziplin w\u00e4hrend der Entwicklung ein:<\/p>\n<ol>\n<li>Test auf Probe.<\/li>\n<li>A\/B-Testing oder Canaries.<\/li>\n<li>Allm\u00e4hliche Ver\u00f6ffentlichung (progressive rollout).<\/li>\n<\/ol>\n<p>\nMit den Proben wurde der Ansatz beschrieben \u2013 \u00c4nderungen werden zun\u00e4chst mithilfe eines konfigurierten Rezepts getestet.<\/p>\n<p>F\u00fcr das Canary-Testing m\u00fcssen wir vergleichbare Serverpaare erhalten, auf denen wir vergleichen k\u00f6nnen, wie das System vor und nach den \u00c4nderungen funktioniert. Dazu ziehen wir aus unseren zahlreichen CDN-Standorten Paare von Servern, die einen vergleichbaren Verkehr erhalten:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDann stellen wir die Version mit den \u00c4nderungen auf den Canary-Server bereit. Um die Ergebnisse zu bewerten, f\u00fchren wir ein System aus, das etwa 100-150 Metriken mit einer Kontrollgruppe von Servern vergleicht:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWenn der Canary-Test erfolgreich war, nehmen wir das Release schrittweise und wellenartig vor. Auf jeder Website aktualisieren wir die Server nicht gleichzeitig \u2013 der Ausfall einer gesamten Website hat bei Problemen einen gr\u00f6\u00dferen Einfluss auf den Service f\u00fcr die Benutzer als der Ausfall desselben Mengen an Servern, aber an verschiedenen Standorten.<\/p>\n<p>Insgesamt h\u00e4ngt die Effizienz und Sicherheit dieses Ansatzes von der Anzahl und Qualit\u00e4t der gesammelten Metriken ab. F\u00fcr unser System zur Beschleunigung von Anfragen sammeln wir Metriken aus allen m\u00f6glichen Komponenten: <\/p>\n<ul>\n<li>von Clients \u2013 Anzahl der Sitzungen und Anfragen, Fallback-Raten; <\/li>\n<li>Proxy \u2013 Statistiken zur Anzahl und Zeit der Anfragen;<\/li>\n<li>DNS \u2013 Anzahl und Ergebnisse von Anfragen;<\/li>\n<li>Cloud Edge \u2013 Anzahl und Zeit zur Bearbeitung von Anfragen in der Cloud.<\/li>\n<\/ul>\n<p>\nAll dies wird in einer einheitlichen Pipeline gesammelt, und je nach Bedarf entscheiden wir, welche Metriken f\u00fcr die Echtzeitanalyse gesendet werden und welche in Elasticsearch oder Big Data f\u00fcr eine detailliertere Diagnose.<\/p>\n<h2>\u00dcberwachung<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn unserem Fall nehmen wir \u00c4nderungen 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. \u00c4nderungen auf dem Client und Server erfolgen st\u00e4ndig \u2013 im Laufe der Arbeit von Dutzenden von Teams und nat\u00fcrlichen Ver\u00e4nderungen im \u00d6kosystem. Wir sind in der Mitte \u2013 bei der Diagnose von Problemen besteht eine hohe Wahrscheinlichkeit, dass wir daran beteiligt sind. Daher m\u00fcssen wir klar verstehen, wie wir Metriken definieren, sammeln und analysieren, um Probleme schnell zu lokalisieren. <\/p>\n<p>Ideal ist ein vollst\u00e4ndiger 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\u00dfen auf:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZum Entdecken und zur Priorisierung von Problemen verwenden wir unser eigenes Echtzeitsystem mit offenem Quellcode <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2013 f\u00fcr die Visualisierung. Es speichert aggregierte Metriken im Speicher, ist zuverl\u00e4ssig und integriert sich mit der Alarmierungssoftware. F\u00fcr die Lokalisierung und Diagnose haben wir Zugriff auf Logs mit Elasticsearch und Kibana. F\u00fcr statistische Analysen und Modellierungen nutzen wir Big Data und Visualisierung in Tableau.<\/p>\n<p>Es scheint, dass es mit diesem Ansatz sehr schwierig ist zu arbeiten. Wenn wir jedoch eine hierarchische Organisation der Metriken und Werkzeuge haben, k\u00f6nnen wir das Problem schnell analysieren, den Problemtyp bestimmen und dann in die detaillierten Metriken eintauchen. Um die Quelle eines Fehlers zu identifizieren, ben\u00f6tigen wir im Allgemeinen etwa 1-2 Minuten. Danach arbeiten wir mit einem bestimmten Team an der Diagnose \u2013 von zehn Minuten bis zu mehreren Stunden.<\/p>\n<p>Selbst wenn die Diagnose schnell erfolgt, m\u00f6chten wir nicht, dass dies h\u00e4ufig geschieht. Im Idealfall erhalten wir einen kritischen Alarm nur dann, wenn es erhebliche Auswirkungen auf den Dienst gibt. F\u00fcr unser System zur Beschleunigung von Anfragen gibt es nur 2 Alarme, die benachrichtigen werden:<\/p>\n<ul>\n<li>Prozentsatz Client Fallback \u2013 Bewertung des Kundenverhaltens;<\/li>\n<li>Prozentsatz Probe-Fehler \u2013 Daten zur Stabilit\u00e4t der Netzwerkkomponenten.<\/li>\n<\/ul>\n<p>\nDiese kritischen Alarme \u00fcberwachen, ob das System f\u00fcr 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 \u00c4nderungen gibt. Warum reicht uns das?<\/p>\n<ol>\n<li>Es gibt einen Client-Fallback, falls unser Proxy nicht funktioniert.<\/li>\n<li>Es gibt ein automatisches Steuerungssystem, das auf Probleme reagiert.<\/li>\n<\/ol>\n<p>\nZum Letzten mehr Details. Unser Probe-System und das System zur automatischen Bestimmung des optimalen Weges f\u00fcr Anfragen vom Kunden zur Cloud erm\u00f6glichen es, automatisch mit einigen Problemen umzugehen. <\/p>\n<p>Kehren wir zu unserer Konfiguration der Proben und den 3 Kategorien von Wegen zur\u00fcck. Neben der Ladezeit k\u00f6nnen wir auf das Thema der Lieferung selbst achten. Wenn es nicht m\u00f6glich ist, Daten zu laden, k\u00f6nnen wir anhand der Ergebnisse \u00fcber verschiedene Wege feststellen, wo und was kaputt ist, und ob wir das automatisch beheben k\u00f6nnen, indem wir den Anfrageweg \u00e4ndern.<\/p>\n<p>Beispiele:<\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDieser Prozess kann automatisiert werden. In das Steuerungssystem integriert werden. Und es dazu bringen, auf Probleme mit der Leistung und Zuverl\u00e4ssigkeit zu reagieren. Wenn etwas anf\u00e4ngt zu brechen \u2013 reagieren, wenn es eine bessere Option gibt. Dabei ist eine sofortige Reaktion nicht kritisch, dank des Fallbacks auf den Kunden.<\/p>\n<p>So lassen sich die Prinzipien der Systemunterst\u00fctzung formulieren:<\/p>\n<ul>\n<li>Wir minimieren den Umfang der Ausf\u00e4lle;<\/li>\n<li>Wir sammeln Metriken;<\/li>\n<li>Wir beheben Ausf\u00e4lle automatisch, wenn m\u00f6glich;<\/li>\n<li>Wenn nicht, benachrichtigen wir;<\/li>\n<li>Wir arbeiten an Dashboards und einem Triage-Toolset f\u00fcr schnelle Reaktionen.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Aus den gewonnenen Erkenntnissen<\/h2>\n<p>\nF\u00fcr die Erstellung eines Prototyps wird nicht viel Zeit ben\u00f6tigt. 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\u00fchsame und sehr komplexe Arbeit: die allm\u00e4hliche Produktivsetzung und Skalierung des Systems, die Migration des Hauptverkehrs und das Lernen aus Fehlern. Dabei wird dieser effiziente Prozess nicht linear verlaufen \u2014 trotz aller Anstrengungen kann nicht alles vorhergesehen werden. Weitaus effektiver ist schnelle Iteration und Reaktion auf neue Daten. <\/p>\n<p><img decoding=\"async\" alt=\"Wir beschleunigen Internetanfragen und schlafen ruhig\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBasierend auf unserer Erfahrung k\u00f6nnen wir Folgendes empfehlen:<\/p>\n<ol>\n<li>Vertrauen Sie nicht auf Ihr Bauchgef\u00fchl.\n<p>Unser Bauchgef\u00fchl hat uns st\u00e4ndig 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\u00e4tzt.<\/li>\n<li>Erhalten Sie Daten aus der Produktion.\n<p>Es ist wichtig, so schnell wie m\u00f6glich Zugang zu zumindest einer kleinen Menge an Produktionsdaten zu erhalten. Die Anzahl der einzigartigen F\u00e4lle, Konfigurationen und Einstellungen unter Laborbedingungen ist praktisch unm\u00f6glich zu ermitteln. Schneller Zugang zu Ergebnissen erm\u00f6glicht es, schnell von potenziellen Problemen zu erfahren und diese in der Systemarchitektur zu ber\u00fccksichtigen.<\/li>\n<li>Folgen Sie nicht den Ratschl\u00e4gen und Ergebnissen anderer \u2014 sammeln Sie Ihre eigenen Daten.\n<p>Befolgen Sie die Prinzipien der Datensammlung und -analyse, aber \u00fcbernehmen Sie nicht blind die Ergebnisse und Aussagen anderer. Nur Sie k\u00f6nnen genau wissen, was f\u00fcr Ihre Benutzer funktioniert. Ihre Systeme und Ihre Kunden k\u00f6nnen sich erheblich von anderen Unternehmen unterscheiden. Gl\u00fccklicherweise sind die Analysewerkzeuge heutzutage verf\u00fcgbar und leicht zu bedienen. Ihre Ergebnisse k\u00f6nnen 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 \u2014 weil wir andere Ger\u00e4te, Kunden und Datenstr\u00f6me haben.<\/li>\n<li>Streben Sie nicht unn\u00f6tig modischen Trends nach, ohne deren Effizienz zu bewerten.\n<p>Beginnen Sie einfach. Es ist besser, ein einfaches funktionierendes System in kurzer Zeit zu erstellen, als viel Zeit mit der Entwicklung unn\u00f6tiger Komponenten zu verbringen. L\u00f6sen Sie Aufgaben und Probleme, die auf Grundlage Ihrer Messungen und Ergebnisse wichtig sind. <\/li>\n<li>Seien Sie bereit f\u00fcr neue Anwendungen.\n<p>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 \u2014 ihre F\u00e4higkeit, sich an die Bed\u00fcrfnisse der Kunden anzupassen. In Ihrem Fall k\u00f6nnen Sie neue Probleme und deren L\u00f6sungen entdecken. In unserem Projekt hatten wir das Ziel, die Anfragen zu verz\u00f6gern. Doch im Verlauf der Analyse und Diskussionen haben wir festgestellt, dass wir Proxy-Server auch einsetzen k\u00f6nnen:<\/p>\n<ul>\n<li>zum Lastenausgleich des Traffics \u00fcber AWS-Regionen und zur Senkung der Kosten;<\/li>\n<li>zur Modellierung der Stabilit\u00e4t von CDN;<\/li>\n<li>zur Konfiguration von DNS;<\/li>\n<li>zur Konfiguration von TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Fazit<\/h2>\n<p>\nIn meinem Vortrag habe ich beschrieben, wie Netflix das Problem der Beschleunigung von Internetanfragen zwischen Kunden und der Cloud l\u00f6st. Wie wir Daten durch unser System f\u00fcr Kunden-Probieren sammeln und die gesammelten historischen Daten nutzen, um Produktionsanfragen \u00fcber 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.<\/p>\n<p>Unser Ansatz ist nur ein Beispiel daf\u00fcr, wie wir bei Netflix ein solches System implementiert haben. Was f\u00fcr uns funktioniert hat. Der praktische Teil meines Vortrags f\u00fcr Sie sind die Entwicklungs- und Unterst\u00fctzungsprinzipien, denen wir folgen und mit denen wir gute Ergebnisse erzielen.<\/p>\n<p>Unsere L\u00f6sung des Problems k\u00f6nnte f\u00fcr 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. <\/p>\n<p>Die Geschwindigkeit der Anfragen bleibt auch f\u00fcr das Gesch\u00e4ft wichtig. Und selbst f\u00fcr einen einfachen Service m\u00fcssen Sie Entscheidungen treffen: zwischen \u201eCloud\u201c-Anbietern, dem Standort der Server, CDN- und DNS-Anbietern. Ihre Wahl wird die Effizienz der Internetanfragen f\u00fcr Ihre Kunden beeinflussen. Es ist f\u00fcr Sie wichtig, diesen Einfluss zu messen und zu verstehen.<\/p>\n<p>Beginnen Sie mit einfachen L\u00f6sungen, achten Sie darauf, wie Sie das Produkt ver\u00e4ndern. Lernen Sie im Prozess und verbessern Sie das System basierend auf Daten von Ihren Kunden, Ihrer Infrastruktur und Ihrem Gesch\u00e4ft. Denken Sie an die M\u00f6glichkeit unerwarteter Ausf\u00e4lle im Entwurfsprozess. Dann k\u00f6nnen Sie Ihren Entwicklungsprozess beschleunigen, die Effizienz der L\u00f6sung verbessern, \u00fcberm\u00e4\u00dfige Belastungen des Supports vermeiden und ruhig schlafen.<\/p>\n<blockquote><p>In diesem Jahr <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">findet die Konferenz vom 6. bis 10. Juli statt.<\/a><\/noindex> im Online-Format. Es wird m\u00f6glich sein, einem der V\u00e4ter von DevOps, John Willis selbst, Fragen zu stellen!<\/p><\/blockquote>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wir beschleunigen Internetanfragen und schlafen ruhig | ProHoster","description":"Netflix ist Marktf\u00fchrer im Internet-TV.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}