58 أسطر
3.2 KiB
Markdown
58 أسطر
3.2 KiB
Markdown
# Q4 — معمارية تطبيق يستقبل 15,000 req/s على غيمة
|
|
|
|
## Architecture Diagram
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
U[المستخدمون<br/>15,000 req/s] --> DNS[DNS<br/>ghaymah.systems / نطاق مخصص]
|
|
DNS --> LB["Load Balancer مُدار<br/>(SSL Termination + Health Checks)"]
|
|
|
|
LB --> AS["Auto-Scaling Group<br/>Container Fleet"]
|
|
|
|
subgraph Fleet["أسطول الحاويات (39 container - راجع calculations.md)"]
|
|
C1["Container 1<br/>g5.large"]
|
|
C2["Container 2<br/>g5.large"]
|
|
C3["..."]
|
|
C39["Container 39<br/>g5.large"]
|
|
end
|
|
|
|
AS --> C1
|
|
AS --> C2
|
|
AS --> C3
|
|
AS --> C39
|
|
|
|
C1 --> CACHE[("Redis Cache<br/>(Sessions / Hot Data)")]
|
|
C2 --> CACHE
|
|
C39 --> CACHE
|
|
|
|
C1 --> DB[("PostgreSQL مُدارة<br/>Primary + Read Replica")]
|
|
C2 --> DB
|
|
C39 --> DB
|
|
|
|
C1 --> BS[("Block Storage<br/>Uploads / Persistent Files")]
|
|
C39 --> BS
|
|
|
|
DB --> BK["نسخ احتياطي يومي/كل ساعة<br/>(ghaymah Backup)"]
|
|
|
|
subgraph Observability["المراقبة"]
|
|
MET[Metrics Collector]
|
|
LOGS[Log Aggregator]
|
|
ALERT[Alerting → Slack/Telegram]
|
|
end
|
|
|
|
C1 -.-> MET
|
|
C39 -.-> MET
|
|
MET --> ALERT
|
|
C1 -.-> LOGS
|
|
C39 -.-> LOGS
|
|
```
|
|
|
|
## قرارات التصميم
|
|
|
|
1. **Load Balancer مُدار أمام الأسطول:** يوزّع الحمل بخوارزمية round-robin/least-connections، ينهي SSL مركزياً بدل كل حاوية، ويستبعد الحاويات الفاشلة في health check تلقائياً — هذا يمنع نقطة فشل واحدة (single point of failure).
|
|
2. **Auto-Scaling Group بدل عدد ثابت:** الحمل نادراً ما يكون ثابتاً على مدار اليوم؛ نحتاج الحد الأدنى لتغطية 15K req/s + الهامش، لكن التوسع الإضافي (burst) يجب أن يكون تلقائياً بدل توفير أقصى سعة دائماً (توفير تكلفة).
|
|
3. **فصل التخزين المؤقت (Redis) عن قاعدة البيانات:** لتقليل الحمل على PostgreSQL في القراءات المتكررة (sessions، rate limiting counters)، وهذا ضروري عند 15K req/s لأن قاعدة بيانات واحدة لن تتحمل هذا الحجم من الاستعلامات المباشرة.
|
|
4. **PostgreSQL Primary + Read Replica:** فصل القراءة عن الكتابة يوزّع الحمل، ويحسّن التعافي من الكوارث (RTO أقل عند فشل Primary).
|
|
5. **Block Storage منفصل للحالة الدائمة (uploads):** الحاويات نفسها stateless وقابلة للاستبدال والتوسع الأفقي بحرية؛ أي بيانات يجب أن تبقى (ملفات مرفوعة) تُخزَّن في Block Storage مشترك بدل القرص المحلي للحاوية (الذي يُفقد عند إعادة الجدولة).
|
|
6. **مراقبة وتنبيه منفصلين (Observability layer):** لاكتشاف الانحرافات (زيادة زمن الاستجابة، ارتفاع معدل الأخطاء) قبل أن تتحول لانقطاع كامل، خصوصاً عند هذا الحجم من الحركة.
|