DEVELOPyo

[ Types of load balancer on AWS ]

- AWS has 3 kinds of managed Load Balancers

1) Classic Load Balancer(v1 - old generation) - 2009

  : HTTP, HTTPS, TCP

2) Application Load Balancer(v2 - new generation) - 2016

  : HTTP, HTTPS, WebSocket

3) Network Load Balancer(v2 - new generation) - 2017

  : TCP, TLS(secure TCP) & UDP

- Overall, it is recommended to use the newer/v2 generation load balancers as they provide more features

- You can setup internal(private) or external(public) ELBs

[ Load Balancer Security Groups ] 

1) Load Balancer Security Group 설정

  HTTP 80 port 시큐리티 그룹 생성

2) Application(EC2 Instance) Security Group : Allow traffic only from Load Balancer

  HTTP 80 port , Source로 Load Balancer 의 Security Group 설정

[ Load Balancer Good to know ]

- LBs can scale(확장) but not instantaneously(즉시) - contact AWS for a "warm-up"

- Troubleshooting

  -- 4xx errors are client induced(유발) erros

  -- 5xx errors are application induced erros

  -- Load Balancer ERRORs 503 means at capacity or no registered target

  -- If the LB can't connect to your application, check your security groups

- Monitoring

  -- ELB access logs will log all access requests(so you can debug per request)

  -- CloudWatch Metrics will give you aggregate(집계) statistics (eg: connections count)

# 1. ALB : Application Load Balancer (v2)

- Application load balancers is Layer7 (HTTP)

- Load balancing to multiple HTTP applications across machines (target groups)

- Load balancing to multiple applications on the same machine (ex: containers)

- Support for HTTP/2 and WebSocket

- Support redirects (from HTTP to HTTPS for example)

- Routing tables to different target groups:

  1) Routing based on path in URL (example.com/users , example.com/posts)

  2) Routing based on hostname in URL (one.example & other.example.com)

  3) Routing based on Query String, Headers (example.com/users?id=123&order=false)

- ALB are a great fit for micro services & container-based application (eg. Docker & Amazon ECS)

- Has a port mapping feature to redirect to a dynamic port in ECS

# Target Groups

- EC2 instances (can be managed by an Auto Scaling Group) - HTTP

- ECS tasks (managed by ECS itself) - HTTP

- Lambda functions - HTTP request is translated into a JSON event

- IP Address - must be private IPs

- ALB can route to multiple target groups

- Health checks are at the target group level

# Good to know

- Fixed hostname

- The application servers don't see the IP for the client directly

  -- The true IP of the client is inserted in the header X-Forwared-For

  -- We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

# 2. NLB : Network Load Balancer (v2)

- Network load Balancers (Layer 4) allow to :

  1) Forward TCP & UDP traffic to your instances

  2) Handle millions of request per seconds

  3) Less latency ~ 100ms (vs 400 ms for ALB)

- NLB has one static IP per AZ, and supports assigning Elastic IP  (helpful for whitelisting specific IP)

- NLB are used for extreme performance, TCP or UDP traffic

- Not included in the AWS free tier

- Only NLB provides Elastic IP (CLB/ALB doesn't provide)

# Hands-on : LB

1. ALB / NLB / CLB(Classic Load Balancer) 선택

2. Step1. Configure Load Balancer 

  Listeners (LB Protocol) 선택 eg. HTTP/HTTPS/UDP/TCP

3. Step1. AZ 선택 ( can be multiple )

4. Step2. Security Group 설정

5. Step3. Target Group 설정 : Target type(Instance or IP), Protocol, Port, Health checks(timeout sec, Interval)

6. Step4. Register Targets : Add instances 

[ Load Balancer Stickiness ]

일정 시간동안 동일한 클라이언트의 요청은 동일한 서버에 의해 처리 되도록 

- It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer

- This works for Classic Load Balancers & Application Load Balancers

- The cookie used for stickiness has an expiration date you control

- Use case : make sure the user doesn't lose his session data

- Enabling stickiness may bring imbalance to the load over the backend EC2 instances

* same request originating from the same client, to go to the same target

* stickiness 설정은 Target Group 에 있음. duration 설정시 cookie expiration 까지 동일한 인스턴스에 request 하게 됨.

[ Cross-Zone Load Balancing ]

With Cross Zone Load Balancing : each load balancer instance distributes evenly across all registered instances in all AZ

Without Cross Zone Load Balancing : each load balancer node distributes requests evenly across the registered instances in its Availability Zone only

[ Cross-Zone LB charge ]

1) CLB (Classic Load Balancer)

