ayashosha/ghaymah-exam-ayashosha-sre
1
0
نسخ 0
الشفرة المشكلات طلبات السحب Actions Packages المشاريع الإصدارات الويكي النشاط
الملفات
main
ghaymah-exam-ayashosha-sre/q4-scalability/calculations.md
ayashosha 0a4a236f77 othe ffiles
2026-07-29 05:15:26 +03:00

6.3 KiB
خام الرابط الدائم اللوم التاريخ

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

    /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 سريع

المراجع