Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

تجاوزت حركة المرور المشروعة على شبكة DDoS-Guard مؤخرًا مائة جيجابت في الثانية. في الوقت الحالي، يتم إنشاء 50% من إجمالي حركة المرور لدينا عن طريق خدمات الويب الخاصة بالعملاء. وهي عبارة عن عشرات الآلاف من المجالات، وهي مختلفة جدًا وتتطلب في معظم الحالات نهجًا فرديًا.

يوجد أدناه كيفية إدارة العقد الأمامية وإصدار شهادات SSL لمئات الآلاف من المواقع.

Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

يعد إعداد واجهة لموقع واحد، حتى لو كان كبيرًا جدًا، أمرًا سهلاً. نحن نأخذ nginx أو haproxy أو lighttpd ونقوم بتكوينه وفقًا للأدلة وننسى الأمر. إذا أردنا تغيير شيء ما، فإننا نقوم بإعادة التحميل وننسى مرة أخرى.

يتغير كل شيء عند معالجة كميات كبيرة من حركة المرور بسرعة، وتقييم شرعية الطلبات، وضغط محتوى المستخدم وتخزينه مؤقتًا، وفي نفس الوقت تغيير المعلمات عدة مرات في الثانية. يريد المستخدم رؤية النتيجة على جميع العقد الخارجية فور قيامه بتغيير الإعدادات في حسابه الشخصي. يمكن للمستخدم أيضًا تنزيل عدة آلاف (وأحيانًا عشرات الآلاف) من النطاقات باستخدام معلمات معالجة حركة المرور الفردية عبر واجهة برمجة التطبيقات. كل هذا يجب أن يعمل أيضًا على الفور في أمريكا وأوروبا وآسيا - فالمهمة ليست تافهة، مع الأخذ في الاعتبار أنه يوجد في موسكو وحدها العديد من نقاط الترشيح المنفصلة ماديًا.

لماذا يوجد العديد من العقد الكبيرة الموثوقة حول العالم؟

  • جودة الخدمة لحركة مرور العملاء - يجب معالجة الطلبات الواردة من الولايات المتحدة في الولايات المتحدة (بما في ذلك الهجمات والتحليل وغيرها من الحالات الشاذة)، وعدم سحبها إلى موسكو أو أوروبا، مما يؤدي إلى زيادة تأخير المعالجة بشكل غير متوقع.

  • يجب أن تكون حركة مرور الهجوم محلية - يمكن أن يتدهور مشغلو النقل أثناء الهجمات، والتي يتجاوز حجمها غالبًا 1 تيرابت في الثانية. لا يعد نقل حركة مرور الهجوم عبر الروابط عبر المحيط الأطلسي أو عبر آسيا فكرة جيدة. كانت لدينا حالات حقيقية عندما قال مشغلو المستوى الأول: "إن حجم الهجمات التي تتلقاها يمثل خطورة بالنسبة لنا". ولهذا السبب نقبل التدفقات الواردة في أقرب مكان ممكن من مصادرها.

  • متطلبات صارمة لاستمرارية الخدمة - يجب ألا تعتمد مراكز التنظيف على بعضها البعض أو على الأحداث المحلية في عالمنا سريع التغير. هل قطعت الكهرباء عن جميع الطوابق الـ11 في MMTS-9 لمدة أسبوع؟ - لا مشكلة. لن يعاني أي عميل ليس لديه اتصال فعلي في هذا الموقع المحدد، ولن تتأثر خدمات الويب تحت أي ظرف من الظروف.

كيفية إدارة كل هذا؟

يجب توزيع تكوينات الخدمة على جميع العقد الأمامية في أسرع وقت ممكن (من الأفضل أن تكون على الفور). لا يمكنك فقط أخذ تكوينات النص وإعادة بنائها وإعادة تشغيل البرامج الشيطانية عند كل تغيير - فنفس nginx يحافظ على إيقاف العمليات (إيقاف تشغيل العامل) لبضع دقائق إضافية (أو ربما ساعات إذا كانت هناك جلسات websocket طويلة).