- Disabled by default

- No charges for inter AZ data if enabled

2) ALB (Application Load Balancer)

- Always on (can't be disabled)

- No charges for inter AZ data

3) Network Load Balancer

- Disabled by default

- You pay charges for inter AZ data if enabled

[ ELB (Elastic Load Balancers) - SSL Certificates ]

1) CLB 

- Support only one SSL certificate

- Must user multiple CLB for multiple hostname with multiple SSL certificates

2) ALB

- Supports multiple listeners with multiple SSL certificates

- Uses Server Name Indication (SNI) to make it work

3) NLB 

- Same as ALB

* SNI : Server Name Indication

- SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)

- It's a newer protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake

- The server will then find the correct certificate, or return the default one

[ ELB - Connection Draining ]

EC2 가 중단중 혹은 제거되고 있는 상태 (= DRAINING ) 일 때, 설정해놓은 Deregistration Delay 시간동안 response를 기다린 후, 응답이 오지 않을 경우 ELB 밑의 다른 EC2 에 request 

- Feature naming :

  -- CLB : Connection Draining

  -- ALB/NLB (which has Target Group) : Deregistration Delay

- Time to complete "in-flight requests" while the instance is de-registering or unhealty

- Stops sending new requests to the instance which is de-registering

- Between 1 to 3600 secs, default is 300 secs.

- Can be disabled (set value to 0)

- Set to a low value if your requests are short

[ Scalability & High Availability ]

확장성과 고가용성

- Scalability means that an application/system can handle greater loads by adapting.

- There are two kinds of scalability :

1) Vertical Scalability

2) Horizontal Scalability (=elasticity)

- Scalability is linked but different to High Availability

1. Vertical Scalability

인스턴스의 크기를 키우는 수직적 확장

- Vertical scalability means increasing the size of the instance

  eg. t2.micro -> t2.large

- Vertical scalability is very common for non distributed systems, such as database.

- RDS, ElastiCache are services that can scale vertically.

- There's usually a limit to how much you can vertically scale (hardware limit)

2. Horizontal Scalability

인스턴스/시스템의 수를 늘리는 수평적 확장

- Horizontal Scalability means increasing the number of instances/systems for your application

- Horizontal scaling implies distributed systems.

- This is very common for web applications/modern applications

- It's easy to horizontally scale thanks the cloud offerings such as Amazon EC2

[ High Availability ]

- High Availability usually goes hand in hand with horizontal scaling

- High availability means running your application/system in at least 2 data centers (= AZ)

- The goal of high availability is to survive a data center loss

- The high availability can be passive (for RDS Multi AZ for example)

- The high availability can be active (for horizontal scaling)

[ High Availability & Scalability For EC2 ]

- Vertical Scaling : Increase instance size (=scale up/down)

  From : t2.nano

  To : u-|2tb|.metal

- Horizontal Scaling : Increase number of instances (=scale out/in)

  1) Auto Scaling Group

  2) Load Balancer

- High Availability : Run instances for the same application across multi AZ

  1) Auto Scaling Group multi AZ

  2) Load Balancer multi AZ

# Why use a load balancer?

- Spread load across multiple downstream instances

- Expose a single point of access (DNS) to your application

- Seamlessly handle failures of downstream instances

- Do regular health checks to your instances

- Provide SSL termination (HTTPS) for your websites

- Enforce stickiness with cookies

- High availability across zones

- Separate public traffic from private traffic

# Why use an EC2 Load Balancer?

- An ELB(EC2 Load Balancer) is a managed load balancer

 1) AWS guarantees that it will be working

 2) AWS takes care of upgrades, maintenance, high availability

 3) AWS provides only a few configuration knobs

- It costs less to setup your own load balancer but it will be a lot more effort on your end.

[ Health Checks ]

- Health Checks are crucial for Load Balancers

- They enable the load balancer to know if instances it forwards traffic to are available to reply to requests

- The health check is done on a port and a route (/health is common)

- If the response is not 200(OK), then the instance is unhealthy

[ Types of load balancer on AWS ]

- AWS has 3 kinds of managed Load Balancers

1) Classic Load Balancer(v1 - old generation) - 2009

  : HTTP, HTTPS, TCP

