اختبار مايكروسوفت أزور أوتوسكال

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

 

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

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

 

 

 

 

حلول الحوسبة في Azure

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

 

أنواع التحجيم التلقائي

 

التحجيم التلقائي العمودي

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

 

 

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

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

 

 

 

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

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

 

تنبيهات

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

 

 

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

 

 

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

 

 

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

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

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

 

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

 

 

 

اختبار Azure Autoscale

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

 

 

 

 

 

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

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

 

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

 

 

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

 

اختبار Azure Autoscale: الخاتمة

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

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