🥇Webb-HighLoad — hur vi hanterar trafiken för tiotusentals domäner

Legitim trafik i DDoS-Guard-nätverket har nyligen överstigit hundra gigabit per sekund. Nu genererar 50 % av hela vår trafik webbservicen från kunder. Det handlar om många tiotusentals domäner, väldigt olika, och i de flesta fall som kräver en individuell strategi.

Under ytan - hur vi hanterar frontnodarna och levererar SSL-certifikat för hundratusentals webbplatser.

Att konfigurera fronten för en enda webbplats, även en mycket stor, är enkelt. Vi tar nginx eller haproxy eller lighttpd, konfigurerar enligt guider och glömmer det. Om vi behöver ändra något - gör vi en reload och glömmer igen.

Allt förändras när du i realtid hanterar stora mängder trafik, bedömer legitimiteten av förfrågningar, komprimerar och cachar användarinnehåll, och samtidigt ändrar inställningar flera gånger per sekund. Användaren vill se resultatet på alla externa noder direkt efter att hen ändrat inställningarna i sitt konto. Dessutom kan användaren ladda upp flera tusen (ibland tiotusentals) domäner med individuella trafikbehandlingsparameter via API. Allt detta måste också fungera direkt, både i Amerika, Europa och Asien - en uppgift som inte är särskilt trivial, med tanke på att det bara i Moskva finns flera fysiskt åtskilda filtreringsnoder.

Varför etablera många stora, pålitliga noder över hela världen?

Kvaliteten på servicen för kundtraffic - förfrågningar från USA måste bearbetas just i USA (inklusive med avseende på attacker, parsing och andra anomalier), och inte dirigeras till Moskva eller Europa, vilket oförutsägbart ökar latensen för behandlingen.
Angreppstrafik måste lokaliseras - transitoperatörer kan degradera under attacker, vars volym ofta överstiger 1Tbps. Att transportera angreppstrafik över transatlantiska eller transasiatiska länkar är ingen bra idé. Vi har haft verkliga fall där Tier-1-operatörer har sagt: "De angreppsmängder ni tar emot är farliga för oss". Det är just därför vi tar emot inkommande strömmar så nära deras källor som möjligt.
Stränga krav på driftsäkerhet – rensningscentraler får inte vara beroende av varandra eller av lokala händelser i vår snabbt föränderliga värld. Strömavbrott på alla 11 våningar i MMT9 i en vecka? – Ingen fara. Ingen kund som inte har fysisk anslutning i just den här platsen kommer att påverkas, och webbtjänsterna kommer inte att drabbas under några omständigheter.

Hur hanterar man allt detta?

Tjänstekonfigurationer måste spridas så snabbt som möjligt (idealiskt omedelbart) till alla frontnoder. Man kan inte bara ta och rekonstruera textkonfigurationer och starta om demonerna vid varje ändring – samma nginx håller avslutande processer (worker shutting down) i flera minuter (eller till och med timmar om det finns långa websocket-sessioner).

Vid omstart av nginx-konfigurationen är följande bild helt normal:

Om minnesanvändning:

Gamla arbetare använder minne, bland annat, vilket inte är linjärt beroende av antalet anslutningar – det är normalt. När de klientanslutningar stängs, kommer detta minne att frigöras.

Varför var detta inte ett problem när nginx just började utvecklas? Det fanns varken HTTP/2, WebSocket, eller massor av långa keep-alive anslutningar. 70% av vår webtrafik är HTTP/2, vilket medför mycket långa anslutningar.

Lösningen är enkel – att inte använda nginx, inte hantera fronterna baserat på textfiler, och absolut inte skicka komprimerade textkonfigurationer över transatlantiska kanaler. Kanalerna är förstås garanterade och reserverade, men det gör dem inte mindre transkontinentala.

Vi har en egen front-server-balancer, vars inre strukturer kommer jag att berätta om i kommande artiklar. Det viktigaste den kan göra är att tillämpa tusentals konfigurationsändringar i sekunden utan omstarter, omladdningar, plötsliga minnesökningar och så vidare. Det liknar mycket på Hot Code Reload, till exempel i Erlang. Data lagras i en geo-distribuerad key-value databas och läses omedelbart av frontens exekveringsmekanismer. Det vill säga, du laddade upp SSL-certifikatet via webgränssnittet eller API:t i Moskva, och inom några sekunder är det redan klart att användas i vårt rengöringscenter i Los Angeles. Om det skulle inträffa ett världskrig och internet skulle försvinna över hela världen, skulle våra noder fortsätta att fungera autonomt och åtgärda split-brain så snart en av de dedikerade kanalerna Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong-Los Angeles, eller åtminstone en av backup-overlay GRE blir tillgänglig.

Denna mekanism gör det möjligt för oss att omedelbart utfärda och förlänga Let’s Encrypt-certifikat. Mycket förenklat fungerar det så här:

Så snart vi ser minst en HTTPS-förfrågan för vår kunds domän utan certifikat (eller med ett utgånget certifikat), meddelar den externa nod som tagit emot förfrågan det interna certifieringscentret.
Om användaren inte har förbjudit utfärdande av Let’s Encrypt, formar certifieringscentret en CSR, får en bekräftelsetoken från LE och sprider ut den till alla frontar via en krypterad kanal. Nu kan vilken nod som helst bekräfta valideringsförfrågan från LE.
Inom några ögonblick kommer vi att få det korrekta certifikatet och den privata nyckeln och skickar dem på samma sätt till frontarna. Återigen utan att starta om demonerna.
Sju dagar före utgångsdatumet initieras proceduren för att återfå certifikatet.

Just nu roterar vi 350 000 certifikat i realtid, helt transparent för användarna.

I kommande artiklar i cykeln kommer jag att berätta om andra egenskaper hos realtidsbearbetning av stor webbtrafik - till exempel om analys av RTT baserat på ofullständiga data för att förbättra servicekvaliteten för transitkunder och övergripande om skydd av transittrafik mot terabit-attacker, om leverans och aggregering av trafikdata, om WAF, nästan obegränsad CDN och många mekanismer för optimering av innehållsleverans.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.