توصيات لتصميم استراتيجية تحجيم موثوقة
ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:
| RE:06 | تنفيذ استراتيجية تحجيم في الوقت المناسب وموثوق بها على مستويات التطبيق والبيانات والبنية الأساسية. |
|---|
دليل ذو صلة:تقسيم البيانات
يصف هذا الدليل توصيات تصميم استراتيجية تحجيم موثوقة.
التعريفات
| المصطلح | التعريف |
|---|---|
| تحجيم عمودي | نهج التحجيم الذي يضيف سعة الحوسبة إلى الموارد الموجودة. |
| تحجيم أفقي | نهج التحجيم الذي يضيف مثيلات لنوع معين من الموارد. |
| التكلس التلقائي | نهج التحجيم الذي يضيف الموارد أو يزيلها تلقائيا عند استيفاء مجموعة من الشروط. |
ملاحظة
يمكن أن تكون عمليات التحجيم ثابتة (التحجيم اليومي المجدول بانتظام لاستيعاب أنماط التحميل العادية)، أو تلقائية (عملية تلقائية استجابة للشروط التي يتم استيفاءها)، أو يدوية (يقوم عامل التشغيل بعملية تحجيم لمرة واحدة ردا على تغيير التحميل غير المتوقع). يمكن إجراء كل من التحجيم العمودي والأفقي عبر أي من هذه الطرق. ومع ذلك، يتطلب التحجيم العمودي التلقائي تطويرا مخصصا إضافيا للأتمتة ويمكن أن يتسبب في وقت تعطل اعتمادا على الموارد التي يتم توسيع نطاقها.
استراتيجيات التصميم الرئيسية
لتصميم استراتيجية تحجيم موثوقة لأحمال العمل الخاصة بك، ركز على تحديد أنماط التحميل للمستخدم وتدفقات النظام لكل حمل عمل يؤدي إلى عملية تحجيم. فيما يلي أمثلة على أنماط التحميل المختلفة:
ثابت: كل ليلة بحلول الساعة 11 مساء بتوقيت الولايات المتحدة الأمريكية، يقل عدد المستخدمين النشطين عن 100 وينخفض استخدام وحدة المعالجة المركزية لخوادم التطبيقات بنسبة 90٪ عبر جميع العقد.
ديناميكي ومنتظم ويمكن التنبؤ به: كل صباح الاثنين، يقوم 1000 موظف عبر مناطق متعددة بتسجيل الدخول إلى نظام ERP.
ديناميكي وغير منتظم ويمكن التنبؤ به: يحدث إطلاق المنتج في اليوم الأول من الشهر وهناك بيانات تاريخية من عمليات الإطلاق السابقة حول كيفية زيادة نسبة استخدام الشبكة في هذه الحالات.
ديناميكي وغير منتظم وغير متوقع: يتسبب حدث واسع النطاق في ارتفاع الطلب على منتج. على سبيل المثال، يمكن لشركات تصنيع وبيع مزيلات الرطوبة أن تواجه طفرة مفاجئة في حركة المرور بعد إعصار أو حدث فيضانات أخرى عندما يحتاج الناس في المناطق المتضررة إلى تجفيف الغرف في منازلهم.
بعد تحديد هذه الأنواع من أنماط التحميل، يمكنك:
حدد كيف يؤثر تغيير التحميل المرتبط بكل نمط على البنية الأساسية الخاصة بك.
إنشاء أتمتة لمعالجة التحجيم بشكل موثوق.
بالنسبة للأمثلة السابقة، يمكن أن تكون استراتيجيات التحجيم الخاصة بك:
ثابت: لديك مقياس مجدول لعقد الحوسبة الخاصة بك إلى الحد الأدنى لعدد (2) بين 11 مساء و6 صباحا EST.
ديناميكية ومنتظمة ويمكن التنبؤ بها: لديك مقياس مجدول من عقد الحوسبة إلى السعة اليومية العادية قبل أن تبدأ المنطقة الأولى في العمل.
ديناميكية وغير منتظمة ويمكن التنبؤ بها: يمكنك تحديد مقياس مجدول لمرة واحدة لمثيلات الحوسبة وقاعدة البيانات الخاصة بك في صباح تشغيل المنتج، وتتراجع بعد أسبوع واحد.
ديناميكي وغير منتظم وغير متوقع: لديك حدود مقياس تلقائي محددة لحساب ارتفاعات نسبة استخدام الشبكة غير المخطط لها.
عند تصميم أتمتة التحجيم، تأكد من حساب هذه المشكلات:
يجب أن تكون جميع مكونات حمل العمل الخاص بك مرشحة لتوسيع نطاق التنفيذ. في معظم الحالات، تقوم الخدمات العالمية مثل Microsoft Entra بتحجيم المعرف تلقائيا وشفافا لك ولزبائنك. تأكد من فهم قدرات التحجيم لوحدات التحكم في دخول الشبكات والخروج وحل موازنة التحميل الخاص بك.
تلك المكونات التي لا يمكن توسيع نطاقها. مثال على ذلك هو قواعد البيانات الارتباطية الكبيرة التي لم يتم تمكين التقسيم ولا يمكن إعادة بناء التعليمات البرمجية لها دون تأثير كبير. قم بتوثيق حدود الموارد التي نشرها موفر السحابة لديك وراقب هذه الموارد عن كثب. قم بتضمين هذه الموارد المحددة في التخطيط المستقبلي للترحيل إلى خدمات قابلة للتطوير.
الوقت المستغرق لتنفيذ عملية التحجيم بحيث تقوم بجدولة العملية بشكل صحيح لتحدث قبل أن يصل التحميل الإضافي إلى البنية الأساسية الخاصة بك. على سبيل المثال، إذا استغرق تغيير حجم مكون مثل APIM 45 دقيقة، فقد يساعدك ضبط حد التحجيم إلى 65٪ بدلا من 90٪ في التوسع في وقت سابق والاستعداد للزيادة المتوقعة في الحمل.
علاقة مكونات التدفق من حيث ترتيب عمليات المقياس. تأكد من أنك لا تفرط عن غير قصد في تحميل مكون انتقال البيانات من الخادم عن طريق توسيع نطاق مكون المصدر أولا.
أي عناصر تطبيق ذات حالة قد تتم مقاطعتها بواسطة عملية التحجيم وأي ترابط جلسة عمل (أو ثبات جلسة العمل) يتم تنفيذه. يمكن أن تحد الثبات من قدرتك على التحجيم وتقدم نقاط فشل واحدة.
الازدحامات المحتملة. لا يعمل التوسع على إصلاح كل مشكلة في الأداء. على سبيل المثال، إذا كانت قاعدة البيانات الخلفية هي الازدحام، فلا يساعد ذلك في إضافة المزيد من خوادم الويب. حدد الازدحامات في النظام وحلها أولا قبل إضافة المزيد من المثيلات. الأجزاء ذات الحالة من النظام هي السبب الأكثر احتمالاً للازدحامات.
يساعد اتباع نمط تصميم طابع التوزيع في إدارة البنية الأساسية بشكل عام. يعد إنشاء تصميم التحجيم الخاص بك على الخوادم المخصصة كوحدات مقياس مفيدا أيضا. كما يساعدك على التحكم بإحكام في عمليات التحجيم عبر أحمال عمل متعددة ومجموعات فرعية من أحمال العمل. بدلا من إدارة جداول التحجيم وحد التحجيم التلقائي للعديد من الموارد المميزة، يمكنك تطبيق مجموعة محدودة من تعريفات التحجيم على طابع نشر ثم عكس ذلك عبر الطوابع حسب الحاجة.
المفاضلة: التوسيع له آثار على التكلفة، لذا قم بتحسين استراتيجيتك لتقليلها في أقرب وقت ممكن للمساعدة في إبقاء التكاليف تحت السيطرة. تأكد من أن الأتمتة التي تستخدمها لتوسيع النطاق لديها أيضا مشغلات للتحجيم.
تسهيل Azure
تتوفر ميزة التحجيم التلقائي في العديد من خدمات Azure. يتيح لك تكوين الشروط بسهولة لتوسيع نطاق المثيلات أفقيا تلقائيا. تحتوي بعض الخدمات على وظائف مضمنة محدودة أو لا يمكن توسيع نطاقها تلقائيا، لذا تأكد من توثيق هذه الحالات وتحديد العمليات للتعامل مع التحجيم.
توفر العديد من خدمات Azure واجهات برمجة التطبيقات التي يمكنك استخدامها لتصميم عمليات تحجيم تلقائي مخصصة باستخدام Azure Automation، مثل نماذج التعليمات البرمجية في التحجيم التلقائي ل Azure IoT Hub. يمكنك استخدام أدوات مثل KEDA للتحجيم التلقائي المستند إلى الحدث، والذي يتوفر في Azure Kubernetes ServiceوAzure Container Apps.
يوفر التحجيم التلقائي ل Azure Monitor مجموعة شائعة من وظائف التحجيم التلقائي لمجموعات مقياس جهاز Azure الظاهري وخدمة تطبيقات Azure وتطبيقات Azure Spring والمزيد. يمكن إجراء التحجيم وفقا لجدول زمني أو استنادا إلى مقياس وقت التشغيل، مثل استخدام وحدة المعالجة المركزية أو الذاكرة. راجع دليل Azure Monitor للحصول على أفضل الممارسات.
Tradeoffs
اعتبارات التحجيم التلقائي
لا يعد تغيير الحجم التلقائي حلاً فورياً. إن مجرد إضافة الموارد إلى نظام أو تشغيل المزيد من مثيلات العملية لا يضمن تحسن أداء النظام. ضع في اعتبارك النقاط التالية عند تصميم إستراتيجية قياس تلقائي:
يجب تصميم النظام ليكون قابلاً للتطوير أفقيًا. تجنب وضع افتراضات حول ترابط المثيل. لا تصمم الحلول التي تتطلب تشغيل التعليمات البرمجية دائما في مثيل معين من العملية. عند تحجيم خدمة سحابية أو موقع ويب أفقيا، لا تفترض أن سلسلة من الطلبات من نفس المصدر يتم توجيهها دائما إلى نفس المثيل. لنفس السبب، يجب أن تكون خدمات التصميم عديمة الحالة لتجنب طلب سلسلة من الطلبات من تطبيق ليتم توجيهها دائمًا إلى نفس مثيل الخدمة. عند تصميم خدمة تقرأ الرسائل من قائمة انتظار وتعالجها، لا تقم بأي افتراضات حول مثيل الخدمة الذي يعالج رسالة معينة. يمكن أن يبدأ التحجيم التلقائي في المزيد من مثيلات الخدمة مع زيادة طول قائمة الانتظار. يصف نمط المستهلكين المتنافسين كيفية التعامل مع هذا السيناريو.
إذا كان الحل ينفذ مهمة طويلة الأمد، فصمم هذه المهمة لدعم كل من التوسيع والتحجيم. بدون العناية الواجبة، يمكن أن تمنع مثل هذه المهمة إيقاف تشغيل مثيل عملية بشكل نظيف عندما يتوسع النظام. أو قد تفقد البيانات إذا أنهت العملية قسرا. من الناحية المثالية، إعادة بناء التعليمات البرمجية لمهمة طويلة الأمد وتقسيم المعالجة التي تقوم بها إلى مجموعات أصغر منفصلة. يوفر نمط الأنابيب وعوامل التصفية مثالا على كيفية تحقيق هذا الحل.
بدلا من ذلك، يمكنك تنفيذ آلية نقطة تحقق تسجل معلومات الحالة حول المهمة على فترات منتظمة. يمكنك بعد ذلك حفظ هذه الحالة في تخزين دائم يمكن الوصول إليه بواسطة أي مثيل للعملية التي تقوم بتشغيل المهمة. بهذه الطريقة، إذا تم إيقاف تشغيل العملية، يمكن استئناف العمل الذي كانت تقوم به من نقطة التحقق الأخيرة بواسطة مثيل آخر. هناك مكتبات توفر هذه الوظيفة، مثل NServiceBus و MassTransit. وهي تستمر بشفافية في الحالة، حيث تتم محاذاة الفواصل الزمنية مع معالجة الرسائل من قوائم الانتظار في ناقل خدمة Azure.
عند تشغيل مهام الخلفية على مثيلات حساب منفصلة، كما هو الحال في أدوار العامل لتطبيق مستضاف على الخدمات السحابية، قد تحتاج إلى توسيع نطاق أجزاء مختلفة من التطبيق باستخدام نهج تحجيم مختلفة. على سبيل المثال، قد تحتاج إلى نشر مثيلات حساب إضافية لواجهة المستخدم (UI) دون زيادة عدد مثيلات حساب الخلفية، أو العكس. إذا كنت تقدم مستويات مختلفة من الخدمة، مثل حزم الخدمة الأساسية والمميزة، فقد تحتاج إلى توسيع نطاق موارد الحوسبة لحزم الخدمات المتميزة بقوة أكبر من حزم الخدمة الأساسية لتلبية اتفاقيات مستوى الخدمة (SLAs).
ضع في اعتبارك طول قائمة الانتظار التي تتصل بها واجهة المستخدم ومثيلات حساب الخلفية. استخدمه كمعيار لاستراتيجية التحجيم التلقائي. هذه المشكلة هي أحد المؤشرات المحتملة على عدم التوازن أو الفرق بين الحمل الحالي وسعة المعالجة لمهمة الخلفية. السمة الأكثر تعقيدا قليلا ولكن الأفضل التي تستند إليها قرارات التحجيم هي استخدام الوقت بين وقت إرسال رسالة ووقت اكتمال معالجتها. يعرف هذا الفاصل الزمني بالوقت الحرج. إذا كانت قيمة الوقت الحرج هذه أقل من حد عمل ذي معنى، فمن غير الضروري التحجيم، حتى إذا كان طول قائمة الانتظار طويلا.
على سبيل المثال، قد يكون هناك 50000 رسالة في قائمة انتظار. ولكن الوقت الحرج لأقدم رسالة هو 500 مللي ثانية، ونقطة النهاية تتعامل مع التكامل مع خدمة ويب تابعة لجهة خارجية لإرسال رسائل البريد الإلكتروني. من المحتمل أن يعتبر أصحاب المصلحة في الأعمال أن هذه فترة زمنية لا تبرر إنفاق أموال إضافية للتحجيم.
من ناحية أخرى، قد يكون هناك 500 رسالة في قائمة انتظار، بنفس الوقت الحرج البالغ 500 مللي ثانية، ولكن نقطة النهاية جزء من المسار الهام في بعض الألعاب عبر الإنترنت في الوقت الحقيقي حيث حدد أصحاب المصلحة في الأعمال وقت استجابة يبلغ 100 مللي ثانية أو أقل. وفي هذه الحالة، فإن التوسع سيكون منطقيا.
لاستخدام الوقت الحرج في قرارات التحجيم التلقائي، من المفيد أن تضيف مكتبة المعلومات ذات الصلة تلقائيا إلى رؤوس الرسائل أثناء إرسالها ومعالجتها. مكتبة واحدة توفر هذه الوظيفة هي NServiceBus.
إذا قمت بإنشاء استراتيجية التحجيم التلقائي الخاصة بك على العدادات التي تقيس العمليات التجارية، مثل عدد الطلبات المقدمة في الساعة أو متوسط وقت تشغيل معاملة معقدة، فتأكد من فهمك الكامل للعلاقة بين النتائج من هذه الأنواع من العدادات ومتطلبات سعة الحساب الفعلية. قد يكون من الضروري توسيع نطاق أكثر من مكون واحد أو وحدة حساب استجابة للتغييرات في عدادات عمليات الأعمال.
لمنع النظام من محاولة التوسع بشكل مفرط، ولتجنب التكاليف المرتبطة بتشغيل عدة آلاف من المثيلات، ضع في اعتبارك الحد الأقصى لعدد المثيلات التي تتم إضافتها تلقائيا. تتيح لك معظم آليات التحجيم التلقائي تحديد الحد الأدنى والحد الأقصى لعدد المثيلات للقاعدة. بالإضافة إلى ذلك، ضع في اعتبارك تدهور الوظائف التي يوفرها النظام بأمان إذا تم نشر الحد الأقصى لعدد المثيلات وما زال النظام محملا بشكل زائد.
ضع في اعتبارك أن التحجيم التلقائي قد لا يكون الآلية الأنسب للتعامل مع اندفاع مفاجئ في حمل العمل. يستغرق الأمر وقتا لتوفير مثيلات جديدة من الخدمة وبدء تشغيلها أو إضافة موارد إلى نظام، وقد يمر ذروة الطلب بحلول الوقت الذي تتوفر فيه هذه الموارد الإضافية. في هذا السيناريو، قد يكون من الأفضل تقييد الخدمة. لمزيد من المعلومات، راجع نمط التقييد.
على العكس من ذلك، إذا كنت بحاجة إلى القدرة على معالجة جميع الطلبات عندما يتقلب الحجم بسرعة، والتكلفة ليست عاملا مساهما رئيسيا، ففكر في استخدام استراتيجية تحجيم تلقائي عدوانية تبدأ المزيد من المثيلات بسرعة أكبر. يمكنك أيضًا استخدام سياسة مجدولة تُشغّل عددًا كافٍ من المثيلات لتلبية الحد الأقصى من التحميل قبل توقع هذا التحميل.
يجب أن تراقب آلية التحجيم التلقائي عملية التحجيم التلقائي وتسجل تفاصيل كل حدث تحجيم تلقائي (ما الذي أدى إليه، وما هي الموارد التي تمت إضافتها أو إزالتها، ومتى). إذا قمت بإنشاء آلية قياس تلقائية مخصصة، فتأكد من أنها تتضمن هذه الإمكانية. تحليل المعلومات للمساعدة في قياس فعالية استراتيجية التحجيم التلقائي، وضبطها إذا لزم الأمر. يمكنك ضبط كليهما على المدى القصير، حيث تصبح أنماط الاستخدام أكثر وضوحًا، وعلى المدى الطويل، مع توسيع الأعمال أو تطور متطلبات التطبيق. إذا وصل أحد التطبيقات إلى الحد الأعلى المحدد للتحجيم التلقائي، فقد تنبه الآلية أيضا عامل التشغيل الذي يمكنه بدء المزيد من الموارد يدويا إذا لزم الأمر. في ظل هذه الظروف، قد يكون عامل التشغيل مسؤولا أيضا عن إزالة هذه الموارد يدويا بعد تخفيف حمل العمل.
مثال
راجع إرشادات تحجيم البنية المرجعية الأساسية ل AKS.
الروابط ذات الصلة
قائمة التحقق من الموثوقية
راجع المجموعة الكاملة من التوصيات.