High Availability and Scalability - ELB & ASG

Scalability

When it comes to scalability, it divides into two parts:

1. Horizontal Scalability -> elasticity, we also call this scale up and scale down
2. Vertical Scalability -> we also call this scale in and scale out

Horizontal Scalability

increase the number of instances/systems, distributed system

Vertical Scalability

increase the size of the instance, like from t2.micro to t2.large, etc…

HA (High Availability)

HA (High Availability) is a plan for failure, you should prepare for

1. Everything will fail
2. You should always plan for failure

High Availability:

1. HA usually goes hand-in-hand with Horizontal Scalability
2. HA means running your application/system in at least 2 data centers, to be specific, 2 AZs
3. HA can be both active or passive
   1. active: Horizontal Scalability
   2. passive: RDS Multi-AZ

There are two methods of Horizontal Scaling:

• Auto Scaling Group - ASG
• Load Balancer

Load Balancing (Elastic Load Balancer - ELB)

Load Balancers are servers that forward internet traffic to multiple servers (EC2) downstream

But, why would we use a load balancer, anyway?

• Spread load across multiple downstream instances
• Expose a single point of access (DNS) to your application
• Seamlessly handle failures of downstream instances, through health checks
• Do regular health checks to your instances
• Provide SSL Termination (HTTPS) for your website
• Enforce stickiness with cookies
• HA across AZs
• Separate public traffic from private traffic

There are three types of Load Balancers on AWS

1. Application Load Balancer
   1. HTTP, HTTPS, WebSocket
   2. supports SSL
2. Network Load Balancer
   1. TCP, TLS (secure TCP) & UDP
   2. supports SSL
3. Classic Load Balancer
   1. HTTP, HTTPS, TCP
   2. DO NOT support SSL

You can setup internal/private or external/public ELBs

more details, please refer here: https://aws.amazon.com/elasticloadbalancing/

Application Load Balancer (ALB)

It balances HTTP / HTTPS traffic, you can also create

• advanced request routing
• sending specific requests to specific web servers

Target Groups

Each target group is used to route requests to one or more registered targets.

where targets can be:

• EC2 Instances (can be managed by an ASG) - HTTP
• ECS tasks (Elastic Container Service) - HTTP
• Lambda functions - HTTP request if translated into a JSON event
• IP Address - must be private IPs

ALB can also route to multiple target groups, also, Health checks are at the target group level

Network Load Balancer (NLB)

It balances TCP (layer 4) traffic

Forward TCP & UDP traffic to your instances. Network Load Balancer can handle millions of requests per second while maintaining ultra-low latencies, ~100ms, where 400ms for ALB

NLB has one static IP per AZ and supports assigning Elastic IP

Normally, NLB is used for extreme performance, TCP or UDP traffic

Classic Load Balancer (CLB)

This is just legacy Load Balancers

Advanced Load Balancer Theory

Sticky Sessions

Sticky Session allows you to bind a user’s session to a specific EC2 Instance. This ensures that all requests from the user during the session are sent to the same instance

you can enable the “sticky session” for Application Load Balancer, but the traffic will be sent at the “Target Group” level, rather than Individual EC2 Instance

Cross-zone Load Balancing

With cross-zone load balancing, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its Availability Zone only.

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html

• With Cross Zone Load Balancing each load balancer instance distributes evenly across all registered instances in all AZ
• Otherwise, each load balancer node distributes requests evenly across the registered instances in its AZ only

Cross-Zone in 3 types of Load Balancers

1. Application Load Balancer
   1. Always on (cannot be disabled)
   2. No charges for inter AZ data
2. Network Load Balancer
   1. Disabled by default
   2. You pay charges for inter AZ data is enabled
3. Classic Load Balancer
   1. Disabled by default
   2. No charges for inter AZ data is enabled

Path Patterns

This creates a listener with rules to forward requests based on the URL Path -> “path-based routing”

Auto Scaling Group (ASG)

the goal for an ASG is to:

1. Scale in or scale out to match an increased load or decreased load
2. Ensure minimum / maximum number of running instances
3. automatically register new instances to a load balancer

Scaling Policies

• Target Tracking Scaling
  • Most simple and easy to set-up
  • Example I want the average ASG CPU to stay at around 40%
• Simple / Step Scaling
  • When some metrics is triggered, do something
• Scheduled Actions
  • eg. increase the min capacity to 10 at 5 pm.

Launch Configurations are where the details (AMI, IAM) are specified for creating/launching new instances

Elastic Beanstalk

Deploy the application to AWS without actually knowing AWS

Elastic Beanstalk automatically handles the details of capacity provisioning load balancing, scaling, and application health monitoring

There are 3 components in ElasticBeanStalk

• Application
• Application version: each deployment gets assigned a version
• Environment name (dev, test, prod ..): free naming

You can deploy application versions to environments and can promote application versions to the next environment; It supports Rollback feature to previous application version; Full control over the lifecycle of environments