Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

DDoS-Guard şəbəkəsində qanuni trafik bu yaxınlarda saniyədə yüz giqabiti keçib. Hazırda bütün trafikimizin 50%-i müştəri veb xidmətləri tərəfindən yaradılır. Bunlar çox fərqli və əksər hallarda fərdi yanaşma tələb edən on minlərlə domendir.

Aşağıda ön qovşaqları necə idarə etdiyimiz və yüz minlərlə sayt üçün SSL sertifikatları verəcəyik.

Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

Bir sayt üçün, hətta çox böyük bir sayt üçün cəbhə qurmaq asandır. Nginx və ya haproxy və ya lighttpd götürürük, təlimatlara uyğun olaraq konfiqurasiya edirik və bunu unuduruq. Əgər nəyisə dəyişmək lazımdırsa, yenidən yükləyirik və yenidən unuduruq.

Böyük həcmli trafiki tez emal etdikdə, sorğuların legitimliyini qiymətləndirdikdə, istifadəçi məzmununu sıxışdırıb keş etdikdə və eyni zamanda parametrləri saniyədə bir neçə dəfə dəyişdikdə hər şey dəyişir. İstifadəçi şəxsi hesabında parametrləri dəyişdikdən dərhal sonra bütün xarici qovşaqlarda nəticəni görmək istəyir. İstifadəçi həmçinin API vasitəsilə fərdi trafikin emal parametrləri ilə bir neçə min (və bəzən on minlərlə) domeni yükləyə bilər. Bütün bunlar dərhal Amerikada, Avropada və Asiyada işləməlidir - təkcə Moskvada bir neçə fiziki cəhətdən ayrılmış filtrasiya qovşağının olduğunu nəzərə alsaq, vəzifə ən əhəmiyyətsiz deyil.

Niyə dünyada çoxlu böyük etibarlı qovşaqlar var?

  • Müştəri trafiki üçün xidmət keyfiyyəti - ABŞ-dan gələn sorğular ABŞ-da (hücumlar, təhlil və digər anomaliyalar da daxil olmaqla) emal edilməli və Moskva və ya Avropaya çatdırılmamalı, emal gecikməsini gözlənilməz şəkildə artırmalıdır.

  • Hücum trafiki lokallaşdırılmalıdır - həcmi tez-tez 1Tbps-dən çox olan hücumlar zamanı tranzit operatorları pisləşə bilər. Hücum trafikinin transatlantik və ya transasiya keçidləri üzərində daşınması yaxşı fikir deyil. Tier-1 operatorlarının: "Aldığınız hücumların həcmi bizim üçün təhlükəlidir" dedikdə real hallarımız oldu. Buna görə də daxil olan axınları mənbələrinə mümkün qədər yaxın qəbul edirik.

  • Xidmətin davamlılığı üçün ciddi tələblər - təmizlik mərkəzləri nə bir-birindən, nə də sürətlə dəyişən dünyamızda yerli hadisələrdən asılı olmamalıdır. Bir həftə ərzində MMTS-11-un bütün 9 mərtəbəsinin enerjisini kəsmisiniz? - problem deyil. Bu xüsusi məkanda fiziki əlaqəsi olmayan heç bir müştəri əziyyət çəkməyəcək və heç bir halda veb xidmətləri əziyyət çəkməyəcək.

Bütün bunları necə idarə etmək olar?

Xidmət konfiqurasiyaları mümkün qədər tez (ideal olaraq dərhal) bütün ön qovşaqlara paylanmalıdır. Siz sadəcə mətn konfiqurasiyalarını götürə və yenidən qura və hər dəyişiklikdə demonları yenidən işə sala bilməzsiniz - eyni nginx prosesləri daha bir neçə dəqiqə (və ya uzun veb-soket seansları olarsa, bəlkə də saatlar) dayandırır (işçi bağlanır).

Nginx konfiqurasiyasını yenidən yükləyərkən aşağıdakı şəkil olduqca normaldır:

Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

Yaddaşdan istifadə haqqında:

Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

Köhnə işçilər yaddaşı, o cümlədən əlaqələrin sayından xətti asılı olmayan yaddaşı yeyirlər - bu normaldır. Müştəri əlaqələri bağlandıqda, bu yaddaş boşalacaq.

Nginx yeni başlayanda niyə bu problem deyildi? Nə HTTP/2, nə WebSocket, nə də kütləvi uzun müddət canlı bağlantılar yox idi. Veb trafikimizin 70%-i HTTP/2-dir ki, bu da çox uzun bağlantılar deməkdir.

