[AWS] High Availability and Scalability ELB and ASG

고가용성 및 스케일링성 : ELB and ASG

고가용성 및 스케일링성

Vertical Scalability : incresing the size of the instance
ex. t2.micro -> t2.large

Horizontal Scalability : the number of instances / systems for your application
ex. ditributed systems

High Availability : 데이터 센터의 손실에서 살아남는 것. AZ를 분산시키는 것

Elastic Load Balancing(ELB) 개요

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
• managed Load balancer
• AWS가 관리하며 동작을 보장한다. 이걸 사용하는 것을 추천한다.

Health Checks

• ELB가 EC2의 상태를 체크한다. 이 체크는 포트와 라우트에서 체크한다.
• 만약 EC2가 200 응답을 하지 않으면 상태가 안좋다고 판단하고 트레픽을 보내주지 않는다.

CLB(Classic Load Balancer) - AWS에서는 사용을 권장하지 않는다. 구형이다.
: HTTP, HTTPS, TCP, SSL (secure TCP)
ALB(Application Load Balancer) - 2016년 춢시
: HTTP, HTTPS, WebSocket
NLB(Network Load Balancer) - 2017년 출시
: TCP, TLS (secure TCP), UDP
GWLB(Gateway Load Balancer) - 2020년 출시
: Operations at layer 3(Network layer) - IP Protocol

-> 더 많은 기능을 가지고 있는 최신 밸런서를 사용하는 것을 추천한다.
-> 몇몇 로드 벨런서는 internal(private) 또는 external(pubulic) ELB로 설정이 가능하다.

유저는 HTTP, HTTPS로 ELB에 접근이 가능한데, EC2 입장에서는 ELB의 트래픽만 허용해야하므로 소스에 IP 범위가 아니라 ELB의 보안그룹이 설정되어야 한다.

CLB

Classic Load Balancer는 이제 AWS에서 지원되지 않는다.

ALB(Application Load Balancer) 개요

• Application Load Balancer is Layer 7 (HTTP)
• Load balancing to multiple HTTP applications across machines (target groups)
• Support for HTTP/2 and WebSocket
• Support redirects (from HTTP to HTTPS for example)
• Routing tables to different target groups:
  • Routing based on path in URL
  • Routing based on hostname in URL
  • Routing based on Query String, Headers
• ALB are a great fit for micro services & container-based application
• Has a port mapping feature to redirect to dynamic port in ECS

Target Group이란

• EC2 instances (can be managed by an Auto Scaling Group) - HTTP
• ECS tasks
• Lambda functions
• IP Address

어플리케이션 로드 벨런서를 사용하는 경우에도 고정된 호스트 이름을 갖게된다.
(XXX.region.elb.amazonaws.com)

그리고 어플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
클라이언트의 실제 IP는 X-Forwarded-For라는 헤더에 삽입된다.
따라서 Port(X-Forwarded-Port)와 Proto(X-Forwarded-Proto)도 갖게 된다.

Client IP를 통해 Client는 로드 밸런서와 통신을 하고, Connection Termination 후에
로드 벨런서는 Private IP를 통해 EC2 Instance와 통신을 한다.
만약에 어플리케이션 서버에서 클라이언트의 IP를 확인하고 싶다면, HTTP 헤더 내의 Port와 Proto를 확인해야 한다.

NLB(Network Load Balancer)

Layer 4 Load Balancer로 Layer 7을 다루는 ALB보다 하위계층을 다룬다.
TCP & UDP 트래픽을 인스턴스로 보낸다.

성능이 매우 높다. 초당 수백만 건의 요청을 처리할 수 있고 ALB보다 지연시간도 짧다.
ALB 400ms
NLB 100ms

NLB는 AZ 별로 1개의 고정 IP를 갖고 Elastic IP 할당을 지원할 수 있다.
여러 개의 고정 IP를 가진 앱을 지원할 때 좋다.

고성능, TCP, UDP, static ip가 나오면 NLB를 생각하자.
작동 방식은 ALB와 유사하다.

외부로부터는 TCP, UDP를 받고, 백엔드 앱 instance에게는 TCP 혹은 HTTP로 통신

대상 그룹

