41 أسطر
1.7 KiB
Markdown
41 أسطر
1.7 KiB
Markdown
# Scalability and Load Balancing
|
||
|
||
## 2. Calculating the Number of Containers Required
|
||
|
||
**Given:**
|
||
- Total load: 15,000 req/s
|
||
- Capacity per container: 500 req/s
|
||
- Safety margin: 30%
|
||
|
||
**Calculation:**
|
||
|
||
```
|
||
Effective load = 15,000 × 1.3 = 19,500 req/s
|
||
Number of containers = 19,500 ÷ 500 = 39 containers
|
||
```
|
||
|
||
**Result: 39 containers**
|
||
|
||
Check: 15,000 ÷ 39 ≈ 385 req/s per container (≈ 77% of max capacity), leaving a ~23% margin to absorb sudden spikes in load.
|
||
|
||
---
|
||
|
||
## 3. Cold Start Strategy for New Containers
|
||
|
||
| Strategy | Description |
|
||
|---|---|
|
||
| **Predictive Scaling** | Monitor the load growth trend and spin up new containers before the critical threshold is reached |
|
||
| **Warm Pool** | Keep 2-3 containers ready in standby mode so they can be activated instantly when needed |
|
||
| **Golden Images** | Use pre-baked, optimized container images to reduce init time |
|
||
| **Gradual Traffic Ramp-up** | Route traffic to the new container gradually instead of sending full load immediately |
|
||
| **Readiness Probe** | Don't add the container to the load balancer until it passes a readiness check |
|
||
|
||
---
|
||
|
||
## 4. Using ghaymah Block Storage for Stateful Workloads
|
||
|
||
- **Persistence across rescheduling:** If a container fails or is moved to another node, the same volume can be reattached without losing data.
|
||
- **Decoupling storage from compute:** Allows the container layer to scale independently from the storage layer.
|
||
- **Low-latency I/O:** Suitable for databases and queueing systems that need fast read/write.
|
||
- **Snapshots:** Periodic snapshots for backup and data recovery in case of failures.
|
||
- **Single-container attachment:** Typically used behind a centralized database rather than inside each of the 39 containers, to preserve statelessness in the processing layer. |