An overview of Scalability (Vertical Vs Horizontal) For High Availability.
Focus:
- Tailored for Devops, DevSecops & Cloud Engineers.
Breakdown:
- Intro,
- The concept: Scalability,
- Horizontal Scalability (Preferred),
- Vertical Scalability,
- High Availability (HA),
- Mechanisms of High Availability that ensures the system remains operational during failures,
- Multi-AZ Design,
- Fault-Tolerant Architecture,
- Backup & Recovery,
- Typical Architecture Example,
- Comparison of Scalability & Availability, modeled for cloud Architecture,
- Insights.
- When twtech is designing for Scalability and High Availability (HA) in AWS (especially for EC2-based architectures), it considers multiple layers:
- Compute,
- Storage,
- Networking,
- Database,
- Failover Mechanisms.
The concept: Scalability
- Scalability means the system can handle increased load by adding resources.
Horizontal Scalability (Preferred):
- Use
Auto Scaling Groups (ASGs) to add/remove EC2 instances
based on demand.
- Distribute
traffic using Elastic Load Balancer (ELB).
- Use stateless
instances—store session state in ElastiCache, DynamoDB, or
S3.
- Microservices
architecture (e.g., via ECS, EKS, or Lambda) for modular
scaling.
- Serverless
services like Lambda, API Gateway, and DynamoDB scale
automatically.
Vertical Scalability:
- Scale by
increasing instance size (e.g.,
m5.large→m5.4xlarge). - Less
flexible than horizontal scaling and may hit limits quickly.
High Availability (HA)
- Mechanisms of High Availability that ensures the system remains operational during failures.
Multi-AZ Design:
- Deploy EC2
instances across multiple Availability Zones
within a region.
- Use Elastic
Load Balancer to route traffic across healthy instances.
- For
databases, use Amazon RDS Multi-AZ
or Aurora Multi-AZ deployments.
Fault-Tolerant Architecture:
- Use Route
53 health checks and DNS failover.
- Store
persistent data in highly available services
(S3, RDS, DynamoDB).
- Use EFS
or Amazon FSx for shared storage with
multi-AZ access.
Backup & Recovery:
- Implement
regular automated backups
(RDS, EBS snapshots).
- Use CloudWatch
and CloudTrail for monitoring and alerting.
Typical Architecture Example:
- ALB
→ Auto Scaling Group (in 2+ AZs) → EFS
or RDS Multi-AZ for shared or persistent storage.
- Use CloudFront
and Route 53 for global scalability and latency
optimization.
Comparison of Scalability & Availability, Modeled for cloud Architecture.
Scalability Vs. Availability
|
Aspect |
Scalability |
Availability |
|
Definition |
The ability of a system to handle
increased load by adjusting resources. |
The ability of a system to remain
accessible and operational, even in the face of failures. |
|
Goal |
Improve performance as
demand grows. |
Ensure reliability and uptime. |
|
Focus |
Capacity and performance. |
Resilience and fault-tolerance. |
|
Scaling Types |
- Horizontal (more nodes) |
Not about scaling; about ensuring
redundancy. |
|
Key AWS Tools |
- Auto Scaling Groups |
- Multi-AZ deployments |
|
Measurement |
Transactions/sec, latency under
load. |
Uptime percentage (e.g., 99.99%). |
|
Example |
Adding more EC2s during peak
traffic. |
Redirecting traffic to another AZ
if one fails. |
Insights:
- Scalability
is about growing to meet demand.
- Availability
is about surviving failures.
Vertical vs Horizontal Scalability
- A clear breakdown of Vertical & Horizontal Scalability strategies used to improve system capacity:
Vertical & Horizontal Scalability
|
Aspect |
Vertical Scalability (Scale Up) |
Horizontal Scalability (Scale Out) |
|
Definition |
Increase the power of a single
node (e.g., more CPU, RAM). |
Add more nodes/instances to
distribute the load. |
|
Example |
Upgrading from t3.medium to m5.4xlarge. |
Adding more EC2 instances behind a
load balancer. |
|
Ease of Implementation |
Easier to implement short-term. |
More complex (requires distributed
architecture). |
|
Scalability Limit |
Limited by max capacity of a
single instance. |
Near-infinite scalability with
right architecture. |
|
Cost Efficiency |
Becomes cost-inefficient at
higher tiers. |
More cost-effective at scale. |
|
Downtime Risk |
May require downtime to upgrade
instance. |
Usually zero downtime with
autoscaling. |
|
Fault Tolerance |
Single point of failure. |
More fault-tolerant (nodes can
fail independently). |
|
Use Cases |
Legacy apps, monoliths,
single-node DBs. |
Web apps, microservices,
distributed systems. |
- Vertical scaling: is simple but hits limits quickly.
- Horizontal scaling: is the preferred cloud-native approach—more resilient, flexible, and suitable for elastic workloads.
twtech Response: No.
Explanation:
- Scalability always be called elasticity—they are related but distinct concepts.
- Here's a clear breakdown of why scalability is not always the same as elasticity:
Scalability
- Definition:
The ability of a system to grow (or shrink)
in capacity to handle increased (or decreased) workload.
- Key Point:
It doesn't specify how or when scaling happens—just that the
system can scale.
- Types:
- Manual scalability: Requires human intervention.
- Automated scalability: May use scripts or triggers.
- Use case Example:
Adding more servers during a holiday sale, planned in advance.
Elasticity
- Definition:
The ability of a system to automatically
and dynamically
adjust capacity up or down as needed, in real-time, based on current workload.
- Key Point:
Elasticity is automated, responsive, and cost-efficient.
- Use case Example:
AWS Auto Scaling adds/removes EC2 instances as traffic fluctuates—without
manual intervention.
More justification of Why
Scalibility is Not the Same as Elasticity.
- All elastic systems are scalable, BUT not all scalable systems are elastic.
- Scalability is about capacity.
- Elasticity is about automated responsiveness.
At what point is scalability equals to elasticity?
twtech Response:
- Only when scalability is automatic and responsive.
- In that situation twtech will be dealing with elastic scalability.
No comments:
Post a Comment