ELB(Elastic Load Balancing) 와 ASG(Auto Scaling Group)

개요

AWS 클라우드와 클라우드 전반의 힘을 살펴보고 이 새로운 패러다임이 어떻게 우리를 도와주고 애플리케이션을 원활하게 확장하는지 배워보자 -> 더 탄력적일 수 있도록 하는 서비스 ELB와 ASG 무슨 역할? 둘이 어떤 관계?

 

ELB(Elastic Load Balancing)

정의

: 인터넷 트래픽을 downstream 의 여러 서버(EC2 인스턴스)로 전달하는 서버

하나 이상의 가용 영역 (AZ)에 있는 여러 대상 및 가상 어플라이언스에서 들어오는 애플리케이션 트래픽을 자동으로 분산

 

Load Balancer 예시

1. User 1이 Load Balacer와 통신을 하면, 해당 트래픽을 여러개의 EC2 인스턴스 중 하나로 보낸다.
2. 그 후 EC2 인스턴스가 무언가로 응답하고 사용자는 그 응답을 받게된다.
3. 나머지 User 도 동일하게 통신한다.
4. 이는 사용자가 많아질수록 여러 EC2  인스턴스에 걸쳐 부하를 더 많이 분산시켜 백엔드를 더 잘 스케일링할 수 있다.

사용 목적

• 여러 다운스트림 인스턴스에 부하를 분산싴리 수 있다.

• 애플리케이션에 대한 DNS 호스트 이름인 단일 액세스 지점을 노출할 수 있다.

• 다운스트림 인스턴스의 실패를 원활하게 처리할 수 있다.
• 정기적으로 상태 확인을 하고 실패가 있는 인스턴스에는 로드 밸런서가 트래픽을 보내지 않는다.
• 웹사이트의 SSL 종료, 즉 HTTPS를 아주 쉽게 제공할 수 있다.
• 여러 가용 영역에서 로드 밸런서를 사용할 수 있어 애플리케이션의 가용성이 높아진다.
• ELB 는 관리형 로드 밸런서. -> 서버를 프로비저닝할 필요가 없이 AWS 에서 처리.
  1. AWS 가 작동을 책임진다.
  2. AWS 가 ELB 의 업그레이드, 유지 보수, 고가용성을 모두 책임진다.
  3. 유일하게 개발자가 할 일은 해당 로드 밸런서의 동작에 관해 몇가지를 구성하는 것이다.
• 자체 Load Balancer 를 EC2 에서 설정하는 경우 비용이 확실히 덜 들지만, 결국에는 이전에 말한 유지보수, 운영체제 업그레이드 처리 등 훨씬 더 많은 작업을 하게 된다.

LSB 의 4가지 차이점

1. HTTP, HTTPS 전용 트래픽을 위한 Application Load Balancer - Layer 7 유형
2. TCP, UDP(Ultra-high Performance) 를 허용하여 초고성능인 NetWork Load Balancer - Layer 4 유형
3. Gatewqy Load Balancer - Layer 3
4. Claasic Load Balancer - 필요없다 2023년에 사라짐, Layer 7,4 유형 -> ALB와 NLB 로 대체 되었음.

--------> 이렇게 Load Balancer 를 이용하여 애플리케이션의 로드를 분산할 수 있다.

그렇다면 어떻게 백엔드에서 자동으로 이 서버를 만들 수 있을까?

    -----> Auto Scaling Group 

 

Auto Scaling Group

What is Auto Scaling Group? : Auto Scaling Group 의 목적은 Scalie Out (Add EC2 Instance)

• 현실에서 웹사이트 로드는 시간에 따라 다르다. ex) 쇼핑하는 사용자가 있을때, 낮 에는 쇼핑을 하고 밤에는 쇼핑을 안할 가능성이 크다. -> 따라서 낮 시간에 로드가 더 많을 것이라 예상할 수 있고, 밤 시간에 로드는 적을 것이다.
• In the Cloud -> 빠른 시간에 서버를 만들고 없앨 수 있다.
• 오토스케일그룹의 목적은 스케일 아웃이다.
  1. 이는 늘어난 로드에 맞춰 EC2 인스턴스를 늘린다.
  2. 또는 Scale In(Remove EC2 Instance) 즉, 줄어든 로드에 맞춰 EC2 인스턴스를 줄인다.
  3. 이를 통해 어느 시점이든 실해하는 Machines 이 러닝하는 숫자를 최소, 최대로 보장할 수 있다.
  4. Auto Scaling Group 이 만들어지거나 EC2 인스턴스를 제거하면 로드밸런서에 등록되거나 해지됨을 확인할 수 있다.
  5. 서버의 상태가 비정상이거나, 애플리케이션에 버그가 있다면 Auto Scaling Group 이 이를 감지하여, 비정산 인스턴스는 필요하지 않으니 등록을 해지하고 종료한다. -> 새로운 정상 인스턴스로 교체해준다,
• 비용절감 -> 항상 최적의 용량에서 실행하기 때문-> 이러한 탄력성은 클라우드의 기본 원칙이다.

AWS 에서 오토 스케일링 그룹

 

 

• 최소 크기의 EC2 인스턴스를 가진다.(Minimum size)
• Actual Size / Desired Capcity 에서는 희망 용량을 설정하는 곳 보통 Auto Scaling Group 의 실제 크기이다.
• 마지막으로 Auto Scaling Group 의 최대 크디를 정의할 수 있다.
• Scale Out as Needed 에서는 ASG 의 최대 크기를 정의할 수 있다. ASG를 자동으로 필요에 따라 스케일 아웃하거나 인을 하여 EC2 인스턴스를 시간에 따라 늘린다.
• 이는 로드밸런서와 함께 동작한다.

