Legitímna prevádzka v sieti DDoS-Guard nedávno presiahla sto gigabitov za sekundu. V súčasnosti 50 % všetkej našej návštevnosti generujú klientske webové služby. Ide o mnoho desiatok tisíc domén, veľmi odlišných a vo väčšine prípadov vyžadujúcich individuálny prístup.
Nižšie je uvedený spôsob, akým spravujeme predné uzly a vydávame certifikáty SSL pre státisíce stránok.
Nastavenie frontu pre jednu lokalitu, dokonca aj veľmi veľkú, je jednoduché. Vezmeme nginx alebo haproxy alebo lighttpd, nakonfigurujeme ho podľa sprievodcov a zabudneme na to. Ak potrebujeme niečo zmeniť, urobíme reload a znova zabudneme.
Všetko sa zmení, keď za behu spracovávate veľké objemy návštevnosti, vyhodnocujete oprávnenosť požiadaviek, komprimujete a ukladáte používateľský obsah do vyrovnávacej pamäte a zároveň meníte parametre niekoľkokrát za sekundu. Používateľ chce vidieť výsledok na všetkých externých uzloch ihneď po zmene nastavení vo svojom osobnom účte. Cez API si môže používateľ stiahnuť aj niekoľko tisíc (niekedy aj desaťtisíc) domén s individuálnymi parametrami spracovania návštevnosti. To všetko by malo okamžite fungovať aj v Amerike, Európe a Ázii - úloha nie je najtriviálnejšia, ak vezmeme do úvahy, že v samotnej Moskve je niekoľko fyzicky oddelených filtračných uzlov.
Prečo je na svete veľa veľkých spoľahlivých uzlov?
-
Kvalita služieb pre návštevnosť klientov – požiadavky z USA musia byť spracované v USA (vrátane útokov, analýzy a iných anomálií), a nie ťahané do Moskvy alebo Európy, čím sa nepredvídateľne zvyšuje oneskorenie spracovania.
-
Útočná prevádzka musí byť lokalizovaná – tranzitní operátori môžu degradovať pri útokoch, ktorých objem často presahuje 1 Tbps. Prenášať útočnú prevádzku cez transatlantické alebo transázijské spojenia nie je dobrý nápad. Mali sme skutočné prípady, keď operátori Tier-1 povedali: „Množstvo útokov, ktoré dostávate, je pre nás nebezpečné.“ Preto prijímame prichádzajúce streamy čo najbližšie k ich zdrojom.
-
Prísne požiadavky na kontinuitu servisu – upratovacie centrá by v našom rýchlo sa meniacom svete nemali závisieť ani od seba, ani od miestnych udalostí. Vypli ste na týždeň napájanie všetkých 11 poschodí MMTS-9? - žiaden problém. Netrpí tým ani jeden klient, ktorý nemá fyzické pripojenie v tejto konkrétnej lokalite a za žiadnych okolností neutrpia ani webové služby.
Ako toto všetko zvládnuť?
Konfigurácie služieb by mali byť distribuované do všetkých predných uzlov čo najrýchlejšie (ideálne okamžite). Nemôžete len vziať a prebudovať textové konfigurácie a reštartovať démonov pri každej zmene – ten istý nginx udržiava procesy vypnuté (vypnutie pracovníka) ešte niekoľko minút (alebo možno hodín, ak existujú dlhé relácie websocket).
Pri opätovnom načítaní konfigurácie nginx je nasledujúci obrázok celkom normálny:
O využití pamäte:
Starí pracovníci zaberajú pamäť, vrátane pamäte, ktorá lineárne nezávisí od počtu spojení - to je normálne. Keď sa klientske pripojenia zatvoria, táto pamäť sa uvoľní.
Prečo to nebol problém, keď nginx práve začínal? Neexistoval žiadny HTTP/2, žiadny WebSocket, žiadne masívne dlhé udržiavacie pripojenia. 70 % našej webovej návštevnosti je HTTP/2, čo znamená veľmi dlhé pripojenia.
Riešenie je jednoduché – nepoužívajte nginx, nespravujte fronty založené na textových súboroch a určite neposielajte zazipované textové konfigurácie cez transpacifické kanály. Kanály sú, samozrejme, zaručené a vyhradené, ale to neznamená, že sú menej transkontinentálne.
Máme vlastný front server-balancer, o ktorého vnútornostiach budem hovoriť v nasledujúcich článkoch. Hlavná vec, ktorú dokáže, je aplikovať tisíce konfiguračných zmien za sekundu za behu, bez reštartov, opätovného načítania, náhleho zvýšenia spotreby pamäte a podobne. Je to veľmi podobné Hot Code Reload, napríklad v Erlangu. Údaje sú uložené v geodistribuovanej databáze kľúč-hodnota a sú okamžite čítané prednými ovládačmi. Tie. nahráte SSL certifikát cez webové rozhranie alebo API v Moskve a za pár sekúnd je pripravený ísť do nášho upratovacieho centra v Los Angeles. Ak sa náhle stane svetová vojna a internet zmizne na celom svete, naše uzly budú pokračovať v autonómnej práci a opravia rozdelený mozog, len čo jeden z vyhradených kanálov Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong- Los-Los sa stáva dostupným Angeles alebo aspoň jedno zo zálohovaných prekrytí GRE.
Rovnaký mechanizmus nám umožňuje okamžite vydávať a obnovovať certifikáty Let's Encrypt. Veľmi jednoducho to funguje takto:
-
Akonáhle uvidíme aspoň jednu HTTPS požiadavku pre doménu nášho klienta bez certifikátu (alebo s vypršaným certifikátom), externý uzol, ktorý požiadavku prijal, to oznámi internej certifikačnej autorite.
-
Ak používateľ nezakázal vydanie Let's Encrypt, certifikačná autorita vygeneruje CSR, prijme potvrdzovací token od LE a pošle ho na všetky fronty cez šifrovaný kanál. Teraz môže ktorýkoľvek uzol potvrdiť overovaciu požiadavku od LE.
-
Za pár okamihov dostaneme správny certifikát a súkromný kľúč a pošleme ho na fronty rovnakým spôsobom. Opäť bez reštartovania démonov
-
7 dní pred dátumom exspirácie sa začne postup na opätovné získanie certifikátu
Práve teraz rotujeme 350 XNUMX certifikátov v reálnom čase, úplne transparentne pre používateľov.
V nasledujúcich článkoch seriálu budem hovoriť o ďalších funkciách spracovania veľkej návštevnosti webu v reálnom čase – napríklad o analýze RTT pomocou neúplných údajov na zlepšenie kvality služieb pre tranzitných klientov a vo všeobecnosti o ochrane tranzitnej prevádzky pred terabitové útoky, o doručovaní a agregácii dopravných informácií, o WAF, takmer neobmedzenom CDN a mnohých mechanizmoch na optimalizáciu doručovania obsahu.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Čo by ste chceli vedieť ako prvé?
-
14,3%Algoritmy na klastrovanie a analýzu kvality návštevnosti webu<3
-
33,3%Vnútorné časti vyvažovačov DDoS-Guard7
-
9,5%Ochrana tranzitnej premávky L3/L4
-
0,0%Ochrana webových stránok pred tranzitnou premávkou0
-
14,3%Firewall webových aplikácií3
-
28,6%Ochrana proti analýze a klikaniu6
Hlasovalo 21 používateľov. 6 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com