DDoS-Guard tarmog'idagi qonuniy trafik yaqinda soniyasiga yuz gigabitdan oshdi. Hozirda barcha trafikimizning 50% mijozning veb-xizmatlari tomonidan yaratilgan. Bular o'n minglab domenlar bo'lib, ular juda farq qiladi va ko'p hollarda individual yondashuvni talab qiladi.
Kesim ostida biz oldingi tugunlarni qanday boshqarishimiz va yuz minglab saytlar uchun SSL sertifikatlarini chiqarishimiz keltirilgan.
Bitta sayt uchun old qismni o'rnatish, hatto juda katta, oson. Biz nginx yoki haproxy yoki lighttpd ni olamiz, uni ko'rsatmalarga muvofiq sozlaymiz va bu haqda unutamiz. Agar biror narsani o'zgartirishimiz kerak bo'lsa, biz qayta yuklaymiz va yana unutamiz.
Katta hajmdagi trafikni tezda qayta ishlash, so'rovlarning qonuniyligini baholash, foydalanuvchi tarkibini siqish va keshlash va shu bilan birga parametrlarni soniyada bir necha marta o'zgartirishda hamma narsa o'zgaradi. Foydalanuvchi shaxsiy hisobidagi sozlamalarni o'zgartirgandan so'ng darhol barcha tashqi tugunlarda natijani ko'rishni xohlaydi. Shuningdek, foydalanuvchi API orqali trafikni qayta ishlashning individual parametrlari bilan bir necha ming (va baʼzan oʻn minglab) domenlarni yuklab olishi mumkin. Bularning barchasi darhol Amerikada, Evropada va Osiyoda ishlashi kerak - bu vazifa eng ahamiyatsiz emas, chunki faqat Moskvada bir nechta jismoniy ajratilgan filtrlash tugunlari mavjud.
Nima uchun dunyo bo'ylab ko'plab yirik ishonchli tugunlar mavjud?
-
Mijoz trafigiga xizmat ko'rsatish sifati - AQShdan so'rovlar AQShda ko'rib chiqilishi kerak (shu jumladan hujumlar, tahlil qilish va boshqa anomaliyalar uchun) va Moskva yoki Evropaga yuborilmasligi, ishlov berish kechikishini oldindan aytib bo'lmaydigan darajada oshiradi.
-
Hujum trafigini mahalliylashtirish kerak - tranzit operatorlari hujumlar paytida yomonlashishi mumkin, ularning hajmi ko'pincha 1Tbps dan oshadi. Hujum trafigini transatlantik yoki transosiyo havolalari orqali tashish yaxshi fikr emas. Bizda 1-darajali operatorlar: "Siz qabul qilayotgan hujumlar hajmi biz uchun xavflidir" degan haqiqiy holatlar bo'lgan. Shuning uchun biz kiruvchi oqimlarni iloji boricha manbalariga yaqinroq qabul qilamiz.
-
Xizmatning uzluksizligi uchun qat'iy talablar - tozalash markazlari bizning tez o'zgaruvchan dunyomizdagi bir-biriga yoki mahalliy voqealarga bog'liq bo'lmasligi kerak. MMTS-11 ning barcha 9 qavatiga bir hafta davomida elektr energiyasini uzib qo'ydingizmi? - hammasi joyida. Ushbu aniq joyda jismoniy aloqaga ega bo'lmagan bitta mijoz zarar ko'rmaydi va veb-xizmatlar hech qanday sharoitda zarar ko'rmaydi.
Bularning barchasini qanday boshqarish kerak?
Xizmat konfiguratsiyasi barcha oldingi tugunlarga imkon qadar tezroq (ideal bir zumda) tarqatilishi kerak. Siz shunchaki matn konfiguratsiyasini olib, qayta tiklay olmaysiz va har bir o'zgarishda demonlarni qayta ishga tushira olmaysiz - xuddi shu nginx jarayonlarni yana bir necha daqiqa (yoki uzoq veb-soket seanslari mavjud bo'lsa, soatlab) yopib qo'yadi (ishchi yopiladi).
Nginx konfiguratsiyasini qayta yuklashda quyidagi rasm juda oddiy:
Xotiradan foydalanish bo'yicha:
Qadimgi ishchilar xotirani, shu jumladan ulanishlar soniga chiziqli bog'liq bo'lmagan xotirani iste'mol qiladilar - bu normal holat. Mijoz ulanishlari yopilganda, bu xotira bo'shatiladi.
Nega nginx endigina boshlanganida bu muammo emas edi? Hech qanday HTTP/2, WebSocket, uzoq davom etadigan katta ulanishlar yo'q edi. Veb-trafikimizning 70% HTTP/2 ni tashkil qiladi, bu juda uzoq ulanishlarni bildiradi.
Yechim oddiy - nginx-dan foydalanmang, matnli fayllarga asoslangan frontlarni boshqarmang va, albatta, transpasifik kanallar orqali ziplangan matn konfiguratsiyalarini yubormang. Kanallar, albatta, kafolatlangan va himoyalangan, ammo bu ularni transkontinental qilmaydi.
Bizda o'z old server-balansatorimiz bor, uning ichki qismlari haqida men keyingi maqolalarda gaplashaman. U qila oladigan asosiy narsa - sekundiga minglab konfiguratsiya o'zgarishlarini qayta ishga tushirmasdan, qayta yuklamasdan, xotira sarfini to'satdan ko'paytirmasdan va hokazo. Bu Hot Code Reload-ga juda o'xshaydi, masalan, Erlang-da. Ma'lumotlar geo taqsimlangan kalit-qiymat ma'lumotlar bazasida saqlanadi va oldingi aktuatorlar tomonidan darhol o'qiladi. Bular. siz Moskvadagi veb-interfeys yoki API orqali SSL sertifikatini yuklaysiz va bir necha soniya ichida u Los-Anjelesdagi tozalash markazimizga borishga tayyor. Agar to'satdan jahon urushi ro'y bersa va butun dunyo bo'ylab Internet yo'qolsa, bizning tugunlarimiz Los-Anjeles-Amsterdam-Moskva, Moskva-Amsterdam-Gonkong- maxsus kanallaridan biri bilanoq avtonom ishlashda davom etadi va bo'lingan miyani tuzatadi. Los-Los mavjud bo'ladi. Anjeles yoki GRE zaxira qoplamalaridan kamida bittasi.
Xuddi shu mexanizm bizga Let’s Encrypt sertifikatlarini bir zumda chiqarish va yangilash imkonini beradi. Juda sodda tarzda ishlaydi:
-
Mijozning domeniga sertifikatsiz (yoki sertifikati muddati o‘tgan) kamida bitta HTTPS so‘rovini ko‘rishimiz bilanoq, so‘rovni qabul qilgan tashqi tugun bu haqda ichki sertifikatlashtirish organiga xabar beradi.
-
Agar foydalanuvchi Let’s Encrypt chiqarilishini taqiqlamagan bo‘lsa, sertifikatlashtirish organi CSR ishlab chiqaradi, LE dan tasdiqlash tokenini oladi va uni shifrlangan kanal orqali barcha jabhalarga yuboradi. Endi har qanday tugun LE dan tasdiqlash so'rovini tasdiqlashi mumkin.
-
Bir necha daqiqadan so'ng biz to'g'ri sertifikat va shaxsiy kalitni olamiz va uni xuddi shu tarzda frontlarga yuboramiz. Shunga qaramay, demonlarni qayta ishga tushirmasdan
-
Yaroqlilik muddati tugashidan 7 kun oldin sertifikatni qayta olish tartibi boshlanadi
Hozir biz real vaqt rejimida 350 ming sertifikatni aylantirmoqdamiz, bu foydalanuvchilar uchun mutlaqo shaffof.
Seriyaning keyingi maqolalarida men katta veb-trafikni real vaqt rejimida qayta ishlashning boshqa xususiyatlari haqida gapiraman - masalan, tranzit mijozlarga xizmat ko'rsatish sifatini yaxshilash uchun to'liq bo'lmagan ma'lumotlardan foydalangan holda RTTni tahlil qilish va umuman olganda tranzit trafigini himoya qilish haqida. terabit hujumlari, trafik ma'lumotlarini etkazib berish va yig'ish haqida, WAF haqida, deyarli cheksiz CDN va kontentni etkazib berishni optimallashtirish uchun ko'plab mexanizmlar.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Avval nimani bilishni xohlaysiz?
-
14,3%Veb-trafik sifatini klasterlash va tahlil qilish algoritmlari<3
-
33,3%DDoS-Guard7 balanslagichlarining ichki qismlari
-
9,5%L3/L4 tranzit trafigini himoya qilish2
-
0,0%Tranzit trafikda veb-saytlarni himoya qilish0
-
14,3%Veb-ilovaning xavfsizlik devori 3
-
28,6%Tahlil qilish va bosishdan himoya qilish6
21 foydalanuvchi ovoz berdi. 6 nafar foydalanuvchi betaraf qoldi.
Manba: www.habr.com