# Auto Scaling Group (ASG)

### Launch Template

**시작 구성**은 레거시다.

- 여러 버전을 가질 수 있다.

- 재사용, 상속 가능하도록 부분별로만 변경할 수도 있다 (parameters subsets)

- On-demand와 스팟 인스턴스 둘 다를 가지고 프로비저닝할 수 있다.

- [T2 무제한 기능](https://aws.amazon.com/ko/blogs/korea/new-t2-unlimited-going-beyond-the-burst-with-high-performance/)을 사용할 수 있다.

### Scaling Policies

- 자동으로 지표를 감시하며 확장할 수도 있고, CW alarm이 트리거할 수도 있다.

- **Cooldown** : 스케일링을 한 후 몇 초 동안은 스케일링을 하지 않는다.

- **Scheduled Actions** : 특정 기간동안 자동으로 스케일링하도록 한다.

### ALB Integration

Target Group에 Health check를 설정하고, unhealthy하면 ASG에 알려 스케일링을 진행한다.

- **EC2** : 인스턴스가 healthy한가?

- **ELB** : health request에 제대로된 응답이 오는가?

**Slow start duration**을 설정해 인스턴스가 준비될 때까지 몇 초동안 기다릴 수도 있다.

### Suspended Process

[Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개 - 아마존 EC2 오토 스케일링](https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/as-suspend-resume-processes.html)

EC2를 Launch, Terminate하는 등의 모든 행위를 프로세스라고 한다. ASG는 이 프로세스를 중지할 수 있다.

예를 들어, Terminate 프로세스를 중지하면, 인스턴스는 **ASG에 의해 **종료되지 않는다.

이는 인스턴스에 오류가 발생했을 때, 트러블슈팅을 할 때 유용하다.

### Troubleshooting

각 인스턴스별로 트러블슈팅을 하고 싶으면 아래 옵션을 적용할 수 있다.

- **Detach** : ASG와 ELB에서 인스턴스를 제거하지만 종료하지는 않는다.

- **Standby** : ELB에서만 인스턴스를 제거하고 ASG에서는 유지한다.

- **Scale in Protection** : 스케일링을 통해 제거되지 않는다.

### 수명 주기 후크 (Lifecycle Hooks)

인스턴스가 실행되거나 종료되기 전에 이벤트를 발생시키고 특정한 행동을 수행하게 할 수 있다. 이 이벤트는 CW Events나 SQS, SNS로 받을 수 있다. 

참고로 `Hook → CW Events → Lambda → SSM Document` 파이프라인을 만들어서 인스턴스 내부에 명령을 보낼 수도 있다.

![Image](https://upload.cafenono.com/image/slashpageHome/20240820/134248_IPpBkVxojHQipbnspu?q=80&s=1280x180&t=outside&f=webp)

### ASG 종료 정책

원하는 종료 정책을 설정할 수 있다. 아래는 디폴트 값이다.

1. 인스턴스의 수가 가장 많은 AZ를 선택한다.

2. 가장 오래된 템플릿을 가진 인스턴스를 삭제한다.

3. 청구 시간이 가장 가까운 인스턴스를 삭제한다.

### SQS Integration

ASG의 인스턴스들이 SQS를 읽어오는 경우 스케일링 정책은 어떻게 해야 할까? 남은 SQS queue를 관찰하고 CW Alarm을 통해 scaling할 수 있다.

![Image](https://upload.cafenono.com/image/slashpageHome/20240820/134249_UC6zEPJYarWBe5pZ2f?q=80&s=1280x180&t=outside&f=webp)

### CloudFormation - CreationPolicy

CFN으로 ASG를 생성할 때, `CreationPolicy` 을 정한다.

```
CreationPolicy:
	Count: '3'
	Timeout: PT15M
```

15분 내로 success 신호가 3번 오면 ASG를 success로 바꾼다. success 신호는 EC2의 user data에 cfn signal을 통해 설정한다.

### CloudFormation - UpdatePolicy

CFN으로 ASG를 업데이트할 때 취하는 액션을 설정한다.

**AutoScalingRollingUpdate**

한 ASG 안에서 n개씩 새 인스턴스를 생성한 후, n개를 종료한다.

```
UpdatePolicy:
	AutoScalingRollingUpdate:
		MinInstancesInService: '1' # 최소한 실행되어야 하는 인스턴스 수
		MaxBatchSize: '2' # 한 번에 만들 인스턴스 수
		PauseTime: PT1M
		WaitOnResourceSignals: 'true' # cfn-signal을 기다리는가?

  AutoScalingScheduleAction:
		# Scheduled Action이 min/max/desired를 바꾸는 것을 막는다.
    IgnoreUnmodifiedGroupSizeProperties: 'true'☕️
```

**AutoScalingReplacingUpdate**

Blue/Green 배포처럼 새로운 ASG를 만든 후, 기존의 ASG를 대체한다.

```
UpdatePolicy:
	AutoScalingReplacingUpdate:
		WillReplace: 'true'
```

### CodeDeploy와 통합

ASG와 CodeDeploy를 양방향으로 잘 엮여 있다.

- CodeDeploy로 배포하면, ASG의 인스턴스들은 모두 배포 전략에 의해 교체된다.

- ASG의 desired를 변경하면, CodeDeploy를 트리거해 ASG에 새로 배포하게한다.

**배포 전략**

- **In-place **: ASG의 인스턴스를 교체한다.

- **Blue/Green** : 새로운 ASG를 만들고, 기존의 ASG를 제거한다.

### CodeDeploy 트러블슈팅

배포 중에 ASG 확장하면 어떻게 되나요? 같은 당황할만한 질문에도 답할 줄 알아야 한다. 읽자.

[Amazon EC2 Auto CodeDeploy Scaling과의 통합 - AWS CodeDeploy](https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws-auto-scaling.html#integrations-aws-auto-scaling-behaviors-mixed-environment)

For the site tree, see the [root Markdown](https://slashpage.com/kaonmir.md).