[AWS] ASG(Auto Scaling Group)

ASG(Auto Scaling Group)

• 웹사이트나 애플리케이션을 배포할 때, 웹사이트 방문자가 갈수록 많아지면서 로드가 바뀔 수 있다. 그리고 클라우드(ASW)에서 EC2 인스턴스 생성 API 호출을 통해 서버를 빠르게 생성하고 종료할 수 있다고 알고 있다.
   → 이를 자동화하는 것이 ASG이다.
• 목표
    : 스케일 아웃(증가한 로드)에 맞춰 EC2 인스턴스를 추가하거나 그리고 스케일 인(감소한 로드)에 맞춰 EC2 인스턴스를 제거하는 것이다. 따라서 ASG 크기는 시간이 지나면서 변할 것이다.
• ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장하기 위해 매개변수를 전반적으로 정의할 수도 있다.
• 로드 밸런서와 페어링하는 경우, ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다.
• 한 인스턴스가 비정상이면, 종료하고 이를 대체할 새 EC2를 생성한다.
• ASG는 무료이며, EC2 인스턴스와 같이 생성된 하위 리소스에 대한 비용만 내면 된다.

 

ASG in AWS 예시

(출처 : 구글이미지)

• 최소 용량(ASG내 인스턴스의 최소 개수)를 설정한다. 예를 들어 2개로 설정할 수 있다.
  다음으로 희망 용량(ASG내 인스턴스의 희망개수)를 설정한다. 예를 들어 4개로 설정할 수 있다.
  마지막으로 최대 용량(ASG내 인스턴스의 최대개수)를 설정한다. 
  최대 용량 내에서 희망 용량을 더 높은 숫자로 설정하면 스케일 아웃이 된다. 즉, EC2 인스턴스를 추가한다.
  따라서 ASG가 점점 더 커질 것이다.
  위 예시의 경우 최대 용량은 7이다.

 

ASG in AWS with Load Balancer 예시

(출처 : 구글이미지)

• 위에서 말했듯이 ASG는 로드 밸런서와 작동한다. 따라서 ASG에 4개의 인스턴스가 등록되어 있으면 ELB가 모든 인스턴스에 트래픽을 즉시 분산하여 사용자가 로드밸런싱된 웹사이트에 액세스가 가능하게 한다.
• ELB는 상태 확인을 통해 EC2 인스턴스의 상태를 확인하고 ASG로 전달할 수 있다.
  따라서, 로드 밸런서가 비정상이라 판단하는 EC2 인스턴스를 ASG가 종료할 수 있어 매우 편리하다.
  또한, 스케일 아웃이 되면(EC2 인스턴스를 추가하면) ELB가 트래픽을 보내고 로드를 분산시킬 것이다.
  (그래서 로드밸런서와 ASG은 정말 좋은 조합이다)

 

ASG 속성(Attributes)

• 인스턴스 속성을 기반으로 ASG를 생성하려면 시작 템플릿(Launch Template)을 생성해야한다.
• 시작 템플릿에는 ASG내에서 EC2 인스턴스를 시작하는 방법에 대한 정보가 포함되어 있다.
• 밑의 이미지처럼 AMI 및 인스턴스 유형, EBS 볼륨, 보안 그룹, SSH 키 페어, IAM 역할, 네트워크 및 서브넷 정보, 로드 밸런서 정보 등 더 많은 정보가 있다. 이러한 모든 매개변수는 EC2 인스턴스를 생성할 때 지정한 매개변수와 매우 유사하다.
• ASG의 최소 크기, 최대 크기, 초기 용량, 스케일링 정책을 정의해야 한다.

(출처 : 구글이미지)

 

 

ASG - CloudWatch Alarms & Scaling 통합되는 방식

• CloudWatch Alarms(경보)를 기반으로 ASG를 스케일 인 및 스케일 아웃할 수 있다.

 

(출처 : 구글이미지)

• 예를 들어, 세 개의 EC2 인스턴스를 포함한 ASG가 있는데 경보가 울리게되면 스케일 아웃이 발생한다.
• 어떤 것이 경보를 울릴까?
   : "지표(metric)"이다. 즉 모니터링할 수 있는 평균 CPU나 원하는 사용자 지정 지표 어떤 것도 지정할 수 있다.
• ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스를 추가로 필요한데 지표에 따라 경보가 울리고
  경보가 ASG의 스케일링 활동을 유발한다.
