Web HighLoad - как управляваме трафика за десетки хиляди домейни

Легитимният трафик в мрежата DDoS-Guard наскоро надхвърли сто гигабита в секунда. В момента 50% от целия ни трафик се генерира от клиентски уеб услуги. Това са много десетки хиляди домейни, много различни и в повечето случаи изискващи индивидуален подход.

По-долу е как управляваме предни възли и издаваме SSL сертификати за стотици хиляди сайтове.

Създаването на фронт за един сайт, дори много голям, е лесно. Взимаме nginx или haproxy или lighttpd, конфигурираме го според ръководствата и забравяме за него. Ако трябва да променим нещо, правим презареждане и забравяме отново.

Всичко се променя, когато обработвате големи обеми трафик в движение, оценявате легитимността на заявките, компресирате и кеширате потребителско съдържание и в същото време променяте параметрите няколко пъти в секунда. Потребителят иска да види резултата на всички външни възли веднага след като промени настройките в личния си акаунт. Потребителят може също така да изтегли няколко хиляди (а понякога и десетки хиляди) домейни с индивидуални параметри за обработка на трафика чрез API. Всичко това трябва да работи незабавно и в Америка, и в Европа, и в Азия - задачата не е от най-тривиалните, като се има предвид, че само в Москва има няколко физически разделени възли на филтриране.

Защо има много големи надеждни възли по света?

• Качество на услугата за клиентски трафик - заявките от САЩ трябва да се обработват в САЩ (включително за атаки, парсинг и други аномалии), а не да се изтеглят към Москва или Европа, което непредвидимо увеличава забавянето на обработката.

• Трафикът от атаки трябва да бъде локализиран - транзитните оператори могат да се влошат по време на атаки, чийто обем често надвишава 1Tbps. Транспортирането на атакуващ трафик през трансатлантически или трансазиатски връзки не е добра идея. Имахме реални случаи, когато оператори от ниво 1 казаха: „Обемът на атаките, които получавате, е опасен за нас.“ Ето защо приемаме входящи потоци възможно най-близо до техните източници.

• Строги изисквания за непрекъснатост на обслужването - центровете за почистване не трябва да зависят нито един от друг, нито от местни събития в нашия бързо променящ се свят. Спряхте ли тока на всичките 11 етажа на ММТС-9 за една седмица? - няма проблем. Нито един клиент, който няма физическа връзка на това конкретно място, няма да пострада и уеб услугите няма да пострадат при никакви обстоятелства.

Как да управлявате всичко това?

Сервизните конфигурации трябва да бъдат разпространени до всички предни възли възможно най-бързо (в идеалния случай незабавно). Не можете просто да вземете и изградите отново текстови конфигурации и да рестартирате демоните при всяка промяна - същият nginx държи процесите да се изключват (работното изключване) за още няколко минути (или може би часове, ако има дълги уебсокет сесии).

При презареждане на конфигурацията на nginx следната картина е съвсем нормална:

Относно използването на паметта:

Старите работници изяждат памет, включително памет, която не зависи линейно от броя на връзките - това е нормално. Когато клиентските връзки са затворени, тази памет ще бъде освободена.

Защо това не беше проблем, когато nginx едва започваше? Нямаше HTTP/2, нямаше WebSocket, нямаше масивни дълги поддържащи връзки. 70% от нашия уеб трафик е HTTP/2, което означава много дълги връзки.

Решението е просто - не използвайте nginx, не управлявайте фронтове въз основа на текстови файлове и със сигурност не изпращайте компресирани текстови конфигурации по транстихоокеански канали. Каналите, разбира се, са гарантирани и запазени, но това не ги прави по-малко трансконтинентални.

Разполагаме със собствен преден сървър-балансьор, за вътрешността на който ще говоря в следващите статии. Основното, което може да прави, е да прилага хиляди промени в конфигурацията в секунда в движение, без рестартиране, презареждане, внезапно увеличаване на потреблението на памет и всичко останало. Това е много подобно на Hot Code Reload, например в Erlang. Данните се съхраняват в гео-разпределена база данни с ключ-стойност и се четат незабавно от предните задвижващи механизми. Тези. качвате SSL сертификата чрез уеб интерфейса или API в Москва и след няколко секунди той е готов да отиде в нашия център за почистване в Лос Анджелис. Ако внезапно се случи световна война и интернет изчезне по целия свят, нашите възли ще продължат да работят автономно и ще поправят разделения мозък веднага щом един от специалните канали Лос Анджелис-Амстердам-Москва, Москва-Амстердам-Хонконг- Лос-Лос става наличен Анджелис или поне едно от резервните наслагвания на GRE.

Същият този механизъм ни позволява незабавно да издаваме и подновяваме Let's Encrypt сертификати. Много просто работи по следния начин:

1. Веднага щом видим поне една HTTPS заявка за домейна на нашия клиент без сертификат (или с изтекъл сертификат), външният възел, приел заявката, докладва това на вътрешния сертифициращ орган.

   

2. Ако потребителят не е забранил издаването на Let's Encrypt, сертифициращият орган генерира CSR, получава токен за потвърждение от LE и го изпраща до всички фронтове по криптиран канал. Сега всеки възел може да потвърди валидираща заявка от LE.

   

3. След няколко минути ще получим правилния сертификат и частния ключ и ще ги изпратим на фронтовете по същия начин. Отново без рестартиране на демоните

   

4. 7 дни преди изтичане на срока на валидност се открива процедура за повторно получаване на сертификата

В момента ротираме 350 XNUMX сертификата в реално време, напълно прозрачни за потребителите.

В следващите статии от поредицата ще говоря за други характеристики на обработката в реално време на голям уеб трафик - например за анализиране на RTT с помощта на непълни данни за подобряване на качеството на услугата за транзитни клиенти и като цяло за защита на транзитния трафик от терабитови атаки, за доставката и агрегацията на информация за трафика, за WAF, почти неограничен CDN и много механизми за оптимизиране на доставката на съдържание.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Какво бихте искали да знаете първо?

• 14,3%Алгоритми за групиране и анализ на качеството на уеб трафика<3

• 33,3%Вътрешни елементи на DDoS-Guard7 балансьори

• 9,5%Защита на транзитния L3/L4 трафик2

• 0,0%Защита на уебсайтове при транзитен трафик0

• 14,3%Защитна стена за уеб приложения 3

• 28,6%Защита срещу анализиране и кликване6

21 потребители гласуваха. 6 потребители се въздържаха.

Източник: www.habr.com