![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/5e4fece0f5039f0fb1af5ead9e0e0089.jpg\")
<\/p>\n
<\/a><\/p>\n Die Konfiguration des Front-Ends f\u00fcr eine einzige Website, selbst wenn sie sehr gro\u00df ist, ist einfach. Wir verwenden nginx oder haproxy oder lighttpd, konfigurieren es nach den Anleitungen und vergessen es. Wenn etwas ge\u00e4ndert werden muss, f\u00fchren wir einen Reload durch und vergessen es wieder.<\/p>\n Alles \u00e4ndert sich, wenn Sie gro\u00dfe Verkehrsvolumen in Echtzeit verarbeiten, die Legitimit\u00e4t von Anfragen bewerten, Nutzerinhalte komprimieren und cachen und dabei die Einstellungen mehrmals pro Sekunde \u00e4ndern. Der Nutzer m\u00f6chte das Ergebnis auf allen externen Knoten sofort sehen, nachdem er die Einstellungen in seinem Dashboard ge\u00e4ndert hat. Au\u00dferdem kann der Nutzer \u00fcber die API mehrere Tausend (manchmal sogar Zehntausende) Domains mit individuellen Verkehrsanpassungen hochladen. All dies muss sofort sowohl in Amerika als auch in Europa und Asien funktionieren \u2014 eine nicht triviale Aufgabe, wenn man bedenkt, dass es allein in Moskau mehrere physisch verteilte Filterknoten gibt.<\/p>\n Die Konfigurationen der Dienste sollten so schnell wie m\u00f6glich (idealerweise sofort) auf allen Front-End-Knoten verteilt werden. Es ist nicht ausreichend, die Textkonfigurationen einfach zu \u00e4ndern und die Daemonen bei jeder \u00c4nderung neu zu starten \u2013 selbst nginx h\u00e4lt die laufenden Prozesse (Worker shutting down) noch einige Minuten (und m\u00f6glicherweise sogar Stunden, wenn dort lange WebSocket-Sitzungen aktiv sind).<\/p>\n Bei der Neulade der Konfiguration sieht das Bild in nginx meist so aus:<\/p>\n Zur Speichernutzung:<\/p>\n Alte Worker verbrauchen Speicher, der nicht linear von der Anzahl der Verbindungen abh\u00e4ngt \u2013 das ist normal. Wenn die Clientverbindungen geschlossen werden, wird dieser Speicher freigegeben.<\/p>\n Warum war das kein Problem, als nginx gerade erst begann, sich zu entwickeln? Es gab weder HTTP\/2 noch WebSocket und keine massiven langen Keep-Alive-Verbindungen. 70 % unseres Webverkehrs sind HTTP\/2, was sehr lange Verbindungen bedeutet.<\/p>\n Die L\u00f6sung ist einfach \u2013 verwenden Sie nginx nicht, verwalten Sie die Frontends nicht auf Basis von Textdateien und lassen Sie auf keinen Fall komprimierte Textkonfigurationen \u00fcber transozeanische Kan\u00e4le laufen. Die Kan\u00e4le sind zwar garantiert und reserviert, aber das macht sie nicht weniger transkontinental.<\/p>\n Wir verf\u00fcgen \u00fcber einen eigenen Front-Server-Balancer, dessen interne Funktionsweise ich in den kommenden Artikeln erl\u00e4utern werde. Das Wichtigste ist, dass er in der Lage ist, Tausende von Konfigurations\u00e4nderungen pro Sekunde in Echtzeit anzuwenden, ohne Neuausf\u00fchrungen, Reloads, pl\u00f6tzliche Speicherverbr\u00e4uche und dergleichen. Das \u00e4hnelt sehr dem Hot Code Reload, beispielsweise in Erlang. Die Daten werden in einer geo-verteilten Key-Value-Datenbank gespeichert und sofort von den ausf\u00fchrenden Mechanismen der Frontend-Server abgerufen. Das bedeutet, dass Sie ein SSL-Zertifikat \u00fcber die Web-Oberfl\u00e4che oder API in Moskau hochgeladen haben, und nach ein paar Sekunden ist es bereits bereit f\u00fcr den Einsatz in unserem Rechenzentrum in Los Angeles. Falls pl\u00f6tzlich ein Weltkrieg ausbricht und das Internet weltweit ausf\u00e4llt, werden unsere Knoten weiterhin autonom arbeiten und das Split-Brain-Problem beheben, sobald einer der dedizierten Kan\u00e4le Moskau-Amsterdam-Los Angeles oder Moskau-Amsterdam-Hongkong-Los Angeles wieder verf\u00fcgbar ist oder zumindest einer der Backup-Overlay-GRE-Kan\u00e4le.<\/p>\n Dasselbe System erm\u00f6glicht es uns, Zertifikate sofort auszustellen und zu verl\u00e4ngern \u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u044b Let’s Encrypt.<\/a> Sehr vereinfacht funktioniert das so:<\/p>\n Momentan rotieren wir in Echtzeit 350.000 Zertifikate v\u00f6llig transparent f\u00fcr die Benutzer.<\/p>\n In den n\u00e4chsten Artikeln dieser Serie werde ich \u00fcber weitere Aspekte der Echtzeitverarbeitung gro\u00dfer Web-Traffic-Mengen sprechen \u2013 zum Beispiel \u00fcber die Analyse von RTT anhand unvollst\u00e4ndiger Daten zur Verbesserung der Servicequalit\u00e4t f\u00fcr Transitkunden und generell \u00fcber den Schutz des Transitverkehrs vor Terabit-Angriffen, \u00fcber die Lieferung und Aggregation von Traffic-Informationen, \u00fcber WAF, eine fast unbegrenzte CDN und viele Mechanismen zur Optimierung der Inhaltsausgabe.<\/p>\n Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a>Sind Sie an Contour interessiert?<\/p>\nWarum viele gro\u00dfe, zuverl\u00e4ssige Knotenpunkte auf der ganzen Welt?<\/h3>\n
\n
Wie l\u00e4sst sich das alles managen?<\/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>\nWas m\u00f6chten Sie zuerst wissen?<\/h2>\n