• EC2 instance
• IP Addresses - must be private IPs (온프레미스 서버 포함 할 때)
• ALB 앞에 사용 가능 - NLB 덕에 고정 IP를 얻고, ALB를 통해 HTTP를 처리할 수 있다 .
• Health check는 TCP, HTTP, HTTPS를 지원한다.

GWLB(Gateway Load Balancer)

Deploy, scale and manage a fleet of 3rd party network virtual appliances in AWS

모든 트래픽이 방화벽이나 침입 방지 시스템을 통과하게 한다.
트래픽이 어플리케이션에 도달하기 전에 Route Table의 값을 통해 GWLB로 가고,
여기서 3rd Party Security Virtual Appliances로 구성된 Target Group을 통해 트래픽을 분석하고 처리한다. [방화벽, 침투감지]

이상이 없으면 GWLB로 다시 보내고, 해당 트래픽을 앱으로 보낸다.

Layer 3(Network Layer) 즉, IP Packets 레벨에서 동작한다.

• Transparent Network Gateway - single entry/exit for all traffic
• Load Balanser - distributes traffic to your virtual appliances

Uses the GENEVE Protocol on port 6081

대상 그룹

• EC2 instance
• IP address

Elasitc Load Balancer - Sticky Sessions

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

: Client가 요청 시에 LB를 거쳐서 백엔드 서버로 가는데, 요청할 때마다 동일한 서버로 가게 하는 것을 Stickiness라고 한다.

CLB, ALB에서 설정이 가능하다.

The "cookie" used for stickiness has an expiration data 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 instance.

Cookie Names

• Application-based Cookies
  • Custom cookie
    • Generated by the target
    • Can include any custom attributes required by the application
    • Cookie name must be specified individually for each target group
    • Don't use AWSALB, AWSALBAPP or AWSALBTG (reserved ues by the ELB)
  • Application cookie
    • Generated by the load balancer
    • cookie name is AWSALBAPP
• Duration-based Cookies
  • Cookie generated by the load balancer
  • Cookie name is AWSALB for ALB, AWSELB for CLB

-> 쿠키를 생성하고, 시간을 1일로 정해놓으면 이제 특정 client가 접근할 때, 정해진 기간동안은 동일한 인스턴스로 접근하게 된다.

Elastic Load Balancer - Cross Zone Load Balancing

2개 AZ가 있는데 하나는 LB 하나에 instance 2개, 다른 곳에는 LB 하나에 instance가 8개 있다고 하자.

만약에 Cross Zone Load Balancing을 활성화시키고 나서, Client가 트래픽을 50 : 50으로 양 쪽 AZ에 보냈을 경우에, AZ에 상관없이 모두 동일하게 트래픽을 나눠가지게 된다.

각각 전부 10%의 트래픽을 나눠 가지게 된다.

ALB - 기본적으로 기능이 활성화되어 있다. 데이터를 다른 AZ로 옮길 때 비용이 들지 않는다. (다른 서비스는 비용이 나간다.)

NLB, GWLB - 비활성화되어 있고, 활성화 시 비용이 발생한다.
CLB - 비활성화되어 있지만, 활성화 해도 비용이 들지 않는다.

ELB - SSL/TLS 인증서

in-flight encryption - 통신 중에 암호화 한다.

An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit.

송/수신자만 복호가 가능하다.

SSL - Secure Socket Layer
TLS - Transport Layer Security

TLS 인증서를 주로 사용하는데, 사람들은 SSL이라고 부른다.

public 인증서는 CA에서 발행하고, 이런 CA로는 Comodo, Symantec, GoDaddy 등등이 있다.
Public SSL 인증서를 LB에 추가하면, Client와 LB 사이의 연결을 암호화할 수 있다.

SSL 인증서는 만료날짜가 있어 주기적으로 갱신해야 한다.

HTTPS(encrypted)

LB는 X.509 인증서를 사용하며, SSL/TLS 서버 인증서라고 부른다.
우리는 이걸 AWS 내 ACM에서 관리할 수 있다.
그리고 유저는 자신만의 인증서를 업로드할 수도 있다.

