إن Netflix مهووسة بتوفر الخدمة. لقد قمنا بمراجعته بالفعل على مدونتنا أكثر من مرة وأخبرنا كيف نجحنا في تحقيق أهدافنا. نستخدم قواطع الدائرة وحدود التزامن واختبار الفوضى والمزيد. نقدم لكم اليوم نهجًا مبتكرًا آخر يزيد بشكل كبير من استقرار التطبيق في ظل الأحمال الشديدة ويتجنب حالات فشل الخدمة المتتالية - حدود التكيف للاتصالات المتوازية. لا حاجة لمزيد من الجهد لتحديد حدود الاتصالات المتوازية ، مما يسمح للنظام بالحفاظ على وقت استجابة قصير. كجزء من هذا الإعلان ، نقوم أيضًا بنشر مكتبة Java بسيطة في المجال العام مع إمكانات تكامل servlets وبرامج التحكم و gRPC.
لنبدأ بالأساسيات
حد الاتصالات المتوازية هو الحد الأقصى لعدد الطلبات التي يستطيع النظام معالجتها في وقت معين. عادةً ، يعتمد هذا المبلغ على مورد محدود ، مثل قوة المعالجة للمعالج المركزي. عادة ، يتم حساب حد الاتصالات المتوازية لنظام وفقًا لقانون Little's ، الذي يقرأ على النحو التالي: بالنسبة لنظام مستقر ، فإن الحد الأقصى لعدد الاتصالات المتوازية يساوي منتج متوسط الوقت المستغرق في معالجة الطلب ومتوسط كثافة الطلبات الواردة (L = λW). لا يمكن للنظام معالجة أي طلبات تتجاوز حد الاتصال المتوازي على الفور ، لذلك سيتم وضعها في قائمة الانتظار أو رفضها. قائمة الانتظار هي وظيفة مهمة تسمح لك باستخدام النظام بالكامل في الحالات التي يتم فيها تلقي الطلبات بشكل غير متساوٍ وتتطلب مقدارًا مختلفًا من الوقت للمعالجة.
إذا لم يكن هناك حد لقائمة الانتظار ، يمكن أن يحدث تعطل النظام ، على سبيل المثال ، إذا كانت كثافة الطلبات لفترة طويلة أعلى من سرعة معالجتها. مع نمو قائمة الانتظار ، ينمو التأخير أيضًا ، مما يؤدي إلى زيادة وقت الانتظار للطلبات. يستمر هذا حتى تنفد الذاكرة الحرة ، وبعد ذلك يتعطل النظام. إذا لم تتبع وقت التأخير المتزايد ، فسيبدأ في التأثير سلبًا على خدمات الاتصال ويؤدي إلى فشل النظام المتتالي.
يعد استخدام حدود الاتصال المتوازي ممارسة قياسية ، ولكن الصعوبة تكمن في تحديدها للأنظمة الموزعة الديناميكية الكبيرة ، حيث تتغير معلمات مثل وقت التأخير والعدد المحتمل للاتصالات المتوازية باستمرار. جوهر حلنا هو القدرة على تحديد حد الاتصالات المتوازية ديناميكيًا. يمكن تمثيل هذا الحد على أنه عدد الطلبات الواردة (التي يتم تنفيذها بالتوازي وقائمة الانتظار) التي يستطيع النظام معالجتها حتى يبدأ أدائه في الانخفاض (ويزداد وقت التأخير).
الحل
في السابق ، كان موظفو Netflix يحددون حدود الاتصال المتزامن اليدوي من خلال اختبار الأداء والتوصيف الذي يستغرق وقتًا طويلاً. كان الرقم الناتج صحيحًا لفترة زمنية محددة ، ولكن سرعان ما بدأت طوبولوجيا النظام في التغيير بسبب الفشل الجزئي ، أو التحجيم التلقائي ، أو إدخال رمز إضافي أثر على وقت التأخير. ونتيجة لذلك ، فإن الحد منتهي الصلاحية. كنا نعلم أننا قادرون على المزيد ، وأنه لم يعد كافياً بالنسبة لنا ببساطة تحديد حدود الاتصال بشكل ثابت. كنا بحاجة إلى طريقة لتحديد الحدود المتأصلة في النظام نفسه تلقائيًا. في الوقت نفسه ، أردنا هذه الطريقة:
- لا يتطلب العمل اليدوي ؛
- لم يتطلب التنسيق المركزي ؛
- يمكن تحديد الحد دون أي معلومات حول طوبولوجيا الأجهزة أو النظام ؛
- تتكيف مع التغيرات في طوبولوجيا النظام ؛
- كانت بسيطة من حيث التنفيذ والحسابات اللازمة.
لحل هذه المشكلة ، انتقلنا إلى خوارزمية تتبع الازدحام التي أثبتت جدارتها TCP. تحدد هذه الخوارزمية عدد حزم البيانات التي يمكن إرسالها بالتوازي (أي حجم نافذة الفائض) دون زيادة وقت التأخير أو تجاوز وقت الانتظار. تستخدم هذه الخوارزميات مؤشرات مختلفة لتحديد حد الحزم المرسلة في وقت واحد وتغيير حجم نافذة الفائض وفقًا لذلك.
يوضح اللون الأزرق في الصورة الحد غير المعروف للاتصالات المتوازية للنظام. أولاً ، يرسل العميل عددًا صغيرًا من الطلبات المتزامنة ، ثم يبدأ بالتحقق من النظام بشكل دوري لمعرفة ما إذا كان يمكنه معالجة المزيد من الطلبات عن طريق زيادة نافذة التدفق حتى يتسبب ذلك في زيادة التأخير. عندما يستمر التأخير في الزيادة ، يقرر المرسل أنه وصل إلى الحد ويقلل مرة أخرى من حجم نافذة الفائض. ينعكس هذا الاختبار المستمر للحد في الرسم البياني الذي تراه أعلاه.
تعتمد الخوارزمية الخاصة بنا على خوارزمية تتبع ازدحام TCP ، والتي تأخذ في الاعتبار العلاقة بين الحد الأدنى لوقت التأخير (أفضل سيناريو ممكن لا يتم فيه استخدام قائمة الانتظار) ووقت التأخير ، والذي يتم قياسه بشكل دوري عند تنفيذ الطلبات. تجعل هذه النسبة من الممكن تحديد أن قائمة الانتظار قد تشكلت التي تثير زيادة في التأخير. تعطينا هذه النسبة التدرج أو حجم تغيير وقت التأخير:
التدرج = (RTTnoload / RTTactual) . إذا كانت القيمة تساوي واحدة ، فإننا نفهم أنه لا يوجد قائمة انتظار ويمكن زيادة الحد الأقصى. تشير قيمة أقل من واحد إلى أن قائمة الانتظار ممتلئة وأن الحد يجب تخفيضه. مع كل قياس جديد لوقت التأخير ، يتم تعديل الحد بناءً على النسبة المذكورة أعلاه ، ومعها يتغير حجم قائمة الانتظار المسموح به وفقًا لهذه الصيغة البسيطة:
_ = _ × + _
للعديد من التكرارات ، تحسب الخوارزمية حدًا لا يسمح فقط بالحفاظ على وقت التأخير عند مستوى منخفض ، ولكن أيضًا لتشكيل قائمة الانتظار اللازمة للطلبات في حالة تفشي النشاط. يمكن تكوين حجم قائمة الانتظار الصالحة. يتم استخدامه لتحديد مدى سرعة زيادة حد التزامن. كحجم افتراضي ، اخترنا الجذر التربيعي لقيمة الحد الحالية. يرجع هذا الاختيار إلى الخاصية المفيدة للجذر التربيعي: عند القيم الصغيرة ، سيكون كبيرًا بما يكفي بالمقارنة مع الحد لضمان النمو السريع ، ولكن في القيم الكبيرة ، على العكس من ذلك ، ستكون قيمته النسبية أقل ، مما سيزيد من استقرار النظام.
حدود التكيف في العمل
ترفض القيود التكييفية على جانب الخادم الطلبات المفرطة وتحافظ على زمن وصول منخفض ، مما يسمح لمثيل النظام بحماية نفسه والخدمات التي يعتمد عليها. في السابق ، عندما لم يكن من الممكن رفض الطلبات الزائدة ، أدت أي زيادة مطردة في عدد الطلبات في الثانية أو وقت التأخير إلى زيادة أكبر في هذا الوقت ، وفي النهاية ، إلى سقوط النظام بأكمله. اليوم ، يمكن للخدمات التخلص من أعباء العمل غير الضرورية والحفاظ على الكمون المنخفض أثناء العمل مع أدوات التثبيت الأخرى ، مثل التحجيم التلقائي.
من المهم أن نتذكر أنه تم تعيين الحدود على مستوى الخادم (وبدون أي تنسيق) ، يمكن أن تنخفض حركة المرور إلى كل خادم وتزيد بشكل حاد. لذلك ، ليس من المستغرب أن يختلف الحد المكتشف وعدد الاتصالات المتزامنة اعتمادًا على الخادم. هذا صحيح بشكل خاص في بيئة السحابة متعددة العملاء. نتيجة لذلك ، قد ينشأ موقف عند تحميل خادم واحد بشكل زائد ، على الرغم من أن الباقي سيكون مجانيًا. في الوقت نفسه ، عند موازنة التحميل من جانب العميل ، سيصل طلب متكرر واحد فقط إلى الخادم بموارد مجانية في ما يقرب من 100٪ من الحالات. وهذا ليس كل شيء: ليس هناك سبب يدعو للقلق من أن الطلبات المتكررة ستثير هجوم DDOS ، حيث أن الخدمات قادرة على رفض حركة المرور بسرعة (في أقل من مللي ثانية) بأقل تأثير على الأداء.
الخلاصة
يلغي استخدام الحدود التكيفية للاتصالات المتوازية الحاجة إلى تحديد كيفية وفي أي الحالات يجب أن ترفض خدماتنا حركة المرور يدويًا. علاوة على ذلك ، فإنه يزيد أيضًا من الموثوقية الإجمالية وتوافر نظامنا البيئي الصغير بأكمله.
يسعدنا أن نشارك معك طرق التنفيذ والتكامل الشامل لهذا الحل ، والذي يمكنك العثور عليه في المكتبة العامة على
github.com/Netflix/concurrency-limits . نأمل أن تساعد شفرتنا المستخدمين في حماية خدماتهم من حالات الفشل المتتالية ومشكلات زيادة الكمون ، فضلاً عن زيادة توفرها.