Veeb-HighLoad — kuidas me haldame kümnete tuhandete domeenide liiklust

Legitiimne liiklus DDoS-Guardi võrgus on hiljuti ületanud saja gigabiti sekundis. Praegu genereerivad 50% kogu meie liiklusest klientide veebiteenused. Need on kümned tuhanded domeenid, väga erinevad ja enamikul juhtudel nõuavad individuaalset lähenemist.

Allpool — kuidas me hallame eesnode ja väljastame SSL-sertifikaadid sajale tuhandele veebisaidile.

Eesnode seadmine ühe veebisaidi jaoks, isegi kui see on väga suur, on lihtne. Võtame nginx'i või haproxy või lighttpd, seadistame juhiste järgi ja unustame. Kui on vaja midagi muuta - teeme reload'i ja jälle unustame.

Kõik muutub, kui te töötlete suures mahus liiklust reaalajas, hindate päringute legitiimsust, tihendate ja vahetate kasutajasisu, ja samas muudate parameetreid mitu korda sekundis. Kasutaja soovib näha tulemusi kõigil väliste nodede jooksul kohe pärast seda, kui ta on oma isiklikus kabinetis seadeid muutnud. Ja kasutaja võib ka API kaudu üles laadida mitu tuhat (mõnikord ka kümneid tuhandeid) domeene individuaalsete liikluse töötlemise parameetritega. See kõik peab ka kohe toimima nii Ameerikas, Euroopas kui ka Aasias - ülesanne pole sugugi triviaalne, arvestades, et üksi Moskvas on mitu füüsiliselt, geograafiliselt eraldatud filtreerimise sõlme.

Miks on üle kogu maailma nii palju suuri ja usaldusväärseid sõlmi?

• Kliendiliikluse teenindamise kvaliteet - USA-st tulevaid päringuid tuleb töödelda just Ameerikas (ka rünnakute, andmete kaevandamise ja muude anomaaliate osas), mitte tuua neid Moskvasse või Euroopasse, et ettearvamatu viivituse protsessi suurendada.
• Ründeliiklust tuleb lokaliseerida - üleminekute operaatorid võivad rünnakute ajal kehvast töö kvaliteedist kannatada, mille mahud ületavad sageli 1Tbps. Ründeliiklust transatlantiliste või transaasia linkide kaudu transportida - ei ole parim idee. Meil on olnud reaalsed juhtumid, kus Tier-1 operaatorid ütlesid: 'Rünnakute mahud, mida te vastu võtate, on meile ohtlikud'. Just seepärast aktsepteerime sisse tulevaid voogusid nii lähedal nende allikatele kui võimalik.
• Ranged maintainability requirements are crucial — the clean centers should not depend on each other or the local events in our rapidly changing world. Power was cut to all 11 floors of MMT-9 for a week? — No problem. Not a single client not physically connected in this location will be affected, and web services will remain intact under any circumstances.

How to manage all of this?

Service configurations must propagate to all front nodes as quickly as possible (ideally instantly). You can't just rebuild text configs and restart daemons at every change — nginx holds terminating processes (worker shutting down) for several minutes (or even hours if there are lengthy websocket sessions).

When reloading nginx configuration, the following scenario is perfectly normal:

Regarding memory utilization:

Old workers consume memory, including memory not linearly dependent on the number of connections — this is normal. When client connections close, this memory will be freed.

Why wasn't this a problem when nginx first started evolving? There was neither HTTP/2, nor WebSocket, nor large numbers of long keep-alive connections. 70% of our web traffic is HTTP/2, which involves very long connections.

The solution is simple — do not use nginx, do not manage fronts based on text files, and definitely do not run zipped text configurations across transpacific channels. These channels are guaranteed and reserved, but that doesn’t make them any less transcontinental.

Meil on oma oma eesmine server-balanseer, mille sisust räägin järgmistes artiklites. Peamine asi, mida ta oskab, on rakendada tuhandeid konfiguratsioonimuutusi sekundis reaalajas, ilma taaskäivituste, laadimiste või järskude mälu tarbimise tõusudeta. See sarnaneb väga Hot Code Reload'iga, näiteks Erlangis. Andmed salvestatakse geoväärise key-value andmebaasi ja loetakse koheselt ette täitmismehhanismide poolt. St, te laadisite SSL-sertifikaadi läbi veebiliidese või API Moskvas ja mõne sekundi pärast on see juba valmis töötamiseks meie puhastuspunktis Los Angeleses. Kui peaks juhtuma maailmasõda ja internet kaoks üle kogu maailma, siis meie nodid jätkavad autonoomset töötamist ja parandavad split-brain'i, kui üks meie pühendatud kanalitest Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong-Los Angeles või vähemalt üks varuülekande GRE on jälle saadaval.

Sama mehhanism võimaldab meil koheselt väljastada ja pikendada Let’s Encrypt sertifikaate. Väga lihtsustatult töötab see nii:

1. Niipea, kui me näeme vähemalt ühte HTTPS-päringut meie kliendi domeeni kohta ilma sertifikaadita (või aegunud sertifikaadiga), teavitab päringu vastu võtav väline node sisemist sertifitseerimiskeskust.

   

2. Kui kasutaja ei ole keelanud Let’s Encrypt'i väljastamist, genereerib sertifitseerimiskeskus CSR-i, saab LE-lt kinnitustokeni ja saadab selle kõikidele frontidele krüpteeritud kanali kaudu. Nüüd võib iga node kinnitada LE-lt kehtivuskinnituspäringu.

   

3. Mõne hetke pärast saame õige sertifikaadi ja privaatvõtme ning saadame need samuti frontidele. Taaskord ilma demonite taaskäivitamiseta.

   

4. Seitsme päeva pärast kehtivuse lõpptähtaega algatatakse sertifikaadi uuesti saamise protseduur.

Praegu rotatsioonime reaalajas 350 000 sertifikaati täiesti läbipaistvalt kasutajatele.

Järgmistes artiklite tsüklites räägin muudest reaalajas töötlemise eripäradest suure veebiliikluse osas — näiteks RTT analüüsist mittetäielike andmete põhjal, et parandada üleminek klientide teenuse kvaliteeti, ja üldiselt, transitiliikluse kaitset terabiti rünnakute eest, liikluse edastamisest ja kogumisest, WAF-ist, peaaegu piiritust CDN-ist ja paljusid sisu esitamise optimeerimise mehhanisme.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Millest sooviksite kõigepealt teada?

• 14,3%Klastri ja veebiliikluse kvaliteedi analüüs
• 33,3%DDoS-Guard balansseerijate sisemus
• 9,5%L3/L4 transiittäienduste kaitse
• 0,0%Veebisaitide kaitse transiidiliikluse puhul
• 14,3%Veebirakenduse tulemüüri kaitse
• 28,6%Kaitse kraapimise ja klikkide eest

21 kasutajat hääletas. 6 kasutajat ei hääletanud.

Allikas: habr.com