🥇Web-HighLoad — ako spravujeme prenos desiatok tisíc domén

Legitímna prevádzka v sieti DDoS-Guard nedávno presiahla sto gigabitov za sekundu. Teraz 50 % celého nášho prevádzky generujú webové služby klientov. Ide o mnohé desiatky tisíc domén, veľmi rôznych a väčšinou vyžadujúcich individuálny prístup.

Pod katom — ako spravujeme front-nody a dodávame SSL certifikáty pre státisíce stránok.

Nastaviť front pre jednu stránku, nech je akokoľvek veľká, — to je jednoduché. Berieme nginx, haproxy alebo lighttpd, nastavíme podľa návodov a zabudneme. Ak je potrebné niečo zmeniť — robíme reload a znova zabudneme.

Všetko sa mení, keď naživo spracovávate veľké objemy prevádzky, hodnotíte legitímnosť požiadaviek, komprimujete a cache-ujete používateľský obsah, pričom meníte parametre niekoľkokrát za sekundu. Používateľ chce vidieť výsledok na všetkých externých nodoch hneď po tom, čo zmenil nastavenia vo svojom užívateľskom rozhraní. A navyše používateľ môže nahrať cez API niekoľko tisíc (niekedy aj desiatok tisíc) domén s individuálnymi parametrami spracovania prevádzky. To všetko musí fungovať okamžite a v Amerike, a v Európe, a v Ázii — úloha nie je najjednoduchšia, keď zohľadníme, že v jednej iba Moskve je niekoľko fyzicky rozdelených uzlov filtrácie.

Prečo toľko veľkých spoľahlivých uzlov po celom svete?

Kvalita obsluhy klientskej prevádzky — požiadavky zo Spojených štátov je potrebné spracovávať práve v Spojených štátoch (vrátane útokov, parsovania a iných anomálií), a nie ich posielať do Moskvy alebo Európy, čím nepredvídateľne zvyšujeme latenciu spracovania.
Útočný prevádzka musí byť lokalizovaná — tranzitní operátori môžu degradovať počas útokov, ktorých objemy často presahujú 1Tbps. Transportovať útočný prevádzku cez transatlantické alebo transázijské linky — nie je najlepšia idea. Mali sme skutočné prípady, keď Tier-1 operátori hovorili: „Objemy útokov, ktoré prijímate, sú pre nás nebezpečné“. Preto akceptujeme prichádzajúce toky čo najbližšie k ich zdrojom.
Prísne požiadavky na kontinuitu služieb — centrá očisty by nemali byť závislé jedno od druhého ani od miestnych udalostí nášho rýchlo sa meniacho sveta. Odstránili elektrinu na celý týždeň všetkých 11 poschodí MMTŠ-9? — to nie je problém. Žiadny klient, ktorý nemá fyzické pripojenie práve v tejto lokalite, nebude postihnutý a webové služby nebudú ohrozené za žiadnych okolností.

Ako s tým všetkým narábať?

Konfigurácie služieb by sa mali čo najrýchlejšie (ideálne okamžite) šíriť na všetkých front-endoch. Nemôžete len tak vziať a prerobiť textové konfigurácie a robiť reštarty démonov pri každej zmene — ten istý nginx udržuje končiace procesy (worker shutting down) ešte niekoľko minút (a možno aj hodín, ak tam sú dlhé websocketové relácie).

Pri reštarte konfigurácie nginx je celkom normálny nasledujúci obraz:

Pokiaľ ide o využitie pamäte:

Staré workery spotrebúvajú pamäť, pričom táto spotreba nie je lineárne závislá od počtu pripojení, — to je normálne. Po uzavretí zákazníckych pripojení sa táto pamäť uvoľní.

Prečo to nebol problém, keď sa nginx len začínal rozvíjať? Nebolo ani HTTP/2, ani WebSocket, ani masové dlhé keep-alive pripojenia. 70% našich webových prenosov — HTTP/2, čo sú veľmi dlhé pripojenia.

Riešenie je jednoduché — nevyužívať nginx, neobsluhovať fronty na základe textových súborov a už vôbec nie prenášať zbalené textové konfigurácie cez transatlantické kanály. Kanály sú síce garantované a rezervované, ale to ich nerobí menej transkontinentálnymi.

Máme vlastný front-end server-balancer, o ktorého vnútri sa s vami podelím v nasledujúcich článkoch. Hlavná vec, ktorú to dokáže, je aplikovať tisíce zmien konfigurácie za sekundu za bežného chodu, bez reštartov, reloadov, skokového nárastu spotreby pamäte a podobne. To veľmi pripomína Hot Code Reload, napríklad v Erlangu. Údaje sa ukladajú v geo-distribuovanej key-value databáze a sú hneď načítané výkonnými mechanizmami front-endu. T.j. nahrali ste SSL certifikát prostredníctvom webového rozhrania alebo API v Moskve, a za niekoľko sekúnd je už pripravený na použitie v našom čistiacom centre v Los Angeles. Ak náhodou dôjde k svetovej vojne a internet zmizne na celom svete, naše uzly budú naďalej fungovať autonómne a opravia split-brain hneď, ako sa sprístupní jeden z vyhradených kanálov Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong-Los Angeles alebo aspoň jeden zo záložných overlayových GRE.

Tento mechanizmus nám tiež umožňuje okamžite vydávať a predlžovať certifikáty Let’s Encrypt. Veľmi zjednodušene to funguje takto:

Hneď ako zaznamenáme aspoň jeden HTTPS požiadavok pre doménu nášho klienta bez certifikátu (alebo s expirovaným certifikátom), externá uzol, ktorý prijal požiadavku, informuje o tom interné centrum certifikácie.
Ak používateľ nezakázal vydanie Let’s Encrypt, centrum certifikácie vytvorí CSR, získa od LE potvrdzujúci token a rozosiela ho na všetky fronty šifrovaným kanálom. Teraz akákoľvek uzol môže potvrdiť validačnú požiadavku od LE.
O niekoľko okamihov získame správny certifikát a súkromný kľúč a presne takto ich rozosielame frontom. Opäť bez reštartovania démonov.
7 dní pred dátumom expirácie sa spúšťa procedúra na opätovné získanie certifikátu.

Práve teraz v reálnom čase rotujeme 350 000 certifikátov úplne transparentne pre používateľov.

V nasledujúcich článkoch cyklu sa podelím o ďalšie špecifiká spracovania veľkého webového trafficu v reálnom čase — napríklad o analýze RTT na základe neúplných údajov pre zlepšenie kvality služieb tranzitných klientov a všeobecne o ochrane tranzitného trafficu pred terabajtovými útokmi, o doručovaní a agregácii informácií o trafficu, o WAF, takmer neobmedzenej CDN a množstve mechanizmov optimalizácie dodávania obsahu.

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.