4. Load Balancing, Auto Scaling Group

Scalability의 두가지 종류

1. Vertical Scalability

• 수직 확장성 : 인스턴스의 크기를 키운다는 생각을 하면 된다.
  t2.micro -> t2.large
• non distributed system인 DB에 적합하다.
• RDS, ElastiCache가 수직 확장성을 늘려주는 서비스들 이다.
• 보통은 수직 확장에는 HW limit 이 있기 마련이다.

2. Horizontal Scalability (= elasticity)

• 수평 확장성 : 인스턴스와 어플리케이션의 수를 늘리는 것이다.
• Distributed System에 적합하다.
• EC2를 덕분에 수평 확장성을 늘리기 쉽다.

High Availabilty의 개념

• 2개 이상의 AZ에서 서비스를 실행하는 것이 서비스가 High Availability가 있다고 한다
  하나가 고장나도 나머지 하나가 해주면 되기 때문

• 그래서 multi AZ 서비스가 고 가용성이라고 한다.(시험에서!)

Load balancing이란?

트래픽을 여러 서버로 나눠서 보내주는 것을 의미한다.

• 왜 로드 벨런서를 사용할까?

1. 말 그대로 load를 분산시킬수 있다.
2. 진행하는 서비스의 single point로 나타낼 수 있다. DNS를 사용하면 되기 때문이다.
3. 서비스의 실패를 방지하기 위해 지속적으로 health check를 한다
   (참고로 health check는 인스턴스들이 제대로 작동하는지 확인을 해주는 것이다)
4. 쿠키를 쓴다 ( 이따 나온다!)
5. public traffic 과 private traffic을 구분시켜 놓는다
6. 고가용성을 갖는다

등등이 있다.

Elastic load Balancer

• 엘라스틱 로드 벨런서는 AWS의 로드 벨런싱 시스템이다.
  AWS의 다양한 서비스와 통합되어 편하게 사용할 수 있다.

• 보안그룹을 사용할 수 있다.

Target Group

ELB에 등록된 EC2 인스턴스의 그룹이다.

Load Balancer의 4가지 종류

1. Classic Load balancer

• 가장 구형의 로드 벨런서 이다.
• L4/L7을 모두 지원한다.
• EC2-Classic을 사용하는 경우에 사용한다.

2. Application Load balancer

• L7 로드 벨런서이다.
• HTTP/HTTPS Header의 정보를 담아 요청을 전달한다.
• 각각 다른 경로로 리다이렉트 및 고정 페이지를 보여준다. (쿼리를 사용하거나 path를 사용할 수 있다)
  이를 target group이 다르다고 표현할 수 있다. 즉, multiple target group에 route 할 수 있으며, health check는 target group 단위로 이루어진다.
• micro services, container-based application 에 적합한데, ECS의 dynamic port를 사용해 리다이렉션을 할 수 있기 때문이다. (ECS는 후에 나오지만 컨테이너 기술이다)
• target group: EC2 인스턴스, ECS , Lambda function, private IP가 될 수 있다 .
  (람다 함수는 serverless한 서비스를 제공하기 위한 방법인데 후에 나온다)
• X-forwarded-for을 사용해 EC2가 클라이언트의 IP를 확인할 수 있다.

3. Network Load balancer

• L4 로드 벨런서이다.
• TCP,UDP를 기반으로 하고, 성능이 굉장히 좋다.
• NLB는 AZ마다 고정 IP 가 생성된다.(elastic IP 사용도 가능하다)
• Target group: EC2, private IP, Application Load Balancer가 될 수 있다.
  (ALB랑 결합하는게 은근 많이 나온다 : 고정 IP를 가질 수 있어서 결합한다고 한다. )

4. Gateway Load balancer

• L3 로드 벨런서이다.
• 모든 트레픽이 가상 환경을 통과할 수 있게 만든다 (방화벽을 생각하면 편하다)
• Transparent Network Gateway : 모든 트레픽의 entry , exit을 파악한다
• GENEVE 라는 프로토콜을 사용하고 , 6081 포트를 사용한다.
• Target Group : EC2 인스턴스, private IP

Sticky Session

• CLB,ALB에만 적용되는 기술로, 같은 클라이언트로부터 온 트래픽을 알 수 있는 기술이다.
• 쿠키 라고 불린다 !
• 사용 예시 : 사용자가 세선 데이터를 잃지 않게 하고 싶다 !

쿠키의 종류

1. Application-based Cookies

• Custom Cookie
  타겟에 의해 생성된다.
  애플리케이션이 필요한 정보를 담을 수 있다.
  이름이 각 target group 마다 specified 되어야 한다

