54 أسطر
1.7 KiB
Markdown
54 أسطر
1.7 KiB
Markdown
# Scalability Calculations
|
||
|
||
## 1. Required Number of Containers
|
||
|
||
### Given
|
||
|
||
- Expected traffic: **15,000 requests/second**
|
||
- Capacity per container: **500 requests/second**
|
||
- Safety margin: **30%**
|
||
|
||
### Calculation
|
||
|
||
First, calculate the minimum number of containers required:
|
||
|
||
```text
|
||
15,000 ÷ 500 = 30 containers
|
||
```
|
||
|
||
Add a 30% safety margin:
|
||
|
||
```text
|
||
30 × 1.30 = 39 containers
|
||
```
|
||
|
||
### Result
|
||
|
||
**39 application containers** are required to handle the expected traffic while maintaining a 30% capacity buffer for traffic spikes and failover scenarios.
|
||
|
||
---
|
||
|
||
## 2. Cold Start Strategy
|
||
|
||
To avoid initial delay during scaling, the following approach is recommended:
|
||
|
||
- Maintain a certain number of replicas for the application at any moment.
|
||
- Configure the horizontal auto-scaling feature based on CPU usage or requests per second.
|
||
- Utilize Docker containers with minimal size.
|
||
- Pre-pull container images onto worker nodes before deployment.
|
||
|
||
In that way, initial delay is avoided while the application is scaled properly during traffic peaks.
|
||
---
|
||
|
||
## 3. Using Ghaymah Block Storage for Stateful Workloads
|
||
|
||
Ghaymah Block Storage is used to provide stateful storage for applications like databases.
|
||
|
||
In this design, the database stores its state on Ghaymah Block Storage instead of storing it on the filesystem inside the container. This way, it makes sure that:
|
||
|
||
- The data will not be lost even after restarting the container/node.
|
||
- It will still be accessible even after rescheduling containers.
|
||
- There will be decoupling between the stateful workloads and the stateless application pods.
|
||
- The storage will be reliable and durable for application data.
|
||
|
||
Examples of stateful workloads are relational databases, NoSQL databases, and others. |