Auto Scaling Group

클라우드에서는 웹사이트나 애플리케이션을 로드하는 방법이 달라집니다. 서버를 생성하거나 삭제하는게 매우 빨라지죠

 

 

오토 스케일링 그룹의 목표는 다음과 같습니다

- 로드가 증가될 때 스케일 아웃(EC2 인스턴스 추가)

- 로드가 감소할 때 스케일 인(EC2 인스턴스 삭제)

- 가용할 수 있는 머신의 최대 최소 수 확인

- 로드밸런서에 새 인스턴스 자동 등록

 

 

 

오토 스케일링 그룹의 특징

a) AMI + Instance Type

b) EC2 User Data

c) EBS Volumes

d) Security Groups

e) SSH Key Pair

- Min Size / Max Size / Initial Capacity

- Network + Subnets Information

- Load Balancer Information

- Scaling Policies

 

오토 스케일링 알람

 

CloudWatch 알람을 통해 오토스케일링을 할 수가 있다

- We can create scale-out policies(increase the number of instances)

- We can create scale-in policies(decrease the number of instances)

Auto Scaling New Rules

 

It is now possible to define "better" auto scaling rules that are directly managed by EC2

- Target Average CPU Usage

- Number of requests on the ELB per instance

- Average Network In

- Average Network Out

These rules are easier to set up and can make more sense 

 

Auto Scaling Custom Metric

 

We can auto scale based on a custom metric (ex: number of connected users)

 

I. Send custom metric from application on EC2 to CloudWatch (PutMetric API)

2. Create CloudWatch alarm to react to low / high values

3. Use the CloudWatch alarm as the scaling policy for ASG

 

ASG Brain dump

 

Scaling policies can be on CPU Network.... and can even be on custom metrics or based on a schedule(If you know your visitors patterns)

ASGs use Launch configurations and you update an ASG by providing a new launch configuration

IAM roles attached to an ASG will get assigned to EC2 instances

ASG are free. You pay for the underlying resources being launched

Having instances under an ASG means that if they get terminated for whatever reason, the ASG will restart them. Extra safety

ASG can terminate instances marked as unhealthy by an LB (and hence replace them)