اختبار Microsoft Azure Autoscale

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

 

القياس التلقائي

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

 

 

 

 

Compute Solutions in Azure

• خدمة التطبيقات. Azure App Service هي خدمة استضافة ويب مدارة بالكامل لإنشاء تطبيقات الويب والنهايات الخلفية للجوال وواجهات برمجة التطبيقات RESTful. من مواقع الويب الصغيرة إلى تطبيقات الويب ذات النطاق العالمي ، يتمتع Azure بخيارات التسعير والأداء التي تناسب احتياجاتك.
• Azure Cloud Services. تعد Azure Cloud Services مثالا على النظام الأساسي كخدمة (PaaS). مثل Azure App Service، تم تصميم هذه التقنية لدعم التطبيقات القابلة للتطوير والموثوقة وغير المكلفة للعمل. يمكنك تثبيت البرنامج الخاص بك على الأجهزة الظاهرية التي تستخدم خدمات Azure Cloud، ويمكنك الوصول إليها عن بعد.
• Azure Service Fabric. Azure Service Fabric عبارة عن نظام أساسي للأنظمة الموزعة يجعل من السهل حزم الخدمات المصغرة والحاويات القابلة للتطوير والموثوقة ونشرها وإدارتها. تمثل Service Fabric النظام الأساسي من الجيل التالي لبناء وإدارة هذه التطبيقات من فئة المؤسسات والمستوى 1 والتطبيقات السحابية التي تعمل في حاويات.
• Azure Functions. تسمح وظائف Azure للمطورين بالعمل من خلال الاتصال بمصادر البيانات أو حلول المراسلة مما يجعل من السهل معالجة الأحداث والتفاعل معها. يمكن للمطورين الاستفادة من وظائف Azure لإنشاء نقاط نهاية واجهة برمجة تطبيقات تستند إلى HTTP يمكن الوصول إليها بواسطة مجموعة واسعة من التطبيقات وأجهزة الجوال وأجهزة إنترنت الأشياء.
• الأجهزة الافتراضية. سيتيح لنا جهاز Azure الظاهري إنشاء واستخدام الأجهزة الظاهرية في السحابة كبنية تحتية كخدمة. يمكننا استخدام صورة مقدمة من Azure، أو شريك، أو يمكننا استخدام صورتنا الخاصة لإنشاء الجهاز الظاهري.

 

أنواع القياس التلقائي

القياس التلقائي العمودي

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

 

 

القياس التلقائي الأفقي

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

 

 

 

المراقبة والتنبيهات

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

 

تنبيهات

يمكنك اختيار إعلام المستخدمين عند حدوث التوسع التلقائي والقياس (خدمة التطبيق).

 

 

بشكل افتراضي ، يتم استخدام رؤى التطبيق لخدمة التطبيق التي تمنحنا رؤى حول وقت استجابة الخادم والطلبات وما إلى ذلك.

 

 

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

 

 

عند استخدام Azure Autoscale، لا داعي للقلق بشأن كيفية تنفيذ موازنات التحميل ومديري الزيارات وما إلى ذلك. يدير Azure كل شيء.

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

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

 

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

 

 

 

Testing Azure Autoscale

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

 

 

 

 

 

استخدام LoadView للتحقق من أن المقياس التلقائي ل Azure يعمل بشكل صحيح

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

 

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

 

 

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

 

اختبار Azure Autoscale: Conclusion

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

جرب LoadView بنفسك وتلقى 20 دولارا أمريكيا في أرصدة اختبار التحميل للبدء.