Web HighLoad - како управуваме со сообраќајот за десетици илјади домени

Легитимниот сообраќај на мрежата DDoS-Guard неодамна надмина сто гигабити во секунда. Во моментов, 50% од целиот наш сообраќај е генериран од клиентски веб-услуги. Ова се многу десетици илјади домени, многу различни и во повеќето случаи бараат индивидуален пристап.

Подолу е прикажано како управуваме со предните јазли и издаваме SSL сертификати за стотици илјади локации.

Поставувањето фронт за една локација, дури и за многу голема, е лесно. Земаме nginx или haproxy или lighttpd, го конфигурираме според водичите и забораваме на тоа. Ако треба да промениме нешто, правиме повторно вчитување и повторно забораваме.

Сè се менува кога обработувате голем обем на сообраќај во лет, ја оценувате легитимноста на барањата, ја компресирате и кеширате корисничката содржина и истовремено ги менувате параметрите неколку пати во секунда. Корисникот сака да го види резултатот на сите надворешни јазли веднаш откако ќе ги промени поставките во неговата лична сметка. Корисникот може да преземе и неколку илјади (а понекогаш и десетици илјади) домени со индивидуални параметри за обработка на сообраќајот преку API. Сето ова треба веднаш да функционира и во Америка, и во Европа и во Азија - задачата не е најтривијална, имајќи предвид дека само во Москва има неколку физички одвоени јазли за филтрирање.

Зошто има многу големи сигурни јазли низ светот?

• Квалитет на услугата за сообраќај на клиенти - барањата од САД треба да се обработуваат во САД (вклучувајќи напади, парсирање и други аномалии), а не да се влечат во Москва или Европа, што непредвидливо го зголемува доцнењето на обработката.

• Сообраќајот за напади мора да биде локализиран - транзитните оператори можат да се деградираат за време на нападите, чиј волумен често надминува 1 Tbps. Транспортирањето на нападниот сообраќај преку трансатлантски или трансазиски врски не е добра идеја. Имавме реални случаи кога операторите на Tier-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 илјади сертификати во реално време, целосно транспарентни за корисниците.

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

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

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

• 14,3%Алгоритми за кластерирање и анализа на квалитетот на веб сообраќајот<3

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

• 9,5%Заштита на транзитниот сообраќај L3/L4

• 0,0%Заштита на веб-страниците на транзитен сообраќај0

• 14,3%Заштитен ѕид на веб-апликации3

• 28,6%Заштита од парсирање и кликнување6

Гласале 21 корисник. Воздржани се 6 корисници.

Извор: www.habr.com