• Application Cookie
  로드 벨런서에 의해 생성된다
  쿠키의 이름은 AWSALBAPP이다. ( 커스텀 쿠키에서 이름 사용 못하게 만든다 )

2. Duration-based Cookie
   특정 기간이 지나면 만료가 되는 쿠키이다.
   로드 벨런서가 생성한다.
   이름이 정해져 있다.

Cross-Zone Load Balancing

• 교차영억 로드벨린싱은 EC2 개수에 기반으로 로드벨런싱을 하는 것이다.

• 예를 들어, AZ 1에는 인스턴스가 2개, AZ 2에는 인스턴스가 8개 있다고 하자
  기본적으로 ELB는 AZ별로 Load를 50프로씩 뿌린다
  교차영역 로드 벨런싱을 한다면 20:80으로 뿌린다. (EC2가 2:8 이니까)

• ALB CLB NLB 모두 지원하는 기능이다. (default로 ALB만 켜져있다)

SSL (Secure Sockets Layer)

• SSL은 client와 load balancer 사이의 트래픽을 암호화 시켜준다.
• TLS라고 Transport Layer Security도 나왔다.
• 만기일이 있다
• 로드벨런서는 ACM을 사용해 인증을 한다 (= AWS Certificate Manager)
• ACM에 개인 인증서를 올려서 인증 할 수도 있다.

SNI

Server Name Indication

• 하나의 Web server에 여러개의 SSL 인증서를 로딩해야하 하는 문제점을 해결해준다.
• 클라이언트가 처음 SSL handshake에서 hostname을 명시함으로써 어떠한 인증서를 사용해야 하는지 알려준다
• ALB,NLB,CloudFront 적용

Listener

포트로 들어오는 요청을 처리해주는 장치라고 생각하면 된다.

• ELB에서는 multiple listener를 둘 수 있고, multiple SSL certificate도 지원한다
  SNI를 활용할 수 있다.

• NLB에서는 multiple listener를 둘 수 있고, multiple SSL certificate도 지원한다
  SNI를 활용할 수 있다.

• CLB에서는 하나의 SSL certificate을 지원한다.
  multiple SSL certificate을 지원하고 싶으면 CLB 자체를 여러개 써야 한다.

Connection Draining

오토스케일링과 ELB를 같이 사용할 때, EC2 인스턴스 삭제시 세션이 완료되는 것을 기다리는 기능이다.
작업이 완료되지 않았는데, 오토 스케일링으로 인해 EC2 인스턴스가 삭제되면 안되기 때문.

Auto Scaling Group과 ELB

• ELB가 자동으로 EC2 instance를 증가(Scale out)시키거나 감소(Scale in)시키고, 등록도 한다. (load의 양에 따라)
• CloudWatch Alarm을 사용해 scaling이 가능하다. 기준은 마음대로 만들어 낼 수 있다.
• min,max number of EC2 instance가 정해져있다.
• 만약 not healthy 한 인스턴스가 있으면 종료시키고, 새로운 인스턴스를 만들어 대체한다.

ASG - 스케일링 방법론

1. Target Tracking Scaling
   평균값을 목표로 인스턴스를 조절

• CPU가 40% 정도 쓰였으면 좋겠어요

2. Simple/step scaling
   Simple : 임계치에 도달하면 인스턴스 조정
   Step : 여러가지 조건을 달 수 있다 ( Simple과 기본 원리는 같다)

• CPU가 70퍼 이상 쓰이면 2개 unit 더해주세요
• CPU가 30퍼 이하로 쓰이면 1개 unit 빼주세요

3. Scheduled Action
   미리 생각해 두는 것

• 금요일 밤에는 트래픽이 보통 많으니 미리 넣어두자

CPUUtilization , RequestCountPerTarget , Average Network in,out 등 기준으로 할 것이 많다.

ASG - Scaling cooldown

• 인스턴스 생성, 제거를 후 또 다시 스케일링이 되어야 한다는 알림이 와도, 휴지기를 갖는 것
• 기본 설정은 300초이다.

ASG - Termination Policy

• 인스턴스가 가장 많은 AZ의 가장 오래된 instance부터 없앤다.
• AZ간의 인스턴스의 수를 맞추기 위한 정책

ASG - Lifecycle Hook

• Scale In,out 이후 Inservice 전에 , 사용자가 미리 정의한 작업을 하는 시간을 제공한다.

• 인스턴스 시작, 종료 시 사용자가 작업을 수행할 수 있다.
  예를 들어, 종료 전에 작업 로그나 파일을 추출하고 종료하는 형식의 작업을 미리 설정해 둘 수 있는 것이다.

끝!

아 진짜 양 많네..