Легітымны трафік у сетцы DDoS-Guard нядаўна перавысіў сотню гігабіт у секунду. Цяпер 50% усяго нашага трафіку генеруюць вэб-сэрвісы кліентаў. Гэта шматлікія дзясяткі тысяч даменаў, вельмі розных і ў большасці выпадкаў патрабавальных індывідуальнага падыходу.
Пад катом - як мы кіруем фронт-нодамі і выдаем SSL-сертыфікаты для сотняў тысяч сайтаў.
Наладзіць фронт для аднаго сайта, няхай нават вельмі вялікага, - гэта проста. Бярэм nginx ці haproxy ці lighttpd, наладжваем па гайдах і забываем. Калі трэба нешта памяняць - які робіцца reload і ізноў забываем.
Усё змяняецца, калі вы на лёце апрацоўваеце вялікія аб'ёмы трафіку, ацэньваеце легітымнасць запытаў, сціскаеце і кэшуеце карыстацкі кантэнт, і пры гэтым змяняеце параметры некалькі разоў у секунду. Карыстальнік жадае бачыць вынік на ўсіх вонкавых нодах адразу пасля таго, як ён памяняў налады ў асабістым кабінеце. А яшчэ карыстач можа загрузіць па API некалькі тысяч (а часам і дзясяткаў тысяч) даменаў з індывідуальнымі параметрамі апрацоўкі трафіку. Усё гэта таксама павінна зарабіць адразу і ў Амерыцы, і ў Еўропе, і ў Азіі – задача не самая трывіяльная, улічваючы, што ў адной толькі Маскве некалькі фізічна разнесеных вузлоў фільтрацыі.
Навошта шмат вялікіх надзейных вузлоў па ўсім свеце?
-
Якасць абслугоўвання кліенцкага трафіку - запыты з ЗША трэба апрацоўваць менавіта ў ЗША (у тым ліку на прадмет нападаў, парсінгу і іншых анамалій), а не цягнуць у Маскву ці Еўропу, непрадказальна павялічваючы затрымку апрацоўкі.
-
Атакуючы трафік трэба лакалізоўваць – транзітныя аператары могуць дэградаваць падчас нападаў, аб'ём якіх часта перавышае 1Тbps. Транспартаваць атакуючы трафік па трансатлантычных або трансазіяцкіх лінкам - не лепшая ідэя. У нас былі рэальныя кейсы, калі Tier-1 аператары казалі: "Аб'ёмы нападаў, якія вы прымаеце, для нас небяспечныя". Менавіта таму мы прымаем уваходныя патокі як мага бліжэй да іх крыніц.
-
Жорсткія патрабаванні бесперапыннасці абслугоўвання - цэнтры ачысткі не павінны залежаць ні адзін ад аднаго, ні ад лакальных падзей нашага імкліва які змяняецца свету. Абясточылі на тыдзень усе 11 паверхаў ММТС-9? - не бяда. Не пацерпіць ніводны кліент, які не мае фізічнага ўключэння менавіта ў гэтай лакацыі, а вэб-сэрвісы не пацерпяць ні пры якіх абставінах.
Як усім гэтым кіраваць?
Канфігурацыі сэрвісаў павінны як мага хутчэй (у ідэале імгненна) распаўсюджвацца на ўсіх фронт-нодах. Нельга проста браць і перабудоўваць тэкставыя канфігі і рабіць перазагрузкі дэманаў на кожнай змене – той жа nginx трымае завяршаюцца працэсы (worker shutting down) яшчэ некалькі хвілін (а можа і гадзін калі там доўгія websocket-сесіі).
Пры перазагрузцы канфігурацыі nginx суцэль звычайная наступная карціна:
Па ўтылізацыі памяці:
Старыя воркеры ядуць памяць, у тым ліку, якая не залежыць лінейна ад колькасці злучэнняў, - гэта нармальна. Калі кліенцкія злучэнні зачыняцца, гэтая памяць вызваліцца.
Чаму гэта не было праблемай, калі nginx толькі пачынаў разьвівацца? Не было ні HTTP/2, ні WebSocket, ні масавых доўгіх keep-alive злучэнняў. 70% нашага вэб-трафіку – HTTP/2, а гэта вельмі доўгія злучэнні.
Рашэнне простае - не выкарыстоўваць nginx, не кіраваць франтамі на аснове тэкставых файлаў, і ўжо сапраўды не ганяць зыпаваныя тэкставыя канфігурацыі па трансціхаакіянскіх каналах. Каналы, вядома, гарантаваныя і рэзерваваныя, але ад гэтага не менш транскантынентальныя.
У нас уласны фронт-сервер-балансер, аб вантробах якога я распавяду ў наступных артыкулах. Галоўнае, што ён умее – ужываць тысячы змен канфігурацый у секунду на лета, без рэстартаў, релоадов, скачкападобнага росту спажывання памяці і вось гэтага ўсяго. Гэта вельмі падобна на Hot Code Reload, напрыклад, у Erlang. Дадзеныя захоўваюцца ў геаразмеркаванай key-value базе і вычытваюцца адразу выканаўчымі механізмамі франтоў. Г.зн. вы загрузілі SSL-сертыфікат праз вэб-інтэрфейс або API у Маскве, а праз некалькі секунд ён ужо гатовы да працы ў нашым цэнтры ачысткі ў Лос-Анжэлесе. Калі раптам здарыцца сусветная вайна, і знікне інтэрнэт ва ўсім свеце, нашы ноды працягнуць працаваць аўтаномна і паправяць split-brain, як толькі стане даступны адзін з вылучаных каналаў Лос-Анжэлес-Амстэрдам-Масква, Масква-Амстэрдам-Гон-Конг-Лос- Анжэлес ці хаця б адзін з рэзервовых оверлейных GRE.
Гэты ж механізм дазваляе нам імгненна выпускаць і падаўжаць сертыфікаты Let's Encrypt. Вельмі спрошчана гэта працуе так:
-
Як толькі мы бачым хаця б адзін HTTPS-запыт для дамена нашага кліента без сертыфіката (або з пратэрмінаваным сертыфікатам), знешняя нода, якая прыняла запыт, паведамляе аб гэтым унутранаму цэнтру сертыфікацыі.
-
Калі карыстач не забараніў выдачу Let's Encrypt, цэнтр сертыфікацыі фармуе CSR, атрымлівае ў LE токен пацверджання і рассылае яго на ўсе франты па шыфраваным канале. Цяпер любая нода можа пацвердзіць які валідуе запыт ад LE.
-
Праз некалькі імгненняў мы атрымаем карэктны сертыфікат і прыватны ключ і сапраўды гэтак жа разашлем франтам. Ізноў жа без перазагрузкі дэманаў
-
За 7 дзён да даты экспірацыі ініцыюецца працэдура пераатрымання сертыфіката
Прама зараз мы ў рэалтайме ратуем 350к сертыфікатаў цалкам празрыста для карыстачоў.
У наступных артыкулах цыклу распавяду пра іншыя асаблівасці рэалтаймавай апрацоўкі вялікага вэб-трафіку - напрыклад, пра аналіз RTT па няпоўных дадзеных для паляпшэння якасці абслугоўвання транзітных кліентаў і наогул аб абароне транзітнага трафіку ад тэрабітных нападаў, аб дастаўцы і агрэгацыі інфармацыі аб трафіку, аб WAF, амаль неабмежаванай CDN і мностве механізмаў аптымізацыі аддачы кантэнту.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Пра што вы хацелі б даведацца ў першую чаргу?
-
14,3%Алгарытмах кластэрызацыі і аналізу якасці вэб-трафіку<3
-
33,3%Унутранасцях балансараў DDoS-Guard7
-
9,5%Абароне транзітнага L3/L4-трафіку2
-
0,0%Абараніце вэб-сайтаў на транзітным трафіке0
-
14,3%Web Application Firewall3
-
28,6%Абараніце ад парсінгу і скліквання6
Прагаласаваў 21 карыстальнік. Устрымаліся 6 карыстальнікаў.
Крыніца: habr.com