[ 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

 

 

반응형

+ Recent posts