التحقق المستمر من الصحة باستخدام Azure Load Testing وAzure Chaos Studio

  • مقالة

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

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

أحمال العمل الحرجة للمهام لها متطلبات توفر عالية، مع أهداف 3 أو 4 أو 5 تسعات (99.9٪، 99.99٪، أو 99.999٪، على التوالي). من الضروري تنفيذ اختبار تلقائي صارم للوصول إلى هذه الأهداف.

يعتمد التحقق المستمر من الصحة على كل حمل عمل وعلى الخصائص المعمارية. توفر هذه المقالة دليلا لإعداد ودمج Azure Load Testing وAzure Chaos Studio في دورة تطوير منتظمة.

1 - تحديد الاختبارات استنادا إلى الحدود المتوقعة

الاختبار المستمر هو عملية معقدة تتطلب الإعداد المناسب. وما سيتم اختباره والنتائج المتوقعة يجب أن تكون واضحة.

في PE:06 - التوصيات لاختبار الأداء و RE:08 - التوصيات لتصميم استراتيجية اختبار الموثوقية، يوصي Azure Well-Architected Framework بالبدء بتحديد السيناريوهات الرئيسية والتبعيات والاستخدام المتوقع والتوافر والأداء وأهداف قابلية التوسع.

يجب عليك بعد ذلك تحديد مجموعة من قيم الحد القابلة للقياس لتحديد الأداء المتوقع للسيناريوهات الرئيسية.

تلميح

تتضمن أمثلة قيم الحد العدد المتوقع لعمليات تسجيل دخول المستخدم والطلبات في الثانية لواجهة برمجة تطبيقات معينة والعمليات في الثانية لعملية خلفية.

يجب استخدام قيم الحد لتطوير نموذج صحي للتطبيق الخاص بك، سواء للاختبار أو لتشغيل التطبيق في الإنتاج.

Visualization of key system flows using green and red connected circles.

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

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

Load test run results screen showing failed load test run.

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

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

2 - تنفيذ التحقق من الصحة باستخدام اختبار التحميل و Chaos Studio

يوفر Microsoft Azure هذه الخدمات المدارة لتنفيذ اختبار التحميل وهندسة الفوضى:

  • ينتج عن Azure Load Testing تحميل المستخدم الاصطناعي على التطبيقات والخدمات.
  • يوفر Azure Chaos Studio القدرة على إجراء تجربة الفوضى، من خلال إدخال حالات الفشل بشكل منهجي في مكونات التطبيق والبنية الأساسية.

يمكنك نشر وتكوين كل من Chaos Studio واختبار التحميل عبر مدخل Microsoft Azure، ولكن في سياق التحقق المستمر، من المهم أكثر أن يكون لديك واجهات برمجة التطبيقات لنشر الاختبارات وتكوينها وتشغيلها بطريقة برمجية وآلية. يتيح لك استخدام هاتين الأداتين معا مراقبة كيفية تفاعل النظام مع المشكلات وقدرته على المعالجة الذاتية استجابة لفشل البنية الأساسية أو التطبيق.

يظهر الفيديو التالي تنفيذا مجمعا لاختبار الفوضى والتحميل المتكامل في Azure DevOps:

إذا كنت تقوم بتطوير حمل عمل بالغ الأهمية للمهمة، فاستغل البنى المرجعية والإرشادات التفصيلية والتطبيقات النموذجية والأدوات البرمجية المقدمة كجزء من مشروع Azure Mission-Critical وإطار عمل Azure Well-Architected.

ينشر التنفيذ Mission-Critical خدمة اختبار التحميل عبر Terraform ويحتوي على مجموعة من البرامج النصية لبرنامج تضمين PowerShell Core للتفاعل مع الخدمة عبر واجهة برمجة التطبيقات الخاصة بها. يمكن تضمين هذه البرامج النصية مباشرة في البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع.

أحد الخيارات في التنفيذ المرجعي هو تنفيذ اختبار التحميل مباشرة من داخل البنية الأساسية لبرنامج ربط العمليات التجارية من طرف إلى طرف (e2e) التي تستخدم لتدوير بيئات التطوير الفردية (الخاصة بالفرع):

Run pipeline screen with the load testing checkbox ticked.

سيقوم المسار تلقائيا بتشغيل اختبار تحميل، مع تجارب الفوضى أو بدونها (اعتمادا على التحديد) بالتوازي:

Azure DevOps pipeline run with chaos and load testing.

إشعار

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

Chart showing increased response time during chaos experiment.

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

3 - ضبط الحدود وإنشاء خط أساس

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

توفر خدمة Azure Load Testing قدرة مضمنة تسمى معايير الاختبار التي تسمح بتحديد معايير معينة يحتاج الاختبار إلى اجتيازها. يمكن استخدام هذه الإمكانية لتنفيذ خطوط أساسية مختلفة.

Test criteria screen with response time and error criteria marked as Failed.

تتوفر الإمكانية من خلال مدخل Microsoft Azure، وعبر واجهة برمجة تطبيقات اختبار التحميل، وتوفر البرامج النصية لبرنامج التضمين التي تم تطويرها كجزء من Azure Mission-critical خيارا لتسليم تعريف أساس يستند إلى JSON.

نوصي بشدة بدمج هذه الاختبارات مباشرة في مسارات CI/CD وتشغيلها أثناء المراحل المبكرة من تطوير الميزات. على سبيل المثال، راجع نموذج التنفيذ في التنفيذ المرجعي ل Azure Mission-critical.

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

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

راجع منطقة تصميم التوزيع والاختبار لأحمال العمل الحرجة للمهام.

منطقة التصميم: النشر والاختبار