Share via

التحجيم التلقائي

  • مقالة

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

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

توجد طريقتان رئيسيتان يمكن للتطبيق من خلالهما تغيير حجمه:

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

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

تدعم العديد من الأنظمة المستندة إلى السحابة، بما في ذلك Microsoft Azure، التحجيم الأفقي التلقائي. تركز بقية هذه المقالة على التحجيم الأفقي.

إشعار

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

مكونات التحجيم التلقائي

تتضمن استراتيجية التحجيم التلقائي عادةً الأجزاء التالية:

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

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

تكوين التحجيم التلقائي لحل Azure

يوفر Azure مقياسًا تلقائيًا مضمنًا لمعظم خيارات الحساب.

تستخدم جميع خيارات الحساب هذه التحجيم التلقائي لـ Azure Monitor لتوفير مجموعة شائعة من وظائف التحجيم التلقائي.

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

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

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

استخدام التحجيم التلقائي لـ Azure Monitor

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

أمثلة:

  • التوسيع إلى 10 مثيلات في أيام الأسبوع، والتضييق إلى 4 مثيلات في السبت والأحد.
  • التوسيع بمقدار مثيل واحد إذا كان متوسط المعالج أعلى من 70٪، والتضييق بمقدار مثيل واحد إذا كان استخدام المعالج أقل من 50 بالمائة.
  • قم بالتوسيع بمقدار مثيل واحد إذا تجاوز عدد الرسائل في قائمة انتظار حدًا معينًا.

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

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

للحصول على قائمة بالقياسات المضمنة، راجع قياسات Azure Monitor الشائعة للتحجيم التلقائي. يمكنك أيضًا تنفيذ قياسات مخصصة باستخدام Application Insights.

يمكنك تكوين التحجيم التلقائي باستخدام PowerShell أو Azure CLI أو قالب Azure Resource Manager أو مدخل Microsoft Azure. للحصول على عنصر تحكم أكثر تفصيلاً، استخدم واجهة برمجة تطبيقات REST لـ Azure Resource Manager. مكتبة Azure Monitoring Service Managementومكتبة Microsoft Insights (في الإصدار الأولي) هي عدد تطوير البرامج التي تسمح بجمع القياسات من موارد مختلفة، وإجراء التحجيم التلقائي من خلال الاستفادة من واجهات برمجة تطبيقات REST. بالنسبة للموارد التي لا يتوفر فيها دعم Azure Resource Manager، أو إذا كنت تستخدم Azure Cloud Services، يمكن استخدام واجهة برمجة تطبيقات REST لإدارة الخدمة للتحجيم التلقائي. في جميع الحالات الأخرى، استخدم Azure Resource Manager.

ضع في اعتبارك النقاط التالية عند استخدام التحجيم التلقائي لـ Azure:

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

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

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

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

  • تجنب الخفقان حيث تنتقل إجراءات التحجيم والتوسيع باستمرار ذهابًا وإيابًا. لنفترض أن هناك مثيلين، والحد الأعلى هو معالج بنسبة 80٪، والحد الأدنى بنسبة 60٪. عندما يكون الحمل عند 85٪، تتم إضافة مثيل آخر. بعد مرور بعض الوقت، ينخفض الحمل إلى 60٪. قبل التحجيم، تحسب خدمة التحجيم التلقائي توزيع الحمل الإجمالي (من ثلاثة مثيلات) عند إزالة مثيل، مع أخذه إلى 90٪. وهذا يعني أنه يجب توسيع النطاق مرة أخرى على الفور. لذلك، فإنه يتخطى التحجيم وقد لا ترى أبدًا نتائج التحجيم المتوقعة.

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

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

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

للحصول على تفاصيل حول كيفية تحجيم Azure Monitor، راجع أفضل الممارسات للتحجيم التلقائي.

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

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

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

  • عند تكوين نُهج وقواعد متعددة، قد تتعارض مع بعضها البعض. يستخدم التحجيم التلقائي قواعد دقة التعارض التالية للتأكد من وجود عدد كافٍ من المثيلات قيد التشغيل دائمًا:

    • دائمًا ما تكون لعمليات التوسيع الأسبقية على عمليات التضييق.
    • عند تعارض عمليات التوسيع، تكون للقاعدة التي تبدأ أكبر زيادة في عدد المثيلات التي لها الأسبقية.
    • عند تعارض عمليات التضييق، فإن القاعدة التي تبدأ أصغر إنقاص في عدد المثيلات لها الأسبقية.

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

اعتبارات تصميم التطبيق

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

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

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

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

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

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

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

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

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

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

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

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

قد تكون الأنماط والإرشادات التالية ذات صلة أيضا بالسيناريو الخاص بك عند تنفيذ التحجيم التلقائي:

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

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

  • المراقبة والتشخيص. يعد التقرير عن حالة النظام وبيانات تتبع الاستخدام أمر حيوي لجمع المعلومات التي يمكن أن تدفع عملية التحجيم التلقائي.