Yousifhamdy7/ghaymah-exam--Yousifhamdyamin---SRE-
1
0
نسخ 0
الشفرة المشكلات طلبات السحب Actions Packages المشاريع الإصدارات الويكي النشاط
الملفات
55335f5faa2a7a1b9b260b8a8fe4c3e551fe0cdf
ghaymah-exam--Yousifhamdyam…/q4-scalability/calculations.md

5.5 KiB
خام اللوم التاريخ

Q4 — الحسابات والاستراتيجيات

1. حساب عدد الحاويات المطلوبة

المعطيات:

  • الحمل المستهدف: 15,000 req/s
  • سعة الحاوية الواحدة: 500 req/s
  • هامش أمان: 30% (لتغطية تذبذب الحمل، فشل حاوية واحدة أو أكثر أثناء rolling deploys، وتفادي التشغيل عند 100% سعة القصوى باستمرار)

الحساب:

الحمل المطلوب توفير سعة له = 15,000 req/s × 1.30 (هامش 30%) = 19,500 req/s
عدد الحاويات = 19,500 ÷ 500 req/s لكل حاوية = 39 حاوية

بدون الهامش، الحد الأدنى النظري هو 30 حاوية (15,000 ÷ 500). لكن التشغيل عند 100% من السعة القصوى بدون أي هامش يعني أن أي زيادة طفيفة في الحمل أو فقدان حاوية واحدة يسبب تدهوراً فورياً في الأداء أو انقطاعاً جزئياً؛ لذلك 39 حاوية هي الرقم الآمن للتشغيل الفعلي.

التوصية العملية:

  • min_replicas: 39 (أو 40 للتقريب لأعلى وسهولة القسمة على مناطق التوفر)
  • max_replicas: 60 لاستيعاب حالات الذروة غير المتوقعة (حملات تسويقية، فيروسية) دون تدخل يدوي
  • توزيع الـ 39 حاوية على 3 مناطق توفر (availability zones) إن كانت متاحة على غيمة، بمعدل 13 حاوية لكل منطقة، لتحمّل فشل منطقة كاملة.

2. استراتيجية Cold Start للحاويات الجديدة

المشكلة: عند التوسع الأفقي المفاجئ (scale-out)، الحاوية الجديدة تحتاج وقتاً لسحب الصورة، بدء العملية، والاتصال بقاعدة البيانات — خلال هذا الوقت هي غير جاهزة لاستقبال حركة، وإن استقبلتها مبكراً جداً ستفشل الطلبات.

الحل المقترح:

  1. صور خفيفة ومُحسّنة (Slim Images): استخدام python:3.12-slim أو صور alpine بدل الصور الكاملة، وطبقات Docker مُخزّنة مسبقاً (layer caching) في سجل الحاويات — يقلل زمن السحب من ثوانٍ لأجزاء من الثانية.
  2. Warm Pool (نسخ جاهزة مسبقاً): الاحتفاظ بعدد صغير من الحاويات "دافئة" (مبدوءة لكن idle، غير مستقبلة لحركة بعد) جاهزة للتفعيل الفوري عند الحاجة، بدل بدء حاوية من الصفر عند كل قرار توسع.
  3. Readiness Probe صارم قبل استقبال الحركة: الحاوية لا تنضم لـ Load Balancer إلا بعد نجاح /health عدة مرات متتالية (وليس فقط بعد بدء العملية) — هذا يمنع توجيه حركة لحاوية لم تكتمل تهيئتها بعد (مثل اتصال قاعدة البيانات).
  4. Predictive/Scheduled Scaling: إذا كان نمط الحمل معروفاً (ذروة صباحية، حملة مجدولة)، جدولة توسّع استباقي قبل الذروة الفعلية بـ 5-10 دقائق بدل الانتظار لتفاعل reactive.
  5. Connection Pooling عند بدء التشغيل: تهيئة connection pool لقاعدة البيانات كجزء من startup script قبل الإعلان عن الجاهزية، لتفادي زمن اتصال إضافي عند أول طلب حقيقي.

3. استخدام ghaymah Block Storage لـ Stateful Workloads

الحاويات في هذه المعمارية stateless بالتصميم (قابلة للحذف والاستبدال والتوسع بحرية)، لكن بعض الأعباء تحتاج تخزيناً دائماً:

  • ملفات المستخدمين المرفوعة (uploads): صور، مستندات — تُخزَّن على Block Storage بدل القرص المحلي للحاوية، لأن القرص المحلي يُفقد عند إعادة جدولة الحاوية أو استبدالها أثناء التوسع.
  • قواعد البيانات (PostgreSQL المُدارة): تعتمد داخلياً على Block Storage عالي الأداء (IOPS مرتفع) لضمان دوام البيانات واستمرارها حتى لو أُعيد تشغيل الحاوية التي تستضيف محرك قاعدة البيانات.
  • التوصيل: حجم Block Storage واحد يمكن ربطه بحاوية أو خدمة واحدة في كل مرة (وليس مشتركاً بين عدة حاويات كتابة متزامنة إلا إذا كان النظام يدعم ذلك)؛ لذلك في هذه المعمارية، Block Storage يُربط بخدمة قاعدة البيانات وليس مباشرة بكل حاوية من الـ 39.
  • النسخ الاحتياطي: الاستفادة من ميزة النسخ الاحتياطي كل ساعة (متوفرة من خطة g5.large فما فوق) على مستوى Block Storage نفسه، بشكل منفصل عن نسخ قاعدة البيانات المنطقية، لتغطية سيناريوهات تلف على مستوى التخزين.
  • التوسعة الفورية: عند نمو حجم البيانات، يمكن توسعة حجم Block Storage مباشرة ($0.10/GB/شهر إضافية) دون إعادة نشر التطبيق بالكامل.