نمط التقييد

تحكم في استهلاك الموارد المستخدمة بواسطة مثيل تطبيق أو مستأجر فردي أو خدمة كاملة. ويمكن أن `g; يسمح للنظام بالاستمرار في العمل والوفاء باتفاقيات مستوى الخدمة، حتى عندما تؤدي زيادة الطلب إلى تحميل شديد على الموارد.

السياق والمشكلة

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

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

حل

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

يمكن للنظام تنفيذ العديد من استراتيجيات التقييد، بما في ذلك:

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

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

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

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

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

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

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

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

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

الشكل التالي يوضح رسمًا بيانيًا مساحيًا للاستخدام العام للموارد من قبل جميع التطبيقات التي تعمل في نظام مقابل الوقت، ويوضح كيف يمكن دمج التقييد مع التحجيم التلقائي.

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

المسائل والاعتبارات

يجب مراعاة النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

• تقييد التطبيق، واستراتيجية الاستخدام، عبارة عن قرار معماري يؤثر على التصميم الكامل للنظام. يجب مراعاة التقييد في وقت مبكر من عملية تصميم التطبيق، لأنه ليس من السهل إضافته بمجرد تنفيذ النظام.

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

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

  • يشير HTTP 429 إلى أن تطبيق الاستدعاء أرسل عددا كبيرا جدا من الطلبات في إطار زمني وتجاوز حدا محددا مسبقا.
  • يشير HTTP 503 إلى أن الخدمة غير جاهزة للتعامل مع الطلب. السبب الشائع هو أن الخدمة تواجه طفرات تحميل مؤقتة أكثر من المتوقع.

يمكن لتطبيق العميل الانتظار لفترة قبل إعادة محاولة الطلب. Retry-After يجب تضمين رأس HTTP، لدعم العميل في اختيار استراتيجية إعادة المحاولة.

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

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

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

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

موعد استخدام النمط

استخدم هذا النمط:

• لضمان استمرار النظام في الوفاء باتفاقيات مستوى الخدمة.

• لمنع مستأجر واحد من احتكار الموارد التي يوفرها التطبيق.

• لمعالجة الاندفاعات في النشاط.

• للمساعدة في تحسين التكلفة للنظام عن طريق الحد من الحد الأقصى لمستويات الموارد اللازمة للحفاظ على عمله.

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط التقييد في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

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

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

الخطوات التالية

كما قد تكون الأنماط والإرشادات التالية ذات صلة عند تنفيذ هذا النمط:

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

الموارد ذات الصلة

قد تكون الأنماط والإرشادات التالية ذات صلة أيضًا عند تنفيذ هذا النمط:

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