2) Application Load Balancer(v2 - new generation) - 2016

  : HTTP, HTTPS, WebSocket

3) Network Load Balancer(v2 - new generation) - 2017

  : TCP, TLS(secure TCP) & UDP

- Overall, it is recommended to use the newer/v2 generation load balancers as they provide more features

- You can setup internal(private) or external(public) ELBs

[ Load Balancer Security Groups ] 

1) Load Balancer Security Group 설정

  HTTP 80 port 시큐리티 그룹 생성

2) Application(EC2 Instance) Security Group : Allow traffic only from Load Balancer

  HTTP 80 port , Source로 Load Balancer 의 Security Group 설정

[ Load Balancer Good to know ]

- LBs can scale(확장) but not instantaneously(즉시) - contact AWS for a "warm-up"

- Troubleshooting

  -- 4xx errors are client induced(유발) erros

  -- 5xx errors are application induced erros

  -- Load Balancer ERRORs 503 means at capacity or no registered target

  -- If the LB can't connect to your application, check your security groups

- Monitoring

  -- ELB access logs will log all access requests(so you can debug per request)

  -- CloudWatch Metrics will give you aggregate(집계) statistics (eg: connections count)

# 1. ALB : Application Load Balancer (v2)

- Application load balancers is Layer7 (HTTP)

- Load balancing to multiple HTTP applications across machines (target groups)

- Load balancing to multiple applications on the same machine (ex: containers)

- Support for HTTP/2 and WebSocket

- Support redirects (from HTTP to HTTPS for example)

- Routing tables to different target groups:

  1) Routing based on path in URL (example.com/users , example.com/posts)

  2) Routing based on hostname in URL (one.example & other.example.com)

  3) Routing based on Query String, Headers (example.com/users?id=123&order=false)

- ALB are a great fit for micro services & container-based application (eg. Docker & Amazon ECS)

- Has a port mapping feature to redirect to a dynamic port in ECS

# Target Groups

- EC2 instances (can be managed by an Auto Scaling Group) - HTTP

- ECS tasks (managed by ECS itself) - HTTP

- Lambda functions - HTTP request is translated into a JSON event

- IP Address - must be private IPs

- ALB can route to multiple target groups

- Health checks are at the target group level

# Good to know

- Fixed hostname

- The application servers don't see the IP for the client directly

  -- The true IP of the client is inserted in the header X-Forwared-For

  -- We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

# 2. NLB : Network Load Balancer (v2)

- Network load Balancers (Layer 4) allow to :

  1) Forward TCP & UDP traffic to your instances

  2) Handle millions of request per seconds

  3) Less latency ~ 100ms (vs 400 ms for ALB)

- NLB has one static IP per AZ, and supports assigning Elastic IP  (helpful for whitelisting specific IP)

- NLB are used for extreme performance, TCP or UDP traffic

- Not included in the AWS free tier

# Hands-on : LB

1. ALB / NLB / CLB(Classic Load Balancer) 선택

2. Step1. Configure Load Balancer 

  Listeners (LB Protocol) 선택 eg. HTTP/HTTPS/UDP/TCP

3. Step1. AZ 선택 ( can be multiple )

4. Step2. Security Group 설정

5. Step3. Target Group 설정 : Target type(Instance or IP), Protocol, Port, Health checks(timeout sec, Interval)

6. Step4. Register Targets : Add instances 

[ Load Balancer Stickiness ]

- It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer

- This works for Classic Load Balancers & Application Load Balancers

- The cookie used for stickiness has an expiration date you control

- Use case : make sure the user doesn't lose his session data

- Enabling stickiness may bring imbalance to the load over the backend EC2 instances

* same request originating from the same client, to go to the same target

* stickiness 설정은 Target Group 에 있음. duration 설정시 cookie expiration 까지 동일한 인스턴스에 request 하게 됨.

[ Cross-Zone Load Balancing ]

With Cross Zone Load Balancing : each load balancer instance distributes evenly across all registered instances in all AZ

Without Cross Zone Load Balancing : each load balancer node distributes requests evenly across the registered instances in its Availability Zone only

[ Cross-Zone LB charge ]

1) CLB (Classic Load Balancer)

- Disabled by default

- No charges for inter AZ data if enabled

2) ALB (Application Load Balancer)

- Always on (can't be disabled)

- No charges for inter AZ data

3) Network Load Balancer

- Disabled by default

- You pay charges for inter AZ data if enabled