Ghaymah SRE exam submission - Mohamed Adel

q4-scalability/calculations.md

@@ -0,0 +1,79 @@
+# Q4 — قابلية التوسع وتوزيع الأحمال
+
+## 1. Architecture Diagram
+
+انظر `architecture.png` في نفس المجلد. المكونات الأساسية:
+
+- **Clients → DNS → Load Balancer (Ghaymah LB):** توزيع الطلبات على الحاويات المتاحة بالتساوي (round-robin / least-connections).
+- **Container Pool (Auto-scaled):** مجموعة حاويات متطابقة بلا حالة (stateless)، يتحكم فيها Autoscaler بناءً على معدل الطلبات (RPS) واستهلاك CPU.
+- **Cache Layer (Redis):** يمتص جزءًا كبيرًا من الحمل عن قاعدة البيانات للبيانات المتكررة القراءة.
+- **Ghaymah Block Storage:** لتخزين أي بيانات يجب أن تبقى (stateful) بمعزل عن دورة حياة الحاوية القصيرة.
+- **Managed DB (Primary + Replica):** طبقة البيانات الدائمة.
+- **Monitoring & Health Checks:** يراقب كل حاوية ويغذي قرار التوسع (autoscaler) وينبه عند الأعطال.
+
+## 2. حساب عدد الحاويات المطلوبة
+
+**المعطيات:**
+- الحمل المطلوب: 15,000 req/s
+- سعة الحاوية الواحدة: 500 req/s
+- هامش أمان (Safety Margin): 30%
+
+**الحساب:**
+
+```
+عدد الحاويات الأساسي = 15,000 / 500 = 30 حاوية
+
+مع هامش أمان 30%:
+عدد الحاويات النهائي = 30 × 1.30 = 39 حاوية
+```
+
+**النتيجة: 39 حاوية (container replicas)**
+
+**لماذا الهامش مهم:**
+- يمتص أي تذبذب مفاجئ في الحمل (spike) دون انتظار دورة scale-up كاملة.
+- يحافظ على أداء مستقر إذا كانت إحدى الحاويات تحت صيانة أو أعيد تشغيلها (rolling restart / deployment).
+- يمنع الوصول لحافة السعة القصوى للحاوية، وهو ما يقلل احتمال تكرار مشاكل مثل OOMKilled الموضحة في Q2.
+
+**توصية عملية للإعداد على غيمة:**
+```yaml
+min_replicas: 15     # يغطي حمل أساسي منخفض في أوقات الهدوء
+max_replicas: 45      # يغطي 39 المطلوبة + هامش إضافي لأي spike غير متوقع
+target_rps_per_replica: 500
+scale_up_cooldown: 60s
+scale_down_cooldown: 300s
+```
+البدء بـ `min_replicas` أقل من الرقم النهائي (39) مع autoscaler سريع الاستجابة أفضل من تثبيت 39 حاوية دائمًا، لأنه يوفر التكلفة في أوقات الحمل المنخفض ويتوسع تلقائيًا وقت الذروة.
+
+## 3. استراتيجية Cold Start للحاويات الجديدة
+
+المشكلة: عندما يضيف الـ Autoscaler حاوية جديدة فجأة، تحتاج وقتًا لتصبح "جاهزة" (تحميل التطبيق، فتح اتصالات DB، تسخين الـ cache المحلي)؛ خلال هذا الوقت قد تستقبل طلبات وهي غير جاهزة فعليًا فتفشل أو تكون بطيئة.
+
+**الاستراتيجية المقترحة:**
+
+1. **Readiness Probe منفصلة عن Liveness Probe:**
+   الحاوية لا تدخل ضمن قائمة الـ Load Balancer إلا بعد نجاح `/ready` (وليس فقط `/health`)، بحيث لا تستقبل طلبات وهي لسه بتشتغل.
+
+2. **Pre-warming تدريجي (Gradual Traffic Ramp-up):**
+   بدل ما الحاوية الجديدة تستقبل حصتها الكاملة من الطلبات فورًا، الـ Load Balancer يزيد نسبة الطلبات الموجهة لها تدريجيًا على مدار 30-60 ثانية (weighted routing) حتى تثبت جاهزتها تمامًا.
+
+3. **Predictive / Proactive Scaling بدل Reactive فقط:**
+   الاعتماد على نمط الحمل التاريخي (مثلاً: ذروة يومية معروفة الوقت) لبدء إضافة حاويات قبل الذروة الفعلية بدقائق، بدلاً من الانتظار حتى يرتفع الحمل فعليًا ثم البدء في cold start وقت الضغط.
+
+4. **Minimum warm pool:**
+   الاحتفاظ بعدد صغير من الحاويات "دافئة" فوق الحد الأدنى الفعلي (buffer بسيط)، بحيث أي زيادة مفاجئة تُستوعب فورًا من حاويات جاهزة بينما الـ Autoscaler يبدأ حاويات جديدة بالتوازي لتعويض الـ buffer.
+
+5. **تقليل زمن الإقلاع نفسه (Application-level):**
+   صور Docker خفيفة (multi-stage build، slim base image)، تأجيل تحميل أي بيانات غير ضرورية عند بدء التشغيل، واستخدام connection pooling بدل فتح اتصال جديد لكل حاوية عند الإقلاع.
+
+## 4. استخدام Ghaymah Block Storage للـ Stateful Workloads
+
+الحاويات في `Container Pool` بلا حالة (stateless) بتصميم — أي حاوية ممكن تتوقف أو تتجدد في أي وقت بدون فقدان بيانات، لأن أي بيانات يجب أن تبقى تُخزَّن خارج الحاوية نفسها.
+
+**أين يُستخدم Ghaymah Block Storage هنا:**
+
+- **ملفات يرفعها المستخدمون** (uploads، صور، مرفقات) — تُخزَّن على Block Storage مشترك بدل القرص المحلي للحاوية، بحيث أي حاوية (أيًا كانت) تقدر توصل لنفس الملف.
+- **بيانات تحتاج استمرارية بين إعادة التشغيل**: مثل قواعد بيانات محلية صغيرة، أو أنظمة قوائم انتظار (queues) تحتفظ بحالتها على القرص.
+- **Logs مؤقتة أو ملفات cache كبيرة** لا تناسب حجمها الذاكرة (RAM) لكن يجب أن تبقى بين عمليات إعادة التشغيل لتحليلها لاحقًا.
+
+**لماذا هذا التصميم مهم لقابلية التوسع تحديدًا:**
+عندما يزيد الـ Autoscaler عدد الحاويات من 15 إلى 39 (كما في القسم 2)، كل حاوية جديدة تحتاج "ترى" نفس البيانات المشتركة فورًا دون نسخها يدويًا — وهو بالضبط ما يوفره Block Storage كطبقة تخزين مستقلة عن دورة حياة الحاوية، بعكس تخزين البيانات على القرص المحلي للحاوية والذي يختفي بمجرد إعادة تشغيلها أو استبدالها.