عند إعادة تحميل تكوين nginx، تكون الصورة التالية طبيعية تمامًا:

Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

في استخدام الذاكرة:

Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

يلتهم العمال القدامى الذاكرة، بما في ذلك الذاكرة التي لا تعتمد خطيًا على عدد الاتصالات - وهذا أمر طبيعي. عند إغلاق اتصالات العميل، سيتم تحرير هذه الذاكرة.

لماذا لم تكن هذه مشكلة عندما كان nginx قد بدأ للتو؟ لم يكن هناك HTTP/2، ولا WebSocket، ولا اتصالات ضخمة طويلة الأمد. 70% من حركة المرور على الويب لدينا هي HTTP/2، وهو ما يعني اتصالات طويلة جدًا.

الحل بسيط - لا تستخدم nginx، ولا تدير الواجهات بناءً على الملفات النصية، وبالتأكيد لا ترسل تكوينات نصية مضغوطة عبر قنوات عبر المحيط الهادئ. القنوات، بالطبع، مضمونة ومحفوظة، لكن هذا لا يجعلها أقل عابرة للقارات.

لدينا موازن الخادم الأمامي الخاص بنا، والذي سأتحدث عنه في المقالات التالية. الشيء الرئيسي الذي يمكن أن يفعله هو تطبيق آلاف تغييرات التكوين في الثانية بشكل سريع، دون إعادة التشغيل، أو إعادة التحميل، أو الزيادات المفاجئة في استهلاك الذاكرة، وكل ذلك. وهذا مشابه جدًا لـ Hot Code Reload، على سبيل المثال في Erlang. يتم تخزين البيانات في قاعدة بيانات ذات قيمة رئيسية موزعة جغرافيًا ويتم قراءتها على الفور بواسطة المحركات الأمامية. أولئك. تقوم بتحميل شهادة SSL عبر واجهة الويب أو واجهة برمجة التطبيقات (API) في موسكو، وفي بضع ثوانٍ تصبح جاهزة للذهاب إلى مركز التنظيف الخاص بنا في لوس أنجلوس. إذا حدثت حرب عالمية فجأة واختفت الإنترنت في جميع أنحاء العالم، فستستمر عقدنا في العمل بشكل مستقل وإصلاح الدماغ المنقسم بمجرد إحدى القنوات المخصصة لوس أنجلوس-أمستردام-موسكو، موسكو-أمستردام-هونج كونج- تصبح Los-Los متاحة في لوس أنجلوس أو على الأقل واحدة من تراكبات النسخ الاحتياطي لـ GRE.

تتيح لنا هذه الآلية نفسها إصدار شهادات Let's Encrypt وتجديدها على الفور. بكل بساطة يعمل مثل هذا:

  1. بمجرد أن نرى طلب HTTPS واحدًا على الأقل لمجال عميلنا بدون شهادة (أو بشهادة منتهية الصلاحية)، تقوم العقدة الخارجية التي قبلت الطلب بإبلاغ المرجع المصدق الداخلي بذلك.

    Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

  2. إذا لم يحظر المستخدم إصدار Let's Encrypt، فإن المرجع المصدق يقوم بإنشاء CSR، ويتلقى رمز تأكيد مميز من LE ويرسله إلى جميع الجبهات عبر قناة مشفرة. الآن يمكن لأي عقدة تأكيد طلب التحقق من LE.

    Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

  3. وبعد لحظات سنتسلم الشهادة الصحيحة والمفتاح الخاص ونرسلهما إلى الجبهات بنفس الطريقة. مرة أخرى، دون إعادة تشغيل الشياطين

    Web HighLoad - كيف ندير حركة مرور عشرات الآلاف من المجالات

  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

إضافة تعليق