# Q4 — قابلية التوسع وتوزيع الأحمال

## 1. Architecture Diagram

راجع الملف `architecture.png` في هذا المجلد.

يوضّح المخطط تدفّق **15,000 req/s** عبر:

| الطبقة | المكوّن | الدور |
|--------|---------|-------|
| Edge | Ghaymah Load Balancer (L7) | توزيع الطلبات، SSL، Health Checks |
| Compute | Auto Scaling Group — 43 حاوية | معالجة الطلبات (500 req/s لكل حاوية) |
| Stateful | Ghaymah Block Storage | تخزين دائم للـ stateful workloads |
| Cache/CDN | Object Storage / CDN | الملفات الثابتة والوسائط |
| Ops | Monitoring & Alerts | مقاييس، تنبيهات، قرارات التوسع |
| Warm Pool | Cold Start Pool | حاويات مُسخَّنة مسبقاً لتقليل زمن الإقلاع |

---

## 2. حساب عدد الحاويات

### المعطيات

| المتغير | القيمة |
|---------|--------|
| إجمالي الحمل | **15,000 req/s** |
| سعة الحاوية الواحدة | **500 req/s** |
| هامش الأمان | **30%** |

### المنطق

الهامش 30% يعني **عدم تشغيل الحاويات فوق 70%** من سعتها القصوى، لترك مساحة للذروات والتقلبات:

```
السعة الفعلية القابلة للتخطيط = 500 × (1 − 0.30) = 500 × 0.70 = 350 req/s لكل حاوية
```

### الحساب

```
عدد الحاويات = ⌈ 15,000 ÷ 350 ⌉
             = ⌈ 42.857 ⌉
             = 43 حاوية
```

### التحقق

```
43 × 350 = 15,050 req/s  ✅ (يغطي 15,000 req/s مع هامش 30%)
```

### ملخص

| البند | القيمة |
|-------|--------|
| الحد الأدنى نظرياً (بدون هامش) | 30 حاوية |
| **العدد الموصى به (مع هامش 30%)** | **43 حاوية** |
| السعة الإجمالية الفعلية | 15,050 req/s |
| نسبة الاستخدام عند 15K req/s | ≈ 99.7% من السعة المُخطَّطة |

> **ملاحظة:** إذا قصدت إضافة 30% فوق العدد الأساسي: `30 × 1.30 = 39 حاوية`.  
> في سياق SRE، هامش السعة (capacity headroom) هو التفسير الأدق — أي 43 حاوية.

---

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

عند التوسع الأفقي (scale-out)، الحاوية الجديدة تحتاج وقتاً قبل أن تستقبل حركة. الاستراتيجية المقترحة:

### أ) Warm Pool (مجموعة تسخين)

- الإبقاء على **3–5 حاويات جاهزة** في حالة `standby` (مُشغَّلة ومُسخَّنة، لكن خارج rotation الـ Load Balancer).
- عند ارتفاع الحمل، تُضاف فوراً إلى الـ LB **بدون** انتظار pull للصورة أو boot.

### ب) Pre-pull الصور

- تخزين صورة Docker في **Ghaymah Internal Registry** داخل نفس المنطقة.
- تقليل زمن `image pull` من دقائق إلى ثوانٍ.

### ج) Readiness Probe تدريجي

```
Startup Probe  →  Readiness Probe  →  إضافة للـ LB
     (30s)              (HTTP /health)
```

- لا تُوجَّه الطلبات للحاوية حتى تمر `/health` بنجاح.
- يمنع إرسال حركة لحاوية لم تكتمل تهيئتها.

### د) Graceful Scale-In

- عند التقليص: إرسال `SIGTERM` → انتظار إنهاء الطلبات الجارية (drain) → إزالة من LB → إيقاف.
- يمنع قطع الطلبات أثناء التوسع العكسي.

### هـ) Predictive Scaling

- مراقبة CPU / RPS / latency.
- بدء التوسع **قبل** الوصول للحد (مثلاً عند 60% utilization) وليس عند 90%.

### ف) Application Warm-up

- عند الإقلاع: تحميل cache محلي، pre-connect لقاعدة البيانات، JIT warm-up.
- endpoint `/warmup` يُستدعى تلقائياً بعد readiness.

---

## 4. Ghaymah Block Storage للـ Stateful Workloads

### ما هو Block Storage؟

تخزين **كتلة (block-level)** يُ attach كقرص افتراضي (volume) لحاوية أو خدمة — مثل `/dev/vdb` — ويحتفظ بالبيانات **بعد** إعادة تشغيل أو استبدال الحاوية.

### متى نستخدمه؟

| Stateful | Stateless (لا يحتاج Block Storage) |
|----------|-------------------------------------|
| PostgreSQL / MySQL | API servers (43 حاوية أعلاه) |
| Redis persistence (AOF/RDB) | Static assets → Object Storage |
| File uploads / media processing | Session في Redis مشترك |
| Logs طويلة الأمد | |

### كيف يُستخدم على غيمة؟

1. **إنشاء Volume**  
   - حجم مناسب (مثلاً 100 GB SSD) في نفس منطقة التطبيق.

2. **Mount على الحاوية Stateful**  
   ```text
   /data/postgresql  ←  Ghaymah Block Volume (persistent)
   ```

3. **فصل Compute عن Storage**  
   - حاويات الـ API **stateless** — تتوسع أفقياً بحرية.
   - قاعدة البيانات **stateful** — volume واحد (أو cluster مع replication).

4. **Snapshots & Backup**  
   - Ghaymah Backup: snapshots دورية للـ volume.
   - استرداد Point-in-Time عند الفشل.

5. **High Availability**  
   - Primary DB على volume + Replica على volume منفصل.
   - Failover تلقائي عند سقوط Primary.

### في مخططنا (architecture.png)

```
Load Balancer → 43 App Containers (stateless)
                      ↓
              Stateful DB Pod ← Ghaymah Block Storage (persistent volume)
```

- الـ **43 حاوية** لا تخزّن state محلياً.
- كل البيانات الدائمة على **Block Storage** م attached لطبقة DB/Cache الم persistent.

### الفوائد

| الفائدة | الشرح |
|---------|--------|
| Persistence | البيانات تبقى بعد restart/redeploy |
| Performance | IOPS مضمون لقواعد البيانات |
| Scalability | فصل التوسع الأفقي (API) عن التخزين (DB) |
| DR | Snapshots + restore سريع |

---

## المراجع

- [Ghaymah Cloud](https://ghaymah.systems/)
- [Ghaymah CLI — `gy resource app launch`](https://cli.ghaymah.systems/)
- Health & Retry: HTTP/TCP probes — down-nodes تخرج فوراً من rotation