Legitimní provoz v síti DDoS-Guard nedávno překročil sto gigabitů za sekundu. Nyní 50 % veškerého našeho provozu generují webové služby klientů. To jsou desetitisíce domén, velmi různorodých a většinou vyžadujících individuální přístup.
Pod článkem — jak spravujeme front-end uzly a distribujeme SSL certifikáty pro stovky tisíc webů.
Nastavit frontu pro jeden web, i když velmi velký, je jednoduché. Vezmeme nginx nebo haproxy či lighttpd, nastavíme podle návodů a zapomeneme. Když je potřeba něco změnit, uděláme reload a opět zapomeneme.
Všechno se mění, když zpracováváte velké objemy provozu, vyhodnocujete legitimitu požadavků, komprimujete a cachujete uživatelský obsah, a přitom měníte parametry několikrát za sekundu. Uživatel chce vidět výsledek na všech externích uzlech ihned poté, co změní nastavení ve svém uživatelském rozhraní. A také uživatel může prostřednictvím API nahrát několik tisíc (někdy i desítky tisíc) domén s individuálními parametry zpracování provozu. To vše by mělo fungovat okamžitě, jak v Americe, tak v Evropě a Asii — úkol to není zrovna triviální, s ohledem na to, že v jedné pouze Moskvě existuje několik fyzicky rozptýlených uzlů filtrace.
Proč máme tolik velkých a spolehlivých uzlů po celém světě?
- Kvalita obsluhy klientského provozu — požadavky z USA je třeba zpracovávat přímo v USA (včetně otázek útoků, parsování a dalších anomálií), a ne je tlačit do Moskvy nebo Evropy, což nepředvídatelně zvyšuje zpoždění zpracování.
- Útočný provoz je třeba lokalizovat — tranzitní operátoři mohou během útoků, jejichž objem často překračuje 1 Tbps, degradovat. Transportovat útočný provoz přes transatlantické nebo transaziatské linky — není nejlepší nápad. Měli jsme reálné případy, kdy Tier-1 operátoři říkali: „Objemy útoků, které přijímáte, jsou pro nás nebezpečné.“ Proto přijímáme příchozí toky co nejblíže k jejich zdrojům.
- Přísné požadavky na kontinuitu služeb — centrální servery by neměly záviset jeden na druhém ani na lokálních událostech našeho rychle se měnícího světa. Bylo odpojeno všechny 11 patra MMTs-9 na týden? — to není problém. Žádný klient, který nemá fyzické připojení právě v této lokalitě, nebude postižen a webové služby nebudou nijak ohroženy.
Jak to všechno řídit?
Konfigurace služeb by se měly co nejdříve (ideálně okamžitě) šířit na všechny front-end uzly. Není možné prostě vzít a přestavět textové konfigurace a restartovat démony při každé změně — ten samý nginx udržuje ukončující se procesy (worker shutting down) ještě několik minut (nebo dokonce hodin, pokud jsou tam dlouhé websocketové relace).
Při restartu konfigurace nginx je zcela normální následující situace:
Ohledně využití paměti:
Starší pracovníci využívají paměť, včetně množství, které není lineárně závislé na počtu připojení, — to je normální. Když se klientská připojení uzavřou, tato paměť bude uvolněna.
Proč to nebyl problém, když nginx teprve začínal vyvíjet? Nebyly ani HTTP/2, ani WebSocket, ani masivní dlouhá keep-alive připojení. 70 % našeho webového provozu — HTTP/2, a to jsou velmi dlouhá připojení.
Řešení je jednoduché — nepoužívat nginx, neřídit fronty na základě textových souborů a rozhodně neodesílat komprimované textové konfigurace přes transpacifické kanály. Kanály jsou samozřejmě garantované a rezervované, ale to nemění nic na jejich transkontinentálním charakteru.
Máme vlastní serverový vyrovnávač zatížení, jehož vnitřní fungování popíšu v následujících článcích. Hlavní věcí, kterou umí, je aplikovat tisíce změn konfigurace za sekundu naživo, bez restartů, reloadů, skokového nárůstu spotřeby paměti a podobně. To velmi připomíná Hot Code Reload, například v Erlangu. Data jsou uchovávána v geograficky distribuované key-value databázi a okamžitě je načítají výkonné mechanismy front. Tedy, pokud jste nahráli SSL certifikát přes webové rozhraní nebo API v Moskvě, za několik sekund je už připraven k použití v našem čistícím centru v Los Angeles. Pokud by náhodou nastala světová válka a internet na celém světě zmizel, naše uzly budou i nadále fungovat autonomně a opraví split-brain, jakmile se jeden z dedikovaných kanálů Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong-Los Angeles nebo alespoň jeden z rezervních přoverených GRE stane dostupným.
Tento mechanismus nám také umožňuje okamžité vydávání a prodlužování certifikátů Let’s Encrypt. Velmi zjednodušeně to funguje takto:
- Jakmile vidíme alespoň jeden HTTPS dotaz pro doménu našeho klienta bez certifikátu (nebo s propadlým certifikátem), externí uzel, který dotaz přijal, o tom informuje vnitřní certifikační centrum.
- Pokud uživatel neprohiboval vydávání Let’s Encrypt, certifikační centrum vytvoří CSR, obdrží od LE potvrzující token a rozesílá ho na všechny fronty přes šifrovaný kanál. Nyní může jakýkoliv uzel potvrdit validační dotaz od LE.
- Během několika okamžiků obdržíme platný certifikát a soukromý klíč a opět stejným způsobem je rozešleme frontám. Opět bez restartování démonů.
- 7 dní před datem expirace se spouští postup pro obnovení certifikátu.
Právě teď rotujeme v reálném čase 350k certifikátů zcela transparentně pro uživatele.
V následujících článcích cyklu se podělím o další zvláštnosti zpracování velkého webového provozu v reálném čase — například o analýze RTT na základě neúplných dat pro zlepšení kvality služeb tranzitních klientů a vůbec o ochraně tranzitního provozu před terabitovými útoky, o dodávce a agregaci informací o provozu, o WAF, téměř neomezeném CDN a mnoha mechanismech optimalizace výstupu obsahu.
Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.
O čem byste se chtěli dozvědět jako první?
- 14,3%Algoritmy klasifikace a analýzy kvality webového provozu<3
- 33,3%Vnitřnosti vyvažovačů DDoS-Guard7
- 9,5%Ochrana přenosového L3/L4 provozu2
- 0,0%Ochrana webových stránek v přenosovém provozu0
- 14,3%Web Application Firewall3
- 28,6%Ochrana proti parsování a klikání6
Hlasovalo 21 uživatelů. 6 uživatelů se zdrželo.
Zdroj: habr.com
