Web HighLoad – hogyan kezeljük több tízezer domain forgalmát

A DDoS-Guard hálózat jogos forgalma nemrégiben meghaladta a másodpercenkénti száz gigabitet. Jelenleg az összes forgalmunk 50%-át az ügyfél webszolgáltatásai generálják. Sok tízezer tartományról van szó, amelyek nagyon eltérőek, és a legtöbb esetben egyéni megközelítést igényelnek.

A kivágás alatt bemutatjuk, hogyan kezeljük az elülső csomópontokat és adunk ki SSL-tanúsítványokat több százezer webhely számára.

Az előlap felállítása egy helyhez, még egy nagyon nagyhoz is, egyszerű. Vegyünk nginxet vagy haproxyt vagy lighttpd-t, beállítjuk az útmutatók szerint, és elfelejtjük. Ha változtatnunk kell valamit, újratöltjük, és újra elfelejtjük.

Minden megváltozik, ha nagy mennyiségű forgalmat dolgoz fel menet közben, értékeli a kérések jogosságát, tömöríti és gyorsítótárazza a felhasználói tartalmat, és ezzel egyidejűleg másodpercenként többször módosítja a paramétereket. A felhasználó azonnal látni szeretné az eredményt az összes külső csomóponton, miután megváltoztatta a beállításokat a személyes fiókjában. Egy felhasználó több ezer (néha több tízezer) tartományt is letölthet egyedi forgalomfeldolgozási paraméterekkel az API-n keresztül. Mindennek azonnal működnie kell Amerikában, Európában és Ázsiában is - a feladat nem a legtriviálisabb, tekintve, hogy csak Moszkvában van több fizikailag elválasztott szűrőcsomópont.

Miért van sok nagy megbízható csomópont szerte a világon?

• Az ügyfélforgalom szolgáltatásának minősége - az USA-ból érkező kéréseket az USA-ban kell feldolgozni (beleértve a támadásokat, elemzéseket és egyéb rendellenességeket), és nem kell Moszkvába vagy Európába húzni, ami előreláthatatlanul megnöveli a feldolgozási késést.

• A támadási forgalmat lokalizálni kell - a tranzitkezelők leépülhetnek a támadások során, amelyek mennyisége gyakran meghaladja az 1 Tbps-t. Nem jó ötlet a támadóforgalom transzatlanti vagy transzázsiai összeköttetéseken keresztül történő továbbítása. Voltak valós eseteink, amikor a Tier-1 kezelők azt mondták: „Az Ön által kapott támadások mennyisége veszélyes számunkra.” Ezért fogadjuk be a bejövő streameket a forrásukhoz a lehető legközelebb.

• A szolgáltatás folytonosságának szigorú követelményei – a takarítóközpontok nem függhetnek sem egymástól, sem a helyi eseményektől gyorsan változó világunkban. Lekapcsolta az áramellátást az MMTS-11 mind a 9 emeletén egy hétre? - Nincs mit. Egyetlen olyan ügyfél sem fog szenvedni, akinek nincs fizikai kapcsolata ezen a helyen, és a webszolgáltatások sem szenvednek kárt semmilyen körülmények között.

Hogyan lehet mindezt kezelni?

A szolgáltatáskonfigurációkat a lehető leggyorsabban (ideális esetben azonnal) el kell juttatni az összes elülső csomóponthoz. Nem lehet egyszerűen átépíteni és újraépíteni a szöveges konfigurációkat, és minden változtatásnál újraindítani a démonokat – ugyanaz az nginx leállítja a folyamatokat (a dolgozók leállását) még néhány percig (vagy akár órákig, ha hosszú websocket munkamenetek vannak).

Az nginx konfiguráció újratöltésekor a következő kép teljesen normális:

A memóriahasználatról:

A régi munkások felemésztik a memóriát, beleértve a nem lineárisan függõ memóriákat is a kapcsolatok számától – ez normális. Az ügyfélkapcsolatok bezárásakor ez a memória felszabadul.

