عزل حمل العمل باستخدام التقسيم العشوائي

تستضيف اليوم Amazon Route 53 العديد من أكبر شركات الأعمال العالمية وأكثر المواقع الإلكترونية شيوعًا، رغم أن بداياتها كانت أكثر تواضعًا.

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

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

في الوقت الذي أنشأنا فيه Amazon Route 53، كانت حالة الأعمال الفنية الخاصة بدفاع DNS تعتبر أجهزة شبكات مخصصة يمكن أن تستخدم مجموعة متنوعة من الحيل من أجل «تنقيح» حركة المرور بمعدل مرتفع جدًا. كان لدينا العديد من هذه الأجهزة في Amazon لخدمات DNS الداخلية الموجودة، كما أننا تحدثنا مع بائعي الأجهزة حول ما هو المتوفر أيضًا. لقد اكتشفنا أن شراء أجهزة كافية لتغطية كل نطاق واحد من Route 53 سيكلف مئات الملايين من الدولارات كما إلى أننا نحتاج إضافة أشهر إلى جدولنا لتقديمها وتثبيتها وتشغيلها. وهذا لم يتماشى مع الحاجة الملحة لخططنا أو مع جهدنا في أن نكون مقتصدين، لذا لم نضع في الاعتبار على محمل الجد. لقد كنا بحاجة إلى إيجاد طريقة لننفق بها فقط على الموارد التي تدافع عن النطاقات التي تواجه هجومًا بالفعل. وتحولنا إلى المبدأ القديم، ألا وهو أن الحاجة أم الاختراع. وكانت حاجتنا الضرورية تتمثل في سرعة إنشاء خدمة DNS لوقت تشغيل بنسبة 100 % ذات طراز عالمي باستخدام قدر معقول من الموارد. وكان اختراعنا يتمثل في التقسيم العشوائي.

التقسيم العشوائي بسيط، لكنه قوي. فهو حتى أكثر قوة مما تخيلناه في البداية. لقد استخدمناه مرارًا وتكرارًا، حتى أصبح نمطًا أساسيًا يجعل من الممكن لـ AWS تقديم خدمات فعالة من حيث التكلفة ومتعددة المستأجرين مما يمنح كل عميل تجربة مستأجر واحد.

لعرض كيفية عمل التقسيم العشوائي، يجب بداية مراعاة كيف يمكن للنظام أن يكون مرنًا وأكثر قابلية للتكيف من خلال التقسيم العادي. تخيل نظامًا قابلًا للتكيف أفقيًا أو خدمة تتكون من ثمان عاملين. توضح الصورة التالية العاملين وطلباتهم. يمكن أن يكون العاملون خوادم أو قوائم انتظار أو قواعد بيانات، أيًا كان هذا «الشيء» فإنه يشكل نظامك.

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

ستقضي المشكلة على العامل الأول الذي تأثر، لكنها تتقدم بعد ذلك لتسقط عبر العاملين الآخرين حينما يتولى العاملون المتبقون زمام الأمور. يمكن أن تقضي المشكلة على جميع العاملين والخدمة بالكامل بسرعة للغاية.

ويتمثل نطاق التأثر لهذا النوع من الفشل في «كل شيئ وكل شخص». تتعطل الخدمة بأكملها. يتأثر كل عميل. كما نقول في هندسة التوافر: الأمر ليس مثاليًا.

ويمكننا التحسّن باستخدام التقسيم المنتظم. إذا قسمنا الأسطول إلى 4 تقسيمات من العاملين، يمكننا استبدال الكفاءة بنطاق التأثر. تعرض الصورتان التاليتان كيف يمكن أن يحُد التقسيم من أثر هجمة الحرمان من الخدمة الموزعة.

في هذا المثال، يحتوي كل قسم على عاملين. وقد قسمنا الموارد، مثل نطاقات العملاء وعبر الأقسام. لا يزال لدينا احتياط فائض، لكن تظرًأ لأن هناك عاملين لكل قسم، فإنه يجب علينا المحافظة على مزيد من سعة الفائض في النظام لمعالجة أي حالات فشل. وفي المقابل، يتم خفض نطاق التأثر بدرجة كبيرة.

