DEVELOPyo

[ ASG : Auto Scaling Groups ]

로드밸런서의 인스턴스 갯수의 최소 최대 값을 정해놓고 사용. 설정값보다 수가 적은 경우 인스턴스 갯수를 확장(scale out), 적을 경우 축소(scale in)

In the cloud you can create and get rid of servers very quickly

The goal of an ASG is to :

1) Scale out (add EC2 instances) to match an increased load

2) Scale in (remove EC2 instances) to match a decreased load

3) Ensure we have a minimum and a maximum number of machines running

4) Automatically Register new instances to a load balancer

# ASGs have the follong attributes

- A launch configuration

  1) AMI + Instance Type

  2) EC2 User Data

  3) EBS Volumes

  4) Security Groups

  5) SSH Key Pair

- Min Size/Max Size/Initial Capacity

- Network + Subnets Information

- Load Balancer Information

# Auto Scaling Alarms

CloudWatch alarm 을 이용하여 ASG 를 컨트롤 (Alarm 은 ASG 를 컨트롤 하기 위한 트리거 역할)

- It is possible to scale an ASG based on CloudWatch alarms

- An Alarm monitors a metric (such as Average CPU)

- Metrics are computed(집계/산정) for the overall ASG instances

- Based on the alarm :

   -- 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 ]

직접적으로 EC2 상태(CPU사용률 등)를 기반으로 확장 기준을 정의할 수 있음

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

  1) Target Average CPU Usage

  2) Number of requests on the ELB per instance

  3) Average Network In

  4) 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 (eg. number of connected users)

1) Send custom metric from application on EC2 to CloudWatch

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 or Launch Templates(newer)

- To update an ASG, you must provide a new launch configuration/launch template

- 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 automatically create new ones as a replacement. (Extra safety)

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

[ Scaling Policies of ASG ]

1. Target Tracking Scaling (타겟 기준점 정함)

  - Most simple and easy to set-up

  eg. I want the average ASG CPU to stay at around 40%

2. Simple/Step Scaling (상한 하한 기준 정함)

  - When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units

  - When a CloudWatch alarm is triggered (example CPU < 30%), then remove 1 unit

3. Scheduled Actions (특정 스케쥴에 확장/축소)

   - Anticipate a scaling based on known usage patterns

   - eg. increase the min capacity to 10 at 5 PM on Fridays

# Simple Scaling vs Step Scaling :

보통 Step Scaling 사용을 추천

- Simple Scaling 은 Scaling 이 완료될 때 까지, 그리고 cooldown 시간을 기다린 후 Alarm 에 응답.

- Step Scaling 은 Scaling 이 진행 중일 때도 Alarm 에 응답. 경보 메시지 수신 가능

참고

[ Scaling Cooldowns *** ]

직전의 ASG에 의한 인스턴스 확장/축소가 실제로 효과를 내기 전에 추가적인 확장/축소가 일어나지 않도록 일정 시간 딜레이를 주는 옵션.

쿨다운 시간이 너무 길 경우 축소(scale in)시 바로 꺼져도 되는 인스턴스가 살아있어 무의미한 인스턴스 사용요금이 발생 할 수 있음. 이 경우 쿨다운 시간을 줄여 비용절감을 할 수 있음.

짧은 시간 동안 여러번의 확장/축소가 이뤄져야 할 경우 쿨다운 시간을 적게 주어야 함.

- The cooldown period helps to ensure that your Auto Scaling group doesn't launch or terminate additional instances before the previous scaling activity takes effect.

- In addition to default cooldown for Auto Scaling group, we can create cooldowns that apply to a specific simple scaling policy

- A scaling-specific cooldown period overrides the default cooldown period.

- One common use for scaling-specific cooldowns is with a scale-in policy-a policy that terminates instances based on a specific criteria or metric. Because this policy terminates instances, Amazon EC2 Auto Scaling needs less time to determine whether to terminate additional instances.

- If the default cooldown period of 300 secs is too long - you can reduce costs by applying a scaling-specific cooldown period of 180 secs to the scale-in policy.

- If your application is scaling up and down multiple times each hour, modify the ASG cool-down timers and the CloudWatch Alarm Period that triggers the scale in 

[ ASG for Solutions Architects *** ]

ASG 축소시 인스턴스 제거 정책. 인스턴스가 가장 많은 AZ 를 찾은 후, 그 안에서 가장 오래된 런치 설정의 인스턴스를 찾아 제거

1. ASG Default Termination Policy :

   1) Find the AZ which has the most number of instances

   2) If there are multiple instances in the AZ to choose from, delete the one with the oldest launch configuration

* ASG tries the balance the number of instances across AZ by default.

2. Lifecycle Hooks

- You have the ability to perform extra steps before the instance goes in service (Pending state)

- You have the ability to perform some actions before the instance is terminated (terminating state)

  eg. logging 

3. Launch Template vs Launch Configuration

* Both :

ID of AMI, the instance type, the instance type, a key pair, security groups, and the other parameters that you use to launch EC2 instances (tags, EC2 user-data..)

* Differences :

1) Launch Configuration (legacy) :

   - Must be re-created every time

2) Luanch Template (newer) :

   - Can have multiple versions

   - Create parameters subsets (partial configuration for re-use and inheritance)

   - Provision using both On-Demand and Spot instances (or a mix)

   - Can use T2 unlimited burst feature

   - Recommended by AWS going forward