أنماط التوافر العالي والتعافي من الكوارث
التصميم للفشل هو كفاءة أساسية لمهندسي السحابة. هذا الدرس يغطي أنماط بناء أنظمة مرنة تحقق أهداف التوافر والتعافي.
مفاهيم التوافر
قياس التوافر
| التسعات | التوافر | التوقف/سنة | التوقف/شهر |
|---|---|---|---|
| تسعتان | 99% | 3.65 يوم | 7.3 ساعة |
| ثلاث تسعات | 99.9% | 8.77 ساعة | 43.8 دقيقة |
| أربع تسعات | 99.99% | 52.6 دقيقة | 4.4 دقيقة |
| خمس تسعات | 99.999% | 5.26 دقيقة | 26 ثانية |
تكوين SLA
للخدمات على التوالي:
إجمالي التوافر = الخدمة1 × الخدمة2 × ... × الخدمةN
مثال:
موازن الحمل (99.99%) × خادم التطبيق (99.9%) × قاعدة البيانات (99.95%)
= 0.9999 × 0.999 × 0.9995
= 99.84%
للخدمات بالتوازي:
إجمالي التوافر = 1 - (1 - الخدمة1) × (1 - الخدمة2)
مثال: قاعدتا بيانات (99.95% كل منهما):
= 1 - (1 - 0.9995)²
= 1 - 0.00000025
= 99.999975%
سؤال المقابلة: تحقيق 99.99%
س: "كيف تصمم تطبيق ويب لتحقيق توافر 99.99%؟"
ج: هندسة معمارية متعددة AZ مع تكرار في كل طبقة:
الهندسة المعمارية:
Route 53 (100% SLA)
↓
CloudFront (99.9%)
↓
ALB - Multi-AZ (99.99%)
↓
EC2 ASG - Multi-AZ (99.99% مع التكرار)
↓
Aurora Multi-AZ (99.99%)
الممارسات الرئيسية:
1. لا نقاط فشل واحدة
2. التوسع التلقائي للسعة
3. فحوصات الصحة والاستبدال التلقائي
4. طبقة تطبيق بدون حالة
5. تجاوز فشل قاعدة البيانات < 30 ثانية
أنماط التوافر العالي
نشط-نشط
مثيلات متعددة تخدم حركة المرور في وقت واحد.
┌─────────────────┐
│ موازن الحمل │
└────────┬────────┘
┌───────────┼───────────┐
▼ ▼ ▼
[App AZ-a] [App AZ-b] [App AZ-c]
│ │ │
└───────────┴───────────┘
▼
[كتلة قاعدة البيانات]
الخصائص:
- جميع المثيلات تتعامل مع الطلبات
- الحمل موزع عبر المثيلات
- تجاوز فشل فوري (تخدم بالفعل)
- تكلفة أعلى (جميع الموارد نشطة)
نشط-سلبي
الأساسي يتعامل مع حركة المرور؛ الاحتياطي ينتظر.
[المنطقة النشطة - us-east-1] [المنطقة السلبية - us-west-2]
│ │
[خوادم التطبيق] [الخوادم الاحتياطية]
│ │
[قاعدة البيانات الأساسية] ──── النسخ ───► [النسخة]
الخصائص:
- الاحتياطي يستهلك موارد لكن لا يخدم
- التجاوز يتطلب ترقية (دقائق)
- تكلفة أقل من نشط-نشط
- RPO يعتمد على تأخر النسخ
سؤال المقابلة: نشط-نشط مقابل نشط-سلبي
س: "متى تختار نشط-سلبي على نشط-نشط؟"
ج: اعتبر هذه العوامل:
| العامل | نشط-نشط | نشط-سلبي |
|---|---|---|
| RTO المطلوب | < 1 دقيقة | الدقائق مقبولة |
| حساسية التكلفة | يمكن تحمل 2x السعة | تحتاج تحسين التكلفة |
| اتساق البيانات | يمكن التعامل مع تأخر النسخ | تحتاج اتساقاً قوياً |
| توزيع حركة المرور | يستفيد من التوزيع الجغرافي | حركة المرور المركزية مقبولة |
| تحمل التعقيد | يمكن إدارة حالة متعددة المناطق | تفضل البساطة |
استراتيجيات التعافي من الكوارث
تصنيف DR
| الاستراتيجية | RTO | RPO | التكلفة | مثال |
|---|---|---|---|---|
| النسخ الاحتياطي والاستعادة | ساعات | ساعات | $ | الاستعادة من S3 |
| الضوء التجريبي | دقائق | دقائق | $$ | بنية تحتية دنيا قيد التشغيل |
| الاحتياطي الدافئ | دقائق | ثوانٍ | $$$ | نسخة مخفضة الحجم |
| الاحتياطي الساخن | ثوانٍ | صفر | $$$$ | نسخة كاملة |
⚠ Prices change frequently. The values above are for illustration only and may be out of date. Always verify current pricing directly with the provider before making cost decisions: Anthropic · OpenAI · Google Gemini · Google Vertex AI · AWS Bedrock · Azure OpenAI · Mistral · Cohere · Together AI · DeepSeek · Groq · Fireworks AI · Perplexity · xAI · Cursor · GitHub Copilot · Windsurf.
نمط الضوء التجريبي
احتفظ بالأنظمة الحرجة تعمل بالحد الأدنى:
المنطقة الأساسية: منطقة DR:
├── خوادم تطبيق كاملة ├── (لا شيء - توسع من صفر)
├── قاعدة بيانات كاملة ├── نسخة قاعدة البيانات (قيد التشغيل)
└── ذاكرة مخبأة كاملة └── AMIs جاهزة للإطلاق
خطوات التعافي:
- نسخة قاعدة البيانات متزامنة بالفعل
- إطلاق خوادم التطبيق من AMIs
- التوسع للسعة المطلوبة
- تحديث DNS
نمط الاحتياطي الدافئ
نسخة بسعة مخفضة:
الأساسي (100% سعة): DR (20% سعة):
├── 10 خوادم تطبيق ├── 2 خوادم تطبيق
├── db.r6g.4xlarge ├── db.r6g.large
└── بنية تحتية كاملة └── بنية تحتية دنيا
خطوات التعافي:
- توسيع خوادم تطبيق DR
- ترقية نسخة قاعدة البيانات (أو تغيير الحجم)
- إعادة توجيه حركة المرور (DNS أو فحص صحة Route 53)
سؤال المقابلة: اختيار استراتيجية DR
س: "شركة رعاية صحية تحتاج DR لنظام سجلات المرضى. RTO: 15 دقيقة، RPO: 5 دقائق. أي استراتيجية؟"
ج: الاحتياطي الدافئ مناسب:
لماذا:
- RTO 15 دقيقة يسمح بوقت للتوسع
- RPO 5 دقائق قابل للتحقيق مع النسخ غير المتزامن (تأخر < 1 دقيقة نموذجي)
- الرعاية الصحية لا تحتاج تجاوزاً فورياً (ليس تداولاً في الوقت الحقيقي)
- فعال من حيث التكلفة للمتطلبات
التنفيذ:
الأساسي (us-east-1):
- Aurora Primary (Multi-AZ)
- ECS Fargate (10 مهام)
DR (us-west-2):
- Aurora Read Replica (يُرقَّى عند التجاوز)
- ECS Fargate (2 مهمة، تُوسَّع عند التجاوز)
المراقبة:
- فحوصات صحة Route 53
- دليل تشغيل آلي في Systems Manager
- اختبار DR منتظم (ربع سنوي)
أنماط المرونة
قاطع الدائرة
منع الفشل المتتالي:
class CircuitBreaker:
def __init__(self, failure_threshold=5, timeout=30):
self.failure_count = 0
self.threshold = failure_threshold
self.timeout = timeout
self.state = 'CLOSED' # CLOSED, OPEN, HALF_OPEN
def call(self, func):
if self.state == 'OPEN':
if time_since_open > self.timeout:
self.state = 'HALF_OPEN'
else:
raise CircuitOpenError()
try:
result = func()
self.on_success()
return result
except Exception as e:
self.on_failure()
raise
نمط الحاجز
عزل الفشل لمنع فشل النظام الكلي:
حاجز تجمع الخيوط:
├── التجمع 1: خدمة الدفع (10 خيوط)
├── التجمع 2: خدمة المخزون (10 خيوط)
└── التجمع 3: خدمة الشحن (5 خيوط)
إذا استنفدت خدمة الدفع الخيوط،
تستمر خدمة المخزون والشحن في العمل.
إعادة المحاولة مع التراجع الأسي
التعامل مع الفشل العابر:
def retry_with_backoff(func, max_retries=5, base_delay=1):
for attempt in range(max_retries):
try:
return func()
except TransientError:
if attempt == max_retries - 1:
raise
delay = base_delay * (2 ** attempt) + random.uniform(0, 1)
time.sleep(delay)
سؤال المقابلة: استراتيجية المرونة
س: "خدمتك تستدعي ثلاث APIs خارجية. كيف تجعلها مرنة؟"
ج: نفذ مرونة متعددة الطبقات:
1. المهلات: فشل سريع (1-5 ثوانٍ)
2. قاطع الدائرة: توقف عن استدعاء الخدمات الفاشلة
3. إعادة المحاولة: مع تراجع أسي + تذبذب
4. الحاجز: تجمعات خيوط/اتصالات معزولة
5. البديل: تدهور رشيق
مثال التكوين:
Payment API:
- المهلة: 3 ثوانٍ
- الدائرة: تفتح بعد 5 فشلات، استعادة 30 ثانية
- إعادة المحاولة: 3 محاولات، تراجع أسي
- البديل: وضع في قائمة انتظار للمعالجة لاحقاً
Inventory API:
- المهلة: 2 ثانية
- الدائرة: تفتح بعد 3 فشلات، استعادة 15 ثانية
- إعادة المحاولة: 2 محاولات
- البديل: إرجاع المخزون المخبأ
مبدأ الهندسة المعمارية: صمم للفشل. كل تبعية خارجية ستفشل في النهاية. مرونة نظامك تحدد تجربة المستخدم أثناء الفشل.
هذا يختتم وحدة أنماط الهندسة المعمارية. اختبر معرفتك مع اختبار الوحدة. :::