Web HighLoad – wie wir den Datenverkehr für Zehntausende Domains verwalten

Der legitime Datenverkehr im DDoS-Guard-Netzwerk überstieg kürzlich 50 Gigabit pro Sekunde. Derzeit werden XNUMX % unseres gesamten Datenverkehrs durch Client-Webdienste generiert. Dabei handelt es sich um viele Zehntausende Domänen, die sehr unterschiedlich sind und in den meisten Fällen eine individuelle Herangehensweise erfordern.

Im Folgenden erfahren Sie, wie wir Frontknoten verwalten und SSL-Zertifikate für Hunderttausende Websites ausstellen.

Das Einrichten einer Fassade für einen Standort, selbst für einen sehr großen, ist einfach. Wir nehmen Nginx oder Haproxy oder Lighttpd, konfigurieren es gemäß den Anleitungen und vergessen es. Wenn wir etwas ändern müssen, führen wir ein erneutes Laden und Vergessen durch.

Alles ändert sich, wenn Sie große Verkehrsmengen im laufenden Betrieb verarbeiten, die Legitimität von Anfragen bewerten, Benutzerinhalte komprimieren und zwischenspeichern und gleichzeitig Parameter mehrmals pro Sekunde ändern. Der Nutzer möchte das Ergebnis auf allen externen Knoten sofort sehen, nachdem er die Einstellungen in seinem persönlichen Konto geändert hat. Ein Benutzer kann über die API auch mehrere tausend (und manchmal zehntausende) Domains mit individuellen Traffic-Verarbeitungsparametern herunterladen. All dies sollte auch in Amerika, in Europa und in Asien sofort funktionieren – die Aufgabe ist nicht die trivialste, wenn man bedenkt, dass es allein in Moskau mehrere physisch getrennte Filterknoten gibt.

Warum gibt es weltweit viele große zuverlässige Knoten?

• Servicequalität für den Kundenverkehr – Anfragen aus den USA müssen in den USA verarbeitet werden (einschließlich Angriffen, Parsing und anderen Anomalien) und dürfen nicht nach Moskau oder Europa weitergeleitet werden, was die Verarbeitungsverzögerung unvorhersehbar erhöht.

• Der Angriffsverkehr muss lokalisiert werden – Transitbetreiber können bei Angriffen, deren Volumen oft 1 Tbit/s übersteigt, beeinträchtigt werden. Es ist keine gute Idee, den Angriffsverkehr über transatlantische oder transasiatische Verbindungen zu transportieren. Wir hatten reale Fälle, in denen Tier-1-Betreiber sagten: „Das Ausmaß der Angriffe, die Sie erhalten, ist gefährlich für uns.“ Deshalb akzeptieren wir eingehende Streams so nah wie möglich an ihren Quellen.

• Strenge Anforderungen an die Kontinuität des Dienstes – Reinigungszentren sollten in unserer sich schnell verändernden Welt weder voneinander noch von lokalen Ereignissen abhängig sein. Haben Sie eine Woche lang den Strom auf allen 11 Etagen von MMTS-9 abgeschaltet? - Kein Problem. Kein einziger Client, der an diesem bestimmten Standort nicht über eine physische Verbindung verfügt, wird darunter leiden, und Webdienste werden unter keinen Umständen darunter leiden.

Wie schafft man das alles?

Dienstkonfigurationen sollten so schnell wie möglich (idealerweise sofort) an alle Frontknoten verteilt werden. Sie können nicht einfach Textkonfigurationen übernehmen und neu erstellen und die Daemons bei jeder Änderung neu starten – derselbe Nginx sorgt dafür, dass Prozesse noch ein paar Minuten (oder vielleicht Stunden, wenn es lange Websocket-Sitzungen gibt) heruntergefahren (Worker heruntergefahren) werden.

Beim Neuladen der Nginx-Konfiguration ist das folgende Bild ganz normal:

Zur Speichernutzung:

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

Warum war das kein Problem, als Nginx gerade erst anfing? Es gab kein HTTP/2, kein WebSocket, keine massiven Long-Keep-Alive-Verbindungen. 70 % unseres Webverkehrs erfolgt über HTTP/2, was sehr lange Verbindungen bedeutet.

