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

Legitiimne liiklus DDoS-Guard võrgus ületas hiljuti saja gigabiti sekundis. Hetkel genereerivad meie liiklusest 50% klientide veebiteenused. Need on kümned tuhanded domeenid, väga erinevad ja enamikul juhtudel vajavad need individuaalset lähenemist.

Allpool on selgitatud, kuidas me hallame fronte-node ja välja anname SSL-sertifikaadid sajatele tuhandetele veebisaitidele.

Ühe saidi, isegi väga suures, konfigureerimine on lihtne. Võtame nginx-i või haproxy või lighttpd, seadistame vastavalt juhistele ja unustame. Kui on vaja midagi muuta, siis teeme reloadi ja unustame jälle.

Kõik muutub, kui töötlete suuremaid liiklusvooge reaalajas, hindate päringute legitiimsust, tihendate ja cache'ite kasutajasisu ning muudate parameetreid mitu korda sekundis. Kasutaja soovib näha tulemust kõigil välisnõludel kohe pärast oma seadete muutmist isiklikus kabinetis. Lisaks võib kasutaja API kaudu üles laadida mitmeid tuhandeid (mõnikord ka kümneid tuhandeid) domeene individuaalsete liikluse töötlemise parameetritega. Kõik see peab samuti kohe töötama nii Ameerikas, Euroopas kui ka Aasias - ülesanne ei ole sugugi triviaalne, arvestades, et ühes Moskvas on mitu füüsiliselt hajutatud filtreerimisse positiivne sõlme.

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

Kliendiliikluse teenindamise kvaliteet - USA-sse suunatud päringud tuleb töödelda just USA-s (sealhulgas rünnakute, kraapimise ja muude anomaaliate osas), mitte viia neid Moskvasse või Euroopasse, et ettearvamatult suurendada töötlemise viivitust.
Rünnakut räime tulu tuleb lokaliseerida — transpordioperaatorid võivad rünnakute ajal, mille maht tihti ületab 1 Tbps, halveneda. Rünnaku liiklus transportimine transatlantiliste või transasiatlike linkide kaudu pole parim idee. Meil on olnud reaalsed juhtumid, kus Tier-1 operaatorid ütlesid: „Teie poolt vastu võetud rünnakute mahud on meile ohtlikud.” Just seetõttu võtame sissetulevaid vooge võimalikult lähedal nende allikatele.
Tugevad nõuded teenuse pidevusele — puhastuspunktid ei tohi üksteisest ega kohalike sündmustest sõltuda meie kiiresti muutuvas maailmas. Kui kõik 11 korrust MMT-9 on nädala jooksul elektrita? — pole hullu. Ükski klient, kellel ei ole füüsilist ühendust just selles asukohas, ei kannata, ja veebiteenused ei jää mingites oludes kehvaks.

Kuidas kõike seda juhtida?

Teenuste konfiguratsioonid peavad võimalikult kiiresti (ideaalis koheselt) kõikidesse esifrontidesse ning olema levitatud. Ei saa lihtsalt võtta ja ümber määrata tekstilisi konfiguratsioone ning teha demonite taaskäivitusi iga muudatuse korral — näiteks nginx hoiab lõpetavaid protsesse (worker shutting down) veel mitu minutit (võib-olla isegi tunde, kui seal on pikad websocket-seansid).

Nginxi konfiguratsiooni taaskäivitamisel on täiesti tavaline järgmine pilt:

Mälu kasutuse osas:

Vanad tööprotsessid tarbivad mälu, sealhulgas mäluruumi, mis ei sõltu lineaarsetest ühenduste arvust — see on normaalne. Kui kliendiühendused suletakse, vabastatakse see mälu.

Miks see ei olnud probleem, kui nginx alles hakkas arenema? Ei olnud ei HTTP/2, ei WebSocket't, ega massilisi pikki keep-alive ühendusi. 70% meie veebiliiklusest on HTTP/2, mis tähendab väga pikki ühendusi.

Lahendus on lihtne — mitte kasutada nginx'i, mitte haldada fronte tekstipõhiselt, ja kindlasti mitte edastada kokku pakitud tekstilisi konfiguratsioone transkontinentaalsetes kanalis. Kanalid on muidugi garanteeritud ja reserveeritud, kuid need on siiski transkontinentaalsed.

Meil on oma front-serveri koormuse tasakaalustaja, mille sisust räägin järgmistes artiklites. Peamine, mida ta teeb, on rakendada tuhandeid konfiguratsioonimuudatusi sekundis reaalajas, ilma taaskäivitusteta, laadimisteta ning ilma mälutarbimise järskude hüpeteta. See sarnaneb näiteks Hot Code Reloadiga, nagu Erlangis. Andmed salvestatakse geograafiliselt jaotatud key-value andmebaasi ning loetakse koheselt välja frontide täiturmehhanismide kaudu. See tähendab, et olete laadinud SSL-sertifikaadi veebiliidese või API kaudu Moskvas, ja mõne sekundiga on see juba valmis tööks meie puhastuspunktis Los Angeleses. Kui peaks toimuma maailmasõda ja internet kaoks igaveseks, jätkavad meie sõlmed iseseisvat tööd ning taastavad split-braini, kui üks meie pühendatud kanalitest Los Angeles-Amsterdam-Moskva, Moskva-Amsterdam-Hongkong-Los Angeles või vähemalt üks varu GRE-ümberkatte kanalitest taastub.

See sama mehhanism võimaldab meil koheselt välja anda ja pikendada Let’s Encrypt sertifikaate. Lihtsustatult toimib see järgmiselt:

Niipea, kui näeme vähemalt ühte HTTPS-päringut meie kliendi domeeni ilma sertifikaadita (või aegunud sertifikaadiga), teavitab väline sõlm, kes päringu vastu võttis, sellest sisemist sertifitseerimiskeskust.
Kui kasutaja ei ole Let’s Encrypti väljastamist keelanud, genereerib sertifitseerimiskeskus CSR-i, saada LE-lt kinnitustokeni ja saadab selle kõigisse frontidesse krüpteeritud kanalil. Nüüd saavad kõik sõlmed kinnitada LE-lt tulevat valideerimist.
Mõne sekundi pärast saame õige sertifikaadi ja privaatvõtme ning saadame need samuti frontidele. Taaskord ilma daemonite taaskäivitamiseta.
7 päeva enne kehtivusaja lõppu algatatakse sertifikaadi uuskehtestamise protsess.

Praegu rotatsiooni käigus haldame reaalajas 350 000 sertifikaati kasutajatele täiesti nähtamatult.

Järgmistes artiklites käsitlen teisi reaalajas suure veebiliikluse töötlemise omadusi - näiteks RTT analüüsi osalistest andmetest, et parandada üleminekuteenuste kvaliteeti ning üldiselt, kuidas kaitsta üleminekuvõrku terabiti rünnakute eest, samuti liikluse edastamist ja aggregeerimist, WAF-i, praktiliselt piiramatu CDN-i ning mitmeid sisu edastamise optimeerimise mehhanisme.

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