في عالم التقسيم هذا، يتم خفض نطاق التأثر حسب عدد الأقسام. ومع هذه الأقسام الأربعة، إذا واجه العميل مشكلة، فإن استضافة القسم قد تتأثر حينئذ وكذلك جميع العملاء الآخرين بهذا القسم. مع ذلك، يمثل هذا القسم ربعًا واحدًا من الخدمة الكلية. تعد نسبة 25 % من التأثر أفضل بكثير من 100 في المائة من التأثر. باستخدام التقسيم العشوائي، يمكننا العودة بشكل أقوى مرة أخرى.

وباستخدام التقسيم العشوائي، فإنن نُنشئ أقسامًا افتراضية لكل عاملين على حدة، ونعيّن عملاءنا أو مواردنا أو أيًا ما نريد عزله لواحدة من هذه الأقسام الافتراضية.

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

في مثالنا، نُعين عميل قوس قزح للعامل الأول وللعامل الرابع. يُشِّكل المزيج من هذين العاملين التقسيم العشوائي للعميل. سيتحول العملاء الآخرون إلى أقسام افتراضية مختلفة، وذلك بمزيج خاص من عاملين خاصين بهم. على سبيل المثال، يتم أيضًا تعيين العميل الوردة للعامل الأول، لكن عامله الآخر هو العامل الثامن.

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

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

وعند حدوث مشكلة، يمكننا أيضًا أن نخسر ربع الخدمة بالكامل، لكن طريقة تعيين العملاء أوالموارد تعني أن نطاق التأثر باستخدام التقسيم العشوائي يعتبر أفضل بدرجة كبيرة. ومع ثمانية عاملين، يصبح هناك 28 مزيجًا فريدًا من عاملين، ما يعني أن هناك 28 قسمًا عشوائيًا ممكنًا. إذا كان لدينا مئات من العملاء أو أكثر، وقمنا بتعيين كل عميل إلى قسم عشوائي، فحينئذ يصبح نطاق التأثر 1/28 بسبب مشكلة ما. وهذا يعد أفضل 7 مرات من التقسيم العادي.

من المثير للغاية رؤية العدد يتحسن بشكل هائل عن الكثير من العاملين والعملاء الذين لديك. وتزداد معظم التحديات المتصاعدة صعوبة في هذه الأبعاد، لكن يصبح التقسيم العشوائي أكثر فعالية. في الحقيقة، مع وجود ما يكفي من العاملين، يمكن أن يصبح هناك كثير من الأقسام العشوائية أكثر من العملاء، كما يمكن عزل كل عميل.

كيف يساعد كل هذا Amazon Route 53؟ باستخدام Route 53، قررنا تنظيم السعة لدينا في إجمالي 2048 خادم ذي أسماء افتراضية. هذه الخوادم افتراضية لأنها لا تتطابق مع الخوادم المادية التي تستضيف Route 53. ويمكننا نقلها للمساعدة في إدارة السعة. ثم نُعين لكل نطاق عميل تقسيمًا عشوائيًا من الأربع خوادم ذات الأسماء الافتراضية. باستخدام هذه الأرقام، يصبح هناك تنظيم من 730 مليار تقسيم عشوائي ممكن. لدينا العديد من التقسيمات العشوائية الممكنة التي يمكننا بها تعيين تقسيم عشوائي لكل نطاق. في الواقع، يمكننا المتابعة وضمان عدم مشاركة أي نطاق عميل أكثر من خادمين ذوي أسماء افتراضية مع أي نطاق عميل آخر.

وتعتبر النتائج مذهلة. إذا استُهدِف نطاق عميل من هجمة الحرمان من الخدمة الموزعة، فإن الخوادم الأربعة ذات الأسماء الافتراضية المُعينة لهذا النطاق ستصل لذروة نسبة استخدام الشبكة، لكن لن يلاحظ ذلك أي نطاق عميل آخر. لا نقوم بإعادة التعيين للعميل المستهدف الذي واجه يومًا سيئًا. يعني التقسيم العشوائي أنه يمكننا تحديد العميل المستهدف لسعة الهجمات المخصصة الخاصة وعزله. إضافة إلى ذلك، فقد طورنا أيضًا طبقة مُسجلة الملكية خاصة بنا لمؤشرات ضبط نسبة استخدام الشبكة لدى AWS Shield. ومع ذلك، يشكل التقسيم العشوائي فرقًا ضخمًا في ضمان أن تكون خبرة العميل بأكملها الخاصة بـ Route 53 سلسة، أثناء حدوت هذه الأحداث.

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

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

جرّب بعض المبادئ التي تعلمتها هنا من خلال تدريب عملي.