• 경보에 의해 내부에서 자동적인 스케일링이 이루어진다.
   : 경보를 기반으로 스케일 아웃 정책을 만들어 인스턴스 수를 늘리거나 스케일 인 정책을 만들어 인스턴스 수를 줄일 수 있다.
  
  

 

ASG - Scaling Policies(정책)

• 어떤 좋은 메트릭을 활용해서 스케일링 할 수 있을지가 문제이다. 이는 실제로 애플리케이션이 수행하는 작업과 작동방식에 따라 달라진다.

Dynamic Scaling(동적 스케일링)

• Target Tracking Scaling(목표 추적)
   - 설정이 매우 간단한 스케일링이다.
   - 예를 들어, CPU 사용률과 같은 ASG에 대한 메트릭을 정의하고 40%와 같은 목표 값을 정의하는 것이다.
     : 자동으로 ASG가 확장되거나 축소되어 이 메트릭을 약40%로 유지할 수 있다.
• Simple / Step Scaling(단순 또는 단계 스케일링)
   - CloudWatch 경보가 트리거될 때 (ex. CPU > 70%), 2 유닛 추가하도록 설정
   - CloudWatch 경보가 트리거될 때 (ex. CPU < 30%), 1 유닛 제거 설정

Scheduled Scaling(예약 스케일링)

• 알려진 사용 패턴을 기반으로 스케일링을 예상할 수 있다.
• 예를 들어, 금요일 오후 5시에 매번 새로운 사용자가 발생하므로 최소 용량을 10으로 늘리려는 경우이다.

Predictive Scaling(예측 스케일링)

• 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우이다. 따라서, 반복되는 패턴이 있을 때 매우 좋다.

(출처 : 구글이미지)

• ASG는 자동으로 과거 부하를 분석한 다음 예측치를 생성하여 예측치를 기반으로 스케일링 작업을 예약한다. 이는 주기적 데이터가 있는 경우 매우 유용할 수 있다.

 

Good metrics to scale on(스케일 조절할 때 좋은 지표)

• CPU 활용도
    : 인스턴스가 요청을 받을 때마다 일반적으로 일종의 계산을 수행하기 때문에, 일부 CPU를 사용하게 된다.
     따라서, 모든 인스턴스의 평균 CPU 사용률을 살펴본 후, 이 비율이 높아지면 인스턴스의 활용도가 더 높다는 의미이다.
• 테스트를 기반으로 하는 타깃당 요청 수
    : EC2 인스턴스는 한 번에 타깃별로 1000개의 요청이라는 최적의 요청으로 작동하므로, 사용자가 원하는 스케일링 목표일 수도 있다. (이 내용에 추가 설명은 밑의 이미지 설명을 참고해주시면 감사하겠습니다.)
• Average Network In / Out(애플리케이션이 네트워크에 의존적인 경우)
    : 예를 들어 업로드와 다운로드가 너무 많다. 그리고 네트워크가 EC2 인스턴스의 병목 현상이 될 것 이라고 예상된다면 평균 네트워크 사용량을 기준으로 스케일링을 설정하는 것이 좋다.
• Any custom metric(사용자 정의 메트릭)
    : 특정 임계값에 도달했을 때 자동으로 스케일링이 이루어지거나 클라우드 와치에 설정한 사용자 정의 메트릭을 기반으로 스케일링을 조정할 수 있다. 따라서, 애플리케이션별로 고유한 메트릭을 설정할 수 있다.

(출처 : 구글이미지)

• 3개의 EC2 인스턴스가 있는 ASG이 있다. 현재 ELB는 모든 인스턴스에 요청을 고르게 분산시키고 있다. 
  따라서 현재 각 EC2 인스턴스에는 평균 3개의 미해결 요청이 있으므로, 타깃 메트릭당 요청 수 값은 3이다.

 

ASG - Scaling Cooldowns(스케일링 쿨다운)

• 스케일링 작업이 있은 후에, 인스턴스를 추가하거나 제거할 때마다 기본적으로 5분(300초) 쿨다운 시간에 들어간다.
  이 쿨다운 시간 동안 ASG는 추가 인스턴스를 개시하거나 종료하지 않는다.
   - 이유는? 
        : 메트릭이 안정화되도록 하고 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지를 지켜보는 시간을 가지기 위해서이다.
• 즉시 사용이 가능한 AMI등을 사용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다. 그래야 활성화 시간을 빠르게 해야 휴지기간 또한 줄어들어 더 많은 동적 스케일링이 가능하다.