🥇Веб-HighLoad — как управляваме трафика на десетки хиляди домейни

Легитимният трафик в мрежата на 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 000 сертификата напълно прозрачно за потребителите.

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

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