Die Lösung ist einfach: Verwenden Sie kein Nginx, verwalten Sie keine Fronten basierend auf Textdateien und senden Sie auf keinen Fall gezippte Textkonfigurationen über transpazifische Kanäle. Die Kanäle sind natürlich garantiert und reserviert, aber das macht sie nicht weniger transkontinental.

Wir haben unseren eigenen Front-Server-Balancer, über dessen Interna ich in den folgenden Artikeln sprechen werde. Das Wichtigste, was es tun kann, ist, Tausende von Konfigurationsänderungen pro Sekunde im laufenden Betrieb durchzuführen, ohne Neustarts, Neuladen, plötzliche Erhöhungen des Speicherverbrauchs und all das. Dies ist dem Hot Code Reload sehr ähnlich, beispielsweise in Erlang. Die Daten werden in einer geografisch verteilten Schlüsselwertdatenbank gespeichert und von den Frontaktoren sofort gelesen. Diese. Sie laden das SSL-Zertifikat über die Webschnittstelle oder API in Moskau hoch und in wenigen Sekunden ist es bereit für den Versand an unser Reinigungszentrum in Los Angeles. Wenn plötzlich ein Weltkrieg ausbricht und das Internet auf der ganzen Welt verschwindet, werden unsere Knoten weiterhin autonom arbeiten und das Split-Brain reparieren, sobald einer der dedizierten Kanäle Los Angeles-Amsterdam-Moskau, Moskau-Amsterdam-Hongkong- Los-Los wird verfügbar, Angeles oder mindestens eines der GRE-Backup-Overlays.

Derselbe Mechanismus ermöglicht es uns, Let's Encrypt-Zertifikate sofort auszustellen und zu erneuern. Ganz einfach funktioniert es so:

1. Sobald wir mindestens eine HTTPS-Anfrage für die Domain unseres Kunden ohne Zertifikat (oder mit abgelaufenem Zertifikat) sehen, meldet der externe Knoten, der die Anfrage angenommen hat, dies an die interne Zertifizierungsstelle.

   

2. Wenn der Benutzer die Ausgabe von Let's Encrypt nicht verboten hat, generiert die Zertifizierungsstelle eine CSR, erhält von LE ein Bestätigungstoken und sendet es über einen verschlüsselten Kanal an alle Fronten. Jetzt kann jeder Knoten eine Validierungsanfrage von LE bestätigen.

   

3. In wenigen Augenblicken erhalten wir das richtige Zertifikat und den richtigen privaten Schlüssel und senden ihn auf dem gleichen Weg an die Fronten. Wieder ohne Neustart der Daemons

   

4. 7 Tage vor Ablaufdatum wird das Verfahren zum erneuten Erhalt des Zertifikats eingeleitet

Derzeit rotieren wir 350 Zertifikate in Echtzeit, völlig transparent für die Benutzer.

In den folgenden Artikeln der Serie werde ich über andere Funktionen der Echtzeitverarbeitung von großem Webverkehr sprechen – zum Beispiel über die Analyse von RTT mithilfe unvollständiger Daten, um die Servicequalität für Transitkunden zu verbessern, und allgemein über den Schutz des Transitverkehrs vor Terabit-Angriffe, über die Bereitstellung und Aggregation von Verkehrsinformationen, über WAF, nahezu unbegrenztes CDN und viele Mechanismen zur Optimierung der Inhaltsbereitstellung.

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Was möchten Sie zuerst wissen?

• 14,3%Algorithmen zum Clustering und zur Analyse der Qualität des Webverkehrs<3

• 33,3%Interna von DDoS-Guard7-Balancern

• 9,5%Schutz des Transit-L3/L4-Verkehrs2

• 0,0%Schutz von Websites im Transitverkehr0

• 14,3%Webanwendungs-Firewall3

• 28,6%Schutz vor Parsen und Klicken6

21 Benutzer haben abgestimmt. 6 Benutzer enthielten sich der Stimme.

Source: habr.com