🥇Web-HighLoad — hogyan kezeljük a forgalmat több tízezer domain számára

A DDoS-Guard hálózatában a legitimizált forgalom nemrégiben meghaladta a száz gigabitet másodpercenként. Jelenleg az összes forgalmunk 50%-át az ügyfél webszolgáltatásai generálják. Ez sok tízezer domain, nagyon változatosak, és a legtöbb esetben egyedi megközelítést igényel.

A továbbiakban bemutatjuk, hogyan kezeljük a front-nódokat és teljesítjük SSL tanúsítványok számtalan weboldal számára.

Egyetlen weboldal frontjának beállítása, még ha nagyon nagy is, egyszerű. Használunk nginx-et, haproxy-t vagy lighttpd-t, beállítjuk a útmutatók alapján, és elfelejtjük. Ha valamit módosítani kell — reload-ot végzünk, és ismét elfelejtjük.

Minden megváltozik, amikor valós időben kell nagy forgalmat kezelni, értékelni a kérések legitimitását, tömöríteni és gyorsítótárazni a felhasználói tartalmat, miközben a paramétereket másodpercenként többször is módosítjuk. A felhasználónak azonnal látnia kell az eredményt az összes külső noden, amint módosította a beállításokat a felhasználói fiókjában. Ráadásul a felhasználó API-n keresztül akár több ezer (néha akár tízezer) domaint is feltölthet egyedi forgalomkezelési paraméterekkel. Ennek mind azonnal működnie kell az Egyesült Államokban, Európában és Ázsiában — ez nem a legegyszerűbb feladat, figyelembe véve, hogy Moszkvában is több fizikailag elkülönített szűrőpont található.

Miért van szükség sok nagy, megbízható nodra világszerte?

A kliens forgalmának minősége — az Egyesült Államokból érkező kéréseket pontosan az Egyesült Államokban kell kezelni (beleértve a támadások, a parse-olás és egyéb anomáliák ellenőrzését), nem pedig Moszkvába vagy Európába vontatni, ami előre nem láthatóan megnöveli a feldolgozási késleltetést.
A támadó forgalmat lokalizálni kell — a tranzit szolgáltatók a támadások alatt degradálódhatnak, amelyek volumene gyakran meghaladja az 1Tbps-t. A támadó forgalmat transzatlanti vagy transzázsiai kapcsolatain szállítani nem a legjobb ötlet. Valódi esetekben a Tier-1 szolgáltatók azt mondták: „Az önök által fogadott támadások volumene veszélyes számunkra.” Ezért a bejövő forgalmat a lehető legközelebb kell kezelni a forrásaikhoz.
A szolgáltatás folyamatosságának szigorú követelményei azt jelentik, hogy a tisztítócsoportok nem függhetnek egymástól, és nem befolyásolhatják őket a gyorsan változó világunk helyi eseményei. Az MMTS-9 összes 11 emelete egy hétig áram nélkül maradt? – nem probléma. Egyetlen ügyfél sem szenved kárt, aki nem rendelkezik fizikai csatlakozással éppen ezen a helyszínen, és a webszolgáltatások semmilyen körülmények között nem sérülnek.

Hogyan lehet mindezt kezelni?

A szolgáltatások konfigurációit a lehető leggyorsabban (ideális esetben azonnal) el kell terjeszteni az összes frontnode-on. Nem lehet csak úgy átkonfigurálni a szöveges konfigurációkat és újraindítani a démonokat minden változáskor – az nginx például a leálló folyamatokat (worker shutting down) még néhány percig (vagy akár órákig, ha hosszú websocket session-ök vannak) tartja.

Az nginx konfigurációjának újraindításakor a következő kép teljesen normális:

A memóriahasználat szempontjából:

A régi munkavállalók memóriahasználata nem csupán a kapcsolatok számától függ, ami normális. Amikor az ügyfélkapcsolatok lezárulnak, ez a memória felszabadul.

Miért nem volt ez probléma, amikor az nginx elkezdett fejlődni? Nem volt HTTP/2, WebSocket, és tömeges hosszú keep-alive kapcsolatok. A webes forgalmunk 70%-a HTTP/2, ami nagyon hosszú kapcsolatok.

A megoldás egyszerű – ne használjon nginxt, ne kezelje a frontokat szöveges fájlok alapján, és főleg ne küldjön tömörített szöveges konfigurációkat transzceánus csatornákon. A csatornák persze garantáltak és fenntartottak, de ettől még transzkontinentálisak.

Saját front- és terheléselosztó szerverünk van, amelynek belső működéséről a következő cikkekben mesélek. A legfontosabb, hogy másodpercenként ezrekben alkalmazhat konfigurációs módosításokat anélkül, hogy újra kellene indítani, vagy hogy hirtelen megnövekedne a memóriahasználat. Ez nagyon hasonlít a Hot Code Reload-ra, mint például az Erlang esetében. Az adatok geográfiailag elosztott key-value adatbázisban tárolódnak, és azonnal, a frontok végrehajtó mechanizmusai által olvashatók. Tehát, ha SSL-tanúsítványt töltött fel a webes felületen vagy API-n keresztül Moszkvában, néhány másodpercen belül már használatra kész a Los Angeles-i adatközpontunkban. Ha világháború történik, és az internet világszerte megszűnik, a csomópontjaink autonóm módon folytatják a működést és helyreállítják a split-brain állapotot, amint elérhetővé válik a Los Angeles–Amsterdam–Moszkva, Moszkva–Amsterdam–Hongkong–Los Angeles vagy legalább egy tartalék overlay GRE csatorna.

Ez a mechanizmus lehetővé teszi számunkra, hogy azonnal kiadjuk és meghosszabbítsuk a Let’s Encrypt tanúsítványokat. Nagyon leegyszerűsítve ez így működik:

Amint legalább egy HTTPS-kérelmet észlelünk az ügyfelünk domainjére, amelyhez nincs tanúsítvány (vagy a tanúsítvány lejárt), a kéréshez érkező külső csomópont értesíti a belső tanúsítvány-kibocsátó központot.
Ha a felhasználó nem tiltotta le a Let’s Encrypt kiadását, a tanúsítvány-kibocsátó központ CSR-t képez, megszerzi a LE megerősítő tokenjét, és titkosított csatornán keresztül elküldi azt az összes frontra. Most bármely csomópont képes megerősíteni a LE-től érkező érvényesítési kérést.
Néhány pillanaton belül megkapjuk a megfelelő tanúsítványt és a privát kulcsot, és pontosan ugyanígy eljuttatjuk a frontra. Újra, a démonok újraindítása nélkül.
A lejárati dátum előtt 7 nappal megkezdődik a tanúsítvány megújításának folyamata.

Jelenleg valós időben 350 ezer tanúsítványt forgatunk, teljesen átlátható módon a felhasználók számára.

A következő ciklus cikkeiben mesélek a nagy webforgalom valós idejű feldolgozásának egyéb jellemzőiről — például az RTT elemzéséről hiányos adatok alapján a tranzit ügyfelek szolgáltatási minőségének javítása érdekében, valamint a tranzitforgalom védelméről a terabites támadások ellen, a forgalomról szóló információk biztosításáról és aggregálásáról, WAF-ról, szinte korlátlan CDN-ről és számos tartalomoptimalizáló mechanizmusról.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.