تصميم تجارب الفوضى
يجب أن يكون تطبيقك بالغ الأهمية مرنا وأن يكون جاهزا للاستجابة لحالات الفشل. ولكن، من الصعب التنبؤ بسيناريوهات الفشل المحتملة في السحابة. تسمح لك هندسة الفوضى بإجراء تجارب الفشل في بيئة خاضعة للرقابة لتحديد المشكلات التي من المحتمل أن تنشأ أثناء التطوير والنشر. يمكنك إدخال أخطاء العالم الحقيقي عن عمد ومراقبة كيفية تفاعل النظام.
في هذه الوحدة، سنستخدم Azure Chaos Studio. ستساعدك الخدمة على قياس التطبيق السحابي ومرونة الخدمة وفهمهما وتحسينهما. ستكون مستعدا للاستجابة بسرعة إذا حدث هذا الفشل في ظل ظروف معاكسة في الإنتاج.
إجراء تحليل وضع الفشل
عند تصميم تجربة فوضى، فإن الخطوة الأولى هي إجراء تحليل وضع الفشل (FMA) لمكونات التطبيق لتحديد سيناريوهات الفشل المحتملة.
سرد جميع المكونات ذات الصلة بتدفق المستخدم التي تحتاج إلى أن تكون متاحة ووظائف. على سبيل المثال، يستخدم تدفق مستخدم السداد مع الخروج قاعدة بيانات Azure App Services و Functions و Cosmos DB.
لكل مكون، قم بإدراج حالات الفشل المحتملة وتأثيرها وأي عوامل تخفيف محتملة.
دعونا نر نتيجة FMA التي تم إجراؤها لمكونات مثال تدفق مستخدم السداد مع الخروج من Contoso Shoes.
Azure App Service لاستضافة تطبيق الواجهة الأمامية
| مخاطر | تأثير | التخفيف المحتمل |
|---|---|---|
| انقطاع منطقة التوفر | قد تصبح المثيلات في تلك المنطقة غير متوفرة. لا يتوقع حدوث انقطاع كامل لأن التكرار في المنطقة ممكن على خطة App Service. | السماح بالتحميل الإضافي على المثيلات المتبقية وتوفير مساحة رأس كافية لهذا السيناريو مع تحقيق أهداف الأداء. |
| استنفاد منفذ SNAT | لا يمكن إنشاء الاتصالات الصادرة. ونتيجة لذلك، تفشل استدعاءات انتقال البيانات من الخادم، مثل الاستدعاءات إلى قاعدة البيانات. | استخدم نقاط النهاية الخاصة للاتصال بمكونات انتقال البيانات من الخادم. |
| يصبح المثيل الفردي غير صحي | قد ترى نسبة استخدام الشبكة للمستخدم التي تم توجيهها إلى مثيل غير سليم أداء ضعيفا أو حتى تفشل تماما. | ستؤدي ميزة التحقق من صحة App Service إلى تحديد المثيلات غير السليمة تلقائيا واستبدالها بمثيلات جديدة وصحية. |
Azure Functions لمنطق السداد مع الخروج
| مخاطر | تأثير | التخفيف المحتمل |
|---|---|---|
| أداء البدء البطيء (البارد) | نظرا لاستخدام خطة استهلاك وظائف Azure، لن يكون لدى المثيلات الجديدة ضمانات للأداء. قد يتسبب الطلب المرتفع على الخدمة (من "الجيران المزعجين") في أن تواجه وظيفة السداد مع الخروج مدة بدء تشغيل طويلة تؤثر على أهداف الأداء. | الترقية إلى خطة Azure Functions Premium. |
| انقطاع التخزين الأساسي | إذا أصبح حساب التخزين الأساسي غير متوفر، فستتوقف الدالة عن العمل. | استخدم الحوسبة المتوازنة التحميل مع التخزين الإقليمي أو تحميل حساب متوازن مع التخزين المشترك GRS. |
قاعدة بيانات Azure Cosmos DB
| مخاطر | تأثير | التخفيف المحتمل |
|---|---|---|
| إعادة تسمية قاعدة بيانات أو مجموعة | بسبب عدم التطابق في التكوين، قد يكون هناك فقدان للبيانات. لن يتمكن التطبيق من الوصول إلى أي بيانات حتى يتم تحديث التكوين وإعادة تشغيل مكوناته. | منع هذا الموقف باستخدام قاعدة البيانات والتأمين على مستوى المجموعة. |
| كتابة انقطاع المنطقة | إذا واجهت المنطقة الأساسية (أو منطقة الكتابة) انقطاعا، سيقوم حساب Azure Cosmos DB تلقائيا بترقية منطقة ثانوية لتكون منطقة الكتابة الأساسية الجديدة عند تكوين تجاوز الفشل التلقائي (المدار بواسطة الخدمة) على حساب Azure Cosmos DB. سيحدث تجاوز الفشل لمنطقة أخرى حسب أولوية المنطقة التي حددتها. | تكوين حساب قاعدة البيانات مع مناطق متعددة وتجاوز الفشل التلقائي. إذا كان هناك فشل، فستفشل الخدمة تلقائيا وتمنع أي مشكلات مستمرة في التطبيق. |
| تقييد واسع النطاق بسبب نقص وحدات الطلب (RUs) | قد تعمل بعض الطوابع الساخنة على استخدام Azure Cosmos DB بينما لا يزال بإمكان الآخرين تقديم الطلبات. | استخدم توزيع تحميل أفضل لمزيد من الطوابع، أو إضافة المزيد من وحدات الطلب. |
تصميم تجربة فوضى
لتصميم تجربة فوضى، اختر بعض حالات الفشل. يمكن أن يستند الاختيار إلى احتمال حدوث الفشل أو التأثير المحتمل.
الهدف من التجربة هو التحقق من صحة مقاييس المرونة التي قمت بتنفيذها في التطبيق الخاص بك. على سبيل المثال فرضية، افترض أنك قمت بتشغيل التطبيق الخاص بك على App Service مع تمكين تكرار المنطقة. إذا كانت جميع المثيلات الأساسية في منطقة ما معطلة، تتوقع أن يظل التطبيق قيد التشغيل.
استخدم Chaos Studio لإدخال الأخطاء في المكونات ذات الصلة. تقدم Chaos Studio مكتبة من الأخطاء للاختيار من بينها. ومع ذلك، نظرا لأن مكتبة الخطأ لا تغطي كل شيء، فقد تحتاج إلى ضبط السيناريو الخاص بك. أو قد تحتاج إلى العثور على المزيد من الأدوات لمساعدتك على حقن الفشل.
هام
استهداف بيئة غير إنتاجية فقط مع تجاربك. يمكن أن يكون إدخال الأخطاء في بيئة الإنتاج الخاصة بك محفوفا بالمخاطر ويتطلب خبرة وتخطيطا.
مثال: انقطاع Azure Cosmos DB وتجاوز الفشل
لنفترض أنك اخترت سيناريو فشل "انقطاع منطقة الكتابة" ل Azure Cosmos DB المدرج في الجدول. الفرضية هي: لا يجب أن يؤدي تجاوز الفشل الذي بدأته الخدمة إلى أي تأثير مستمر على التطبيق. إذا ثبت أن هذه الفرضية صحيحة، فقد تحققت من أن مقياس المرونة الخاص بك للنسخ المتماثل إلى مناطق متعددة له التأثير الإيجابي المطلوب على موثوقية التطبيق.
لمحاكاة هذا الخطأ، استخدم فشل Azure Cosmos DB من مكتبة خطأ Chaos Studio.
هذا المثال مخصص لتجاوز فشل Azure Cosmos DB الذي يعمل لمدة 10 دقائق (PT10M) ويستخدم West US 2 كمنطقة كتابة جديدة. يفترض أنه West US 2 تم إعداده بالفعل كأحد مناطق النسخ المتماثل للقراءة.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
بعد انتهاء التجربة، يقوم Chaos Studio بتبديل منطقة الكتابة مرة أخرى إلى قيمتها الأصلية.
قبل أن تتمكن من إدخال خطأ مقابل مورد Azure، يجب تمكين إعداد الأهداف والقدرات المقابلة لهذا المورد. يتحكم هذا الإعداد في الأخطاء التي يمكن تشغيلها مقابل الموارد الممكنة لإدخال الخطأ. عند استخدام الأهداف والقدرات مع تدابير الأمان الأخرى، يمكنك تجنب حقن الخطأ العرضي أو الضار.
الآن بعد أن قمت بتصميم اختبارات التحميل وتجارب الفوضى، تحتاج إلى أتمتتها في خطوط الأنابيب الخاصة بك بحيث تعمل بشكل مستمر ومنتظم. في الوحدة التالية، ستتعرف على إضافة الاختبارات الخاصة بك CI/CD pipelines.