Легітимний трафік у мережі 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