![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/5e4fece0f5039f0fb1af5ead9e0e0089.jpg\")
<\/p>\n
<\/a><\/p>\n Die Front f\u00fcr eine einzige Webseite einzurichten, selbst f\u00fcr eine sehr gro\u00dfe, ist einfach. Wir nehmen nginx oder haproxy oder lighttpd, richten sie gem\u00e4\u00df den Anleitungen ein und vergessen es. Wenn wir etwas \u00e4ndern m\u00fcssen, machen wir einen Reload und vergessen es wieder.<\/p>\n Alles \u00e4ndert sich, wenn man in Echtzeit gro\u00dfe Verkehrsvolumen bearbeitet, die Legitimit\u00e4t von Anfragen bewertet, Nutzerinhalte komprimiert und cached und dabei die Parameter mehrmals pro Sekunde \u00e4ndert. Der Nutzer m\u00f6chte die Ergebnisse auf allen externen Nodes sehen, sobald er die Einstellungen in seinem Benutzerkonto ge\u00e4ndert hat. Au\u00dferdem kann der Nutzer \u00fcber die API mehrere Tausend (manchmal sogar Zehntausende) Domains mit individuellen Verkehrsbearbeitungsparametern hochladen. All dies muss ebenfalls sofort in Amerika, Europa und Asien funktionieren \u2013 eine nicht triviale Aufgabe, wenn man bedenkt, dass in Moskau mehrere physisch verteilte Filterknoten existieren.<\/p>\n Die Konfigurationen der Dienste m\u00fcssen so schnell wie m\u00f6glich (idealerweise sofort) auf allen Front-End-Knoten verbreitet werden. Man kann nicht einfach die Textkonfigurationen \u00e4ndern und die Dienste bei jeder \u00c4nderung neu starten \u2013 dasselbe gilt f\u00fcr nginx, das laufende Prozesse (worker shutting down) noch mehrere Minuten (oder sogar Stunden, wenn es lange Websocket-Sitzungen gibt) h\u00e4lt.<\/p>\n Beim Neustarten der nginx-Konfiguration sieht die folgende Situation durchaus normal aus:<\/p>\n Zur Speichernutzung:<\/p>\n Die alten Worker verbrauchen Speicher, der unter anderem nicht linear von der Anzahl der Verbindungen abh\u00e4ngt \u2013 das ist normal. Wenn die clientseitigen Verbindungen geschlossen werden, wird dieser Speicher wieder freigegeben.<\/p>\n Warum war das kein Problem, als nginx gerade anfing, sich zu entwickeln? Es gab weder HTTP\/2 noch WebSocket noch viele langfristige Keep-Alive-Verbindungen. 70 % unseres Webtraffics sind HTTP\/2, und das sind sehr langanhaltende Verbindungen.<\/p>\n Die L\u00f6sung ist einfach \u2013 nginx nicht verwenden, Frontends nicht auf Basis von Textdateien verwalten und auf keinen Fall komprimierte Textkonfigurationen \u00fcber transozeanische Kan\u00e4le bombardieren. Die Kan\u00e4le sind zwar garantiert und reserviert, aber dennoch transkontinental.<\/p>\n Wir haben einen eigenen Front-Server-Balancer, \u00fcber dessen Innere ich in den folgenden Artikeln berichten werde. Das Wichtigste ist, dass er in der Lage ist, Tausende von Konfigurations\u00e4nderungen pro Sekunde in Echtzeit anzuwenden, ohne Neustarts, Reloads, sprunghaften Anstieg des Speicherverbrauchs und all das. Das ist sehr \u00e4hnlich wie Hot Code Reload, zum Beispiel in Erlang. Die Daten werden in einer geo-distribuierten Key-Value-Datenbank gespeichert und sofort von den ausf\u00fchrenden Mechanismen der Front-End-Systeme abgerufen. D.h. Sie haben das SSL-Zertifikat \u00fcber die Web-Oberfl\u00e4che oder API in Moskau hochgeladen, und nach ein paar Sekunden ist es bereits einsatzbereit in unserem Rechenzentrum in Los Angeles. Falls eines Tages ein Weltkrieg ausbricht und das Internet weltweit ausf\u00e4llt, werden unsere Knoten weiterhin autonom arbeiten und das Split-Brain-Problema beheben, sobald einer der dedizierten Kan\u00e4le Los Angeles-Amsterdam-Moskau, Moskau-Amsterdam-Hongkong-Los Angeles oder zumindest einer der Reserve-Overlay-GRE verf\u00fcgbar ist.<\/p>\n Dieser Mechanismus erm\u00f6glicht es uns auch, Zertifikate sofort auszustellen und zu verl\u00e4ngern. Zertifikate von Let’s Encrypt.<\/a> Sehr vereinfacht funktioniert das so:<\/p>\n Aktuell rotieren wir in Echtzeit 350.000 Zertifikate v\u00f6llig transparent f\u00fcr die Benutzer.<\/p>\n In den kommenden Artikeln der Reihe werde ich \u00fcber andere Eigenschaften der Echtzeitverarbeitung gro\u00dfer Web-Traffic-Mengen berichten \u2014 zum Beispiel \u00fcber die Analyse von RTT bei unvollst\u00e4ndigen Daten zur Verbesserung der Servicequalit\u00e4t f\u00fcr Transitkunden und allgemein \u00fcber den Schutz von Transit-Traffic gegen Terabitt-Angriffe, \u00fcber die Lieferung und Aggregation von Informationen \u00fcber den Traffic, \u00fcber WAF, nahezu unbegrenzte CDN und viele Mechanismen zur Optimierung der Inhaltsauslieferung.<\/p>\n Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a>.<\/p>\nWarum viele gro\u00dfe zuverl\u00e4ssige Knoten weltweit?<\/h3>\n
\n
Wie verwaltet man das alles?<\/h3>\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/6a1ffc01ad9bac1e51d46c3130ea2a37.jpg\")
<\/p>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/d356134b0866b8c92a3d5f7a3a8df208.jpg\")
<\/p>\n\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/20830ee7c4ea57ec1d0833f0bc25412d.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/1c8b295065f27c1b69c810ff74ce4018.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/e4fc349089fbf7cbe7824ea539865daf.jpg\")
<\/li>\nWor\u00fcber m\u00f6chten Sie zuerst Informationen erhalten?<\/h2>\n