Miért nem volt ez probléma, amikor az nginx még csak most indult? Nem volt sem HTTP/2, sem WebSocket, sem hatalmas, hosszú életben tartási kapcsolatok. Webforgalmunk 70%-a HTTP/2, ami nagyon hosszú kapcsolatokat jelent.

A megoldás egyszerű – ne használjon nginxet, ne kezelje a frontokat szöveges fájlok alapján, és semmiképpen ne küldjön tömörített szöveges konfigurációkat a tengerentúli csatornákon. A csatornák természetesen garantáltak és fenntartottak, de ettől még nem lesznek kevésbé transzkontinentálisak.

Saját elülső szerver-kiegyenlítőnk van, melynek belső részeiről a következő cikkekben fogok beszélni. A lényeg, hogy másodpercenként több ezer konfigurációmódosítást alkalmazzon menet közben, újraindítások, újratöltések, hirtelen megnövekedett memóriafelhasználás és hasonlók nélkül. Ez nagyon hasonlít a Hot Code Reload-hoz, például az Erlangban. Az adatokat egy földrajzilag elosztott kulcsérték adatbázisban tárolják, és az elülső működtetők azonnal beolvassák. Azok. feltölti az SSL-tanúsítványt a webes felületen vagy az API-n keresztül Moszkvában, és néhány másodpercen belül készen áll a Los Angeles-i tisztítóközpontunkba. Ha hirtelen kitör egy világháború, és az internet eltűnik a világ minden tájáról, csomópontjaink továbbra is önállóan működnek, és helyreállítják a megosztott agyat, amint az egyik dedikált csatorna Los Angeles-Amszterdam-Moszkva, Moszkva-Amszterdam-Hongkong- Los-Los elérhetővé válik. Angeles vagy legalább egy GRE biztonsági mentési átfedés.

Ugyanez a mechanizmus lehetővé teszi számunkra a Let's Encrypt tanúsítványok azonnali kiadását és megújítását. Nagyon egyszerűen így működik:

1. Amint legalább egy HTTPS-kérést látunk ügyfelünk domainjéhez tanúsítvány nélkül (vagy lejárt tanúsítvánnyal), a kérést elfogadó külső csomópont jelenti ezt a belső hitelesítés-szolgáltatónak.

   

2. Ha a felhasználó nem tiltotta meg a Let's Encrypt kiadását, akkor a hitelesítésszolgáltató generál egy CSR-t, megerősítő tokent kap a LE-től, és egy titkosított csatornán elküldi az összes frontra. Mostantól bármelyik csomópont megerősítheti az LE-től érkező érvényesítési kérelmet.

   

3. Néhány pillanat múlva megkapjuk a megfelelő tanúsítványt és privát kulcsot, és ugyanúgy elküldjük a frontoknak. Ismét a démonok újraindítása nélkül

   

4. 7 nappal a lejárat előtt indul az igazolás újbóli átvételére irányuló eljárás

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

A sorozat következő cikkeiben a nagy webes forgalom valós idejű feldolgozásának egyéb jellemzőiről fogok beszélni – például az RTT elemzéséről a hiányos adatok felhasználásával a tömegközlekedési ügyfelek szolgáltatási minőségének javítása érdekében, és általában a tranzitforgalom védelméről. terabites támadások, a forgalmi információk továbbításáról és összesítéséről, a WAF-ról, a szinte korlátlan CDN-ről és a tartalomszolgáltatás optimalizálására szolgáló számos mechanizmusról.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Mit szeretnél először tudni?

• 14,3%Algoritmusok a klaszterezéshez és a webforgalom minőségének elemzéséhez<3

• 33,3%A DDoS-Guard7 kiegyensúlyozók belső részei

• 9,5%A tranzit L3/L4 forgalom védelme2

• 0,0%Webhelyek védelme a tranzitforgalomban0

• 14,3%Webalkalmazás tűzfal 3

• 28,6%Védelem elemzés és kattintás ellen6

21 felhasználó szavazott. 6 felhasználó tartózkodott.

Forrás: will.com