• 즉, 로드 밸런서를 통해 오는 웹 트래픽은 EC2 인스턴스로 바로 리디렉션 한다.
• 오토 스케일링 그룹이 인스턴스를 추가하여 스케일 아웃함에 따라 로드 밸러서는 이를 등록하고, 이들에게도 트래픽을 보낼 것이다.
• EC2 인스턴스를 추가할수록 로드밸런서가 더 많은 트래픽을 ASG의 최대 크기까지 분산할 수 있다.

ASG(Auto Scaling Group) 에 관한 Scaling 전략

• Manual Scaling: 수동으로 스케일링하는 것 - ASG 크기를 수동으로 업데이트 하는 것(ex : 용량을 1에서 2로 변경하거나 2에서 1로 변경하는 것)
•   Dynamic Scaling: 변경사항을 자동으로 스케일링하여 대응 하는 것 
  [1] Simple / Step Scaling(단순 / 단계 스케일링) :
  1. CloudWatch alarm 이 트리거 됐을 때 ( ex: EC2 인스턴스의 CPU 사용량이 5분동안 70%를 초과할 때마다) ASG 용량에 2개의 unit을 추가
  2. CloudWatch alarm 이 트리거 됐을 때 (ex: EC2 인스턴스의 CPU 사용률이 10분 동안 30% 이하일 때마다) ASG 용량에서 1개의 unit을 제거한다.
  -> 이는 트리거를 정의한다음에 유닛을 얼마나 추가하고 삭제할지 정의
  [2] Target Tracking Scaling -> 스케일링 정책을 손쉽게 정의하는 방식
  1. ASG의 모든 EC2 인스턴스의 평균 CPU 사용률을 평균 40%로 유지하고자 하면, ASG에서 목표인 40%를 유지하기 위해 자동으로 조정하는 것
  [3] Scheduled Scaling (예약 스케일링)
  1. 변경 사항을 미리 아는 것으로 사용자 패턴을 기반으로 확장을 예측한다.
  2. Example: 사람들이 금요일 오후 5시에 축구 경기에 배팅을 한다고 하면, 금요일 오후 5시에 ASG의 EC2 인스턴스 최소용량을 10까지 높이는 것 
  [4] Predictive Scaling (예측 스케일링) -> 중요
  1. Maching Leaning 을 사용해 트래픽 을 미리 예측한다. -> 과거 트래픽 패턴을 확인하는 알고리즘이 있고, 과거의 패턴을 기반으로 트래픽을 예측한다.
  2.  예측 스케일링인 이유는 시간이 지남에 따라 발생하는 로드를 예측하기 때문....!
  3. 로드는 하루에 3시간 동안 최고조가 될 것.-> 예측 스케일링을 통해 알 수 있따.
  4. 예측한 기간에 도달하기 전에 올바른 수의 EC2 인스턴스를 자동으로 provisions 한다.
  5. 아래의 그래프와 같다. -> 시간적인 패턴이 존재하고 스케일링 유형에 따라 달라지는 신뢰 전략을 신경쓰지 않고 머신 러닝을 기반으로 쉽게 스케일링 하고자 한다면, 예측 스케일링이 매우 유용하다.

ELB 와 ASG 요약

1. 고가용성 vs 수직적 vs 수평적 일 수 있는 확장성 탄력성 클라우드의 민첩성 개념
2. 고가용성: 여러 가용 영역에 걸쳐 애플리케이션을 보유.
3. 수직확장: 인스턴스의 크기를 늘리는 것
4. 수평확장: 인스턴스의 수를 늘리는 것
5. 탄력성: 수요에 따라 확장 및 축소할 수 있는 기능
6. 민첩성: 리소스를 매우 빠르게 생성 및 삭제할 수 있어, 작업을 더 신속하게 할 수 있도록 지원하는 클라우드

 

Elastic Load Balncers(ELB)
1. 로드 밸런서로는 ELB가 있고, 이를 통해 백엔드 EC2 인스턴스에 트래픽을 분산할 수 있으며, Mutil-AZ(여러 가용 영역에 걸쳐 분산할 수 있다.)
2. 상태 확인을 지원하여 백엔드 EC2 인스턴스가 정상 상태인지 확인할 수 있다.
3. 4개 종류의 로드 밸런서가 있다.
* Classic Load Balancer(폐기)
* 워크로드를 위한 Application Load Balancer(HTTP유형 - Layer 7
수준의 로드 밸런싱)
* 매우 높은 성능과 속도 Network Load Balancer(TCP - L4 수준의 로드 밸런싱)
* 네트워크 자체를 라우팅하여 가상 어플라이언스 등을 통과하도록 하는 Gateway Load Balancer(Layer 3 수준의 로드 밸런싱)

Auto Scaling Group
1. 애플리케이션의 탄력성을 구현할 수 있어, 부하를  Multi-AZ(여러 가용 영역) 걸쳐 분산하고 적절히 스케일링할 수 있다.
2. 시스템의 수요에 따라 이러한 EC2 인스턴스를 스케일링하고 비정상 인스턴스를 교체할 수 있다.

 

즉.

ASG 와 ELB 는 서로 연결되어 있다. 

-> 이 조합을 가지고, 고가용성, 확장성, 탄력성, 클라우드의 민첩성을 확보할 수 있다.!!!!!!!!