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

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

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

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

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

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

Качеството на обслужване на клиентския трафик — заявките от САЩ трябва да се обработват именно в САЩ (включително по отношение на атаки, парсинг и други аномалии), а не да се пренасят в Москва или Европа, непредсказуемо увеличавайки закъснението в обработката.
Атакуващият трафик трябва да се локализира — транзитните оператори могат да се деградират по време на атаки, чийто обем често надвишава 1Тbps. Транспортироването на атакуващ трафик по трансатлантически или трансазиатски линкове — не е най-добрата идея. Имали сме реални случаи, когато Tier-1 оператори казваха: «Обемите атаки, които приемате, са опасни за нас». Именно затова приемаме входящите потоци колкото се може по-близо до източниците им.
Строгите изисквания за непрекъснатост на услугите - центровете за почистване не трябва да зависят един от друг или от местните събития на нашия бързо променящ се свят. Изключили са всички 11 етажа на ММТС-9 за една седмица? - Няма значение. Няма да пострада нито един клиент, който няма физическо включване точно в тази локация, а уеб услугите няма да пострадат при никакви обстоятелства.

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

Конфигурациите на услугите трябва да се разпространяват възможно най-бързо (в идеалния случай незабавно) на всички фронт нодовe. Не може просто да взимате и да пренастройвате текстовите конфигурации и да рестартирате демоните при всяка промяна - същият 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 и множество механизми за оптимизация на предаване на съдържанието.

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