그리고 LB의 HTTPS Listener에 기본 인증서를 지정해줘야 한다.
다중 도메인 지원을 위해 다른 인증서를 올릴 수도 있다.
Clients can user SNI(Server Name Indication) to specify the hostname they reach
원하는대로 정책을 지정할 수 있다.

SNI - Server Name Indication

SNI는 여러 개의 SSL 인증서를 하나의 웹서버에 로드해서 하나의 웹서버에서 여러 개의 웹 사이트를 지원할 수 있게 해준다.

it's a "newer" protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake
-> 확장된 프로토콜 개념이라고 봐야 한다.

서버는 알맞는 인증서를 찾고, 리턴한다.

Only works for ALB & NLB, CloudFront

CLB - SSL을 지원하지만 다중 지원 X
ALB - 다중 지원 가능, SNI
NLB - 다중 지원 가능, SNI

Connection Draining

다른 이름들

Connection Draining - CLB
Deregistration Delay - ALB & NLB

인스턴스가 등록 취소, 또는 비정상인 상황일 때, 인스턴스에 어느정도 시간을 주어서 활성 요청을 완료할 수 있게 해주는 것이다.

그리고 de-registering 인 instance에게 ELB는 새로운 요청을 보내는 것을 중단한다.

기존 유저가 사용 중이면 해당 요청이 종료될 때까지 기다렸다가 EC2를 종료하고, 다른 유저는 다른 백엔드 서버로 연결하게 한다.

기본적으로 300초이다.

0이면 비활성이다.

1 ~ 3600초까지 설정가능하다.

짧은 요청의 경우에는 낮은 값으로 설정하는 것이 좋다.

Auto Scaling Group (ASG) basic

우리가 운영하는 웹사이트에 방문하는 사람이 증가할 수도 있다.
클라우드 환경에서는 원하는대로 서버를 늘리거나 줄일 수 있다.

ASG(Auto scaling Group)의 목표는

• 증가하는 부하에 맞춰 EC2 instance를 추가한다. (Scale out)
• 감소하는 부하에 맞춰 EC2 instance를 제거한다. (Scale in)

ASG의 크기는 시간이 지날 수록 변하고, 매개변수로 최소, 최대 값을 정할 수 있다.
자동으로 새로운 instance를 LB에 등록할 수 있다.
또 다른 기능으로 instance의 health가 비정상이면 종료하고 재 생성한다.

ASG 기능 자체는 무료고 생성된 서버 비용만 내면 된다.

• minimun capacity
• Desired capacity
• maximum capacity

ASG를 위해서는 Launch Template를 사용하는데,

• AMI + Instance type
• EC2 User Data
• EBS Volumes
• Security Groups
• SSH key Pair
• IAM Roles for your EC2 Instances
• Network + Subnets Information
• Load Balancer Information
• Min Size/ Max Size/ Initial Capacity

CloutWatch alarm

• 특정 지표가 어떤 조건이 되면 경보가 울리게 할 수 있다.
• triggering 되면 scale in/ out 하게 연결할 수 있다.

Auto Scaling Groups - Dynamics Scaling Policies

1. Target Tracking Scaling
   • 가장 설정하기 쉽다.
   • Ex. 평균 ASG CPU를 40% 가량으로 유지하고 싶을 때 사용한다.
   • 기본 기준점을 정하고 유지하게 할 수 있다.
2. Simple/Step Scaling
   • CloudWatch 알람이 울릴 때(CPU > 70%) 2개 추가
   • CloudWatch 알람이 울릴 때(CPU < 30%) 1개 제거
3. Scheduled Actions
   • 알려진 패턴을 기반으로 스케일링을 예측한다.
   • Ex. 금요일 5시에는 min capacity를 10으로 증가시킨다.

Auto Scaling Groups - Predictive Scaling

1. Predictive Scaling
   • Continuosly forecast load and schedule scaling ahead

참고할 지표들

CPU 사용량, 타겟 별 요청 수, 평균 업로드 다운로드 수, 어떤 커스텀 메트릭 들

Auto Scaling Groups - Scaling Cooldowns

- 매 Scaling 후에 휴지기를 갖는다. (default 300s)
- 휴지기에는 인스턴스를 추가하거나 종료할 수 없다.