Həll sadədir - nginx istifadə etməyin, mətn faylları əsasında cəbhələri idarə etməyin və əlbəttə ki, transpasifik kanallar üzərində sıxılmış mətn konfiqurasiyalarını göndərməyin. Kanallar, əlbəttə ki, zəmanətlidir və qorunur, lakin bu, onları daha az transkontinental etmir.

Bizim öz ön server balanslaşdırıcımız var, onun daxili hissələri haqqında növbəti məqalələrdə danışacağam. Onun edə biləcəyi əsas şey, saniyədə minlərlə konfiqurasiya dəyişikliyini yenidən başlatmadan, yenidən yükləmədən, yaddaş istehlakında qəfil artım olmadan və bütün bunlar olmadan tətbiq etməkdir. Bu, məsələn, Erlang-da Hot Code Reload-a çox bənzəyir. Məlumat coğrafi olaraq paylanmış açar-dəyər verilənlər bazasında saxlanılır və dərhal ön ötürücülər tərəfindən oxunur. Bunlar. siz SSL sertifikatını veb-interfeys və ya API vasitəsilə Moskvada yükləyirsiniz və bir neçə saniyədən sonra o, Los-Ancelesdəki təmizlik mərkəzimizə getməyə hazırdır. Birdən dünya müharibəsi baş verərsə və internet bütün dünyada yox olarsa, Los-Anceles-Amsterdam-Moskva, Moskva-Amsterdam-Honq-Konq kimi xüsusi kanallardan biri olan kimi qovşaqlarımız avtonom işləməyə və bölünmüş beyni təmir etməyə davam edəcək. Los-Los əlçatan olur. Anceles və ya GRE ehtiyat nüsxələrindən ən azı biri.

Eyni mexanizm bizə Let's Encrypt sertifikatlarını dərhal buraxmağa və yeniləməyə imkan verir. Çox sadə şəkildə belə işləyir:

  1. Müştərimizin domeni üçün sertifikatsız (və ya müddəti bitmiş sertifikatla) ən azı bir HTTPS sorğusunu görən kimi sorğunu qəbul edən xarici qovşaq bu barədə daxili sertifikatlaşdırma orqanına məlumat verir.

    Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

  2. İstifadəçi Let's Encrypt-in buraxılmasını qadağan etməyibsə, sertifikatlaşdırma orqanı KSM yaradır, LE-dən təsdiq nişanı alır və onu şifrələnmiş kanal vasitəsilə bütün cəbhələrə göndərir. İndi istənilən qovşaq LE-dən təsdiqləmə sorğusunu təsdiq edə bilər.

    Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

  3. Bir neçə dəqiqədən sonra düzgün sertifikatı və şəxsi açarı alacaq və eyni şəkildə cəbhələrə göndərəcəyik. Yenə demonları yenidən işə salmadan

    Web HighLoad - on minlərlə domenin trafikini necə idarə edirik

  4. Müddət bitməsinə 7 gün qalmış sertifikatın yenidən alınması proseduruna başlanılır

Hal-hazırda biz real vaxt rejimində 350k sertifikatı istifadəçilər üçün tamamilə şəffaf şəkildə döndəririk.

Serialın növbəti məqalələrində mən böyük veb-trafikin real vaxt rejimində emalının digər xüsusiyyətləri haqqında danışacağam - məsələn, tranzit müştərilər üçün xidmət keyfiyyətini yaxşılaşdırmaq üçün natamam məlumatlardan istifadə edərək RTT-nin təhlili və ümumiyyətlə tranzit trafikinin qorunması haqqında terabit hücumları, trafik məlumatlarının çatdırılması və yığılması haqqında, WAF haqqında, demək olar ki, qeyri-məhdud CDN və məzmun çatdırılmasını optimallaşdırmaq üçün bir çox mexanizmlər.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

İlk olaraq nəyi bilmək istərdiniz?

  • 14,3%Veb trafikinin keyfiyyətinin klasterləşdirilməsi və təhlili üçün alqoritmlər<3

  • 33,3%DDoS-Guard7 balanslaşdırıcılarının daxili hissələri

  • 9,5%Tranzit L3/L4 trafikinin mühafizəsi2

  • 0,0%Tranzit trafikdə veb saytların qorunması0

  • 14,3%Veb Tətbiq Firewall 3

  • 28,6%Təhlildən və klikdən qorunma6

21 istifadəçi səs verib. 6 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com

Добавить комментарий