🥇Web-HighLoad — wie wir den Verkehr von Zehntausenden von Domains verwalten

Der legale Datenverkehr im DDoS-Guard-Netzwerk hat kürzlich die hundert Gigabit pro Sekunde überschritten. Derzeit generieren 50 % unseres gesamten Datenverkehrs die Webdienste unserer Kunden. Das sind mehrere Zehntausend verschiedene Domains, die meistens individuelle Lösungen erfordern.

Im Folgenden erklären wir, wie wir die Front-End-Knoten verwalten und ausgeben SSL-Zertifikate für Hunderttausende von Websites.

Die Konfiguration des Front-Ends für eine einzige Website, selbst wenn sie sehr groß ist, ist einfach. Wir verwenden nginx oder haproxy oder lighttpd, konfigurieren es nach den Anleitungen und vergessen es. Wenn etwas geändert werden muss, führen wir einen Reload durch und vergessen es wieder.

Alles ändert sich, wenn Sie große Verkehrsvolumen in Echtzeit verarbeiten, die Legitimität von Anfragen bewerten, Nutzerinhalte komprimieren und cachen und dabei die Einstellungen mehrmals pro Sekunde ändern. Der Nutzer möchte das Ergebnis auf allen externen Knoten sofort sehen, nachdem er die Einstellungen in seinem Dashboard geändert hat. Außerdem kann der Nutzer über 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 — eine nicht triviale Aufgabe, wenn man bedenkt, dass es allein in Moskau mehrere physisch verteilte Filterknoten gibt.

Warum viele große, zuverlässige Knotenpunkte auf der ganzen Welt?

Die Qualität der Kundenverkehrsverarbeitung — Anfragen aus den USA müssen genau in den USA verarbeitet werden (einschließlich hinsichtlich Angriffe, Parsing und anderen Anomalien) und dürfen nicht nach Moskau oder Europa geleitet werden, wodurch die Verarbeitungsverzögerung unvorhersehbar erhöht wird.
Angreifender Traffic muss lokalisiert werden – Transitbetreiber können während Angriffe, deren Umfang oft 1 Tbps übersteigt, in Schwierigkeiten geraten. Angreifenden Traffic über transatlantische oder transasiatische Verbindungen zu transportieren, ist keine gute Idee. Wir haben konkrete Fälle erlebt, in denen Tier-1-Betreiber sagten: "Die Mengen an Angriffen, die Sie empfangen, sind für uns gefährlich." Aus diesem Grund nehmen wir eingehende Ströme so nah wie möglich an ihren Quellen entgegen.
Strenge Anforderungen an die Kontinuität des Dienstes – Rechenzentren dürfen weder voneinander noch von lokalen Ereignissen in unserer sich schnell verändernden Welt abhängig sein. Wurden alle 11 Etagen des MMTS-9 eine Woche lang stromlos gemacht? – Kein Problem. Kein Kunde, der nicht physisch an diesem Standort angeschlossen ist, wird betroffen sein, und Webdienste leiden unter keinen Umständen.

Wie lässt sich das alles managen?

Die Konfigurationen der Dienste sollten so schnell wie möglich (idealerweise sofort) auf allen Front-End-Knoten verteilt werden. Es ist nicht ausreichend, die Textkonfigurationen einfach zu ändern und die Daemonen bei jeder Änderung neu zu starten – selbst nginx hält die laufenden Prozesse (Worker shutting down) noch einige Minuten (und möglicherweise sogar Stunden, wenn dort lange WebSocket-Sitzungen aktiv sind).

Bei der Neulade der Konfiguration sieht das Bild in nginx meist so aus:

Zur Speichernutzung:

Alte Worker verbrauchen Speicher, der nicht linear von der Anzahl der Verbindungen abhängt – das ist normal. Wenn die Clientverbindungen geschlossen werden, wird dieser Speicher freigegeben.

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.

Die Lösung ist einfach – verwenden Sie nginx nicht, verwalten Sie die Frontends nicht auf Basis von Textdateien und lassen Sie auf keinen Fall komprimierte Textkonfigurationen über transozeanische Kanäle laufen. Die Kanäle sind zwar garantiert und reserviert, aber das macht sie nicht weniger transkontinental.

Wir verfügen über einen eigenen Front-Server-Balancer, dessen interne Funktionsweise ich in den kommenden Artikeln erläutern werde. Das Wichtigste ist, dass er in der Lage ist, Tausende von Konfigurationsänderungen pro Sekunde in Echtzeit anzuwenden, ohne Neuausführungen, Reloads, plötzliche Speicherverbräuche und dergleichen. Das ähnelt sehr dem Hot Code Reload, beispielsweise in Erlang. Die Daten werden in einer geo-verteilten Key-Value-Datenbank gespeichert und sofort von den ausführenden Mechanismen der Frontend-Server abgerufen. Das bedeutet, dass Sie ein SSL-Zertifikat über die Web-Oberfläche oder API in Moskau hochgeladen haben, und nach ein paar Sekunden ist es bereits bereit für den Einsatz in unserem Rechenzentrum in Los Angeles. Falls plötzlich ein Weltkrieg ausbricht und das Internet weltweit ausfällt, werden unsere Knoten weiterhin autonom arbeiten und das Split-Brain-Problem beheben, sobald einer der dedizierten Kanäle Moskau-Amsterdam-Los Angeles oder Moskau-Amsterdam-Hongkong-Los Angeles wieder verfügbar ist oder zumindest einer der Backup-Overlay-GRE-Kanäle.

Dasselbe System ermöglicht es uns, Zertifikate sofort auszustellen und zu verlängern für Let’s Encrypt. Sehr vereinfacht funktioniert das so:

Sobald wir eine HTTPS-Anfrage für die Domain eines unserer Kunden ohne Zertifikat (oder mit abgelaufenem Zertifikat) sehen, informiert der externe Knoten, der die Anfrage empfangen hat, das interne Zertifizierungszentrum.
Wenn der Benutzer die Ausstellung von Let’s Encrypt nicht verboten hat, erstellt das Zertifizierungszentrum CSR, erhält ein Bestätigungstoken von LE und verteilt es über einen verschlüsselten Kanal an alle Frontends. Jetzt kann jeder Knoten die Validierungsanfrage von LE bestätigen.
Nach wenigen Momenten erhalten wir das korrekte Zertifikat und den privaten Schlüssel und verteilen es so an die Frontends. Wieder ohne Neustart der Dämonen.
Sieben Tage vor dem Ablaufdatum wird das Verfahren zur Neuausstellung des Zertifikats eingeleitet.

Momentan rotieren wir in Echtzeit 350.000 Zertifikate völlig transparent für die Benutzer.

In den nächsten Artikeln dieser Serie werde ich über weitere Aspekte der Echtzeitverarbeitung großer Web-Traffic-Mengen sprechen – zum Beispiel über die Analyse von RTT anhand unvollständiger Daten zur Verbesserung der Servicequalität für Transitkunden und generell über den Schutz des Transitverkehrs vor Terabit-Angriffen, über die Lieferung und Aggregation von Traffic-Informationen, über WAF, eine fast unbegrenzte CDN und viele Mechanismen zur Optimierung der Inhaltsausgabe.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?