기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 조정 기능으로 애플리케이션의 컴퓨팅 용량 늘리거나 줄이기
*조정*은 애플리케이션의 컴퓨팅 용량을 늘리거나 줄이는 기능입니다. 조정은 이벤트와 함께 시작되거나 Auto Scaling 그룹에 Amazon EC2 인스턴스를 시작 또는 해지하도록 지시하는 조정 작업과 함께 시작됩니다.
Amazon EC2 Auto Scaling에서는 여러 가지 방법으로 애플리케이션의 요건에 가장 적합하게 조정 기능을 조절할 수 있습니다. 그러므로 애플리케이션을 충분히 이해하는 것이 중요합니다. 다음 사항에 유의하세요.
+ Amazon EC2 Auto Scaling이 애플리케이션 아키텍처에서 수행해야 하는 역할은 무엇인가요? 자동 조정을 주로 용량을 늘리거나 줄이는 수단으로 생각하는 것이 일반적이지만, 이는 안정적인 서버 수를 유지하려는 경우에도 유용합니다.
+ 나에게 중요한 비용 제약 조건은 무엇인가요? Amazon EC2 Auto Scaling에서는 EC2 인스턴스를 사용하므로 사용한 리소스에 대해서만 비용을 지불합니다. 비용 제약 조건을 알면 애플리케이션의 스케일 아웃 시기와 규모를 결정하는 데 도움이 될 수 있습니다.
+ 애플리케이션에 어떤 지표가 중요한가요? Amazon CloudWatch는 Auto Scaling 그룹에서 사용할 수 있는 여러 가지 지표를 지원합니다.
**Topics**
+ [스케일링 방법 선택](scaling-overview.md)
+ [스케일링 한도 설정](asg-capacity-limits.md)
+ [기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md)
+ [수동 조정](ec2-auto-scaling-scaling-manually.md)
+ [예약된 크기 조정](ec2-auto-scaling-scheduled-scaling.md)
+ [동적 조정](as-scale-based-on-demand.md)
+ [예측 크기 조정](ec2-auto-scaling-predictive-scaling.md)
+ [인스턴스 종료 제어](as-instance-termination.md)
+ [프로세스 일시 중지 후 재개](as-suspend-resume-processes.md)
# 스케일링 방법 선택
Amazon EC2 Auto Scaling은 Auto Scaling 그룹을 조정하는 다양한 방법을 제공합니다.
**일정한 수의 인스턴스 유지**
Auto Scaling 그룹의 기본값은 연결된 스케일링 정책이나 예약된 작업이 없어 고정된 크기를 유지하도록 하는 것입니다. Auto Scaling 그룹을 생성하면 그 그룹은 원하는 용량을 충족하도록 충분한 인스턴스를 시작하여 시작합니다. 그룹에 연결된 스케일링 조건이 없는 경우, 인스턴스가 비건전 상태가 되더라도 원하는 용량을 계속 유지합니다. Amazon EC2 Auto Scaling은 귀하의 Auto Scaling 그룹에서 각 인스턴스의 상태를 모니터링합니다. 인스턴스가 비건전 상태가 된 것을 발견하면 새 인스턴스로 교체합니다. 이 프로세스에 대한 자세한 설명은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md)에서 확인할 수 있습니다.
**수동 조정**
수동 스케일링은 Auto Scaling 그룹을 스케일링하는 가장 기본적인 방법입니다. Auto Scaling 그룹을 원하는 용량으로 업데이트하거나 Auto Scaling 그룹의 인스턴스를 종료할 수 있습니다. 자세한 내용은 [Amazon EC2 Auto Scaling의 수동 조정](ec2-auto-scaling-scaling-manually.md) 단원을 참조하십시오.
**일정에 근거하여 조정**
일정에 따른 조정은 조정 작업이 날짜 및 시간 함수에 따라 자동으로 수행됨을 의미합니다. 그룹의 인스턴스 수를 늘려야 할지 또는 줄여야 할지 정확히 아는 경우에 유용합니다. 그 이유는 예측 가능한 일정에 따라 수요가 증가하기 때문입니다. 자세한 내용은 [Amazon EC2 Auto Scaling에 예약된 조정](ec2-auto-scaling-scheduled-scaling.md) 단원을 참조하십시오.
**수요에 따라 동적으로 조정**
동적 조정을 사용해 리소스를 조정하는 더 향상된 방법을 사용하면 수요 변화에 맞춰 Auto Scaling 그룹의 크기를 동적으로 조정하는 조정 정책을 정의할 수 있습니다. 예컨대, 현재 인스턴스 2개에서 웹 애플리케이션이 실행되고 있고 사용자가 애플리케이션 로드에 변경이 있는 경우, Auto Scaling 그룹의 CPU 사용량을 50% 정도로 유지시키려 한다고 가정해 보겠습니다. 이 방법은 트래픽이 변경될 시점을 모르는 경우 트래픽 변경 발생 시 조정하는 데 유용합니다. 대신 응답하도록 스케일링 정책을 구성할 수 있습니다. 트래픽 변경에 따라 스케일 인 대응에 사용할 수 있는 여러 정책 유형(또는 이들의 조합)이 있습니다. 자세한 내용은 [Amazon EC2 Auto Scaling의 동적 조정](as-scale-based-on-demand.md) 단원을 참조하십시오.
**사전 예방적 조정**
예측 조정과 동적 조정(각각 사전 예방형 및 사후 대응형 접근 방식)을 결합하여 EC2 용량을 보다 신속하게 조정할 수도 있습니다. 예측 조정을 사용하여 트래픽 흐름의 일일 및 주간 패턴에 앞서 Auto Scaling 그룹의 EC2 인스턴스 수를 늘릴 수 있습니다. 자세한 설명은 [Amazon EC2 Auto Scaling의 예측 조정](ec2-auto-scaling-predictive-scaling.md) 섹션을 참조하세요.
# Auto Scaling 그룹에 대한 스케일링 제한 설정
스케일링 한도는 Auto Scaling 그룹의 원하는 최소 및 최대 그룹 크기를 나타냅니다. 최소 및 최대 크기에 대해 별도로 제한을 설정합니다.
그룹의 원하는 용량은 최소 및 최대 크기 제한 범위 내의 수치로 조정할 수 있습니다. 원하는 용량은 최소 그룹 크기보다 크거나 같아야 하며 최대 그룹 크기보다 작거나 같아야 합니다.
+ **Desired capacity**(원하는 용량): 생성 시의 초기 Auto Scaling 그룹 용량을 나타냅니다. Auto Scaling 그룹은 원하는 용량을 유지하려고 시도합니다. 이는 원하는 용량을 제공하도록 지정된 수의 인스턴스를 시작하는 것으로 시작되며, Auto Scaling 그룹에 연결된 조정 정책이나 예약된 작업이 없는 경우, 이 인스턴스 수를 유지합니다.
+ **최소 용량(Minimum capacity)**: 최소 그룹 크기를 나타냅니다. 조정 정책이 설정되면 정책은 그룹이 원하는 용량을 최소 용량보다 작게 줄일 수 없습니다.
+ **최대 용량(Maximum capacity)**: 최대 그룹 크기를 나타냅니다. 조정 정책이 설정되면 정책은 그룹이 원하는 용량을 최대 용량보다 크게 늘일 수 없습니다.
최소 및 최대 크기 제한은 다음 시나리오에서도 적용됩니다.
+ 원하는 용량을 업데이트하여 Auto Scaling 그룹을 수동으로 조정하는 경우
+ 원하는 용량을 업데이트하는 예약된 작업이 실행되는 경우 그룹에 대해 새 최소 및 최대 크기 제한을 지정하지 않고 예약된 작업을 실행하면, 그룹의 현재 최소 및 최대 크기 제한이 적용됩니다.
Auto Scaling 그룹은 항상 원하는 용량을 유지하려고 시도합니다. 인스턴스가 예기치 않게 해지되는 경우(예: 스팟 인스턴스 중단, 건전성 체크 불합격 또는 사용자 작업으로 인해) 이 그룹은 원하는 용량을 유지하기 위해 새 인스턴스를 자동으로 시작합니다.
**콘솔에서 이러한 설정을 관리하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Auto Scaling**에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. **Auto Scaling 그룹** 페이지에서 Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. 아래 창의 **세부 정보** 탭에서 그룹의 원하는 용량, 최소 및 최대 용량에 대한 현재 설정을 확인하거나 변경합니다. 자세한 내용은 [기존 Auto Scaling 그룹의 원하는 용량 변경](ec2-auto-scaling-scaling-manually.md#change-desired-capacity) 단원을 참조하십시오.
**세부 정보** 창 위에는 Auto Scaling 그룹의 현재 인스턴스 수, 원하는 용량, 최소 및 최대 용량, 그리고 상태 열 같은 정보가 나와 있습니다. Auto Scaling 그룹이 인스턴스 가중치를 사용하는 경우, 원하는 용량에 기여한 용량 단위 수도 확인할 수 있습니다.
목록에서 열을 추가하거나 제거하려면 페이지 상단의 설정 아이콘을 선택합니다. 그런 다음 **Auto Scaling groups attributes**(Auto Scaling 그룹 속성)에서 각 열을 켜거나 끄고 **Confirm**(확인)을 선택합니다.
**변경한 후 Auto Scaling 그룹의 크기 확인**
**인스턴스(Instances)** 열에는 현재 실행 중인 인스턴스 수가 표시됩니다. 인스턴스가 시작되거나 해지되는 동안에는 다음 이미지에 표시된 것처럼 **상태(Status)** 열에 *용량 업데이트 중(Updating capacity)* 상태가 표시됩니다.
![\[Auto Scaling 그룹의 용량을 업데이트합니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/asg-console-updating-capacity.png)
몇 분 동안 기다렸다가 보기를 새로 고쳐 최신 상태를 확인합니다. 크기 조정 활동이 완료되면 **인스턴스(Instances)** 열에 업데이트된 값이 표시됩니다.
**Instance management**(인스턴스 관리) 탭의 **Instances**(인스턴스)에서 현재 실행 중인 인스턴스의 개수와 상태를 확인할 수 있습니다.
# Auto Scaling 그룹의 기본 인스턴스 워밍업 설정
CloudWatch는 Auto Scaling 인스턴스 전체에서 CPU 및 네트워크 I/O와 같은 사용 데이터를 수집하고 집계합니다. 이러한 지표를 사용하여 선택한 지표의 값이 증가 및 감소함에 따라 Auto Scaling 그룹의 인스턴스 수를 조정하는 조정 정책을 생성합니다.
인스턴스가 `InService` 상태에 도달한 후 사용량 데이터를 집계 지표에 제공하기 전에 대기하는 시간을 지정할 수 있습니다. 이 지정된 시간을 *기본 인스턴스 워밍업*이라고 합니다. 이렇게 하면 동적 조정이 아직 애플리케이션 트래픽을 처리하지 않고 있고 일시적으로 컴퓨팅 리소스 사용량이 많을 수 있는 개별 인스턴스에 대한 지표의 영향을 받지 않습니다.
대상 추적 및 단계 조정 정책의 성능을 최적화하려면 기본 인스턴스 워밍업을 활성화하고 구성하는 것이 좋습니다. 기본적으로 활성화되거나 구성되지 않습니다.
기본 인스턴스 워밍업을 활성화할 때 Auto Scaling 그룹이 인스턴스 유지 관리 정책을 사용하도록 설정되어 있거나 인스턴스 새로 고침을 사용하여 인스턴스를 교체하는 경우, 인스턴스가 초기화를 완료하기 전에 최소 정상 비율에 계산되지 않게 할 수 있습니다.
**Topics**
+ [스케일링 수행 고려 사항](#scaling-performance-considerations)
+ [인스턴스 워밍업 시간 기본값 선택](#choose-the-default-instance-warmup)
+ [그룹에 대한 기본 인스턴스 워밍업 활성화](enable-default-instance-warmup.md)
+ [그룹에 대한 기본 인스턴스 워밍업 시간 확인](verify-default-instance-warmup.md)
+ [이전에 설정한 인스턴스 워밍업 시간으로 조정 정책 찾기](find-policies-with-a-previously-set-instance-warmup.md)
+ [스케일링 정책에 대해 이전에 설정한 인스턴스 워밍업을 지웁니다.](clearing-the-previously-set-instance-warmup.md)
## 스케일링 수행 고려 사항
대부분의 애플리케이션은 기능마다 다른 워밍업 시간보다 모든 기능에 적용되는 하나의 기본 인스턴스 워밍업 시간을 사용하는 것이 더 효과적입니다. 예를 들어 기본 인스턴스 워밍업을 설정하지 않으면 인스턴스 새로 고침 기능에서 상태 확인 유예 기간을 기본 워밍업 시간으로 사용합니다. 목표 추적 및 단계 조정 정책이 있는 경우, 기본 쿨다운에 설정된 값을 기본 워밍업 시간으로 사용합니다. 예측 조정 정책이 있는 경우 기본 워밍업 시간이 없습니다.
인스턴스가 워밍업 기간에 있는 동안 동적 조정 정책은 워밍업되지 않은 인스턴스의 지표 값이 정책의 경보 상한 임계값(또는 목표 추적 조정 정책의 목표 사용률)보다 큰 경우에만 스케일 아웃됩니다. 수요가 감소하면 애플리케이션의 가용성을 보호하기 위해 동적 조정이 더욱 보수적으로 됩니다. 이는 새 인스턴스 워밍업이 완료될 때까지 동적 조정을 위한 스케일 인 활동을 차단합니다.
스케일 아웃하는 동안 Amazon EC2 Auto Scaling은 그룹에 추가할 인스턴스 수를 결정할 때 워밍업 중인 인스턴스를 그룹 용량의 일부로 고려합니다. 따라서 비슷한 양의 용량을 추가해야 하는 경보 위반이 여러 번 발생하면 단일 조정 활동이 발생합니다. 지속적이지만 과도하지는 않게 스케일 아웃하기 위한 목적입니다.
기본 인스턴스 워밍업이 활성화되지 않은 경우, 인스턴스가 CloudWatch에 지표를 전송하고 현재 용량에 계산하기 전에 대기하는 시간은 인스턴스마다 다릅니다. 따라서 조정 정책이 실제 발생하는 워크로드와 비교하여 예측할 수 없는 방식으로 수행될 가능성이 있습니다.
예컨대, 반복적인 온/오프 워크로드 패턴이 있는 애플리케이션을 고려해 보겠습니다. 예측 스케일링 정책은 인스턴스 수를 늘릴지 여부에 대한 반복적인 결정을 내리는 데 사용됩니다. 예측 조정 정책에는 기본 워밍업 시간이 없으므로 인스턴스는 즉시 집계된 지표에 기여하기 시작합니다. 이러한 인스턴스가 시작 시 리소스 사용량이 많은 경우, 인스턴스를 추가하면 집계된 지표이 급증할 수 있습니다. 사용량이 안정화되는 데 걸리는 시간에 따라 이러한 지표를 사용하는 동적 스케일링 정책에 영향을 미칠 수 있습니다. 동적 스케일링 정책의 경보 최고 임계값을 위반하면 그룹 크기가 다시 증가합니다. 새 인스턴스가 워밍업되는 동안에는 스케일 인 활동이 차단됩니다.
## 인스턴스 워밍업 시간 기본값 선택
기본 인스턴스 워밍업 설정의 핵심은 인스턴스가 초기화를 완료하고 리소스 소비가 `InService` 상태에 도달한 후 안정화되는 데 필요한 시간을 결정하는 것입니다. 인스턴스 워밍업 시간을 선택할 때 합법적인 트래픽에 대한 사용량 데이터 수집과 시작 시 일시적인 사용량 급증과 관련된 데이터 수집 최소화 사이에 최적의 균형 유지를 목표로 하세요.
Elastic Load Balancing 로드 밸런서에 Auto Scaling 그룹이 연결되어 있다고 가정해 보겠습니다. 새 인스턴스 실행이 완료되면 로드 밸런서에 등록되어 `InService` 상태가 되기 전에 로드 밸런서에 등록됩니다. 인스턴스가 `InService` 상태가 된 후에도 리소스 소비가 일시적으로 급증할 수 있으며 안정화하는 데 시간이 필요할 수 있습니다. 예컨대, 큰 자산을 다운로드하고 캐시해야 하는 애플리케이션 서버의 리소스 소비는 다운로드할 큰 자산이 없는 경량 웹 서버보다 안정화하는 데 더 오래 걸립니다. 인스턴스 워밍업은 리소스 소비가 안정화되는 데 필요한 시간 지연을 제공합니다.
**중요**
워밍업에 필요한 시간이 확실하지 않은 경우 300초로 시작할 수 있습니다. 그런 다음 애플리케이션에 가장 적합한 조정 성능을 얻을 때까지 점진적으로 줄이거나 늘립니다. 이 작업을 올바르게 하려면 몇 번 수행해야 할 수 있습니다. 또는 자체 워밍업 시간(`EstimatedInstanceWarmup`)이 있는 조정 정책이 있는 경우 이 값을 사용하여 시작할 수 있습니다. 자세한 내용은 [이전에 설정한 인스턴스 워밍업 시간으로 조정 정책 찾기](find-policies-with-a-previously-set-instance-warmup.md) 단원을 참조하십시오.
시작 시 실행할 구성 작업 또는 스크립트가 있는 사용 사례에 대해 수명 주기 후크를 사용하는 것을 고려하십시오. 수명 주기 후크는 초기화가 완료될 때까지 새 인스턴스가 서비스 상태가 되는 것을 지연시킬 수 있습니다. 이 기능은 완료하는 데 시간이 걸리는 부트스트랩 스크립트가 있는 경우, 특히 유용합니다. 수명 주기 후크를 추가하면 기본 인스턴스 워밍업 값을 줄일 수 있습니다. 수명 주기 후크 사용에 대한 자세한 설명은 [Amazon EC2 Auto Scaling 수명 주기 후크](lifecycle-hooks.md) 섹션을 참조하세요.
# 그룹에 대한 기본 인스턴스 워밍업 활성화
Auto Scaling 그룹을 생성할 때 기본 인스턴스 워밍업을 활성화할 수 있습니다. 기존 그룹에 대해 기본 인스턴스 워밍업을 활성화할 수도 있습니다.
기본 인스턴스 워밍업 기능을 활성화하면 다음 기능에 대한 워밍업 파라미터 값을 더 이상 지정할 필요가 없습니다.
+ [인스턴스 새로 고침](instance-refresh-overview.md#instance-refresh-core-concepts)
+ [대상 추적 스케일링](as-scaling-target-tracking.md#as-target-tracking-scaling-warmup)
+ [단계적 조정](as-scaling-simple-step.md#as-step-scaling-warmup)
------
#### [ Console ]
**새 그룹에 대한 기본 인스턴스 워밍업 활성화(콘솔)**
Auto Scaling 그룹을 생성할 때 **고급 옵션 구성(Configure advanced options)** 페이지의 **추가 설정(Additional settings)**에서 **기본 인스턴스 워밍업 활성화(Enable default instance warmup)** 옵션을 선택합니다. 애플리케이션에 필요한 워밍업 시간을 선택합니다.
------
#### [ AWS CLI ]
**새 그룹에 대한 기본 인스턴스 워밍업 활성화(AWS CLI)**
Auto Scaling 그룹의 기본 인스턴스 워밍업을 활성화하려면 `--default-instance-warmup` 옵션을 추가하고 0에서 3600 사이의 값을 초 단위로 지정합니다. 활성화된 후 `-1` 값은 이 설정을 끕니다.
다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령은 이름이 *my-asg*인 Auto Scaling 그룹을 생성하고 *120*초 값으로 기본 인스턴스 워밍업을 활성화합니다.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg --default-instance-warmup 120 ...
```
**작은 정보**
이 명령에서 오류가 발생하면 AWS CLI 로컬에서를 최신 버전으로 업데이트했는지 확인합니다.
------
------
#### [ Console ]
**기존 그룹에 대한 기본 인스턴스 워밍업 활성화(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹을 생성한 AWS 리전 을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보(Details)** 탭에서 **고급 구성(Advanced configurations)**, **편집(Edit)**을 선택합니다.
1. **기본 인스턴스 워밍업**에서 애플리케이션에 필요한 워밍업 시간을 선택합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**기존 그룹에 대한 기본 인스턴스 워밍업 활성화(AWS CLI)**
다음 예에서는 [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용하여 *my-asg*라는 기존 Auto Scaling 그룹에 대해 *120*초 값으로 기본 인스턴스 워밍업을 활성화합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --default-instance-warmup 120
```
**작은 정보**
이 명령에서 오류가 발생하면 AWS CLI 로컬에서를 최신 버전으로 업데이트했는지 확인합니다.
------
# 그룹에 대한 기본 인스턴스 워밍업 시간 확인
다음 절차에 따라 AWS CLI를 사용하여 Auto Scaling 그룹의 기본 인스턴스 워밍업 시간을 확인합니다.
**Auto Scaling 그룹의 기본 인스턴스 워밍업 시간을 확인하려면**
다음 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하십시오. *my-asg*를 Auto Scaling 그룹의 명칭으로 바꿉니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
다음은 응답의 예입니다.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
...
"DefaultInstanceWarmup": 120
}
]
}
```
# 이전에 설정한 인스턴스 워밍업 시간으로 조정 정책 찾기
`EstimatedInstanceWarmup`에 대한 자체 워밍업 시간이 있는 정책이 있는지 확인하려면 AWS CLI를 사용하여 다음 [describe-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-policies.html) 명령을 실행합니다. *my-asg*를 Auto Scaling 그룹의 명칭으로 바꿉니다.
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg
--query 'ScalingPolicies[?EstimatedInstanceWarmup!=`null`]'
```
다음은 예제 출력입니다.
```
[
{
"AutoScalingGroupName":"my-asg",
"PolicyName":"cpu50-target-tracking-scaling-policy",
"PolicyARN":"arn",
"PolicyType":"TargetTrackingScaling",
"StepAdjustments":[],
"EstimatedInstanceWarmup":120,
"Alarms":[{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}],
"TargetTrackingConfiguration":{
"PredefinedMetricSpecification":{
"PredefinedMetricType":"ASGAverageCPUUtilization"
},
"TargetValue":50.0,
"DisableScaleIn":false
},
"Enabled":true
},
... additional policies ...
]
```
# 스케일링 정책에 대해 이전에 설정한 인스턴스 워밍업을 지웁니다.
기본 인스턴스 워밍업을 활성화한 후 자체 워밍업 시간이 남아 있는 스케일링 정책을 업데이트하여 이전에 설정한 값을 지웁니다. 그렇지 않으면 기본 인스턴스 워밍업을 재정의합니다.
콘솔 AWS CLI, 또는 AWS SDKs. 이 섹션에서는 콘솔의 단계를 다룹니다. AWS CLI AWS SDKs를 사용하는 경우 기존 정책 구성을 유지하되 `EstimatedInstanceWarmup` 속성을 제거해야 합니다. 기존 스케일링 정책을 업데이트하면 해당 정책은 프로그래밍 방식으로 [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PutScalingPolicy.html)를 호출할 때 지정한 정책으로 교체됩니다. 원래 값은 유지되지 않습니다.
**스케일링 정책에 대해 이전에 설정한 인스턴스 워밍업을 지우기(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Auto Scaling** 탭의 **동적 스케일링 정책**에서 관심 있는 정책을 선택한 다음 **작업**, **편집**을 선택합니다.
1. **인스턴스 워밍업**의 경우 인스턴스 워밍업 값을 지우고 대신 기본 인스턴스 워밍업 값을 사용합니다.
1. **업데이트**를 선택합니다.
# Amazon EC2 Auto Scaling의 수동 조정
Auto Scaling 그룹의 EC2 인스턴스 수를 언제든지 수동으로 조정할 수 있습니다. 인스턴스 수를 수동으로 변경하는 이 프로세스를 *수동 조정*이라고 합니다. 수동 조정은 오토 스케일링의 대안으로, 특히 일회성 용량 변경을 원하는 경우 더욱 그렇습니다.
그룹을 수동으로 조정한 후 Amazon EC2 Auto Scaling은 정의한 조정 정책 및 예약된 작업에 따라 정상적인 오토 스케일링 활동을 재개합니다. 기본 인스턴스 워밍업이 활성화된 그룹의 경우 새 인스턴스는 오토 스케일링에 사용되는 지표에 기여하기 전에 워밍업 기간을 거칩니다. 이 워밍업 기간은 새 용량에서 그룹을 안정화하는 데 도움이 됩니다. 자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 단원을 참조하십시오.
가끔 그룹을 수동으로 조정하기 전에 조정 정책 및 예약된 작업을 일시적으로 비활성화할 수 있습니다. 이렇게 하면 수동 조정 작업과 자동 조정 활동 간에 충돌이 발생하지 않습니다. 자세한 내용은 [조정 활동 비활성화](CHAP_Troubleshooting.md#turn-off-scaling-activities) 단원을 참조하십시오.
**Topics**
+ [기존 Auto Scaling 그룹의 원하는 용량 변경](#change-desired-capacity)
+ [Auto Scaling 그룹에서 인스턴스 해지 (AWS CLI)](#terminate-an-instance-aws-cli)
## 기존 Auto Scaling 그룹의 원하는 용량 변경
Auto Scaling 그룹의 원하는 용량을 변경하면 Amazon EC2 Auto Scaling에서 인스턴스를 시작 및 종료하는 프로세스를 관리하여 원하는 새 크기에 도달합니다.
------
#### [ Console ]
**Auto Scaling 그룹의 크기 변경**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 표시됩니다.
1. **세부 정보(Details)** 탭에서 **그룹 세부 정보(Group details)**, **편집(Edit)**을 선택합니다.
1. **원하는 용량**에서 원하는 용량을 늘리거나 줄입니다. 예를 들어 그룹의 크기를 하나씩 늘리려면 현재 값이 `1`인 경우 `2`를 입력합니다.
새 **희망 용량** 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다.
1. 완료되면 **업데이트(Update)**를 선택합니다.
지정한 그룹 크기로 인해 동일한 양의 인스턴스가 시작되었는지 확인합니다. 예를 들어 그룹의 크기를 하나씩 늘린 경우 Auto Scaling 그룹이 인스턴스 한 개를 추가로 시작했는지 확인합니다.
**Auto Scaling 그룹의 크기가 변경되었는지 확인**
1. **활동** 탭의 **활동 기록**에서 Auto Scaling 그룹과 연결된 활동의 진행률을 볼 수 있습니다. **상태** 열에는 인스턴스의 현재 상태가 표시됩니다. 인스턴스가 시작되는 동안 상태 열에 `Not yet in service`가 표시됩니다. 인스턴스가 시작되면 상태가 `Successful`로 변경됩니다. 새로 고침 아이콘을 사용하여 인스턴스의 현재 상태를 볼 수도 있습니다. 자세한 내용은 [Auto Scaling 그룹에 대한 크기 조정 활동 확인](as-verify-scaling-activity.md) 단원을 참조하십시오.
1. **인스턴스 관리** 탭의 **인스턴스**에서 인스턴스의 상태를 볼 수 있습니다. 인스턴스를 시작하는 데 약간 시간이 걸립니다.
+ **수명 주기** 열에는 인스턴스의 상태가 표시됩니다. 처음에는 인스턴스가 `Pending` 상태로 되어 있습니다. 인스턴스가 트래픽을 수신할 준비가 되면 상태가 `InService`로 전환됩니다.
+ **상태** 열에는 해당 인스턴스에 대한 Amazon EC2 Auto Scaling 상태 확인 결과가 표시됩니다.
------
#### [ AWS CLI ]
다음 예에서는 최소 크기가 1이고 최대 크기가 5인 Auto Scaling 그룹을 생성한 것으로 가정합니다. 따라서 그룹에는 현재 실행 중인 인스턴스가 1개입니다.
**Auto Scaling 그룹의 크기 변경**
[set-desired-capacity](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-desired-capacity.html) 명령을 사용하여 다음 예에 표시된 것처럼 Auto Scaling 그룹의 크기를 변경합니다.
```
aws autoscaling set-desired-capacity --auto-scaling-group-name my-asg \
--desired-capacity 2
```
Auto Scaling 그룹의 기본 냉각 기간을 지키기로 한 경우, 다음 예에 표시된 것처럼 `–-honor-cooldown` 옵션을 지정해야 합니다. 자세한 설명은 [Amazon EC2 Auto Scaling을 위한 조정 휴지](ec2-auto-scaling-scaling-cooldowns.md) 섹션을 참조하세요.
```
aws autoscaling set-desired-capacity --auto-scaling-group-name my-asg \
--desired-capacity 2 --honor-cooldown
```
**Auto Scaling 그룹의 크기 확인**
[describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하여 다음 예와 같이 Auto Scaling 그룹의 크기가 변경되었음을 확인할 수 있습니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
다음은 시작된 그룹 및 인스턴스의 세부 정보를 제공하는 출력 예시입니다.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 2,
"DefaultCooldown": 300,
"AvailabilityZones": [
"us-west-2a"
],
"LoadBalancerNames": [],
"TargetGroupARNs": [],
"HealthCheckType": "EC2",
"HealthCheckGracePeriod": 300,
"Instances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "Pending"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0c20ac468fa3049e8",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
}
],
"CreatedTime": "2019-03-18T23:30:42.611Z",
"SuspendedProcesses": [],
"VPCZoneIdentifier": "subnet-c87f2be0",
"EnabledMetrics": [],
"Tags": [],
"TerminationPolicies": [
"Default"
],
"NewInstancesProtectedFromScaleIn": false,
"ServiceLinkedRoleARN": "arn",
"TrafficSources": []
}
]
}
```
`DesiredCapacity`에 새 값이 표시됩니다. Auto Scaling 그룹에서 추가 인스턴스를 시작했습니다.
------
## Auto Scaling 그룹에서 인스턴스 해지 (AWS CLI)
Auto Scaling 그룹에서 수동으로 스케일링하고 싶지만 특정 인스턴스를 해지하고 싶은 경우가 있을 수 있습니다. Auto Scaling 그룹에서 [terminate-instance-in-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/terminate-instance-in-auto-scaling-group.html) 명령을 사용하고 다음 예와 같이 해지하려는 인스턴스의 ID와 `--should-decrement-desired-capacity` 옵션을 지정하여 수동으로 스케일링할 수 있습니다.
```
aws autoscaling terminate-instance-in-auto-scaling-group \
--instance-id i-026e4c9f62c3e448c --should-decrement-desired-capacity
```
다음은 조정 활동에 관한 세부 정보를 제공하는 출력 예시입니다.
```
{
"Activities": [
{
"ActivityId": "b8d62b03-10d8-9df4-7377-e464ab6bd0cb",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-026e4c9f62c3e448c",
"Cause": "At 2023-09-23T06:39:59Z instance i-026e4c9f62c3e448c was taken out of service in response to a user request, shrinking the capacity from 1 to 0.",
"StartTime": "2023-09-23T06:39:59.015000+00:00",
"StatusCode": "InProgress",
"Progress": 0,
"Details": "{\"Subnet ID\":\"subnet-6194ea3b\",\"Availability Zone\":\"us-west-2c\"}"
}
]
}
```
콘솔에서는 이 옵션을 사용할 수 없습니다. 그러나 Amazon EC2 콘솔의 **인스턴스** 페이지를 사용하여 Auto Scaling 그룹의 인스턴스를 종료할 수 있습니다. 이렇게 하면 Amazon EC2 Auto Scaling이 인스턴스가 더 이상 실행되지 않음을 감지하고 상태 확인 프로세스의 일부로 자동으로 교체합니다. 인스턴스를 종료한 후 새 인스턴스가 시작되기까지 1분\$12분이 걸립니다. 인스턴스를 종료하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 종료](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)를 참조하세요.
그룹에서 인스턴스를 종료하여 가용 영역 간에 고르지 않은 분포가 발생하는 경우, `AZRebalance` 프로세스를 일시 중단하지 않는 한 Amazon EC2 Auto Scaling이 그룹의 균형을 재조정하여 균등한 분포를 다시 설정합니다. 자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
# Amazon EC2 Auto Scaling에 예약된 조정
예약된 조정을 사용하면 예측 가능한 로드 변경에 따라 애플리케이션의 자동 조정을 설정할 수 있습니다. 특정 시간에 그룹의 원하는 용량을 늘리거나 줄이는 예약된 작업을 생성합니다.
예를 들어 주중에는 로드가 증가하고 주말에는 감소하는 주간 트래픽 패턴이 정기적으로 발생합니다. Amazon EC2 Auto Scaling에서 이 패턴에 맞게 조정 일정을 구성할 수 있습니다.
+ 수요일 아침에는 예약된 작업이 이전에 설정된 Auto Scaling 그룹의 원하는 용량을 늘려 용량을 늘립니다.
+ 금요일 저녁에는 예약된 또 다른 작업이 이전에 설정된 Auto Scaling 그룹의 원하는 용량을 줄여 용량을 줄입니다.
이러한 예약된 규모 조정 작업을 통해 비용과 성능을 최적화할 수 있습니다. 애플리케이션은 주중 트래픽 피크를 처리할 수 있을 만큼 충분한 용량을 갖추게 되지만, 다른 시간에 불필요한 용량을 과도하게 프로비저닝하지는 않습니다.
예약된 조정 및 조정 정책을 함께 사용하면 조정에 대한 두 접근 방식의 이점을 모두 얻을 수 있습니다. 예약된 작업이 실행된 후 조정 정책은 계속해서 용량을 추가로 조정할지를 결정할 수 있습니다. 이를 통해 애플리케이션의 로드를 처리할 수 있는 충분한 용량을 보유하도록 보장합니다. 애플리케이션이 수요에 맞게 조정되는 동안 현재 용량은 예약된 작업에서 설정한 최소 및 최대 용량 이내여야 합니다.
**Topics**
+ [예약된 조정 작동 방식](#scheduled-scaling-how-it-works)
+ [반복되는 일정](#scheduled-scaling-recurring-schedules)
+ [시간대](#scheduled-scaling-time-zone)
+ [고려 사항](#scheduled-scaling-considerations)
+ [제한 사항](#scheduled-scaling-limitations)
+ [예약된 작업 생성](scheduled-scaling-create-scheduled-action.md)
+ [예약 작업 세부 정보 보기](scheduled-scaling-view-scheduled-actions.md)
+ [예약된 작업 삭제](scheduled-scaling-delete-scheduled-action.md)
## 예약된 조정 작동 방식
예약된 조정을 사용하려면 Amazon EC2 Auto Scaling이 특정 시간에 조정 활동을 수행하게 하는 *예약된 작업*을 생성할 수 있습니다. 예약 작업을 생성할 때 Auto Scaling 그룹, 조정 활동이 발생해야 할 시점, 원하는 새 용량, 선택 사항인 새 최소 용량 및 최대 용량을 지정합니다. 한 번만 조정하거나 반복 일정에 따라 조정되는 예약된 작업을 생성할 수 있습니다.
지정된 시간에 Amazon EC2 Auto Scaling은 현재 용량을 지정된 원하는 용량과 비교하여 새 용량 값을 기반으로 조정합니다.
+ 현재 용량이 지정된 원하는 용량보다 작으면 Amazon EC2 Auto Scaling이 스케일 아웃하거나 인스턴스를 지정된 원하는 용량으로 추가합니다.
+ 현재 용량이 지정된 원하는 용량보다 크면 Amazon EC2 Auto Scaling이 스케일 인하거나 인스턴스를 지정된 원하는 용량에서 제거합니다.
예약된 작업은 그룹의 최소, 최대 및 원하는 용량을 지정된 날짜와 시간에 설정합니다. 예를 들어 원하는 용량과 같이 이러한 용량 중 하나에 대해서만 예약된 작업을 한 번에 생성할 수 있습니다. 그러나 경우에 따라 해당 작업에 지정한 원하는 용량이 이러한 제한을 벗어나지 않도록 최소 및 최대 용량을 포함해야 합니다.
## 반복되는 일정
AWS CLI 또는 SDK를 사용하여 반복 일정을 생성하려면 cron 표현식과 시간대를 지정하여 예약된 작업이 반복되는 시기를 설명합니다. 선택적으로 시작 시간, 해지 시간 또는 두 가지 모두에 대한 날짜 및 시간을 지정할 수 있습니다.
를 사용하여 반복 일정을 생성하려면 예약된 작업의 반복 패턴, 시간대, 시작 시간 및 선택적 종료 시간을 AWS Management Console지정합니다. 모든 반복 패턴 옵션은 cron 표현식에 근거하여 합니다. 또는 사용자 지정 cron 표현식을 작성할 수 있습니다.
지원되는 cron 표현식 형식은 다음과 같이 공백으로 구분된 다섯 개의 필드로 구성됩니다. [Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]. 예컨대, cron 표현식 `30 6 * * 2`는 매주 화요일 오전 6:30에 발생하는 예약된 작업을 구성합니다. 별표는 필드의 모든 값을 일치시키기 위한 와일드카드로 사용됩니다. cron 표현식의 다른 예는 [https://crontab.guru/examples.html](https://crontab.guru/examples.html)을 참조하세요. 이 형식으로 자체 cron 표현식을 작성하는 방법에 대한 자세한 설명은 [Crontab](http://crontab.org)을 참조하세요.
시작 시간과 해지 시간은 신중하게 선택합니다. 다음 사항에 유의하세요.
+ 시작 시간을 지정하면 Amazon EC2 Auto Scaling이 해당 시간에 작업을 수행한 다음 지정된 반복에 따라 작업을 수행합니다.
+ 해지 시간을 지정하면 이 시간 이후에는 작업이 반복되지 않습니다. 예약된 작업은 해지 시간이 되면 해당 계정에 존속하지 않습니다.
+ 반복 시간이 종료 시간과 정확히 일치하면 Amazon EC2 Auto Scaling은 종료 시간에 예약된 작업을 수행하지 않습니다.
+ AWS CLI 또는 SDK를 사용할 때는 시작 시간과 종료 시간을 UTC로 설정해야 합니다.
## 시간대
기본적으로 사용자가 설정한 반복 일정의 시간대는 UTC(협정 세계시)입니다. 현지 표준 시간대 또는 네트워크의 다른 부분에 대한 표준 시간대와 일치하도록 시간을 변경할 수 있습니다. DST(일광 절약 시간)를 준수하는 시간대를 지정하면 작업이 DST에 맞게 자동으로 조정됩니다.
유효한 값은 Internet Assigned Numbers Authority(IANA) 시간대 데이터베이스의 표준 시간대 이름입니다. 예를 들어 미국 동부 시간은 표준에 따라 `America/New_York`으로 식별됩니다. 자세한 내용은 [https://www.iana.org/time-zones](https://www.iana.org/time-zones)를 참조하세요.
위치 기반 표준 시간대(예: `America/New_York`)는 DST에 맞춰 자동으로 조정됩니다. 그러나 UTC 기반 표준 시간대(예: `Etc/UTC`)는 절대 시간이며 DST에 맞춰 조정되지 않습니다.
예컨대, 해당 표준 시간대가 `America/New_York`인 반복되는 일정이 있습니다. 첫 번째 조정 작업은 DST 시작 전 `America/New_York` 표준 시간대에 발생합니다. 다음 조정 작업은 DST 시작 후 `America/New_York` 표준 시간대에 발생합니다. 첫 번째 작업은 현지 시간으로 오전 8시 UTC-5에 시작하며, 두 번째 작업은 현지 시간으로 오전 8시 UTC-4에 시작됩니다.
를 사용하여 예약된 작업을 생성하고 DST를 준수하는 시간대를 AWS Management Console 지정하면 반복 일정과 시작 및 종료 시간이 모두 DST에 맞게 자동으로 조정됩니다.
## 고려 사항
예약된 작업을 만들 경우, 다음 사항에 유의해야 합니다.
+ 그룹 전체가 아니라 동일한 그룹 내에서 예약된 작업의 실행 순서가 보장됩니다.
+ 예약된 작업은 일반적으로 수 초 내에 실행됩니다. 하지만 작업이 예약된 시작 시간에서 최대 2분까지 지연될 수 있습니다. 이것은 Auto Scaling 그룹 내의 예약된 작업은 지정된 순서대로 실행하기 때문이며 예약된 시작 시간이 서로 가까운 작업은 실행하는 데 더 많은 시간이 소요될 수 있습니다.
+ `ScheduledActions` 프로세스를 일시 중지하여 Auto Scaling 그룹에 대해 예약된 조정을 일시적으로 끌 수 있습니다. 이렇게 하면 예약된 작업을 삭제할 필요 없이 활성 상태가 되는 것을 방지할 수 있습니다. 그런 다음 다시 사용하려는 경우, 예약된 조정을 재개할 수 있습니다. 자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
+ 예약된 작업을 생성한 후 이름을 제외한 모든 설정을 업데이트할 수 있습니다.
+ 동일한 cron 표현식을 사용하는 여러 예약 작업이 같은 Auto Scaling 그룹에 있을 경우, 실행 순서는 임의적이며 보장되지 않습니다. 예측 가능한 동작을 보장하기 위해 각 예약된 작업에 고유한 예약된 시작 시간을 사용할 수 있습니다.
## 제한 사항
+ 예약된 작업의 이름은 Auto Scaling 그룹별로 고유해야 합니다.
+ 예약된 작업은 고유한 시간 값을 가져야 합니다. 다른 크기 조정 활동이 이미 예약된 경우, 한 번에 하나의 활동을 예약하려고 시도하면 호출이 거부되고 예약된 시작 시간에 예약된 작업이 이미 있음을 알리는 오류가 반환됩니다.
+ Auto Scaling 그룹당 최대 125개의 예약된 작업을 만들 수 있습니다.
# 예약된 작업 생성
Auto Scaling 그룹에 대해 예약 작업을 생성하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**예약된 작업을 만들려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **자동 조정** 탭의 **Scheduled actions(예약된 작업)**에서 **Create scheduled action(예약된 작업 생성)**을 선택합니다.
1. 예약된 작업의 **이름**을 입력합니다.
1. **원하는 용량**,**최소**,**최대**에서 그룹에 새로 원하는 용량과 최소 및 최대 크기 한도를 선택합니다. 원하는 용량은 최소 그룹 크기보다 크거나 같아야 하며 최대 그룹 크기보다 작거나 같아야 합니다.
1. **Recurrence(반복)**에서 사용 가능한 옵션 중 하나를 선택합니다.
+ 반복되는 일정에 따라 조정하려면 Amazon EC2 Auto Scaling에서 예약된 작업을 실행하는 빈도를 선택합니다.
+ **Every(간격)**로 시작하는 옵션을 선택하면 cron 식이 자동으로 생성됩니다.
+ **Cron**을 선택하는 경우, 작업을 수행하는 시기를 지정하는 Cron 식을 입력합니다.
+ 한 번만 조정하려면 **Once(한 번)**를 선택합니다.
1. **Time zone(표준 시간대)**에서 시간대를 선택합니다. 기본값은 `Etc/UTC`입니다.
나열된 모든 표준 시간대는 IANA 표준 시간대 데이터베이스에서 가져온 것입니다. 자세한 정보는 [https://en.wikipedia.org/wiki/List\$1of\$1tz\$1database\$1time\$1zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하세요.
1. **Specific start time(특정 시작 시간)**의 날짜 및 시간을 정의합니다.
+ 반복되는 일정을 선택한 경우, 시작 시간은 일련의 반복에서 첫 번째 예약된 작업이 실행되는 시점을 정의합니다.
+ 반복으로 **Once(한 번)**를 선택하면 시작 시간은 예약된 작업이 실행될 날짜와 시간을 정의합니다.
1. (옵션) 반복되는 일정의 경우**Set End Time(해지 시간 설정)**을 선택하한 다음 **End by(해지 기한)**의 날짜 및 시간을 선택하여 해지 시간을 지정할 수 있습니다.
1. **Create(생성)**를 선택합니다. 콘솔에 Auto Scaling 그룹에 대해 예약된 작업이 표시됩니다.
------
#### [ AWS CLI ]
예약 작업을 생성하려면 다음 예제 명령 중 하나를 사용할 수 있습니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
**예: 일회성 조정**
`--start-time "YYYY-MM-DDThh:mm:ssZ"` 및 `--desired-capacity` 옵션과 함께 다음 [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령을 사용합니다.
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-one-time-action \
--auto-scaling-group-name my-asg --start-time "2021-03-31T08:00:00Z" --desired-capacity 3
```
**예: 반복되는 일정으로 조정 예약**
`--recurrence "cron expression"` 및 `--desired-capacity` 옵션과 함께 다음 [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령을 사용합니다.
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-recurring-action \
--auto-scaling-group-name my-asg --recurrence "0 9 * * *" --desired-capacity 3
```
기본적으로 Amazon EC2 Auto Scaling은 UTC 시간대를 기반으로 지정된 반복 일정을 실행합니다. 다른 시간대를 지정하려면 `--time-zone` 옵션을 포함하고 IANA 시간대의 이름을 다음 예와 같이 지정합니다.
```
--time-zone "America/New_York"
```
자세한 설명은 [https://en.wikipedia.org/wiki/List\$1of\$1tz\$1database\$1time\$1zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하세요.
------
# 예약 작업 세부 정보 보기
Auto Scaling 그룹에 대해 예정된 예약 작업의 세부 정보를 보려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**예약 작업 세부 정보를 보려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹을 선택합니다.
1. **자동 조정** 탭의 **예약된 작업**에서 예정된 예약 작업을 볼 수 있습니다.
콘솔은 **시작 시간** 및 **종료 시간**을 지정된 날짜 및 시간에 UTC 오프셋이 적용된 현지 시간으로 표시합니다. UTC 오프셋은 현지 시간과 UTC 간의 시간 및 분 단위 차이입니다. **Time zone(표준 시간대)** 값은 요청한 시간대를 나타냅니다(예: `America/New_York`).
------
#### [ AWS CLI ]
다음 [describe-scheduled-actions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scheduled-actions.html) 명령을 사용합니다.
```
aws autoscaling describe-scheduled-actions --auto-scaling-group-name my-asg
```
이 명령이 성공하면 다음과 비슷한 출력이 반환됩니다.
```
{
"ScheduledUpdateGroupActions": [
{
"AutoScalingGroupName": "my-asg",
"ScheduledActionName": "my-recurring-action",
"Recurrence": "30 0 1 1,6,12 *",
"ScheduledActionARN": "arn:aws:autoscaling:us-west-2:123456789012:scheduledUpdateGroupAction:8e86b655-b2e6-4410-8f29-b4f094d6871c:autoScalingGroupName/my-asg:scheduledActionName/my-recurring-action",
"StartTime": "2020-12-01T00:30:00Z",
"Time": "2020-12-01T00:30:00Z",
"MinSize": 1,
"MaxSize": 6,
"DesiredCapacity": 4
}
]
}
```
------
## 크기 조정 활동 확인
예약된 스케일링과 관련된 스케일링 작업을 확인하려면 [Auto Scaling 그룹에 대한 크기 조정 활동 확인](as-verify-scaling-activity.md)을 참조하세요.
# 예약된 작업 삭제
예약된 작업을 삭제하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**예약된 작업을 삭제하는 방법**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹을 선택합니다.
1. **자동 조정(Automatic scaling)** 탭의 **예약된 작업(Scheduled actions)**에서 예약된 작업을 선택합니다.
1. **작업**(Actions), **삭제**(Delete)를 선택합니다.
1. 확인 메시지가 나타나면 **예, 삭제합니다(Yes, Delete)**를 선택합니다.
------
#### [ AWS CLI ]
다음 [delete-scheduled-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-scheduled-action.html) 명령을 사용합니다.
```
aws autoscaling delete-scheduled-action --auto-scaling-group-name my-asg \
--scheduled-action-name my-recurring-action
```
------
# Amazon EC2 Auto Scaling의 동적 조정
동적 조정은 트래픽의 변화에 따라 Auto Scaling 그룹의 용량을 조정합니다.
Amazon EC2 Auto Scaling은 다음과 같은 유형의 동적 조정 정책을 지원합니다.
+ **대상 추적 조정(Target tracking scaling)** -Amazon CloudWatch 지표와 목표 값을 기준으로 그룹의 현재 용량을 늘리거나 줄입니다. 이는 온도 조절기가 집안 온도를 유지하는 방식과 비슷하게 작동합니다. 사용자가 온도만 선택하면 나머지는 온도 조절기가 알아서 합니다.
+ **단계별 조정(Step scaling)** - 그룹의 현재 용량을 일련의 조정 조절에 따라 늘리고 줄이며 경보 위반의 크기에 따라 달라지는 *단계 조절*이라고 합니다.
+ **단순 조정(Simple scaling)** - 단일 조정 설정에 따라 그룹의 현재 용량을 늘리고 줄입니다. 각 조정 작업 간에는 냉각 기간이 발생합니다.
대상 추적 조정 정책을 사용하고 Auto Scaling 그룹의 용량 변화에 반비례하여 변경되는 지표를 선택하는 것이 좋습니다. 따라서 Auto Scaling 그룹의 크기를 두 배로 늘리면 지표가 50% 감소합니다. 이렇게 하면 지표 데이터가 비례적 조정 이벤트를 정확하게 트리거할 수 있습니다. 평균 CPU 사용률 또는 목표당 평균 요청 수와 같은 지표가 포함됩니다.
대상 추적을 사용하면 Auto Scaling 그룹이 애플리케이션의 실제 부하에 비례하여 스케일 인됩니다. 즉, 대상 추적 정책은 로드 변화에 대응하여 즉각적인 용량 요건을 충족하는 것 외에도, 계절적 변동 등으로 인해 시간 경과에 따라 발생하는 로드 변화에도 맞추어 조정할 수 있습니다.
또한 대상 추적 정책을 사용하면 CloudWatch 경보 및 조정 작업을 수동으로 정의할 필요가 없습니다. Amazon EC2 Auto Scaling은 사용자가 설정한 대상에 따라 이를 자동으로 처리합니다.
**Topics**
+ [동적 조정 정책 작동 방식](#as-how-scaling-policies-work)
+ [여러 동적 조정 정책](#multiple-scaling-policy-resolution)
+ [Amazon EC2 Auto Scaling의 대상 추적 조정 정책](as-scaling-target-tracking.md)
+ [Amazon EC2 Auto Scaling의 단계별 조정 및 단순 조정 정책](as-scaling-simple-step.md)
+ [Amazon EC2 Auto Scaling을 위한 조정 휴지](ec2-auto-scaling-scaling-cooldowns.md)
+ [Amazon SQS 기반 조정 정책](as-using-sqs-queue.md)
+ [Auto Scaling 그룹에 대한 크기 조정 활동 확인](as-verify-scaling-activity.md)
+ [Auto Scaling 그룹에 대한 조정 정책 비활성화](as-enable-disable-scaling-policy.md)
+ [Auto Scaling 그룹에 대한 조정 정책 삭제](deleting-scaling-policy.md)
+ [에 대한 조정 정책 예제 AWS CLI](examples-scaling-policies.md)
## 동적 조정 정책 작동 방식
동적 조정 정책은 Amazon EC2 Auto Scaling에 특정 CloudWatch 지표를 추적하도록 지시하며, 연결된 CloudWatch 경보가 경보 상태일 때 수행할 작업을 정의합니다. 경보 상태를 호출하는 데 사용되는 지표는 Auto Scaling 그룹의 모든 인스턴스에서 보내는 지표를 집계한 것입니다. 예컨대, 하나는 CPU 사용률이 60%이고 다른 하나는 CPU 사용률이 40%인 두 개의 인스턴스로 구성된 Auto Scaling 그룹이 있다고 가정해 보겠습니다. 두 인스턴스의 평균 CPU 사용률은 50%입니다. 정책이 적용되면 경보의 임계값이 위반될 때 Amazon EC2 Auto Scaling이 그룹의 원하는 용량을 늘리거나 줄입니다.
동적 조정 정책이 호출될 때 용량 계산에서 그룹의 최소 및 최대 크기 범위를 벗어나는 숫자를 생성하는 경우, Amazon EC2 Auto Scaling은 새 용량이 최소 및 최대 크기 제한을 벗어나지 않도록 합니다. 용량은 두 가지 방법 중 하나로 측정됩니다. 인스턴스 기준으로 원하는 용량을 설정할 때 선택한 것과 동일한 단위를 사용하거나 용량 단위를 사용합니다([인스턴스 가중치](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)가 적용된 경우).
+ 예 1: Auto Scaling 그룹 최대 용량 3, 현재 용량 2, 인스턴스 3개를 추가하는 조정 정책. 이 정책을 호출할 때 Amazon EC2 Auto Scaling은 그룹에 인스턴스를 하나만 추가하여 그룹이 최대 크기를 초과하지 않도록 합니다.
+ 예 2: Auto Scaling 그룹 최소 용량 2, 현재 용량 3, 인스턴스 2개를 제거하는 동적 조정 정책. 이 정책을 호출할 때 Amazon EC2 Auto Scaling은 그룹에서 인스턴스를 하나만 제거하여 그룹이 최소 크기보다 작아지지 않도록 합니다.
원하는 용량이 최대 크기 제한에 도달하면 스케일 아웃이 중지됩니다. 수요가 감소하고 용량이 줄어들면 Amazon EC2 Auto Scaling이 다시 스케일 아웃할 수 있습니다.
인스턴스 가중치를 사용하는 경우는 예외입니다. 이 경우, Amazon EC2 Auto Scaling은 최대 크기 제한을 초과하여 스케일 아웃할 수 있지만 최대 인스턴스 가중치까지만 스케일 아웃할 수 있습니다. 그 의도는 최대한 새로운 원하는 용량에 근접하면서도 그룹에 지정된 할당 전략을 고수하는 것입니다. 할당 전략에 따라 시작할 인스턴스 유형이 결정됩니다. 가중치는 인스턴스 유형에 따라 각 인스턴스가 그룹의 원하는 용량에 기여하는 용량 유닛 수를 결정합니다.
+ 예 3: Auto Scaling 그룹 최대 용량 12, 현재 용량 10, 용량 유닛 5를 추가하는 동적 조정 정책. 인스턴스 유형에는 1, 4 또는 6의 세 가지 가중치 중 하나가 할당됩니다. 이 정책을 호출할 때 Amazon EC2 Auto Scaling은 할당 전략에 따라 가중치가 6인 인스턴스 유형을 시작하도록 선택합니다. 이 스케일 아웃 이벤트의 결과는 원하는 용량이 12이고 현재 용량이 16인 그룹입니다.
## 여러 동적 조정 정책
대부분의 경우에는 Auto Scaling 그룹이 자동으로 스케일 아웃 및 축소되도록 구성하는 데 대상 추적 조정 정책으로 충분합니다. 대상 추적 조정 정책을 사용하면 원하는 결과를 선택하고, 그러한 결과를 얻기 위해 필요에 따라 Auto Scaling 그룹이 인스턴스를 추가 및 제거하도록 할 수 있습니다.
고급 조정 구성의 경우, Auto Scaling 그룹에 하나 이상의 조정 정책이 있을 수 있습니다. 예컨대, 하나 이상의 대상 추적 조정 정책, 하나 이상의 단계별 조정 정책, 또는 둘 모두를 정의할 수 있습니다. 이로 인해 유연성이 늘어나고 여러 시나리오를 처리할 수 있습니다.
여러 개의 동적 조정 정책이 함께 작동하는 방식에 대해 알아보기 위해, Auto Scaling 그룹을 사용하는 애플리케이션과 해당 그룹 EC2 인스턴스에 요청을 전송하는 Amazon SQS 대기열을 고려해 보겠습니다. 애플리케이션에서 최적의 수준으로 작업이 수행되도록 보장하기 위해, Auto Scaling 그룹이 스케일 아웃되어야 하는 시기를 제어하는 두 개의 정책이 마련되어 있습니다. 하나는 대상 추적 정책으로, 사용자 지정 지표를 사용하여 대기열에 있는 SQS 메시지 수에 따라 용량을 추가 및 제거합니다. 또 다른 하나는 단계별 조정 정책으로, 지정된 시간 동안 인스턴스가 90% 사용률을 초과할 때 Amazon CloudWatch `CPUUtilization` 지표를 사용하여 용량을 추가합니다.
동시에 여러 정책이 실행되는 경우, 각 정책이 동시에 Auto Scaling 그룹이 스케일 아웃(또는 축소)하도록 지시할 수 있습니다. 예컨대, `CPUUtilization` 지표가 CloudWatch 경보를 스파이크 및 트리거하고 동시에 SQS 사용자 지정 지표가 사용자 지정 지표 경보를 스파이크 및 트리거할 수 있습니다.
이러한 상황이 발생하는 경우, Amazon EC2 Auto Scaling은 스케일 아웃 및 축소를 위한 최대 용량을 제공하는 정책을 선택합니다. 예컨대, `CPUUtilization`에 대한 정책에서 1개의 인스턴스를 시작하는 한편, SQS 대기열에 대한 정책에서는 2개의 인스턴스를 시작하는 경우를 생각해 볼 수 있습니다. 만일 두 정책의 스케일 아웃 조건이 동시에 충족되는 경우, Amazon EC2 Auto Scaling은 SQS 대기열 정책을 우선 적용합니다. 이렇게 하면 Auto Scaling 그룹에서 인스턴스 두 개가 시작됩니다.
가장 큰 용량을 제공하는 정책에 우선순위를 부여하는 접근법은 다른 스케일 아웃 기준을 사용하는 정책에도 적용됩니다. 예컨대, 어떤 정책은 인스턴스 세 개를 해지하고, 다른 정책은 인스턴스 수를 25% 줄이며, 축소 시점 현재 해당 그룹에 인스턴스가 여덟 개 있는 경우, Amazon EC2 Auto Scaling은 헤딩 그룹에 가장 많은 수의 인스턴스를 제공하는 정책을 우선 적용합니다. 따라서 Auto Scaling 그룹은 인스턴스 두 개를 해지합니다(8의 25% = 2). 목표는 Amazon EC2 Auto Scaling에서 인스턴스를 너무 많이 제거하지 않도록 하는 것입니다.
그러나 대상 추적 조정 정책과 단계별 조정 정책을 함께 사용하는 경우, 정책 간 충돌로 인해 바람직하지 않은 동작이 발생할 수 있으므로 주의해야 합니다. 예를 들어 대상 추적 정책이 스케일 인 준비가 되기 전에 단계별 조정 정책이 스케일 인 활동을 시작하는 경우, 스케일 인 활동이 차단되지 않습니다. 스케일 인 작업이 완료된 후 대상 추적 정책이 그룹에 다시 스케일 아웃하도록 지시할 수 있습니다.
# Amazon EC2 Auto Scaling의 대상 추적 조정 정책
대상 추적 조정 정책은 대상 지표값을 기준으로 Auto Scaling 그룹의 용량을 자동으로 조정합니다. 각 애플리케이션의 고유한 사용 패턴에 자동으로 적응합니다. 이를 통해 애플리케이션은 별도의 관리 없이도 최적의 성능을 유지하고 EC2 인스턴스 활용도를 높여 비용 효율성을 개선할 수 있습니다.
대상 추적을 사용할 때는 애플리케이션의 이상적인 평균 사용률 또는 처리량 수준을 나타내는 지표와 목표 값을 선택합니다. Amazon EC2 Auto Scaling은 지표가 대상에서 벗어날 경우 조정 이벤트를 호출하는 CloudWatch 경보를 생성하고 관리합니다. 예를 들는 온도 조절기가 목표 온도를 유지하는 방식과 비슷합니다.
예컨대, 현재 인스턴스 2개에서 애플리케이션이 실행되고 있고 사용자가 애플리케이션 로드에 변경이 있는 경우, Auto Scaling 그룹의 CPU 사용량을 50% 정도로 유지시키려 한다고 가정해 보겠습니다. 이로 인해 과도한 유휴 리소스를 유지하지 않고도 트래픽 급증을 처리할 수 있는 추가 용량을 확보할 수 있습니다.
평균 CPU 사용률 50%를 목표로 하는 대상 추적 조정 정책을 생성하면 이러한 요건을 충족할 수 있습니다. CPU가 50%를 초과하면 Auto Scaling 그룹이 스케일 아웃하거나 용량을 늘려 증가된 로드를 처리합니다. CPU가 50% 미만으로 떨어지면 스케일 인하거나 용량을 줄여 사용률이 낮은 기간 동안 비용을 최적화합니다.
**Topics**
+ [다수의 대상 추적 조정 정책](#target-tracking-multiple-policies)
+ [지표 선택](#target-tracking-choose-metrics)
+ [목표 값 정의](#target-tracking-define-target-value)
+ [인스턴스 워밍업 시간 정의](#as-target-tracking-scaling-warmup)
+ [고려 사항](#target-tracking-considerations)
+ [대상 추적 조정 정책 생성](policy_creating.md)
+ [더 빠른 대응을 위해 고해상도 지표를 사용하여 대상 추적 정책 생성](policy-creating-high-resolution-metrics.md)
+ [지표 수식을 사용하여 대상 추적 조정 정책 생성](ec2-auto-scaling-target-tracking-metric-math.md)
## 다수의 대상 추적 조정 정책
조정 성능을 최적화하기 위해, 각각 다른 지표를 사용한다는 전제하에 다수의 대상 추적 조정 정책을 함께 사용할 수 있습니다. 예컨대, 사용률과 처리량(throughput)은 서로 영향을 줄 수 있습니다. 이러한 지표 중 하나가 변경될 때마다 일반적으로 다른 지표도 영향을 받게 됩니다. 따라서 여러 지표를 사용하면 Auto Scaling 그룹의 로드에 대한 추가 정보를 얻을 수 있습니다. 이렇게 하면 Amazon EC2 Auto Scaling이 그룹에 추가할 용량을 결정할 때 정보에 입각한 결정을 내리는 데 도움이 됩니다.
Amazon EC2 Auto Scaling의 목적은 항상 가용성의 우선순위를 지정하는 것입니다. 대상 추적 정책 중 하나를 스케일 아웃할 준비가 되면 Auto Scaling 그룹이 스케일 아웃됩니다. 모든 대상 추적 정책(스케일 인 부분이 활성화된 상태)이 스케일 인 준비가 된 경우에만 스케일 인됩니다.
## 지표 선택
사용자 지정 또는 사전 정의된 지표를 사용하여 대상 추적 크기 조정 정책을 생성할 수 있습니다. 사전 정의된 지표를 사용하면 규모 조정에 가장 자주 활용되는 지표에 더 쉽게 접근할 수 있습니다. 사용자 지정 지표를 활용하면, 몇 초 단위의 더 미세한 간격으로 게시되는 [고해상도 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)를 포함해 CloudWatch에서 제공되는 기타 메트릭을 기반으로 스케일링할 수 있습니다. 직접 고해상도 지표를 게시하거나 다른 AWS 서비스에서 게시하는 지표를 사용할 수도 있습니다.
고해상도 지표를 사용해 대상 추적 정책을 생성하는 방법에 대한 자세한 내용은 [더 빠른 대응을 위해 고해상도 지표를 사용하여 대상 추적 정책 생성](policy-creating-high-resolution-metrics.md) 섹션을 참조하세요.
대상 추적은 다음과 같은 사전 정의된 지표를 지원합니다.
+ `ASGAverageCPUUtilization` - Auto Scaling 그룹의 평균 CPU 사용률.
+ `ASGAverageNetworkIn` - Auto Scaling 그룹별로 모든 네트워크 인터페이스에서 수신한 평균 바이트 수.
+ `ASGAverageNetworkOut` - Auto Scaling 그룹별로 모든 네트워크 인터페이스에서 전송한 평균 바이트 수.
+ `ALBRequestCountPerTarget` - Auto Scaling 그룹의 대상당 평균 Application Load Balancer 요청 수.
**중요**
CPU 사용률, 네트워크 I/O, 대상당 Application Load Balancer 요청 수 등의 지표에 대한 기타 중요한 정보는 각각 *Amazon EC2 사용 설명서*의 [인스턴스에 사용 가능한 CloudWatch 지표 목록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) 주제와 *Application Load Balancer 사용 설명서*의 [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) 주제에서 확인할 수 있습니다.
사용자 지정 지표를 지정하여 CloudWatch에서 사용 가능한 다른 CloudWatch 지표 또는 고유한 지표를 선택할 수 있습니다. 를 사용하여 대상 추적 조정 정책에 대한 사용자 지정 지표 사양을 지정하는 예제는 섹션을 AWS CLI참조하세요[에 대한 조정 정책 예제 AWS CLI](examples-scaling-policies.md).
지표를 선택하는 경우, 다음 사항에 유의하세요.
+ 사용률 변화에 따라 더 빠르게 조정할 수 있도록 1분 간격 이하로 제공되는 지표만 사용할 것을 권장합니다. 더 짧은 간격으로 게시되는 지표일수록 대상 추적 정책이 Auto Scaling 그룹의 사용률 변화를 더 빠르게 감지하고 대응할 수 있습니다.
+ CPU 사용률과 같이 Amazon EC2에서 게시하는 사전 정의된 지표를 선택하는 경우 세부 모니터링을 활성화하는 것이 좋습니다. 기본적으로 모든 Amazon EC2 지표는 5분 간격으로 게시되지만, 세부 모니터링을 활성화하면 게시 간격을 1분으로 단축할 수 있습니다. 세부 모니터링을 활성화하는 방법에 대한 자세한 내용은 [Auto Scaling 인스턴스에 대한 모니터링 구성](enable-as-instance-metrics.md) 섹션을 참조하세요.
+ 모든 사용자 지정 지표를 대상 추적에 사용할 수 있는 것은 아닙니다. 지표는 유효한 사용량 수치로서 인스턴스의 사용량을 설명해야 합니다. 지표 값은 Auto Scaling 그룹의 인스턴스 수에 비례하여 증가하거나 감소합니다. 즉, 지표 데이터를 사용하여 인스턴스 수에 따라 비례적으로 스케일 아웃하거나 축소할 수 있습니다. 예컨대, Auto Scaling 그룹의 부하가 인스턴스로 분산되는 경우에는 Auto Scaling 그룹의 CPU 사용량(즉, 지표 차원 `AutoScalingGroupName`의 Amazon EC2 지표 `CPUUtilization`)이 유효합니다.
+ 다음 지표는 대상 추적에 사용할 수 없습니다.
+ Auto Scaling 그룹에 대한 로드 밸런서가 수신하는 요청 수(즉, Elastic Load Balancing 지표 `RequestCount`). 로드 밸런서가 수신하는 요청 수는 Auto Scaling 그룹의 사용량에 따라 변경되지 않습니다.
+ 로드 밸런서 요청 지연 시간(즉, Elastic Load Balancing 지표 `Latency`). 요청 지연 시간은 사용량 증가에 따라 늘어날 수는 있지만 반드시 비례하지는 않습니다.
+ CloudWatch Amazon SQS 대기열 지표 `ApproximateNumberOfMessagesVisible`. 대기열의 메시지 수는 대기열의 메시지를 처리하는 Auto Scaling 그룹의 크기에 비례하여 변경되지 않을 수 있습니다. 하지만 Auto Scaling 그룹의 EC2 인스턴스당 대기열의 메시지 수를 측정하는 사용자 지정 지표는 작동합니다. 자세한 설명은 [Amazon SQS 기반 조정 정책](as-using-sqs-queue.md) 섹션을 참조하세요.
+ `ALBRequestCountPerTarget` 지표를 사용하려면 `ResourceLabel` 파라미터를 지정하여 지표와 연관된 로드 밸런서 대상 그룹을 식별해야 합니다. 를 사용하여 대상 추적 조정 정책의 `ResourceLabel` 파라미터를 지정하는 예제는 섹션을 AWS CLI참조하세요[에 대한 조정 정책 예제 AWS CLI](examples-scaling-policies.md).
+ 지표가 CloudWatch에 실제 0 값을 내보내는 경우(예: `ALBRequestCountPerTarget`) Auto Scaling 그룹은 유지된 기간 동안 애플리케이션에 대한 트래픽이 없을 때 0으로 스케일 인될 수 있습니다. 해당 그룹에 요청이 라우팅되지 않은 경우, Auto Scaling 그룹을 인스턴스 0개로 스케일 인하려면, 그룹의 최소 용량을 0으로 설정해야 합니다.
+ 조정 정책에 사용할 새 지표를 게시하는 대신 지표 수학을 사용하여 기존 지표를 결합할 수 있습니다. 자세한 설명은 [지표 수식을 사용하여 대상 추적 조정 정책 생성](ec2-auto-scaling-target-tracking-metric-math.md) 섹션을 참조하세요.
## 목표 값 정의
대상 추적 조정 정책을 생성할 경우, 목표 값을 지정해야 합니다. 목표 값은 Auto Scaling 그룹의 최적 평균 사용률 또는 처리량(throughput)을 나타냅니다. 리소스를 비용 효율적으로 사용하려면 예상치 못한 트래픽 증가에 대비하여, 적절한 버퍼를 두고 목표 값을 가능한 한 높게 설정합니다. 애플리케이션이 정상적인 트래픽 흐름을 위해 최적으로 스케일 아웃되면 실제 지표 값은 목표 값과 같거나 그보다 조금 낮아야 합니다.
조정 정책이 Application Load Balancer 대상당 요청 수, 네트워크 I/O 또는 기타 수 지표와 같은 처리량(throughput)에 근거하여 하는 경우, 대상 값은 1분 동안 단일 인스턴스의 최적 평균 처리량(throughput)을 나타냅니다.
## 인스턴스 워밍업 시간 정의
새로 시작된 인스턴스가 워밍업되는 데 걸리는 시간(초)을 선택적으로 지정할 수 있습니다. 지정된 워밍업 시간이 만료될 때까지 인스턴스는 Auto Scaling 그룹의 집계된 EC2 인스턴스 지표에 포함되지 않습니다.
인스턴스가 워밍업 기간에 있는 동안 워밍업되지 않은 인스턴스의 지표 값이 정책의 목표 사용률보다 큰 경우에만 조정 정책이 스케일 아웃됩니다.
그룹이 다시 스케일 아웃되면 아직 워밍업 중인 인스턴스가 다음 스케일 아웃 활동에 대한 원하는 용량의 일부로 계산됩니다. 계속적이지만 과도하지는 않게 스케일 아웃하기 위한 목적입니다.
스케일 아웃 활동이 진행 중인 동안에는 인스턴스 워밍업이 완료될 때까지 조정 정책에 의해 시작된 모든 스케일 인 활동이 차단됩니다. 인스턴스 워밍업이 완료된 후 스케일 인 이벤트가 발생하면 현재 종료 중인 인스턴스는 새로 원하는 용량을 계산할 때 그룹의 현재 용량에 포함됩니다. 따라서 Auto Scaling 그룹에서 인스턴스를 필요 이상으로 빼지 않습니다.
**기본값**
값을 설정하지 않으면 조정 정책은 그룹에 대해 정의된 [기본 인스턴스 워밍업](ec2-auto-scaling-default-instance-warmup.md)의 값인 기본값을 사용합니다. 기본 인스턴스 워밍업이 null 값이면 그것은 [기본 쿨다운](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown) 값으로 돌아갑니다. 워밍업 시간이 변경될 때 모든 조정 정책을 쉽게 업데이트할 수 있도록 기본 인스턴스 워밍업을 사용하는 것이 좋습니다.
## 고려 사항
대상 추적 조정 정책과 관련한 작업을 수행할 때는 다음 고려 사항이 적용됩니다.
+ 대상 추적 조정 정책과 함께 사용되는 CloudWatch 경보는 생성하거나 편집하거나 삭제하지 마세요. Amazon EC2 Auto Scaling은 대상 추적 규모 조정 정책과 연결된 CloudWatch 경보를 생성하고 관리하며, 필요한 경우 이를 편집, 교체 또는 삭제하여 애플리케이션의 규모 조정 환경과 변화하는 사용률 패턴을 사용자 지정할 수 있습니다.
+ 대상 추적 조정 정책은 트래픽이 감소할 때 보다 점진적으로 스케일 인하여 트래픽 수준이 변동하는 기간 동안 가용성을 우선으로 보장합니다. 더 세밀한 제어가 필요하다면, 단계 규모 조정 정책이 더 적합할 수 있습니다. 대상 추적 정책의 스케일 인 동작은 일시적으로 비활성화할 수 있습니다. 이는 성공적인 배포를 위해 필요한 최소 인스턴스 수를 유지하는 데 도움이 됩니다.
+ 지표에 누락된 데이터 포인트가 있는 경우, CloudWatch 경보 상태가 `INSUFFICIENT_DATA`로 변경됩니다. 이 경우, 새 데이터 포인트를 찾을 때까지 Amazon EC2 Auto Scaling이 그룹을 조정할 수 없습니다.
+ 설계상 지표가 드물게 보고되는 경우, 지표 수학이 유용할 수 있습니다. 예컨대, 가장 최근 값을 사용하려면 `m1`이 지표에 있는 `FILL(m1,REPEAT)` 함수를 사용하세요.
+ 대상 값과 실제 지표 데이터 포인트 사이에는 차이가 발생할 수 있습니다. 추가하거나 제거할 인스턴스 수를 결정할 때마다 항상 반올림 또는 내림을 통해 어림짐작으로 동작하기 때문입니다. 이는 인스턴스를 부족하게 추가하거나 너무 많이 제거하는 일을 방지하기 위해서입니다. 하지만 인스턴스가 줄어서 Auto Scaling 그룹이 작아지는 경우에는 그룹의 사용량이 목푯값에서 멀어질 수도 있습니다.
예컨대 CPU 사용률 목푯값을 50%로 설정한 후 Auto Scaling 그룹이 목표 값을 초과한다고 가정해 보겠습니다. 1.5개의 인스턴스를 추가하면 CPU 사용률이 50% 가까이 감소할 것을 알 수 있습니다. 하지만 1.5개의 인스턴스를 추가할 수 없기 때문에 반올림을 통해 인스턴스 2개를 추가합니다. 그러면 CPU 사용량이 50% 아래로 떨어지는 동시에 애플리케이션은 리소스를 충분히 확보하게 됩니다. 마찬가지로 인스턴스를 0.5개 줄이면 CPU 사용률이 50%를 초과하게 된다고 판단될 경우, 스케일 인이 진동을 유발하지 않을 만큼 지표가 충분히 낮아질 때까지 스케일 인을 수행하지 않습니다.
인스턴스가 더 많고 규모가 큰 Auto Scaling 그룹의 경우, 활용도가 더 많은 수의 인스턴스에 분산되므로 인스턴스를 추가 또는 제거하면 대상 값과 실제 지표 데이터 포인트 간 차이가 줄어듭니다.
+ 대상 추적 조정 정책은 지정한 지표가 목푯값을 초과할 때 한해서 Auto Scaling 그룹을 스케일 아웃하게 되어 있습니다. 대상 추적 조정 정책에서는 지정한 지표가 목푯값보다 작을 때 Auto Scaling 그룹을 스케일 아웃할 수 없습니다.
# 대상 추적 조정 정책 생성
Auto Scaling 그룹에 대한 대상 추적 조정 정책을 생성하려면 다음 방법 중 하나를 사용합니다.
시작하기 전에 원하는 지표를 1분 간격으로 사용할 수 있는지 확인하세요(Amazon EC2 지표의 기본 5분 간격과 비교).
------
#### [ Console ]
**새 Auto Scaling 그룹을 위한 대상 추적 조정 정책 생성**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. **Create Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
1. 1, 2, 3단계에서 원하는 옵션을 선택하고 **4단계: 그룹 크기 및 조정 정책 구성**으로 진행합니다.
1. **스케일링** 항목에서 specify the range that you want to scale between by updating the **원하는 최소 용량**과 **원하는 최대 용량**을 업데이트하여 조정할 범위를 지정합니다. 이 두 설정을 사용하면 Auto Scaling 그룹이 크기를 동적으로 조정할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **자동 조정**에서 **대상 추적 조정 정책**을 선택합니다.
1. 정책을 정의하려면 다음을 수행하십시오:
1. 정책의 이름을 지정합니다.
1. **지표 유형(Metric type)**에서 지표를 선택합니다.
**대상당 Application Load Balancer 요청 수(Application Load Balancer request count per target)**를 선택한 경우, **대상 그룹(Target group)**에서 대상 그룹을 선택합니다.
1. 지표의 **대상 값(Target value)**을 지정합니다.
1. (옵션) **인스턴스 워밍업**에서 인스턴스 워밍업 값을 필요에 따라 업데이트합니다.
1. (옵션) **축소 정책을 비활성화하여 스케일 아웃 정책만 생성(Disable scale in to create only a scale-out policy)**을 선택합니다. 이렇게 하면 원할 경우, 유형이 다를 때마다 축소 정책을 별도로 생성할 수 있습니다.
1. 계속해서 Auto Scaling 그룹을 생성합니다. Auto Scaling 그룹이 생성된 후에 조정 정책이 생성됩니다.
**기존 Auto Scaling 그룹을 위한 대상 추적 조정 정책 생성**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. 스케일링 제한이 적절하게 설정되었는지 확인합니다. 예컨대, 그룹의 원하는 용량이 이미 최대치에 있는 경우, 스케일 아웃하려면 새로운 최대값을 지정해야 합니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **자동 크기 조정(Automatic scaling)** 탭의 **동적 크기 조정 정책(Dynamic scaling policies)**에서 **동적 크기 조정 정책 생성(Create dynamic scaling policy)**을 선택합니다.
1. 정책을 정의하려면 다음을 수행하십시오:
1. **정책 유형**의 경우, 기본값 **대상 추적 조정**을 유지합니다.
1. 정책의 이름을 지정합니다.
1. **지표 유형(Metric type)**에서 지표를 선택합니다. 지표 유형은 하나만 선택할 수 있습니다. 둘 이상의 지표를 사용하려면 여러 정책을 생성합니다.
**대상당 Application Load Balancer 요청 수(Application Load Balancer request count per target)**를 선택한 경우, **대상 그룹(Target group)**에서 대상 그룹을 선택합니다.
1. 지표의 **대상 값(Target value)**을 지정합니다.
1. (옵션) **인스턴스 워밍업**에서 인스턴스 워밍업 값을 필요에 따라 업데이트합니다.
1. (옵션) **축소 정책을 비활성화하여 스케일 아웃 정책만 생성(Disable scale in to create only a scale-out policy)**을 선택합니다. 이렇게 하면 원할 경우, 유형이 다를 때마다 축소 정책을 별도로 생성할 수 있습니다.
1. **Create(생성)**를 선택합니다.
------
#### [ AWS CLI ]
대상 추적 조정 정책을 생성하려면 시작하는 데 도움이 되는 다음 예제를 사용할 수 있습니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
**참고**
더 많은 예시는 [에 대한 조정 정책 예제 AWS CLI](examples-scaling-policies.md)를 참조합니다.
**대상 추적 조정 정책(AWS CLI)을 생성하려면**
1. 다음 `cat` 명령을 사용하여 홈 디렉터리에 `config.json`이라는 이름의 JSON 파일에 조정 정책에 대한 목표값과 사전 정의된 지표 사양을 저장합니다. 다음은 평균 CPU 사용률을 50%로 유지하는 대상 추적 구성의 예입니다.
```
$ cat ~/config.json
{
"TargetValue": 50.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}
```
자세한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)을 참조하세요.
1. [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령과 이전 단계에서 만든 `config.json` 파일을 사용하여 조정 정책을 생성합니다.
```
aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
```
이 명령이 성공하면 사용자를 위해 생성된 두 CloudWatch 경보의 ARN과 이름이 반환됩니다.
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/cpu50-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
]
}
```
------
# 더 빠른 대응을 위해 고해상도 지표를 사용하여 대상 추적 정책 생성
대상 추적은 1분 미만의 간격으로 게시되는, 초 단위 데이터 포인트를 포함한 고해상도 CloudWatch 지표를 지원합니다. 클라이언트 API, 라이브 스트리밍 서비스, 전자상거래 웹사이트, 온디맨드 데이터 처리처럼 수요 변동이 큰 애플리케이션의 사용률을 모니터링하기 위해, 고해상도 CloudWatch 지표를 활용해 대상 추적 정책을 구성합니다. 수요에 맞춰 용량을 더욱 정밀하게 조정하기 위해 대상 추적은 이러한 세분화된 모니터링을 활용해 EC2 인스턴스의 수요 및 사용률 변화를 더 빠르게 감지하고 대응합니다.
고해상도로 지표를 게시하는 방법에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)를 참조하세요. CPU 사용률과 같은 EC2 지표를 고해상도로 조회하고 게시하려면 [CloudWatch 에이전트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)를 사용하는 것이 좋습니다.
## AWS 리전
고해상도 지표를 사용한 대상 추적은를 AWS 리전 제외한 모든에서 사용할 수 있습니다 AWS GovCloud (US) Regions.
## 고해상도 지표를 활용한 대상 추적 정책 작동 방식
추적하려는 지표와 해당 지표가 유지해야 하는 목표 값을 정의해 대상 추적 정책을 생성합니다. 고해상도 지표를 기반으로 스케일링하려면, 해당 지표의 이름을 지정하고 대상 추적이 이 지표를 관찰하는 지표 주기를 60초 미만으로 설정해야 합니다. 현재 지원되는 가장 낮은 간격은 10초입니다. 이보다 낮은 간격으로 지표를 게시할 수 있습니다.
**참고**
60보다 큰 지표 기간은 지원되지 않습니다.
대상 추적은 단일 CloudWatch 지표에 대해 구성할 수 있으며, 여러 CloudWatch 지표를 조회한 뒤 수학 식을 사용해 이를 기반으로 새로운 단일 시계열을 생성할 수도 있습니다. 두 옵션 모두 지표 기간을 정의할 수 있습니다.
## 예제
**예제 1.**
다음 예시에서는 고해상도 CloudWatch 지표를 기반으로 대상 추적 정책을 생성합니다. 지표는 10초 해상도로 게시됩니다. 기간을 정의하면 대상 추적이 이 지표를 10초 단위의 세분화된 수준으로 모니터링하도록 설정할 수 있습니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
```
$ cat ~/config.json
{
"TargetValue": 100.0,
"CustomizedMetricSpecification": {
"MetricName": "MyHighResolutionMetric",
"Namespace": "MyNamespace",
"Dimensions": [
{
"Name": "MyOptionalDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
],
"Statistic": "Average",
"Unit": "None"
"Period": "10
}
}
```
**예제 2.**
여러 지표를 결합해 규모 조정에 사용할 단일 시계열로 만들기 위해, 지표 수학 식을 사용할 수 있습니다. 지표 수학은 기존 지표를 인스턴스당 평균값으로 변환할 때 특히 유용합니다. 지표 변환은 필수적입니다. 대상 추적은 지표가 Auto Scaling 그룹의 용량과 반비례한다고 가정하기 때문입니다. 따라서 용량이 증가하면 지표도 거의 같은 비율로 감소해야 합니다.
예를 들어 애플리케이션이 처리해야 하는 대기 작업 수를 나타내는 지표가 있다고 가정해 보겠습니다. 지표 수학을 사용하여 보류 중인 작업을 Auto Scaling 그룹의 실행 용량으로 나눌 수 있습니다. Auto Scaling은 용량 지표를 1분 단위로 게시하므로 1분 미만의 간격에서는 이 지표 값이 제공되지 않습니다. 더 높은 해상도로 규모 조정을 수행하려는 경우, 용량 지표와 대기 작업 지표 간에 기간 불일치가 발생할 수 있습니다. 이런 불일치를 방지하려면 이전 1분 타임스탬프에 기록된 용량 값으로 누락된 값을 채우도록 FILL 식을 사용하는 것을 권장합니다.
다음 예제에서는 지표 수학을 사용해 대기 작업 지표를 용량으로 나눕니다. 기간은 두 지표 모두 10초로 설정합니다. 이 지표는 1분 간격으로 게시되므로 용량 지표에는 FILL 연산을 사용합니다.
지표 수학을 사용하여 여러 지표 수정
```
{
"CustomizedMetricSpecification": {
"Metrics": [
{
"Label": "Pending jobs to be processed",
"Id": "m1",
"MetricStat": {
"Metric": {
"MetricName": "MyPendingJobsMetric",
"Namespace": "Custom",
},
"Stat": "Sum"
"Period": 10
},
"ReturnData": false
},
{
"Label": "Get the running instance capacity (matching the period to that of the m1)",
"Id": "m2",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Average"
"Period": 10
},
"ReturnData": false
},
{
"Label": "Calculate the pending job per capacity (note the use of the FILL expression)",
"Id": "e1",
"Expression": "m1 / FILL(m2,REPEAT)",
"ReturnData": true
}
]
},
"TargetValue": 100
}
```
## 고려 사항
대상 추적 및 고해상도 지표를 사용할 때는 다음 사항을 고려하세요.
+ 원하지 않는 자동 규모 조정 결과를 초래할 수 있는 누락된 데이터 포인트가 발생하지 않도록 하려면, CloudWatch 지표가 지정한 기간과 같거나 더 높은 해상도로 게시되어야 합니다.
+ Auto Scaling 그룹이 유지해야 하는 1분당 인스턴스별 지표 값을 목푯값으로 정의합니다. 지표의 기간에 따라 값이 배로 증가할 수 있는 지표를 사용하는 경우, 적절한 목푯값을 설정하는 것이 매우 중요합니다. 예를 들어 요청 수나 대기 작업 수처럼 SUM 통계를 사용하는 개수 기반 지표는 설정한 기간에 따라 지표 값이 달라지게 됩니다. 여전히 1분당 평균값을 기준으로 목푯값을 설정한다고 가정해야 합니다.
+ Amazon EC2 Auto Scaling 사용에는 추가 요금이 없지만, Amazon EC2 인스턴스, CloudWatch 지표, CloudWatch 알람과 같은 리소스에 대한 비용은 지불해야 합니다. 앞선 예제에서 생성된 고해상도 알람은 표준 CloudWatch 알람과는 다른 기준으로 요금이 부과됩니다. CloudWatch 요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
+ 대상 추적은 지표가 EC2 인스턴스의 인스턴스당 평균 사용률을 나타내야 합니다. 이를 위해 대상 추적 정책 구성에서 [지표 수학 연산](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 사용할 수 있습니다. 지표를 Auto Scaling 그룹의 실행 용량으로 나눕니다. 단일 시계열을 생성할 때 사용하는 모든 지표에 대해 동일한 지표 기간을 정의해야 합니다. 여러 지표가 서로 다른 간격으로 게시되는 경우, 더 긴 간격으로 게시되는 지표에 FILL 연산을 사용해 누락된 데이터 포인트를 채워야 합니다.
# 지표 수식을 사용하여 대상 추적 조정 정책 생성
지표 수학을 사용하면 여러 CloudWatch 지표를 쿼리하고 수학 표현식을 활용함으로써 이러한 지표에 근거하여 새로운 시계열을 만들 수 있습니다. CloudWatch 콘솔에서 결과 시계열을 시각화하고 대시보드에 추가할 수 있습니다. 지표 수학에 대한 자세한 설명은 *Amazon CloudWatch 사용자 가이드*에서 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요.
다음은 지표 수학 표현식에 적용되는 고려 사항입니다.
+ 사용 가능한 모든 CloudWatch 지표를 쿼리할 수 있습니다. 각 지표는 지표 이름, 네임스페이스, 0개 이상의 측정기준으로 이루어진 고유한 조합입니다.
+ 산술 연산자(\$1 - \$1 / ^), 통계 함수(예: AVG 또는 SUM) 또는 CloudWatch에서 지원하는 기타 함수를 사용할 수 있습니다.
+ 수학 표현식의 공식에서 지표 및 다른 수학 표현식의 결과를 모두 사용할 수 있습니다.
+ 지표 사양에 사용된 표현식은 결국 단일 시계열을 반환해야 합니다.
+ CloudWatch 콘솔 또는 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API를 사용하여 지표 수학 표현식이 유효한지 확인할 수 있습니다.
## 예: 인스턴스당 Amazon SQS 대기열 백로그
인스턴스당 Amazon SQS 대기열 백로그를 계산하려면 대기열에서 검색 가능한 대략적인 메시지 수를 가져와 Auto Scaling 그룹의 실행 용량(`InService` 상태인 인스턴스의 수)으로 나눠서 인스턴스당 Amazon SQS 대기열 백로그를 산출합니다. 자세한 설명은 [Amazon SQS 기반 조정 정책](as-using-sqs-queue.md) 섹션을 참조하세요.
표현식의 로직은 다음과 같습니다.
`sum of (number of messages in the queue)/(number of InService instances)`
이 경우, CloudWatch 지표 정보는 다음과 같습니다.
| ID | CloudWatch 지표 | 통계 | Period |
| --- | --- | --- | --- |
| m1 | ApproximateNumberOfMessagesVisible | Sum | 1분 |
| m2 | GroupInServiceInstances | 평균 | 1분 |
지표 수식 ID와 표현식은 다음과 같습니다.
| ID | 표현식 |
| --- | --- |
| e1 | (m1)/(m2) |
다음은 이 지표에 대한 아키텍처를 보여주는 다이어그램입니다.
![\[대기열 아키텍처 다이어그램을 사용한 Amazon EC2 Auto Scaling\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)
**이 지표 수학을 사용하여 대상 추적 조정 정책 생성(AWS CLI)**
1. 지표 수학 표현식을 사용자 지정된 지표 사양의 일부로서 `config.json`이라는 이름의 JSON 파일로 저장합니다.
다음 표가 시작하는 데 도움이 될 수 있습니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
```
{
"CustomizedMetricSpecification": {
"Metrics": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "m1",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Get the group size (the number of InService instances)",
"Id": "m2",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Average"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "e1",
"Expression": "m1 / m2",
"ReturnData": true
}
]
},
"TargetValue": 100
}
```
자세한 설명은* Amazon EC2 Auto Scaling API 참조의* [TargetTrackingConfiguration](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TargetTrackingConfiguration.html)을 참조하세요.
**참고**
다음은 CloudWatch 지표에 대한 지표 이름, 네임스페이스, 차원 및 통계를 찾는 데 도움이 되는 몇 가지 추가 리소스입니다.
AWS 서비스에 사용 가능한 지표에 대한 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 지표를 게시하는AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)를 참조하세요.
AWS CLI를 사용하여 CloudWatch 지표에 대한 정확한 지표 이름, 네임스페이스 및 차원(해당되는 경우)을 얻으려면 [list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)를 참조하세요.
1. 이 정책을 생성하려면 다음 예에 나와 있는 것처럼 JSON 파일을 입력으로 사용하여 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다.
```
aws autoscaling put-scaling-policy --policy-name sqs-backlog-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
```
이 명령이 성공하면 사용자를 대신하여 생성된 두 CloudWatch 경보의 Amazon 리소스 이름(ARN)과, 정책의 ARN이 반환됩니다.
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/sqs-backlog-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
]
}
```
**참고**
이 명령에서 오류가 발생하면 AWS CLI 로컬에서를 최신 버전으로 업데이트했는지 확인합니다.
# Amazon EC2 Auto Scaling의 단계별 조정 및 단순 조정 정책
단계 조정 및 단순 조정 정책은 CloudWatch 경보를 기반으로 사전 정의된 증분 단위로 Auto Scaling 그룹의 용량을 조정합니다. 경보 임계값 위반 시 스케일 아웃(용량 증가) 및 스케일 인(용량 감소)을 처리하도록 별도의 조정 정책을 정의할 수 있습니다.
Auto Scaling 그룹의 용량은 인스턴스로 측정되며 [인스턴스 가중치](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)를 사용하는 경우 용량 단위로 측정됩니다. 또한 원하는 용량과 현재 용량에는 차이가 있습니다.
+ 원하는 용량 - 그룹에 두고자 하는 인스턴스(또는 용량 단위)의 수를 의미합니다. 원하는 용량은 규모 조정 정책을 통해 수동 또는 자동으로 조절할 수 있습니다.
+ 현재 용량 - 워밍업 및 휴지 기간을 모두 완료하여 실행 중이며 사용할 준비가 된 그룹의 인스턴스(또는 용량 단위) 수를 의미합니다.
단계 조정 및 단순 조정을 사용하여 조정 프로세스를 호출하는 CloudWatch 경보를 생성하고 관리합니다. 경보 위반이 발생하면 Amazon EC2 Auto Scaling에서 해당 경보와 관련된 조정 정책을 시작합니다.
목표 추적 조정 정책을 사용하여 목표당 평균 요청 수 또는 평균 CPU 사용률과 같은 지표에 따라 조정하는 것이 좋습니다 용량이 증가할 때 감소하고 용량이 감소할 때 증가하는 지표를 사용하여 비례적으로 스케일 아웃하거나 대상 추적을 사용하여 인스턴스 수를 늘릴 수 있습니다. 이렇게 하면 Amazon EC2 Auto Scaling이 애플리케이션의 수요 곡선을 근접하게 따를 수 있습니다. 자세한 설명은 [대상 추적 조정 정책](as-scaling-target-tracking.md) 섹션을 참조하세요.
**Contents**
+ [단계 조정 정책 작동 방식](#step-scaling-how-it-works)
+ [단계별 조정 정책에 대한 단계별 조정](#as-scaling-steps)
+ [조정 조절 유형](#as-scaling-adjustment)
+ [인스턴스 워밍업](#as-step-scaling-warmup)
+ [고려 사항](#step-scaling-considerations)
+ [스케일 아웃을 위한 단계 조정 정책 생성](step-scaling-create-scale-out-policy.md)
+ [스케일 인을 위한 단계 조정 정책 생성](step-scaling-create-scale-in-policy.md)
+ [단순 조정 정책](simple-scaling-policies.md)
## 단계 조정 정책 작동 방식
단계 조정을 사용하려면 우선 Auto Scaling 그룹의 지표를 모니터링하는 CloudWatch 경보를 생성해야 합니다. 경보 위반을 결정하는 지표, 임계값, 평가 기간 수를 정의합니다. 그런 다음 경보 임곗값이 위반될 때 그룹을 조정하는 방법을 정의하는 단계 조정 정책을 생성합니다. 조정 조절 유형으로 Auto Scaling 그룹의 현재 용량의 백분율 또는 용량 단위를 사용할 수 있습니다. 자세한 내용은 [조정 조절 유형](#as-scaling-adjustment) 단원을 참조하십시오.
정책에 단계 조정을 추가합니다. 경보의 위반 규모에 따라 다양한 단계 조정을 정의할 수 있습니다. 예제:
+ 경보 지표가 60%에 도달하면 10개 인스턴스 단위로 스케일 아웃
+ 경보 지표가 75%에 도달하면 30개 인스턴스 단위로 스케일 아웃
+ 경보 지표가 85%에 도달하면 40개 인스턴스 단위로 스케일 아웃
지정된 수의 평가 기간 동안 경보 임곗값이 위반되면 Amazon EC2 Auto Scaling이 정책에 정의된 단계 조정을 적용합니다. 경보 상태가 `OK`로 돌아갈 때까지 추가 경보 위반에 대해 조정을 계속할 수 있습니다.
각 인스턴스에는 워밍업 기간이 있어 조정 활동이 단기간에 발생하는 변경 사항에 과하게 반응하는 것을 방지합니다. 선택적으로 조정 정책에 대한 워밍업 기간을 구성할 수 있습니다. 하지만 워밍업 시간이 변경될 때 모든 조정 정책을 쉽게 업데이트할 수 있도록 기본 인스턴스 워밍업을 사용하는 것이 좋습니다. 자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 단원을 참조하십시오.
단순 조정 정책은 단일 조정을 기반으로 하고 각 조정 활동 사이에 휴지 기간을 둔다는 점을 제외하면 단계 조정 정책과 유사합니다. 자세한 내용은 [단순 조정 정책](simple-scaling-policies.md) 단원을 참조하십시오.
## 단계별 조정 정책에 대한 단계별 조정
단계별 조정 정책을 생성할 때 경보 위반의 크기에 따라 인스턴스 수를 동적으로 자동 조정되도록 하나 이상의 단계별 조정을 지정합니다. 각 단계별 조정은 다음을 지정합니다.
+ 지표 값의 하한값입니다.
+ 지표 값의 상한값입니다.
+ 조정 유형에 근거하여 축소하거나 스케일 아웃하는 양입니다.
CloudWatch는 CloudWatch 경보와 연결된 지표의 통계를 바탕으로 지표 데이터 포인트를 집계합니다. 경보를 위반하면 적절한 조정 정책이 호출됩니다. Amazon EC2 Auto Scaling은 집계 유형을 CloudWatch의 최근 지표 데이터 포인트에 적용합니다(원시 지표 데이터와 반대). 이 집계된 지표 값을 단계별 조정으로 정의된 상한값 및 하한값과 비교하여 어느 단계의 조정을 수행할 것인지 결정합니다.
위반 임계값과 연계하여 상한값과 하한값을 지정합니다. 예를 들어 지표가 50%를 초과하는 경우에 대한 CloudWatch 경보와 스케일 아웃 정책을 만들었다고 가정해 보겠습니다. 그런 다음 지표가 50% 미만일 때를 대비한 두 번째 경보와 스케일 인 정책을 만들었습니다. 각 정책에 대해 조정 유형이 `PercentChangeInCapacity`(또는 콘솔의 **그룹 백분율**)인 단계 조정 집합이 있습니다.
**예: 스케일 아웃 정책에 대한 단계 조절**
| **하한** | **상한** | **조절** |
| --- | --- | --- |
| 0 | 10 | 0 |
| 10 | 20 | 10 |
| 20 | null | 30 |
**예: 축소 정책에 대한 단계 조절**
| **하한** | **상한** | **조절** |
| --- | --- | --- |
| -10 | 0 | 0 |
| -20 | -10 | -10 |
| null | -20 | -30 |
이렇게 하면 다음과 같은 조정 구성이 생성됩니다.
```
Metric value
-infinity 30% 40% 60% 70% infinity
-----------------------------------------------------------------------
-30% | -10% | Unchanged | +10% | +30%
-----------------------------------------------------------------------
```
현재 용량과 원하는 용량이 모두 10인 Auto Scaling 그룹에 이 조정 구성을 사용한다고 가정해 보겠습니다. 다음은 그룹의 원하는 용량과 현재 용량과 관련된 조정 구성의 동작을 요약한 내용입니다.
+ 집계된 지표 값이 40보다 크고 60보다 작으면 현재 용량과 원하는 용량이 유지됩니다.
+ 지표 값이 60이 되면 스케일 아웃 정책의 2단계 조절(10개의 인스턴스에 10% 합산)에 따라 그룹의 원하는 용량을 1개의 인스턴스만큼 늘려 11개의 인스턴스로 만듭니다. 새 인스턴스가 실행되고 지정된 워밍업 시간이 만료된 후 그룹의 현재 용량을 11개의 인스턴스로 늘립니다. 용량이 이렇게 증가한 후에도 지표 값이 70으로 증가하면 그룹의 원하는 용량이 14개의 인스턴스까지 증가합니다(인스턴스가 3개씩 증가). 이는 스케일 아웃 정책의 세 번째 단계 조절에 근거하여 합니다(11개 인스턴스의 30%인 3.3개 인스턴스가 3개로 반올림되어 추가).
+ 지표 값이 40이 될 경우, 축소 정책의 2단계 조절에 따라(14개의 인스턴스에 10%인 1.4개의 인스턴스를 빼되 1개의 인스턴스로 반내림) 그룹의 원하는 용량을 1개의 인스턴스만큼 더 줄여 13개의 인스턴스로 만듭니다. 이렇게 용량이 감소한 후에도 지표 값이 30으로 떨어지면 그룹의 원하는 용량이 10개의 인스턴스로 감소합니다(인스턴스가 3개씩 감소). 이는 스케일 인 정책의 세 번째 단계 조절에 근거하여 합니다(13개 인스턴스 30%인 3.9개 인스턴스가 3개로 반내림되어 제거).
조정 정책에 대한 단계 조절을 지정할 때는 다음 사항에 유의하세요.
+ 를 사용하는 경우 상한과 하한을 절대값으로 AWS Management Console지정합니다. AWS CLI 또는 SDK를 사용하는 경우 위반 임계값을 기준으로 상한과 하한을 지정합니다.
+ 단계 조절의 범위는 중복되거나 격차가 있어서는 안 됩니다.
+ 1단계 조절에만 null 하한값(negative infinity)이 포함될 수 있습니다. 1단계 조절에 음의 하한값이 포함될 경우, null 하한값으로 단계 조절을 해야 합니다.
+ 1단계 조절에만 null 상한값(positive infinity)이 포함될 수 있습니다. 1단계 조절에 양의 상한값이 포함될 경우, null 상한값으로 단계 조절을 해야 합니다.
+ 상한 및 하한값은 동일한 단계 조절에서 null이 될 수 없습니다.
+ 지표 값이 위반 임계값을 초과할 경우, 하한값은 포함되고 상한값은 제외됩니다. 지표 값이 위반 임계값 미만일 경우, 하한값은 제외되고 상한값은 포함됩니다.
## 조정 조절 유형
선택한 조정 조절 유형에 따라 최적의 조정 작업을 수행하는 조정 정책을 정의할 수 있습니다. 조절 유형을 Auto Scaling 그룹의 현재 용량의 백분율이나 용량 단위로 지정할 수 있습니다. 일반적으로 인스턴스 가중치 부여 기능을 사용하지 않는 한 용량 단위는 인스턴스 한 개를 의미합니다.
Amazon EC2 Auto Scaling은 다음과 같이 단계별 조정 및 단순 조정을 위한 조절 유형을 지원합니다.
+ `ChangeInCapacity` - 그룹의 현재 용량을 지정된 값만큼 늘리거나 줄입니다. 양의 값은 용량을 늘리고, 음의 조절 값은 용량을 줄입니다. 예: 그룹의 현재 용량이 3개의 인스턴스이고 조절이 5개인 경우, 이 정책이 수행되면 용량 단위가 총 8개가 되도록 용량에 5개의 용량 단위를 추가합니다.
+ `ExactCapacity` - 그룹의 현재 용량을 지정된 값으로 변경합니다. 이 조절 유형에는 음이 아닌 값을 지정합니다. 예: 그룹의 현재 용량이 3개의 인스턴스이고 조절이 5개인 경우, 이 정책이 수행되면 용량을 5개의 용량 단위로 변경합니다.
+ `PercentChangeInCapacity` - 그룹의 현재 용량을 지정된 퍼센트만큼 늘리거나 줄입니다. 양의 값은 용량을 늘리고, 음의 값은 용량을 줄입니다. 예: 현재 용량이 10개이고 조절이 10%인 경우, 이 정책이 수행되면 용량 단위가 총 11개가 되도록 용량에 1개의 용량 단위를 추가합니다.
**참고**
결과 값이 정수가 아닌 경우, 다음과 같이 반올림(반내림)합니다.
1보다 큰 값은 반내림합니다. 예컨대, `12.7`은 `12`로 반내림합니다.
0과 1 사이의 값은 1로 반올림합니다. 예컨대, `.67`은 `1`로 반올림합니다.
0과 -1 사이의 값은 1로 반내림합니다. 예컨대, `-.58`은 `-1`으로 반올림합니다.
-1보다 작은 값은 반올림합니다. 예컨대, `-6.67`은 `-6`으로 반올림합니다.
`PercentChangeInCapacity`에서는 `MinAdjustmentMagnitude` 파라미터를 사용하여 조정할 최소 인스턴스 수를 지정할 수도 있습니다. 예컨대, 25퍼센트를 추가하는 정책을 생성하고 최소 증분으로 2개의 인스턴스를 지정한다고 가정해 보세요. Auto Scaling 그룹에 4개 인스턴스가 있고 조정 정책이 실행되는 경우, 4개 인스턴스의 25%는 1개 인스턴스입니다. 그러나 최소 증분을 2로 지정했기 때문에 2개의 인스턴스가 추가됩니다.
[인스턴스 가중치](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)를 사용하면 `MinAdjustmentMagnitude` 파라미터를 0이 아닌 값으로 설정하는 효과가 변경됩니다. 값은 용량 유닛입니다. 조정할 최소 인스턴스 수를 설정하려면 이 파라미터를 가장 큰 인스턴스 가중치 이상의 값으로 설정합니다.
인스턴스 가중치를 사용하는 경우 Auto Scaling 그룹의 현재 용량이 필요에 따라 원하는 용량을 초과할 수 있다는 점에 유의하세요. 절대 감소 수 또는 백분율에서 감소하는 양이 현재 용량과 원하는 용량 간의 차이보다 작으면 조정 작업이 수행되지 않습니다. 임계값 경보가 위반되면 조정 정책의 결과를 확인할 때 이러한 동작을 고려해야 합니다. 예컨대, 원하는 용량이 30개이고 현재 용량이 32개라고 가정해 보겠습니다. 경보가 위반되면 조정 정책이 원하는 용량을 1씩 줄이게 되고 조정 작업이 수행되지 않습니다.
## 인스턴스 워밍업
단계별 조정의 경우, 새로 시작된 인스턴스가 워밍업되는 데 걸리는 시간(초)을 선택적으로 지정할 수 있습니다. 지정된 워밍업 시간이 만료될 때까지 인스턴스는 Auto Scaling 그룹의 집계된 EC2 인스턴스 지표에 포함되지 않습니다.
인스턴스가 워밍업 기간에 있는 동안 워밍업되지 않은 인스턴스의 지표 값이 정책의 경보 상한 임곗값보다 큰 경우에만 조정 정책이 스케일 아웃됩니다.
그룹이 다시 스케일 아웃되면 아직 워밍업 중인 인스턴스가 다음 스케일 아웃 활동에 대한 원하는 용량의 일부로 계산됩니다. 따라서 여러 개의 경보 위반이 동일한 단계 조절 범위에 해당하는 경우, 단일 크기 조정 활동이 이루어집니다. 계속적이지만 과도하지는 않게 스케일 아웃하기 위한 목적입니다.
예컨대, 두 단계로 구성된 정책을 만든다고 가정해 보겠습니다. 첫 번째 단계는 지표이 60%에 도달하면 10%를 추가하고, 두 번째 단계는 지표이 70%에 도달하면 30%를 추가합니다. Auto Scaling 그룹의 원하는 용량과 현재 용량은 10입니다. 집계된 지표 값이 60 미만인 동안에는 원하는 및 현재의 용량은 변하지 않습니다. 지표이 60에 도달하여 인스턴스 1개(10개 인스턴스의 10%)가 추가되었다고 가정합니다. 그런 다음 새 인스턴스가 아직 워밍업 중인 동안 지표는 62가 됩니다. 스케일링 정책은 현재 용량(여전히 10)을 기준으로 새로 원하는 용량을 계산합니다. 하지만 그룹의 필요한 용량이 이미 11개 인스턴스로 증가하였으므로 조정 정책이 원하는 용량을 더 이상 늘리지 않습니다. 지표가 70이 되고 새 인스턴스가 여전히 워밍업 중이면 3개의 인스턴스(10개 인스턴스의 30퍼센트)를 추가해야 합니다. 하지만 그룹의 필요한 용량이 이미 11이므로 새로운 필요 용량 13개 인스턴스에 대해 2개의 인스턴스만 추가합니다.
스케일 아웃 활동이 진행 중인 동안에는 인스턴스 워밍업이 완료될 때까지 조정 정책에 의해 시작된 모든 축소 활동이 차단됩니다. 인스턴스 워밍업이 완료된 후 스케일 인 이벤트가 발생하면 현재 해지 중인 인스턴스는 새로 원하는 용량을 계산할 때 그룹의 현재 용량에 포함됩니다. 따라서 Auto Scaling 그룹에서 인스턴스를 필요 이상으로 빼지 않습니다. 예컨대, 인스턴스가 이미 해지되고 있는 동안 원하는 용량을 1씩 감소시킨 동일한 단계별 조정 범위에서 경보가 위반되는 경우, 스케일링 작업이 수행되지 않습니다.
**기본값**
값을 설정하지 않으면 조정 정책은 그룹에 대해 정의된 [기본 인스턴스 워밍업](ec2-auto-scaling-default-instance-warmup.md)의 값인 기본값을 사용합니다. 기본 인스턴스 워밍업이 null 값이면 그것은 [기본 쿨다운](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown) 값으로 돌아갑니다.
## 고려 사항
단계별 및 단순 조정 정책과 관련한 작업을 수행할 때는 다음 고려 사항이 적용됩니다:
+ 단계별 조정을 사용할 수 있을 만큼 애플리케이션의 단계별 조정을 정확하게 예측할 수 있는지 생각해 보세요. 조정 지표가 스케일 아웃 가능한 대상의 용량에 비례하여 증가하거나 감소하는 경우, 대상 추적 조정 정책을 대신 사용하는 것이 좋습니다. 단계별 조정을 고급 구성에 대한 추가 정책으로 사용할 수도 있습니다. 예컨대, 사용률이 일정 수준에 도달할 때 더 공격적인 대응을 구성할 수 있습니다.
+ 플래핑을 방지하려면 스케일 아웃 임계값과 스케일 인 임계값 사이에서 적절한 마진을 선택해야 합니다. 플래핑은 스케일 인과 스케일 아웃의 무한 루프입니다. 즉, 스케일 아웃 작업을 진행하면 지표 값이 변경되고 반대 방향으로 다른 스케일 아웃 작업이 시작됩니다.
# 스케일 아웃을 위한 단계 조정 정책 생성
Auto Scaling 그룹의 스케일 아웃에 대한 단계 조정 정책을 생성하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**1단계: 지표 상한 임곗값에 대한 CloudWatch 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 필요한 경우, 지역을 변경합니다. 탐색 모음에서 Auto Scaling 그룹이 상주하는 지역을 선택합니다.
1. 탐색 창에서 **경보(Alarms), 모든 경보(All alarms)**를 선택한 다음 **경보 생성(Create alarm)**을 선택합니다.
1. **지표 선택**을 선택합니다.
1. **모든 지표(All metrics)** 탭에서 **EC2**, **Auto Scaling 그룹 기준**(By Auto Scaling Group)을 선택하고 검색 필드에 Auto Scaling 그룹 명칭을 입력합니다. 그런 다음 `CPUUtilization`을 선택하고 **지표 선택(Select metric)**을 선택합니다. 지표에 대한 그래프와 기타 정보가 표시된 **지표 및 조건 지정(Specify metric and conditions)** 페이지가 나타납니다.
1. **기간(Period)**에 예컨대, 1분과 같은 경보에 대한 평가 기간을 선택합니다. 경보를 평가할 때 각 기간이 하나의 데이터 포인트로 집계됩니다.
**참고**
기간이 짧을수록 경보가 더 민감해집니다.
1. **조건(Conditions)**에서 다음을 수행하십시오:
+ **임계값 유형(Threshold type)**에서 **정적(Static)**을 선택합니다.
+ **`CPUUtilization`이 다음과 같은 경우 항상**에서 지표 값이 임곗값보다 클 때 또는 크거나 같을 때 중 경보를 트리거할 조건을 지정합니다. 그런 다음 **기준(than)**에 경보를 위반하려는 임계값을 입력합니다.
1. **추가 구성(Additional configuration)**에서 다음을 수행하십시오:
+ **경보에 대한 데이터 포인트(Datapoints to alarm)**에서 지표 값이 경보에 대한 임계값 조건을 충족해야 하는 데이터 포인트(평가 기간)를 입력합니다. 예컨대, 5분의 시간이 두 차례 연속되면 경보 상태를 호출하기까지 10분이 걸립니다.
+ **누락 데이터 처리(Missing data treatment)**에서 **누락 데이터를 불량으로 처리(임계값 위반)(Treat missing data as bad (breaching threshold))**를 선택합니다. 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [CloudWatch 경보가 누락된 데이터를 처리하는 방법 구성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)을 참조하세요.
1. **다음**을 선택합니다.
**작업 구성** 페이지가 표시됩니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 Amazon SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거(Remove)**를 선택합니다.
1. **작업 구성(Configure actions)** 페이지의 다른 섹션은 비워둘 수 있습니다. 다른 섹션을 비워 두면 조정 정책에 연결하지 않고도 경보가 생성됩니다. 그런 다음 Amazon EC2 Auto Scaling 콘솔에서 경보를 조정 정책에 연결할 수 있습니다.
1. **다음**을 선택합니다.
1. 경보의 이름(예: `Step-Scaling-AlarmHigh-AddCapacity`)과 설명(옵션)을 입력하고 **다음(Next)**을 선택합니다.
1. **경보 생성**을 선택하세요.
다음 절차에 따라 CloudWatch 경보를 생성한 후부터 계속 진행합니다.
**2단계: 스케일 아웃을 위한 단계 조정 정책 생성**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. 스케일링 제한이 적절하게 설정되었는지 확인합니다. 예컨대, 그룹의 원하는 용량이 이미 최대치에 있는 경우, 스케일 아웃하려면 새로운 최대값을 지정해야 합니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **자동 크기 조정(Automatic scaling)** 탭의 **동적 크기 조정 정책(Dynamic scaling policies)**에서 **동적 크기 조정 정책 생성(Create dynamic scaling policy)**을 선택합니다.
1. **정책 유형**에서 **단계 조정**을 선택한 다음 정책의 이름을 지정합니다.
1. **CloudWatch 경보(CloudWatch alarm)**에서 경보를 선택합니다. 경보를 아직 생성하지 않은 경우 **CloudWatch 경보 생성**을 선택하고 이전 절차의 4단계\$114단계까지 완료하여 경보를 생성합니다.
1. **다음 작업을 수행(Take the action)**을 사용하여 이 정책을 실행할 때 적용할 현재 그룹 크기 변경을 지정합니다. 특정 인스턴스 개수 또는 기존 그룹 크기의 백분율을 추가하거나 그룹을 정확한 크기로 설정할 수 있습니다.
예를 들어 그룹의 용량을 30% 늘리는 스케일 아웃 정책을 생성하려면 `Add`를 선택하고 다음 필드에 `30`을 입력한 후 `percent of group`를 선택합니다. 기본적으로 이 단계별 조정의 하한값은 경보 임계값이고 상한값은 양(\$1)의 무한대입니다.
1. 다른 단계를 추가하려면 **단계 추가(Add step)**를 선택한 다음 조정할 양과 경보 임계값에 상대적인 단계 하한 및 상한을 정의합니다.
1. 조정할 최소 인스턴스 수를 설정하려면 **최소 1 단위 용량의 증분으로 용량 단위 추가(Add capacity units in increments of at least** `1` **capacity units)**의 숫자 필드를 업데이트합니다.
1. (옵션) **인스턴스 워밍업**에서 인스턴스 워밍업 값을 필요에 따라 업데이트합니다.
1. **생성(Create)**을 선택합니다.
------
#### [ AWS CLI ]
스케일 아웃(용량 증가)에 대한 단계 조정 정책을 생성하려면 다음 예제 명령을 사용합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
를 사용하는 경우 AWS CLI먼저 지표 값이 증가할 때 스케일 아웃하는 방법에 대한 지침을 Amazon EC2 Auto Scaling에 제공하는 단계 조정 정책을 생성합니다. 그런 다음 조사하려는 지표를 식별하여 경보를 생성하고 지표 상한 임곗값과 경보에 대한 기타 세부 정보를 정의한 다음, 해당 경보를 조정 정책과 연결합니다.
**1단계: 스케일 아웃을 위한 정책 생성**
[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여 다음과 같은 단계별 조정에 따라 그룹 용량을 늘리는 `my-step-scale-out-policy`라는 단계별 조정 정책(조절 유형 `PercentChangeInCapacity`)을 생성합니다(CloudWatch 경보 임계값을 60%로 가정).
+ 지표 값이 60% 이상이고 75% 미만인 경우, 인스턴스 수를 10% 늘립니다.
+ 지표 값이 75% 이상이고 85% 미만인 경우, 인스턴스 수를 20% 늘립니다.
+ 지표 값이 85% 이상이면 인스턴스 수를 30% 증가시킵니다.
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-out-policy \
--policy-type StepScaling \
--adjustment-type PercentChangeInCapacity \
--metric-aggregation-type Average \
--step-adjustments MetricIntervalLowerBound=0.0,MetricIntervalUpperBound=15.0,ScalingAdjustment=10 \
MetricIntervalLowerBound=15.0,MetricIntervalUpperBound=25.0,ScalingAdjustment=20 \
MetricIntervalLowerBound=25.0,ScalingAdjustment=30 \
--min-adjustment-magnitude 1
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. 정책에 대한 CloudWatch 경보를 생성하는 데 필요합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:4ee9e543-86b5-4121-b53b-aa4c23b5bbcc:autoScalingGroupName/my-asg:policyName/my-step-scale-in-policy
}
```
**2단계: 지표 상한 임곗값에 대한 CloudWatch 경보 생성**
CloudWatch [put-metric-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용하여 평균 CPU 임계값 60%를 기준으로 최소 2회 연속 2분간의 평가 기간에 Auto Scaling 그룹의 크기를 증가시키는 경보를 생성합니다. 사용자 지정 지표를 사용하려면 `--metric-name`에 지표 이름을 지정하고, `--namespace`에 네임스페이스를 지정합니다.
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmHigh-AddCapacity \
--metric-name CPUUtilization --namespace AWS/EC2 --statistic Average \
--period 120 --evaluation-periods 2 --threshold 60 \
--comparison-operator GreaterThanOrEqualToThreshold \
--dimensions "Name=AutoScalingGroupName,Value=my-asg" \
--alarm-actions PolicyARN
```
------
# 스케일 인을 위한 단계 조정 정책 생성
Auto Scaling 그룹의 스케일 인에 대한 단계 조정 정책을 생성하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**1단계: 지표 하한 임곗값에 대한 CloudWatch 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 필요한 경우, 지역을 변경합니다. 탐색 모음에서 Auto Scaling 그룹이 상주하는 지역을 선택합니다.
1. 탐색 창에서 **경보(Alarms), 모든 경보(All alarms)**를 선택한 다음 **경보 생성(Create alarm)**을 선택합니다.
1. **지표 선택**을 선택합니다.
1. **모든 지표(All metrics)** 탭에서 **EC2**, **Auto Scaling 그룹 기준**(By Auto Scaling Group)을 선택하고 검색 필드에 Auto Scaling 그룹 명칭을 입력합니다. 그런 다음 `CPUUtilization`을 선택하고 **지표 선택(Select metric)**을 선택합니다. 지표에 대한 그래프와 기타 정보가 표시된 **지표 및 조건 지정(Specify metric and conditions)** 페이지가 나타납니다.
1. **기간(Period)**에 예컨대, 1분과 같은 경보에 대한 평가 기간을 선택합니다. 경보를 평가할 때 각 기간이 하나의 데이터 포인트로 집계됩니다.
**참고**
기간이 짧을수록 경보가 더 민감해집니다.
1. **조건(Conditions)**에서 다음을 수행하십시오:
+ **임계값 유형(Threshold type)**에서 **정적(Static)**을 선택합니다.
+ **`CPUUtilization`이 다음과 같은 경우 항상**에서 지표 값이 임곗값보다 작을 때 또는 작거나 같을 때 중 경보를 트리거할 조건을 지정합니다. 그런 다음 **기준(than)**에 경보를 위반하려는 임계값을 입력합니다.
**중요**
스케일 인 정책(지표 하한)과 함께 사용할 경보의 경우, 임곗값보다 큰 항목이나 크거나 같은 항목을 선택하지 않았는지 확인합니다.
1. **추가 구성(Additional configuration)**에서 다음을 수행하십시오:
+ **경보에 대한 데이터 포인트(Datapoints to alarm)**에서 지표 값이 경보에 대한 임계값 조건을 충족해야 하는 데이터 포인트(평가 기간)를 입력합니다. 예컨대, 5분의 시간이 두 차례 연속되면 경보 상태를 호출하기까지 10분이 걸립니다.
+ **누락 데이터 처리(Missing data treatment)**에서 **누락 데이터를 불량으로 처리(임계값 위반)(Treat missing data as bad (breaching threshold))**를 선택합니다. 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [CloudWatch 경보가 누락된 데이터를 처리하는 방법 구성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)을 참조하세요.
1. **다음**을 선택합니다.
**작업 구성** 페이지가 표시됩니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 Amazon SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거(Remove)**를 선택합니다.
1. **작업 구성(Configure actions)** 페이지의 다른 섹션은 비워둘 수 있습니다. 다른 섹션을 비워 두면 조정 정책에 연결하지 않고도 경보가 생성됩니다. 그런 다음 Amazon EC2 Auto Scaling 콘솔에서 경보를 조정 정책에 연결할 수 있습니다.
1. **다음**을 선택합니다.
1. 경보의 이름(예: `Step-Scaling-AlarmLow-RemoveCapacity`)과 설명(옵션)을 입력하고 **다음(Next)**을 선택합니다.
1. **경보 생성**을 선택하세요.
다음 절차에 따라 CloudWatch 경보를 생성한 후부터 계속 진행합니다.
**2단계: 스케일 인을 위한 단계 조정 정책 생성**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. 스케일링 제한이 적절하게 설정되었는지 확인합니다. 예를 들어 그룹의 원하는 용량이 이미 최소치에 있는 경우, 스케일 인하려면 새로운 최솟값을 지정해야 합니다. 자세한 내용은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 단원을 참조하십시오.
1. **자동 크기 조정(Automatic scaling)** 탭의 **동적 크기 조정 정책(Dynamic scaling policies)**에서 **동적 크기 조정 정책 생성(Create dynamic scaling policy)**을 선택합니다.
1. **정책 유형**에서 **단계 조정**을 선택한 다음 정책의 이름을 지정합니다.
1. **CloudWatch 경보(CloudWatch alarm)**에서 경보를 선택합니다. 경보를 아직 생성하지 않은 경우 **CloudWatch 경보 생성**을 선택하고 이전 절차의 4단계\$114단계까지 완료하여 경보를 생성합니다.
1. **다음 작업을 수행(Take the action)**을 사용하여 이 정책을 실행할 때 적용할 현재 그룹 크기 변경을 지정합니다. 특정 인스턴스 개수 또는 기존 그룹 크기의 백분율을 제거하거나 그룹을 정확한 크기로 설정할 수 있습니다.
예를 들어 그룹의 용량을 두 인스턴스만큼 줄이는 스케일 인 정책을 생성하려면 `Remove`를 선택하고 다음 필드에 `2`를 입력한 후 `capacity units`을 선택합니다. 기본적으로 이 단계별 조정의 상한값은 경보 임계값이고 하한값은 음(-)의 무한대입니다.
1. 다른 단계를 추가하려면 **단계 추가(Add step)**를 선택한 다음 조정할 양과 경보 임계값에 상대적인 단계 하한 및 상한을 정의합니다.
1. **생성(Create)**을 선택합니다.
------
#### [ AWS CLI ]
스케일 인(용량 감소)에 대한 단계 조정 정책을 생성하려면 다음 예제 명령을 사용합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
를 사용하는 경우 AWS CLI먼저 지표 값이 감소할 때 스케일 인하는 방법에 대한 지침을 Amazon EC2 Auto Scaling에 제공하는 단계 조정 정책을 생성합니다. 그런 다음 조사하려는 지표를 식별하여 경보를 생성하고 지표 하한 임곗값과 경보에 대한 기타 세부 정보를 정의한 다음, 해당 경보를 조정 정책과 연결합니다.
**1단계: 스케일 인을 위한 정책 생성**
연결된 CloudWatch 경보가 지표 하한 임계값을 위반하면 다음 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여 그룹 용량을 인스턴스 2개만큼 줄이는 `ChangeInCapacity` 조절 유형으로 `my-step-scale-in-policy`라는 단계별 조정 정책을 생성합니다.
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-in-policy \
--policy-type StepScaling \
--adjustment-type ChangeInCapacity \
--step-adjustments MetricIntervalUpperBound=0.0,ScalingAdjustment=-2
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. 정책에 대한 CloudWatch 경보를 생성하는 데 필요합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:ac542982-cbeb-4294-891c-a5a941dfa787:autoScalingGroupName/my-asg:policyName/my-step-scale-out-policy
}
```
**2단계: 지표 하한 임곗값에 대한 CloudWatch 경보 생성**
CloudWatch [put-metric-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용하여 평균 CPU 임계값 40%를 기준으로 최소 2회 연속 2분간의 평가 기간에 Auto Scaling 그룹의 크기를 줄이라는 경보를 생성합니다. 사용자 지정 지표를 사용하려면 `--metric-name`에 지표 이름을 지정하고, `--namespace`에 네임스페이스를 지정합니다.
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmLow-RemoveCapacity \
--metric-name CPUUtilization --namespace AWS/EC2 --statistic Average \
--period 120 --evaluation-periods 2 --threshold 40 \
--comparison-operator LessThanOrEqualToThreshold \
--dimensions "Name=AutoScalingGroupName,Value=my-asg" \
--alarm-actions PolicyARN
```
------
# 단순 조정 정책
다음 예제에서는 CLI 명령을 사용하여 단순 조정 정책을 생성하는 방법을 보여줍니다. 예제는 이를 사용하려는 모든 고객을 위한 참조로 이 문서에 남아 있지만 대신 대상 추적 또는 단계 조정 정책을 사용하는 것이 좋습니다.
단계 조정 정책과 마찬가지로 단순 조정 정책은 조정 정책에 대한 CloudWatch 경보를 생성해야 합니다. 생성하는 정책에서 인스턴스를 추가 또는 제거할지와 몇 개를 추가 또는 제거할지를 정의하거나 그룹을 정확한 크기로 설정해야 합니다.
단계 조정 정책과 단순 조정 정책의 주요 차이점 중 하나는 단계 조정 정책에서 얻을 수 있는 단계 조정입니다. 단계 조정을 사용하면 지정한 단계 조정을 기반으로 그룹 크기를 더 크게 또는 더 작게 변경할 수 있습니다.
또한 단순 조정 정책은 진행 중인 조정 활동 또는 상태 확인 교체가 완료될 때까지 그리고 추가 경보에 응답하기 전에 [휴지 기간](ec2-auto-scaling-scaling-cooldowns.md)을 기다려야 합니다. 반면 단계 조정에서는 조정 활동 또는 상태 확인 교체가 진행 중인 동안에도 정책이 추가 경보에 계속 응답합니다. 즉 Amazon EC2 Auto Scaling은 경보 메시지를 수신할 때 모든 경보 위반을 평가합니다. 따라서 조정이 하나만 있는 경우에도 단계 조정 정책을 대신 사용하는 것이 좋습니다.
Amazon EC2 Auto Scaling은 초기에 단순 조정 정책만 지원했습니다. 대상 추적 및 단계 조정 정책을 도입하기 전에는 조정 정책을 생성하면 정책이 단순 조정 정책으로 처리되었습니다.
## 스케일 아웃을 위한 단순 조정 정책 생성
연결된 CloudWatch 경보가 지표 상한 임계값을 위반하면 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여 그룹 용량을 30% 늘리는 `PercentChangeInCapacity` 조절 유형으로 `my-simple-scale-out-policy`라는 단순 조정 정책을 생성합니다.
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-out-policy \
--auto-scaling-group-name my-asg --scaling-adjustment 30 \
--adjustment-type PercentChangeInCapacity
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. 정책에 대한 CloudWatch 경보를 생성하는 데 필요합니다.
## 스케일 인을 위한 단순 조정 정책 생성
연결된 CloudWatch 경보가 지표 하한 임계값을 위반하면 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여 그룹 용량을 인스턴스 1개만큼 줄이는 `ChangeInCapacity` 조절 유형으로 `my-simple-scale-in-policy`라는 단순 조정 정책을 생성합니다.
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-in-policy \
--auto-scaling-group-name my-asg --scaling-adjustment -1 \
--adjustment-type ChangeInCapacity --cooldown 180
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. 정책에 대한 CloudWatch 경보를 생성하는 데 필요합니다.
# Amazon EC2 Auto Scaling을 위한 조정 휴지
**중요**
모범 사례로 간단한 조정 정책 및 조정 휴지를 사용하지 않는 것이 좋습니다. 목표 추적 조정 정책 또는 단계별 조정 정책이 성능 조정에 더 좋습니다. 조정 지표의 값이 감소하거나 증가함에 따라 Auto Scaling 그룹 크기를 비례적으로 변경하는 조정 정책의 경우, 단순 조정 또는 단계별 조정보다 [대상 추적](as-scaling-target-tracking.md)을 사용하는 것이 좋습니다.
Auto Scaling 그룹에 대한 간단한 스케일링 정책을 만들 때는 스케일링 쿨다운을 동시에 구성하는 것이 좋습니다.
Auto Scaling 그룹은 인스턴스를 시작하거나 해지한 후 단순 조정 정책에 의해 시작된 추가 조정 활동이 시작되기 전에 냉각 기간이 끝날 때까지 기다립니다. 냉각 기간의 목적은 Auto Scaling 그룹이 안정되도록 하고 이전 조정 활동의 효과가 가시화되기 전에 추가 인스턴스가 시작되거나 해지되는 것을 방지하는 것입니다.
예컨대, CPU 사용률에 대한 간단한 조정 정책에서 두 개의 인스턴스를 시작하도록 권장한다고 가정합니다. Amazon EC2 Auto Scaling은 두 개의 인스턴스를 시작한 다음 냉각 기간이 끝날 때까지 조정 활동을 일시 중지합니다. 냉각 기간이 끝나면 단순 조정 정책에 의해 시작된 모든 조정 활동이 재개될 수 있습니다. CPU 사용률이 다시 경보 상한 임계값을 위반하면 Auto Scaling 그룹이 다시 스케일 아웃되고 냉각 기간이 다시 적용됩니다. 그러나 두 개의 인스턴스로 지표 값을 다시 낮추기에 충분하면 그룹은 현재 크기로 유지됩니다.
**Topics**
+ [고려 사항](#cooldown-considerations)
+ [수명 주기 후크는 추가적 지연을 야기할 수 있습니다.](#cooldowns-lifecycle-hooks)
+ [기본 냉각 기간 변경](#set-default-cooldown)
+ [특정 단순 조정 정책에 대한 냉각 기간 설정](#cooldowns-scaling-specific)
## 고려 사항
단순 조정 정책 및 조정 휴지 작업 시 다음 고려 사항이 적용됩니다.
+ 대상 추적 및 단계별 조정 정책은 냉각 기간이 끝날 때까지 기다리지 않고 즉시 스케일 아웃 활동을 시작할 수 있습니다. 대신 Auto Scaling 그룹이 인스턴스를 시작할 때마다 개별 인스턴스에 워밍업 기간이 있습니다. 자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 단원을 참조하십시오.
+ 스케일 아웃 활동이 진행 중일 때는, 인스턴스의 워밍업이 완료될 때까지 모든 대상 추적 및 단계 조정의 스케일 인 활동이 차단됩니다. Auto Scaling 그룹이 휴지 기간에 있는 경우에도 스케일 인 활동이 지연될 수 있습니다.
+ 예약된 작업이 예약된 시간에 시작되면 냉각 기간이 끝날 때까지 기다리지 않고 즉시 조정 활동을 시작할 수도 있습니다.
+ 인스턴스가 비정상적 상태인 경우, Amazon EC2 Auto Scaling은 냉각 기간이 끝날 때까지 대기하지 않고 비정상적 인스턴스를 교체합니다.
+ 여러 인스턴스가 시작되거나 해지될 때 냉각 기간(기본 휴지 또는 조정 정책별 휴지)은 마지막 인스턴스가 시작 또는 해지될 때부터 적용됩니다.
+ Auto Scaling 그룹을 수동으로 스케일 아웃할 때 기본값은 냉각 기간이 끝날 때까지 기다리지 않는 것입니다. 그러나 AWS CLI 또는 SDK를 사용하여 수동으로 규모를 조정할 때이 동작을 재정의하고 기본 휴지 기간을 준수할 수 있습니다.
+ 기본적으로 Elastic Load Balancing은 등록 취소(Connection Draining) 프로세스를 완료하기 위해 300초 동안 기다립니다. 그룹이 Elastic Load Balancing 로드 밸런서 뒤에 있는 경우, 냉각 기간을 시작하기 전에 해지 인스턴스가 등록 취소될 때까지 기다립니다.
## 수명 주기 후크는 추가적 지연을 야기할 수 있습니다.
[수명 주기 후크](lifecycle-hooks.md)가 호출되면 수명 주기 작업을 완료한 후 또는 제한 시간이 끝난 후 냉각 기간이 시작됩니다. 예컨대, Auto Scaling 그룹에 인스턴스 시작을 위한 수명 주기 후크가 있다고 가정해 봅시다. 애플리케이션에 수요가 증가하면 그룹은 인스턴스를 시작하여 용량을 추가합니다. 수명 주기 후크가 있기 때문에 인스턴스는 대기 상태가 되고 단순 조정 정책으로 인한 크기 조정 활동은 일시 중지됩니다. 인스턴스가 `InService` 상태로 들어가면 냉각 기간이 시작됩니다. 냉각 기간이 끝나면 단순 조정 정책 활동이 재개됩니다.
Elastic Load Balancing이 활성화된 경우, 스케일 인을 위해 종료 대상으로 선택된 인스턴스가 연결 드레이닝(등록 취소 지연)을 시작할 때 휴지 기간이 시작됩니다. 휴지 기간은 연결 드레이닝이 완료되거나 수명 주기 후크가 작업을 완료할 때까지 기다리지 않습니다. 즉 스케일 인 이벤트의 결과가 그룹의 용량에 반영되는 즉시 단순한 조정 정책으로 인한 모든 조정 활동이 재개될 수 있습니다. 그러지 않고 Connection Draining, 수명 주기 후크 및 냉각 기간, 이렇게 세 가지 활동이 모두 완료될 때까지 대기하면 Auto Scaling 그룹에서 크기 조정을 일시 중지하는 데 필요한 시간이 크게 늘어납니다.
## 기본 냉각 기간 변경
Amazon EC2 Auto Scaling 콘솔에서 Auto Scaling 그룹을 처음 생성할 때는 기본 휴지 시간을 설정할 수 없습니다. 기본적으로 냉각 기간은 300초(5분)로 설정됩니다. 필요한 경우, 그룹이 생성된 후 이를 업데이트할 수 있습니다.
**기본 냉각 기간 변경(콘솔)**
Auto Scaling 그룹을 생성한 후 **Details**(세부 정보) 탭에서 **Advanced configurations**(고급 구성), **Edit**(편집)을 선택합니다. **기본 냉각 기간(Default cooldown)**에서 인스턴스 시작 시간 또는 기타 애플리케이션 요건에 따라 원하는 시간을 선택합니다.
**기본 냉각 기간 변경(AWS CLI)**
다음 명령을 사용하여 신규 또는 기존 Auto Scaling 그룹의 기본 냉각 기간을 변경합니다. 기본 냉각 기간이 정의되지 않은 경우, 기본값인 300초가 사용됩니다.
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)
기본 냉각 기간 값을 확인하려면 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용합니다.
## 특정 단순 조정 정책에 대한 냉각 기간 설정
기본적으로 모든 단순 조정 정책은 Auto Scaling 그룹에 대해 정의된 기본 냉각 기간을 사용합니다. 특정 단순 조정 정책에 대한 냉각 기간을 설정하려면 정책을 생성하거나 업데이트할 때 선택적 휴지 파라미터를 사용합니다. 정책에 대한 냉각 기간이 지정되면 기본 냉각 기간이 재정의됩니다.
조정 정책별 휴지 기간의 일반적인 용도 중 하나는 스케일 인 정책입니다. 이 정책이 인스턴스를 해지하기 때문에 Amazon EC2 Auto Scaling은 추가 인스턴스를 해지할지를 결정하는 데 더 적은 시간이 소요됩니다. 인스턴스를 해지하는 것은 인스턴스를 시작하는 것보다 훨씬 빠른 작업이어야 합니다. 따라서 기본 냉각 기간인 300초가 너무 깁니다. 이 경우, 스케일 인 정책에 낮은 값의 조정 정책별 휴지 기간을 적용하면 그룹이 더 빨리 스케일 인되므로 비용을 절감할 수 있습니다.
콘솔에서 단순 조정 정책을 생성하거나 업데이트하려면 그룹을 생성한 후 **자동 조정(Automatic scaling)** 탭을 선택합니다. 를 사용하여 단순 조정 정책을 생성하거나 업데이트하려면 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 AWS CLI사용합니다. 자세한 내용은 [단계별 조정 및 단순 조정 정책](as-scaling-simple-step.md) 단원을 참조하십시오.
# Amazon SQS 기반 조정 정책
**중요**
다음 정보 및 단계는 CloudWatch에 사용자 지정 지표로 게시하기 전에 `ApproximateNumberOfMessages` 대기열 속성을 사용하여 인스턴스당 Amazon SQS 대기열 백로그를 계산하는 방법을 보여줍니다. 하지만 이제 지표 수학을 사용하여 자체 지표를 게시하는 데 드는 비용과 노력을 줄일 수 있습니다. 자세한 내용은 [지표 수식을 사용하여 대상 추적 조정 정책 생성](ec2-auto-scaling-target-tracking-metric-math.md) 단원을 참조하십시오.
Amazon Simple Queue Service(Amazon SQS) 대기열의 시스템 부하 변화에 대응해 Auto Scaling 그룹을 스케일링할 수 있습니다. Amazon SQS를 사용하는 방법에 대한 자세한 설명은 [Amazon Simple Queue Service 개발자 안내서](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)를 참조하세요.
Amazon SQS 대기열의 활동에 따라 조정에 대해 고려할 경우, 다음과 같은 여러 시나리오가 있습니다. 사용자가 이미지를 업로드하고 그러한 이미지를 온라인으로 사용하는 웹 앱을 예로 들어 보겠습니다. 이 시나리오에서 각 이미지를 게시하려면 먼저 크기를 변경하고 인코딩해야 합니다. 이 앱은 Auto Scaling 그룹에서 EC2 인스턴스를 시작하며 일반적인 업로드 속도를 처리하도록 구성됩니다. 인스턴스 수준을 항상 최신으로 유지하기 위해 비건전 인스턴스는 해지되고 교체됩니다. 앱은 이미지의 원시 비트맵 데이터를 처리하기 위해 SQS 대기열에 배치합니다. 그리고 이미지를 처리한 후, 사용자가 볼 수 있는 처리된 이미지를 게시합니다. 이 시나리오의 아키텍처는 이미지 업로드 수가 항상 일정할 경우, 잘 작동합니다. 그러나 시간이 지남에 따라 업로드 수가 변경되는 경우, 동적 조정을 사용하여 Auto Scaling 그룹 용량의 조정을 고려할 수 있습니다.
**Topics**
+ [올바른 지표에 대상 추적 사용](#scale-sqs-queue-custom-metric)
+ [제한 사항](#scale-sqs-queue-limitations)
+ [Amazon SQS 기반 크기 조정 구성](scale-sqs-queue-cli.md)
+ [Amazon SQS 및 인스턴스 스케일 인 방비](#scale-sqs-queue-scale-in-protection)
## 올바른 지표에 대상 추적 사용
사용자 지정 Amazon SQS 대기열 지표에 근거하여 대상 추적 조정 정책을 사용하는 경우, 애플리케이션의 수요 곡선에 맞게 보다 효과적으로 동적 조정을 수행할 수 있습니다. 대상 추적에 대한 지표 선택에 대한 자세한 설명은 [지표 선택](as-scaling-target-tracking.md#target-tracking-choose-metrics) 섹션을 참조하세요.
대상 추적용 `ApproximateNumberOfMessagesVisible`과 같이 CloudWatch Amazon SQS 지표를 사용할 때의 문제는 대기열의 메시지 수가 대기열에서 메시지를 처리하는 Auto Scaling 그룹의 크기에 비례하여 변경되지 않을 수 있다는 것입니다. SQS 대기열의 메시지 수가 필요한 인스턴스 수를 단독으로 정의하지는 않습니다. 하지만 Auto Scaling 그룹의 인스턴스 수는 메시지를 처리하는 데 걸리는 시간이나 허용되는 지연 시간(대기열 지연) 등과 같은 여러 요인의 영향을 받을 수 있습니다.
해결 방법은 *인스턴스당 백로그* 지표와 목표값을 사용하여 *인스턴스당 허용 백로그*를 유지하는 것입니다. 이 값은 다음과 같이 계산할 수 있습니다.
+ **인스턴스당 백로그**: 인스턴스당 백로그를 계산하려면 `ApproximateNumberOfMessages` 대기열 속성을 사용하여 SQS 대기열의 길이(대기열에서 검색할 수 있는 메시지 수)를 확인합니다. 이 값을 플릿의 실행 용량(Auto Scaling 그룹에서 상태가 `InService`인 인스턴스 수)으로 나눠서 인스턴스당 백로그를 산출합니다.
+ **인스턴스당 허용되는 백로그**: 목표값을 계산하려면 먼저 애플리케이션에서 허용할 수 있는 지연 시간을 확인하세요. 그런 다음 이 허용 지연 시간 값을, EC2 인스턴스가 메시지를 처리하기 위해 소요하는 평균 시간으로 나눕니다.
예컨대, 현재 인스턴스 10개로 구성된 Auto Scaling 그룹이 있고, 대기열(`ApproximateNumberOfMessages`)에 표시되는 메시지 수가 1,500개라고 가정해 보겠습니다. 각 메시지의 평균 처리 시간이 0.1초이고 가장 긴 허용 지연 시간이 10초인 경우, 인스턴스당 허용 가능한 백로그는 10/0.1인 100개의 메시지입니다. 즉, 목표 추적 정책의 목표값은 100입니다. 인스턴스당 백로그가 목표 값에 도달하면 스케일 아웃 이벤트가 발생합니다. 인스턴스당 백로그가 이미 150개의 메시지(1,500개의 메시지/10개의 인스턴스)이므로 그룹이 스케일 아웃되고 5개의 인스턴스를 추가하여 목표 값 백분율을 유지합니다.
다음 절차에서는 사용자 지정 지표를 게시하고 이러한 계산에 따라 Auto Scaling 그룹을 조정하도록 구성하는 대상 추적 조정 정책을 생성하는 방법을 보여줍니다.
**중요**
비용을 절감하기 위해서는 지표 수학을 사용해야 한다는 점을 기억하세요. 자세한 설명은 [지표 수식을 사용하여 대상 추적 조정 정책 생성](ec2-auto-scaling-target-tracking-metric-math.md) 섹션을 참조하세요.
이러한 구성을 위해 세 가지 방법을 사용할 수 있습니다.
+ SQS 대기열의 메시지를 처리하기 위해 EC2 인스턴스를 관리하는 Auto Scaling 그룹.
+ Auto Scaling 그룹의 EC2 인스턴스당 대기열의 메시지 수를 측정하여 Amazon CloudWatch로 전송되는 사용자 지정 지표.
+ 사용자 지정 지표와 설정된 목푯값에 따라 크기를 조정하도록 Auto Scaling 그룹을 구성하는 대상 추적 정책. CloudWatch 경보는 조정 정책을 호출합니다.
다음 다이어그램은 이 구성의 아키텍처를 보여 줍니다.
![\[대기열 아키텍처 다이어그램을 사용한 Amazon EC2 Auto Scaling\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)
## 제한 사항
사용자 지정 지표를 CloudWatch에 게시하려면 AWS CLI 또는 SDK를 사용해야 합니다. 그런 다음를 사용하여 지표를 모니터링할 수 있습니다 AWS Management Console.
다음 섹션에서는 수행해야 하는 작업에 AWS CLI 를 사용합니다. 예컨대, 대기열의 현재 사용을 반영하는 지표 데이터를 가져오려면 SQS [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html) 명령을 사용합니다.
# Amazon SQS 기반 크기 조정 구성
다음 절차는 Amazon SQS 기반 자동 규모 조정을 구성하는 방법을 설명합니다. CloudWatch 사용자 지정 지표를 생성하는 방법,를 사용하여 대상 추적 정책을 설정하는 방법 AWS CLI, 구성을 테스트하는 방법을 알아봅니다.
시작하기 전에 AWS CLI [를 설치하고](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)했는지 확인합니다. 또한 사용할 Amazon SQS 대기열이 있어야 합니다. 다음 작업에서는 대기열(표준 또는 FIFO), Auto Scaling 그룹, 대기열을 사용하는 애플리케이션에서 실행 중인 EC2 인스턴스가 이미 있는 것으로 가정합니다.
Amazon SQS에 대한 자세한 설명은 [Amazon Simple Queue Service 개발자 안내서](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)를 참조하세요.
**Topics**
+ [1단계: CloudWatch 사용자 지정 지표 생성](#create-sqs-cw-alarms-cli)
+ [2단계: 대상 추적 조정 정책 생성](#create-sqs-policies-cli)
+ [3단계: 조정 정책 테스트](#validate-sqs-scaling-cli)
## 1단계: CloudWatch 사용자 지정 지표 생성
사용자 지정 지표는 지표 이름과 선택한 네임스페이스를 사용하여 정의됩니다. 사용자 지정 지표를 위한 네임스페이스는 `AWS/`로 시작할 수 없습니다. 사용자 지정 지표 게시에 대한 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 주제를 참조하세요.
다음 절차에 따라 AWS 먼저 계정에서 정보를 읽어 사용자 지정 지표를 생성합니다. 그런 다음, 앞 섹션 에서 권장한 인스턴스당 백로그 지표를 계산합니다. 마지막으로 이 수치를 1분 단위로 CloudWatch에 게시합니다. 가능하면 시스템 로드 변화에 빠르게 대응할 수 있도록 1분 단위로 지표를 조정하는 것이 좋습니다.
**CloudWatch 사용자 지정 지표(AWS CLI)를 생성하려면**
1. SQS [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html) 명령을 사용하여 대기열에서 대기 중인 메시지 수(`ApproximateNumberOfMessages`)를 확인합니다.
```
aws sqs get-queue-attributes --queue-url https://sqs.region.amazonaws.com/123456789/MyQueue \
--attribute-names ApproximateNumberOfMessages
```
1. [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하여 그룹의 실행 용량을 가져올 수 있습니다. 이 용량은 수명 주기 상태가 `InService`인 인스턴스 수입니다. 이 명령은 Auto Scaling 그룹의 인스턴스와 해당 수명 주기 상태를 반환합니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg
```
1. 대기열에서 검색할 수 있는 대략적인 메시지 수를 그룹의 실행 용량으로 나누어 인스턴스당 백로그를 계산합니다.
1. 1분마다 실행되는 스크립트를 만들어 인스턴스당 백로그 값을 검색하고 이를 CloudWatch 사용자 지정 지표에 게시합니다. 사용자 지정 지표를 게시할 때 지표의 이름, 네임스페이스, 단위, 값 및 0개 이상의 차원을 지정합니다. 차원은 차원 이름과 차원 값으로 구성됩니다.
사용자 지정 지표를 게시하려면 *이탤릭체*로 표시된 자리 표시자 값을 원하는 지표 이름, 지표의 값, 네임스페이스("`AWS`"로 시작하지 않는 한) 및 차원(옵션)으로 바꾼 다음 다음 [put-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-data.html) 명령을 실행합니다.
```
aws cloudwatch put-metric-data --metric-name MyBacklogPerInstance --namespace MyNamespace \
--unit None --value 20 --dimensions MyOptionalMetricDimensionName=MyOptionalMetricDimensionValue
```
애플리케이션에서 해당 지표를 생성하면 데이터가 CloudWatch로 전송됩니다. 이 지표는 CloudWatch 콘솔에 표시됩니다. 에 로그인 AWS Management Console 하고 CloudWatch 페이지로 이동하여 액세스할 수 있습니다. 그런 다음 지표 페이지로 이동하거나 검색 상자에서 검색하여 지표를 볼 수 있습니다. 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [사용 가능한 지표 보기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)를 참조하세요.
## 2단계: 대상 추적 조정 정책 생성
이제 생성한 지표를 대상 추적 스케일링 정책에 추가할 수 있습니다.
**대상 추적 조정 정책(AWS CLI)을 생성하려면**
1. 다음 `cat` 명령을 사용하여 홈 디렉터리에 `config.json`라는 명칭의 JSON 파일에 조정 정책에 대한 목표값을 저장하고 사용자 지정 지표 사양을 지정합니다. *user input placeholder*를 사용자의 정보로 바꿉니다. `TargetValue`에, 인스턴스당 허용 백로그 지표를 계산하여 입력합니다. 이 값을 계산하려면 이전 섹션에서 설명한 대로 보통 지연 시간 값을 확인하여, 이 값을 메시지를 처리하는 데 걸리는 평균 시간으로 나눕니다.
1단계에서 만든 지표에 대해 어떤 차원도 지정하지 않았다면 사용자 지정 지표 사양에 어떤 차원도 포함하지 마세요.
```
$ cat ~/config.json
{
"TargetValue":100,
"CustomizedMetricSpecification":{
"MetricName":"MyBacklogPerInstance",
"Namespace":"MyNamespace",
"Dimensions":[
{
"Name":"MyOptionalMetricDimensionName",
"Value":"MyOptionalMetricDimensionValue"
}
],
"Statistic":"Average",
"Unit":"None"
}
}
```
1. [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령과 이전 단계에서 만든 `config.json` 파일을 사용하여 조정 정책을 생성합니다.
```
aws autoscaling put-scaling-policy --policy-name sqs100-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://~/config.json
```
이 정책은 스케일 아웃과 축소에 대해 한 개씩 두 개의 경보를 생성합니다. 또한 CloudWatch에 등록된 정책의 Amazon 리소스 이름(ARN)을 반환합니다. CloudWatch는 지표 임계값이 위반될 때마다 이 이름을 사용하여 조정 기능을 호출합니다.
## 3단계: 조정 정책 테스트
설정을 마친 후, 조정 정책이 작동하는지 확인합니다. SQS 대기열의 메시지 수를 늘린 다음 Auto Scaling 그룹에서 추가 EC2 인스턴스를 시작했는지 확인하여 테스트할 수 있습니다. 또한 SQS 대기열의 메시지 수를 줄인 다음 Auto Scaling 그룹에서 EC2 인스턴스를 해지했는지 확인하여 테스트할 수 있습니다.
**스케일 아웃 기능을 테스트하려면**
1. 대기열에 메시지를 추가하려면 [Amazon SQS 표준 대기열 생성 및 메시지 전송](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/creating-sqs-standard-queues.html) 또는 [Amazon SQS FIFO 대기열 생성 및 메시지 전송](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/creating-sqs-fifo-queues.html)의 단계를 따릅니다. 인스턴스당 백로그 지표가 목표값을 초과하도록 대기열의 메시지 수를 늘려야 합니다.
변경 사항에 따라 경보를 호출하기까지 몇 분 정도 걸릴 수 있습니다.
1. [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하여 그룹에서 인스턴스를 시작했는지 확인합니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
**스케일 인 기능을 테스트하려면**
1. 대기열에서 메시지를 삭제하려면 [메시지 받기 및 삭제(콘솔)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/step-receive-delete-message.html)의 단계를 따릅니다. 인스턴스당 백로그 지표가 목표값 미만이 되도록 대기열의 메시지 수를 줄여야 합니다.
변경 사항에 따라 경보를 호출하기까지 몇 분 정도 걸릴 수 있습니다.
1. [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하여 그룹에서 인스턴스를 해지했는지 확인합니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
## Amazon SQS 및 인스턴스 스케일 인 방비
인스턴스를 해지할 때 처리되지 않은 메시지는 아직 실행 중인 인스턴스에서 처리할 수 있도록 SQS 대기열에 반환됩니다. 오래 실행 중인 작업을 수행하는 애플리케이션의 경우, 인스턴스 스케일 인 방비를 선택적으로 사용하여 Auto Scaling 그룹이 축소될 때 어떤 대기열 작업자를 해지할지 제어할 수 있습니다.
다음 유사 코드는 오래 실행되는 대기열 기반 작업자 프로세스가 축소 시 해지되지 않도록 방지하는 한 가지 방법을 보여 줍니다.
```
while (true)
{
SetInstanceProtection(False);
Work = GetNextWorkUnit();
SetInstanceProtection(True);
ProcessWorkUnit(Work);
SetInstanceProtection(False);
}
```
자세한 설명은 [인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md) 섹션을 참조하세요.
# Auto Scaling 그룹에 대한 크기 조정 활동 확인
Amazon EC2 콘솔의 Amazon EC2 Auto Scaling 섹션에서 Auto Scaling 그룹의 **Activity history**(활동 기록)를 통해 현재 진행 중인 크기 조정 활동의 현재 상태를 볼 수 있습니다. 크기 조정 활동이 완료되면 성공 여부를 확인할 수 있습니다. 이는 Auto Scaling 그룹을 생성하거나 기존 그룹에 조정 조건을 추가할 때 특히 유용합니다.
대상 추적, 단계 또는 단순 조정 정책을 Auto Scaling 그룹에 추가하면 Amazon EC2 Auto Scaling이 지표에 대한 정책 평가를 즉시 시작합니다. 지표가 지정된 수의 평가 기간에 대한 임계값을 위반할 경우, 지표 경보가 ALARM(경보) 상태가 됩니다. 이는 크기 조정 정책이 생성된 직후 크기 조정 활동으로 이어질 수 있음을 의미합니다. Amazon EC2 Auto Scaling이 조정 정책에 응답하여 원하는 용량을 조정한 후 계정에서 크기 조정 활동을 확인할 수 있습니다. Amazon EC2 Auto Scaling으로부터 크기 조정 활동에 대해 알리는 이메일 알림을 받으려면 [Amazon EC2 Auto Scaling에 대한 Amazon SNS 알림 옵션](ec2-auto-scaling-sns-notifications.md)의 지침을 따르세요.
**작은 정보**
다음 절차에서는 Auto Scaling 그룹에 대한 **Activity history**(활동 기록) 및 **Instances**(인스턴스) 섹션을 살펴봅니다. 두 섹션 모두에 명명된 열이 이미 표시되어 있어야 합니다. 숨겨진 열을 표시하거나 표시되는 행 수를 변경하려면 각 섹션의 오른쪽 상단에 있는 톱니바퀴 아이콘을 선택하여 기본 설정 모달을 열고 필요에 따라 설정을 업데이트한 다음 **확인**을 선택합니다.
**Auto Scaling 그룹의 크기 조정 활동 보기(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹이 들어있는 지역을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Activity**(활동) 탭에서 **Activity history**(활동 기록)의 **Status**(상태) 열에 Auto Scaling 그룹이 성공적으로 인스턴스를 시작 또는 해지했는지와 크기 조정 활동이 아직 진행 중인지 여부가 표시됩니다.
1. (옵션) 크기 조정 활동이 많은 경우, 활동 기록 상단 가장자리의 **>** 아이콘을 선택하여 크기 조정 활동의 다음 페이지를 볼 수 있습니다.
1. **인스턴스 관리** 탭의 **인스턴스**에서 **수명 주기** 열은 인스턴스의 상태를 포함합니다. 인스턴스가 시작되고 모든 수명 주기 후크가 완료되면 해당 수명 주기 상태가 `InService`로 변경됩니다. **건전성 체크** 열에 해당 인스턴스에 대한 EC2 인스턴스 건전성 체크 결과가 표시됩니다.
**Auto Scaling 그룹의 크기 조정 활동 보기(AWS CLI)**
다음 [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) 명령을 사용합니다.
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
다음은 예제 출력입니다.
크기 조정 활동은 시작 시간으로 정렬됩니다. 아직 진행 중인 활동이 먼저 설명됩니다.
```
{
"Activities": [
{
"ActivityId": "5e3a1f47-2309-415c-bfd8-35aa06300799",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-06c4794c2499af1df",
"Cause": "At 2020-02-11T18:34:10Z a monitor alarm TargetTracking-my-asg-AlarmLow-b9376cab-18a7-4385-920c-dfa3f7783f82 in state ALARM triggered policy my-target-tracking-policy changing the desired capacity from 3 to 2. At 2020-02-11T18:34:31Z an instance was taken out of service in response to a difference between desired and actual capacity, shrinking the capacity from 3 to 2. At 2020-02-11T18:34:31Z instance i-06c4794c2499af1df was selected for termination.",
"StartTime": "2020-02-11T18:34:31.268Z",
"EndTime": "2020-02-11T18:34:53Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn"
},
...
]
}
```
출력의 필드에 대한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [활동](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_Activity.html)을 참조하세요.
삭제된 그룹에 대한 조정 활동 검색, 발생할 수 있는 오류 유형 및 이를 처리하는 방법에 대한 자세한 설명은 [Amazon EC2 Auto Scaling의 문제 해결](CHAP_Troubleshooting.md)을 참조하세요.
# Auto Scaling 그룹에 대한 조정 정책 비활성화
이 항목에서는 Auto Scaling 그룹에 포함된 인스턴스 수를 변경하지 않도록 조정 정책을 일시적으로 비활성화하는 방법을 설명합니다. 조정 정책을 비활성화하면 구성 세부 정보가 보존되므로 정책을 신속하게 다시 활성화할 수 있습니다. 이는 필요하지 않을 때 일시적으로 정책을 삭제했다가 나중에 다시 생성하는 것보다 쉽습니다.
조정 정책을 비활성화하면 조정 정책이 비활성화된 동안 위반된 지표 경보에 대해 Auto Scaling 그룹이 스케일 아웃 또는 축소되지 않습니다. 그러나 진행 중인 크기 조정 활동은 중지되지 않습니다.
비활성화된 조정 정책도 Auto Scaling 그룹에 추가할 수 있는 조정 정책 수 할당량에 포함됩니다.
**조정 정책을 비활성화하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **자동 크기 조정(Automatic scaling)** 탭의 **동적 조정 정책(Dynamic scaling policies)**에서 원하는 조정 정책의 오른쪽 상단에 있는 확인란을 선택합니다.
1. **동적 조정 정책(Dynamic scaling policies)** 섹션의 맨 위로 스크롤하고 **작업(Actions)**, **사용 중지(Disable)**를 선택합니다.
조정 정책을 다시 활성화할 준비가 되면 이러한 단계를 반복한 다음 **작업**, **활성화**를 선택합니다. 조정 정책을 다시 활성화한 후 현재 ALARM(경보) 상태에 있는 경보가 있으면 Auto Scaling 그룹이 즉시 조정 작업을 시작할 수 있습니다.
**조정 정책을 비활성화하려면(AWS CLI)**
[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여`--no-enabled` 옵션을 다음과 같이 설정합니다. 정책을 생성할 때 지정하는 대로 명령에서 모든 옵션을 지정합니다.
```
aws autoscaling put-scaling-policy --auto-scaling-group-name my-asg \
--policy-name my-scaling-policy --policy-type TargetTrackingScaling \
--estimated-instance-warmup 360 \
--target-tracking-configuration '{ "TargetValue": 70, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" } }' \
--no-enabled
```
**조정 정책을 다시 활성화하려면(AWS CLI)**
[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여`--enabled` 옵션을 다음과 같이 설정합니다. 정책을 생성할 때 지정하는 대로 명령에서 모든 옵션을 지정합니다.
```
aws autoscaling put-scaling-policy --auto-scaling-group-name my-asg \
--policy-name my-scaling-policy --policy-type TargetTrackingScaling \
--estimated-instance-warmup 360 \
--target-tracking-configuration '{ "TargetValue": 70, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" } }' \
--enabled
```
**조정 정책을 설명하려면(AWS CLI)**
[describe-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-policies.html) 명령을 사용하여 조정 정책의 활성화 상태를 확인합니다.
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg \
--policy-names my-scaling-policy
```
다음은 예제 출력입니다.
```
{
"ScalingPolicies": [
{
"AutoScalingGroupName": "my-asg",
"PolicyName": "my-scaling-policy",
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:1d52783a-b03b-4710-bb0e-549fd64378cc:autoScalingGroupName/my-asg:policyName/my-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"StepAdjustments": [],
"Alarms": [
{
"AlarmName": "TargetTracking-my-asg-AlarmHigh-9ca53fdd-7cf5-4223-938a-ae1199204502",
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-9ca53fdd-7cf5-4223-938a-ae1199204502"
},
{
"AlarmName": "TargetTracking-my-asg-AlarmLow-7010c83d-d55a-4a7a-abe0-1cf8b9de6d6c",
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-7010c83d-d55a-4a7a-abe0-1cf8b9de6d6c"
}
],
"TargetTrackingConfiguration": {
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"TargetValue": 70.0,
"DisableScaleIn": false
},
"Enabled": true
}
]
}
```
# Auto Scaling 그룹에 대한 조정 정책 삭제
더 이상 필요 없는 조정 정책은 삭제할 수 있습니다. 조정 정책의 유형에 따라 CloudWatch 경보를 삭제해야 할 수도 있습니다. 대상 추적 조정 정책을 삭제하면 관련된 모든 CloudWatch 경보도 삭제됩니다. 단계별 조정 정책 또는 단순 조정 정책을 삭제하면 기본 경보 작업이 삭제되지만 연결된 작업이 더 이상 없는 경우에도 CloudWatch 경보는 삭제되지 않습니다.
**조정 정책을 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **자동 크기 조정(Automatic scaling)** 탭의 **동적 조정 정책(Dynamic scaling policies)**에서 원하는 조정 정책의 오른쪽 상단에 있는 확인란을 선택합니다.
1. **동적 조정 정책(Dynamic scaling policies)** 섹션의 맨 위로 스크롤하고 **작업(Actions)**, **삭제(Delete)**를 선택합니다.
1. 확인 메시지가 나타나면 **Yes, Delete(예, 삭제합니다)**를 선택합니다.
1. (옵션) 단계별 조정 정책 또는 단순 조정 정책을 삭제한 경우, 다음을 수행하여 정책과 연관된 CloudWatch 경보를 삭제하세요. 나중에 사용할 수 있도록 경보를 유지하려면 다음 하위 단계를 건너뛸 수 있습니다.
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **Alarms(경보)**를 선택합니다.
1. 경보(예: `Step-Scaling-AlarmHigh-AddCapacity`)를 선택하고 **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 **삭제**를 선택합니다.
**Auto Scaling 그룹에 대한 조정 정책 가져오기(AWS CLI)**
조정 정책을 삭제하기 전에 [describe-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-policies.html) 명령을 사용하여 Auto Scaling 그룹에 대해 생성된 조정 정책을 확인합니다. 정책 및 CloudWatch 경보를 삭제할 때 이 출력을 사용할 수 있습니다.
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg
```
`--query` 파라미터를 사용하여 조정 정책 유형별로 결과를 필터링할 수 있습니다. `query`에 대한 이 구문은 Linux 또는 macOS에서만 작동합니다. Windows에서는 작은따옴표를 큰따옴표로 변경합니다.
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg
--query 'ScalingPolicies[?PolicyType==`TargetTrackingScaling`]'
```
다음은 예제 출력입니다.
```
[
{
"AutoScalingGroupName": "my-asg",
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyARN": "PolicyARN",
"PolicyType": "TargetTrackingScaling",
"StepAdjustments": [],
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
],
"TargetTrackingConfiguration": {
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"TargetValue": 50.0,
"DisableScaleIn": false
},
"Enabled": true
}
]
```
**조정 정책을 삭제하려면(AWS CLI)**
다음 [delete-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-policy.html) 명령을 사용합니다.
```
aws autoscaling delete-policy --auto-scaling-group-name my-asg \
--policy-name cpu50-target-tracking-scaling-policy
```
**CloudWatch 경보를 삭제하려면(AWS CLI)**
단계별 조정 및 단순 조정 정책의 경우, [delete-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html) 명령을 사용하여 정책과 관련된 CloudWatch 경보를 삭제하세요. 나중에 경보를 사용하려면 이 단계를 건너뛸 수 있습니다. 한 번에 하나 이상 경보를 삭제할 수 있습니다. 예컨대, 다음 명령을 사용하여 `Step-Scaling-AlarmHigh-AddCapacity` 및 `Step-Scaling-AlarmLow-RemoveCapacity` 경보를 삭제합니다.
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-AddCapacity Step-Scaling-AlarmLow-RemoveCapacity
```
# 에 대한 조정 정책 예제 AWS CLI
( AWS Management Console AWS Command Line Interface AWS CLI) 또는 SDK를 통해 Amazon EC2 Auto Scaling에 대한 조정 정책을 생성할 수 있습니다. SDKs
다음 예제에서는 the AWS CLI [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 사용하여 Amazon EC2 Auto Scaling에 대한 조정 정책을 생성하는 방법을 보여줍니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
를 사용하여 조정 정책 작성을 시작하려면 [대상 추적 조정 정책](as-scaling-target-tracking.md) 및의 소개 연습을 AWS CLI참조하세요[단계별 조정 및 단순 조정 정책](as-scaling-simple-step.md).
**예 1: 사전 정의된 지표 사양을 사용하여 대상 추적 조정 정책 적용**
```
aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}
```
자세한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)을 참조하세요.
**참고**
파일이 현재 디렉터리에 없는 경우 파일의 전체 경로를 입력합니다. 파일에서 AWS CLI 파라미터 값을 읽는 방법에 대한 자세한 내용은 AWS Command Line Interface 사용 설명서의 [파일에서 파라미터 로드를 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html) 참조하세요.
**예 2: 사용자 지정된 지표 사양을 사용하여 대상 추적 조정 정책 적용**
```
aws autoscaling put-scaling-policy --policy-name sqs100-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 100.0,
"CustomizedMetricSpecification": {
"MetricName": "MyBacklogPerInstance",
"Namespace": "MyNamespace",
"Dimensions": [{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}],
"Statistic": "Average",
"Unit": "None"
}
}
```
자세한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [CustomizedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CustomizedMetricSpecification.html)을 참조하세요.
**예 3: 스케일 아웃을 위한 대상 추적 조정 정책 적용**
```
aws autoscaling put-scaling-policy --policy-name alb1000-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 1000.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff"
},
"DisableScaleIn": true
}
```
**예 4: 스케일 아웃을 위한 단계별 조정 정책 적용**
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-out-policy \
--policy-type StepScaling \
--adjustment-type PercentChangeInCapacity \
--metric-aggregation-type Average \
--step-adjustments MetricIntervalLowerBound=10.0,MetricIntervalUpperBound=20.0,ScalingAdjustment=10 \
MetricIntervalLowerBound=20.0,MetricIntervalUpperBound=30.0,ScalingAdjustment=20 \
MetricIntervalLowerBound=30.0,ScalingAdjustment=30 \
--min-adjustment-magnitude 1
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. CloudWatch 경보를 생성할 때 ARN이 필요합니다.
**예 5: 축소를 위한 단계별 조정 정책 적용**
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-in-policy \
--policy-type StepScaling \
--adjustment-type ChangeInCapacity \
--step-adjustments MetricIntervalUpperBound=0.0,ScalingAdjustment=-2
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. CloudWatch 경보를 생성할 때 ARN이 필요합니다.
**예 6: 스케일 아웃을 위한 단순 조정 정책 적용**
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-out-policy \
--auto-scaling-group-name my-asg --scaling-adjustment 30 \
--adjustment-type PercentChangeInCapacity --min-adjustment-magnitude 2
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. CloudWatch 경보를 생성할 때 ARN이 필요합니다.
**예 7: 축소를 위한 단순 조정 정책 적용**
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-in-policy \
--auto-scaling-group-name my-asg --scaling-adjustment -1 \
--adjustment-type ChangeInCapacity --cooldown 180
```
역할의 Amazon 리소스 이름(ARN)을 기록합니다. CloudWatch 경보를 생성할 때 ARN이 필요합니다.
# Amazon EC2 Auto Scaling의 예측 조정
예측 조정은 과거 로드 데이터를 분석하여 트래픽 흐름의 일별 또는 주별 패턴을 탐지하는 방식으로 작동합니다. 이 정보를 사용하여 향후 용량 요구를 예측하므로 Amazon EC2 Auto Scaling은 예상 부하에 맞춰 Auto Scaling 그룹의 용량을 사전에 늘릴 수 있습니다.
예측 조정은 다음과 같은 상황에 매우 적합합니다.
+ 주기적 트래픽(예: 정규 업무 시간 동안 리소스 사용량이 많고 저녁 및 주말에는 리소스가 적게 사용되는 경우)
+ 반복적인 온/오프 워크로드 패턴(예: 배치 처리, 테스트 또는 주기적 데이터 분석)
+ 초기화하는 데 시간이 오래 걸려 스케일 아웃 이벤트 중에 애플리케이션 성능에 눈에 띄는 지연 영향을 받는 애플리케이션
일반적으로 규칙적인 트래픽 증가 패턴과 초기화하는 데 시간이 오래 걸리는 애플리케이션이 있는 경우, 예측 조정 사용을 고려해야 합니다. 예측 조정을 사용하면 본질적으로 대응적인 동적 크기 조정만 사용하는 것에 비해 예상된 로드 전에 용량을 시작하여 더 빠르게 크기를 조정할 수 있습니다. 또한 예측 조정은 용량을 과도하게 프로비저닝할 필요가 없게 하여 EC2 청구 비용을 절감할 수 있습니다.
예컨대, 업무 시간 중에는 사용량이 많고 밤새 사용량이 줄어드는 애플리케이션을 생각해 보겠습니다. 각 영업일이 시작될 때 예측 조정은 트래픽이 처음 유입되기 전에 용량을 추가할 수 있습니다. 이를 통해 사용률이 낮은 기간에서 높은 기간으로 전환될 때 애플리케이션이 고가용성과 성능을 유지할 수 있습니다. 동적 조정이 변화하는 트래픽에 대응할 때까지 기다릴 필요가 없습니다. 또한 애플리케이션의 로드 패턴을 검토하고 예약된 스케일 아웃을 사용하여 적절한 용량을 예약하는 데 시간을 할애할 필요가 없습니다.
**Topics**
+ [예측 조정의 작동 방식](predictive-scaling-policy-overview.md)
+ [예측 조정 정책 생성](predictive-scaling-create-policy.md)
+ [예측적 조정 정책 평가](predictive-scaling-graphs.md)
+ [예측 재정의](predictive-scaling-overriding-forecast-capacity.md)
+ [사용자 정의 지표 사용](predictive-scaling-customized-metric-specification.md)
# 예측 조정의 작동 방식
이 주제에서는 예측 조정의 작동 방식과 예측 조정 정책을 생성할 때 고려해야 할 사항을 설명합니다.
**Topics**
+ [작동 방식](#how-predictive-scaling-works)
+ [최대 용량 제한](#predictive-scaling-maximum-capacity-limit)
+ [고려 사항](#predictive-scaling-considerations)
+ [지원되는 지역](#predictive-scaling-regions)
## 작동 방식
예측 조정을 사용하려면 모니터링 및 분석할 CloudWatch 지표를 지정하는 예측 조정 정책을 생성합니다. 예측 조정이 미래 값 예측을 시작하려면 이 지표에 24시간 이상의 데이터가 있어야 합니다.
정책을 생성한 후 예측 조정은 패턴을 식별하기 위해 지난 14일까지의 지표 데이터를 분석하기 시작합니다. 이 분석을 사용하여 향후 48시간의 용량 요건에 대한 시간별 예측을 생성합니다. 예측은 최신 CloudWatch 데이터를 사용하여 6시간마다 업데이트됩니다. 새로운 데이터가 들어오면 예측 조정을 통해 향후 예측의 정확도를 지속적으로 개선할 수 있습니다.
예측 조정을 처음 활성화하면 *예측 전용* 모드에서 실행됩니다. 이 모드에서는 용량 예측을 생성하지만 이러한 예측을 기반으로 Auto Scaling 그룹을 실제로 조정하지는 않습니다. 이를 통해 예측의 정확성과 적합성을 평가할 수 있습니다. `GetPredictiveScalingForecast` API 작업 또는 AWS Management Console을 사용하여 예측 데이터를 볼 수 있습니다.
예측 데이터를 검토하고 해당 데이터를 기반으로 조정을 시작하기로 결정한 후에 조정 정책을 *예측 및 조정* 모드로 전환합니다. 이 모드에서는 다음을 수행합니다.
+ 예측에서 부하가 증가할 것으로 예상되는 경우 Amazon EC2 Auto Scaling은 스케일 아웃을 통해 용량을 늘립니다.
+ 예측에서 부하가 감소할 것으로 예상되는 경우 용량을 제거하기 위해 스케일 인하지 않습니다. 더 이상 필요하지 않은 용량을 제거하려면 동적 조정 정책을 생성해야 합니다.
기본적으로 Amazon EC2 Auto Scaling은 해당 시간의 예측을 기반으로 매 시간 시작 시 Auto Scaling 그룹을 조정합니다. 선택적으로 `PutScalingPolicy` API 작업의 `SchedulingBufferTime` 속성 또는 AWS Management Console의 **사전 시작 인스턴스** 설정을 사용하여 더 이른 시작 시간을 지정할 수 있습니다. 이에 따라 Amazon EC2 Auto Scaling이 예상 수요보다 먼저 새 인스턴스를 시작하므로 부팅하고 트래픽을 처리할 시간을 확보할 수 있습니다.
예측된 수요보다 먼저 새 인스턴스를 시작할 수 있도록 Auto Scaling 그룹의 *기본 인스턴스 워밍업*을 활성화하는 것이 좋습니다. 이는 동적 조정 정책에서 용량을 줄여야 한다고 표시하더라도 Amazon EC2 Auto Scaling이 스케일 인되지 않는 동안 스케일 아웃 활동 이후의 기간을 지정합니다. 이렇게 하면 새로 시작된 인스턴스가 스케일 인 작업에 고려되기 전에 증가된 트래픽에 대한 서비스를 시작하기에 충분한 시간을 확보할 수 있습니다. 자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 단원을 참조하십시오.
## 최대 용량 제한
Auto Scaling 그룹에는 그룹에 대해 시작할 수 있는 EC2 인스턴스의 최대 수를 제한하는 최대 용량 설정이 있습니다. 기본적으로 조정 정책이 설정되면 용량을 최대 용량보다 크게 늘일 수 없습니다.
또는 예측 용량이 Auto Scaling 그룹의 최대 용량에 가깝거나 이를 초과하는 경우 그룹의 최대 용량을 자동으로 늘리도록 허용할 수 있습니다. 이 동작을 활성화하려면 `PutScalingPolicy` API 작업에서 `MaxCapacityBreachBehavior` 및 `MaxCapacityBuffer` 속성을 사용하거나 AWS Management Console에서 **최대 용량 동작** 설정을 사용합니다.
**주의**
최대 용량을 자동으로 늘리도록 허용할 때에는 주의해야 합니다. 증가한 최대 용량을 모니터링하고 관리하지 않으면 의도한 것보다 더 많은 인스턴스가 시작될 수 있습니다. 증가한 최대 용량은 수동으로 업데이트할 때까지 Auto Scaling 그룹의 새로운 정상 최대 용량이 됩니다. 최대 용량은 원래 최대 용량으로 자동으로 감소하지 않습니다.
## 고려 사항
+ 예측 스케일 아웃이 워크로드에 적합한지 확인합니다. 워크로드가 특정 요일이나 시간에 반복되는 로드 패턴을 나타내는 경우, 예측 조정에 적합합니다. 이를 확인하려면 예상 전용** 모드에서 예측적 조정 정책을 구성한 다음 콘솔의 권장 사항을 참조하세요. Amazon EC2 Auto Scaling은 잠재적인 정책 성능에 대한 관찰에 근거하여 권장 사항을 제공합니다. 예측적 조정이 애플리케이션 크기를 능동적으로 조정하도록 하기 전에 예측과 권장 사항을 평가합니다.
+ 예측 조정이 예상을 시작하려면 최소 24시간 동안의 기록 데이터가 필요합니다. 그러나 기록 데이터가 2주 전체에 걸쳐 있는 경우, 예측이 더 정확합니다. 새 Auto Scaling 그룹을 생성하고 이전 그룹을 삭제하여 애플리케이션을 업데이트하는 경우, 예측 조정에서 예상 생성을 다시 시작하기 전에 새 Auto Scaling 그룹에는 24시간 동안의 기록 로드 데이터가 필요합니다. 사용자 지정 지표를 사용하여 이전 Auto Scaling 그룹과 새 Auto Scaling 그룹의 지표를 집계할 수 있습니다. 그렇지 않으면 더욱 정확한 예측을 위해 며칠을 기다려야 할 수 있습니다.
+ 애플리케이션의 전체 로드를 정확하게 나타내고 확장해야 하는 애플리케이션의 측면인 부하 지표를 선택합니다.
+ 예측 조정과 함께 동적 조정을 사용하면 애플리케이션에 대한 수요 곡선을 면밀히 따를 수 있으며, 트래픽이 적은 기간에는 스케일 인하고 트래픽이 예상보다 높을 때는 스케일 아웃합니다. 여러 조정 정책이 활성화된 경우, 각 정책에서는 원하는 용량을 독립적으로 결정하며 원하는 용량이 최대값으로 설정됩니다. 예컨대, 대상 추적 조정 정책에서 대상 사용률을 유지하기 위해 인스턴스 10개가 필요하고, 예측 조정 정책에서 대상 사용률을 유지하기 위해 인스턴스 8개가 필요한 경우, 그룹의 원하는 용량은 10으로 설정됩니다. 동적 조정이 익숙하지 않은 경우 대상 추적 조정 정책을 사용하는 것이 좋습니다. 자세한 내용은 [Amazon EC2 Auto Scaling의 동적 조정](as-scale-based-on-demand.md) 단원을 참조하십시오.
+ 예측 조정의 핵심적인 가정은 Auto Scaling 그룹이 동질적이며 모든 인스턴스의 용량이 동일하다는 것입니다. 그룹에 속하지 않는 경우, 예측 용량이 정확하지 않을 수 있습니다. 따라서 [혼합 인스턴스 그룹](ec2-auto-scaling-mixed-instances-groups.md)에 대한 예측 조정 정책을 생성할 때는 주의해야 합니다. 용량이 동일하지 않은 여러 유형의 인스턴스를 프로비저닝할 수 있기 때문입니다. 다음은 예측 용량이 부정확할 수 있는 몇 가지 예입니다.
+ 예측 조정 정책은 CPU 사용률에 근거하여 하지만, 각 Auto Scaling 인스턴스의 vCPU 수는 인스턴스 유형에 따라 다릅니다.
+ 예측 조정 정책은 네트워크 인 또는 네트워크 아웃에 근거하여 하지만, 각 Auto Scaling 인스턴스의 네트워크 대역폭 처리량은 인스턴스 유형에 따라 다릅니다. 예컨대, M5 및 M5n 인스턴스 유형은 비슷하지만 M5n 인스턴스 유형은 네트워크 처리량이 상당히 높습니다.
## 지원되는 지역
+ 미국 동부(버지니아 북부)
+ 미국 동부(오하이오)
+ 미국 서부(캘리포니아 북부)
+ 미국 서부(오리건)
+ 아프리카(케이프타운)
+ 아시아 태평양(홍콩)
+ 아시아 태평양(하이데라바드)
+ 아시아 태평양(자카르타)
+ 아시아 태평양(멜버른)
+ 아시아 태평양(뭄바이)
+ 아시아 태평양(오사카)
+ 아시아 태평양(서울)
+ 아시아 태평양(싱가포르)
+ 아시아 태평양(시드니)
+ 아시아 태평양(도쿄)
+ 캐나다(중부)
+ 캐나다 서부(캘거리)
+ 중국(베이징)
+ 중국(닝샤)
+ 유럽(프랑크푸르트)
+ 유럽(아일랜드)
+ 유럽(런던)
+ 유럽(밀라노)
+ 유럽(파리)
+ 유럽(스페인)
+ 유럽(스톡홀름)
+ 유럽(취리히)
+ 이스라엘(텔아비브)
+ Middle East (Bahrain)
+ 중동(UAE)
+ 남아메리카(상파울루)
+ AWS GovCloud(미국 동부)
+ AWS GovCloud(미국 서부)
# Auto Scaling 그룹에 대한 예측 조정 정책 생성
다음 절차는 AWS Management Console 또는를 사용하여 예측 조정 정책을 생성하는 데 도움이 됩니다 AWS CLI.
Auto Scaling 그룹이 새 그룹인 경우, Amazon EC2 Auto Scaling에서 예측을 생성하기 전에 최소 24시간의 데이터를 제공해야 합니다.
**Topics**
+ [예측 조정 정책 생성(콘솔)](#predictive-scaling-policy-console)
+ [예측 조정 정책 생성(AWS CLI)](#predictive-scaling-policy-aws-cli)
## 예측 조정 정책 생성(콘솔)
예측 조정 정책을 처음 생성하는 경우 콘솔을 사용하여 *예측 전용* 모드에서 여러 예측 조정 정책을 생성하는 것이 좋습니다. 이를 통해 다양한 지표와 대상 값의 잠재적 효과를 테스트할 수 있습니다. 각 Auto Scaling 그룹에 대해 여러 예측 조정 정책을 생성할 수 있지만 활성 조정에는 하나의 정책만 사용할 수 있습니다.
### 콘솔에서 예측 조정 정책 생성(사전 정의된 지표)
다음 절차를 사용하여 사전 정의된 지표(CPU, 네트워크 I/O 또는 대상별 Application Load Balancer 요청 수)를 사용하여 예측 조정 정책을 생성합니다. 예측 조정 정책을 만드는 가장 쉬운 방법은 미리 정의된 지표를 사용하는 것입니다. 사용자 지정 지표를 사용하려는 경우, [콘솔에서 예측 조정 정책 생성(사용자 지정 지표)](#create-a-predictive-scaling-policy-in-the-console-custom-metrics)을 참조하세요.
**예측 조정 정책을 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Automatic scaling(자동 조정)** 탭의 **Scaling policies(조정 정책)**에서 **Create predictive scaling policy(예측 조정 정책 생성)**를 선택합니다.
1. 정책의 이름을 입력합니다.
1. **Scale based on forecast(예상 기반 조정)**를 켜 Amazon EC2 Auto Scaling에 바로 조정을 시작할 수 있는 권한을 부여합니다.
정책을 *예상 전용* 모드에서 유지하려면 **Scale based on forecast(예상 기반 조정)**를 끕니다.
1. **Metrics(지표)**의 경우, 옵션 목록에서 지표를 선택합니다. 옵션에는 **CPU**,**Network In(네트워크 입력)**,**Network Out(네트워크 출력)**,**Application Load Balancer request count(Application Load Balancer 요청 횟수)** 및 **Custom metric pair(사용자 지정 지표 페어)**가 포함됩니다.
**Application Load Balancer request count per target(대상당 Application Load Balancer 요청 수)**을 선택한 경우, **Target group(대상 그룹)**에서 대상 그룹을 선택합니다. **Application Load Balancer request count per target(대상별 Application Load Balancer 요청 수)**는 Auto Scaling 그룹에 Application Load Balancer 대상 그룹을 연결한 경우에만 지원됩니다.
**Custom metric pair(사용자 지정 지표 쌍)**를 선택하면 **Load metric(로드 지표)** 및 **Scaling metric(조정 지표)**의 드롭다운 목록에서 개별 지표를 선택합니다.
1. **Target utilization(목표 사용률)**에는 Amazon EC2 Auto Scaling이 유지해야 하는 목푯값을 입력합니다. Amazon EC2 Auto Scaling은 평균 사용률이 목표 사용률이 될 때까지 또는 사용자가 지정한 최대 인스턴스 수에 도달할 때까지 용량을 스케일 아웃합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/predictive-scaling-create-policy.html)
1. (옵션) **Pre-launch instances(사전 인스턴스 시작)**에서는 로드 증가에 대한 예상을 호출하기 전 인스턴스를 미리 시작하려는 시간을 선택합니다.
1. (옵션) **Max capacity behavior**(최대 용량 동작)에서는 예상 용량이 정의된 최대 용량을 초과할 때 Amazon EC2 Auto Scaling이 그룹의 최대 용량보다 더 많이 스케일 아웃되도록 허용할지를 선택합니다. 이 설정을 켜면 트래픽이 가장 높을 것으로 예측되는 기간에 스케일 아웃이 발생할 수 있습니다.
1. (옵션) **Buffer maximum capacity above the forecasted capacity(예상 용량을 초과하는 버퍼 최대 용량)**에서 예상 용량이 최대 용량에 근접하거나 최대 용량을 초과하는 경우, 사용할 추가 용량을 선택합니다. 값은 예측 용량에 상대적인 백분율로 지정됩니다. 예컨대, 버퍼가 10이면 이는 10% 버퍼를 의미합니다. 따라서 예상 용량이 50이고 최대 용량이 40이라면 최대 유효 용량은 55입니다.
0으로 설정하면 Amazon EC2 Auto Scaling이 최대 용량보다 크게 용량을 조정할 수 있지만 예상 용량을 초과할 수 없습니다.
1. **예측 조정 정책 생성**을 선택합니다.
### 콘솔에서 예측 조정 정책 생성(사용자 지정 지표)
사용자 지정 지표를 사용하여 예측 조정 정책을 생성하려면 다음 절차를 따르세요. 사용자 지정 지표에는 CloudWatch에서 제공하는 다른 지표 또는 CloudWatch에 게시하는 지표가 포함될 수 있습니다. 대상별 CPU, 네트워크 I/O 또는 Application Load Balancer 요청 수를 사용하려면 [콘솔에서 예측 조정 정책 생성(사전 정의된 지표)](#create-a-predictive-scaling-policy-in-the-console)을 참조하세요.
사용자 지정 지표를 사용하여 예측 조정 정책을 생성하려면 다음을 수행해야 합니다.
+ Amazon EC2 Auto Scaling이 CloudWatch의 지표와 상호 작용할 수 있도록 원시 쿼리를 제공해야 합니다. 자세한 설명은 [사용자 정의 지표를 사용하는 고급 예측 조정 정책](predictive-scaling-customized-metric-specification.md) 섹션을 참조하세요. Amazon EC2 Auto Scaling이 CloudWatch에서 지표 데이터를 추출할 수 있도록 하려면 각 쿼리가 데이터 포인트를 반환하는지 확인하세요. CloudWatch 콘솔 또는 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 작업을 사용하여 이를 확인합니다.
**참고**
Amazon EC2 Auto Scaling 콘솔의 JSON 편집기에서 샘플 JSON 페이로드를 제공합니다. 이 예제에서는에서 제공하는 다른 CloudWatch 지표 AWS 또는 이전에 CloudWatch에 게시한 지표를 추가하는 데 필요한 키-값 페어에 대한 참조를 제공합니다. 이를 시작점으로 사용한 다음 필요에 맞게 사용자 지정할 수 있습니다.
+ 지표 수학을 사용하는 경우, 고유한 시나리오에 맞게 JSON을 수동으로 구성해야 합니다. 자세한 설명은 [지표 수학 표현식 사용](using-math-expression-examples.md) 섹션을 참조하세요. 정책에서 지표 수학을 사용하기 전에 지표 수학 표현식에 근거하여 하는 지표 쿼리가 유효한지 확인하고 단일 시계열을 반환해야 합니다. CloudWatch 콘솔 또는 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 작업을 사용하여 이를 확인합니다.
잘못된 Auto Scaling 그룹 명칭과 같이 잘못된 데이터를 제공하여 쿼리에 오류가 발생하면 예측에 데이터가 없습니다. 사용자 지정 지표 문제 해결 방법은 [예측 조정 정책에서 사용자 정의 지표 사용 시 고려 사항](custom-metrics-troubleshooting.md)을 참조하세요.
**예측 조정 정책을 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Automatic scaling(자동 조정)** 탭의 **Scaling policies(조정 정책)**에서 **Create predictive scaling policy(예측 조정 정책 생성)**를 선택합니다.
1. 정책의 이름을 입력합니다.
1. **Scale based on forecast(예상 기반 조정)**를 켜 Amazon EC2 Auto Scaling에 바로 조정을 시작할 수 있는 권한을 부여합니다.
정책을 *예상 전용* 모드에서 유지하려면 **Scale based on forecast(예상 기반 조정)**를 끕니다.
1. **Metrics**(지표)에서 **Custom metric pair**(사용자 지정 지표 쌍)을 선택합니다.
1. **Load metric**(로드 지표)에서 **Custom CloudWatch metric**(사용자 지정 CloudWatch 지표)을 선택하여 사용자 지정 지표를 사용합니다. 정책에 대한 로드 지표 정의가 포함된 JSON 페이로드를 구성하고 이를 JSON 편집기 상자에 붙여넣고 상자에 이미 있는 것을 교체합니다.
1. **Scaling metric**(스케일 아웃 지표)에서 **Custom CloudWatch metric**(사용자 지정 CloudWatch 지표)을 선택하여 사용자 지정 지표를 사용합니다. 정책에 대한 스케일 아웃 지표 정의가 포함된 JSON 페이로드를 구성하고 이를 JSON 편집기 상자에 붙여넣고 상자에 이미 있는 것을 교체합니다.
1. (옵션) 사용자 지정 용량 지표를 추가하려면 **Add custom capacity metric**(사용자 지정 용량 지표 추가) 확인란을 선택합니다. 정책에 대한 용량 지표 정의가 포함된 JSON 페이로드를 구성하고 이를 JSON 편집기 상자에 붙여넣고 상자에 이미 있는 것을 교체합니다.
용량 지표 데이터가 여러 Auto Scaling 그룹에 걸쳐 있는 경우, 용량에 대한 새 시계열을 생성하려면 이 옵션을 활성화하기만 하면 됩니다. 이 경우, 지표 수학을 사용하여 데이터를 단일 시계열로 집계해야 합니다.
1. **Target utilization(목표 사용률)**에는 Amazon EC2 Auto Scaling이 유지해야 하는 목푯값을 입력합니다. Amazon EC2 Auto Scaling은 평균 사용률이 목표 사용률이 될 때까지 또는 사용자가 지정한 최대 인스턴스 수에 도달할 때까지 용량을 스케일 아웃합니다.
1. (옵션) **Pre-launch instances(사전 인스턴스 시작)**에서는 로드 증가에 대한 예상을 호출하기 전 인스턴스를 미리 시작하려는 시간을 선택합니다.
1. (옵션) **Max capacity behavior**(최대 용량 동작)에서는 예상 용량이 정의된 최대 용량을 초과할 때 Amazon EC2 Auto Scaling이 그룹의 최대 용량보다 더 많이 스케일 아웃되도록 허용할지를 선택합니다. 이 설정을 켜면 트래픽이 가장 높을 것으로 예측되는 기간에 스케일 아웃이 발생할 수 있습니다.
1. (옵션) **Buffer maximum capacity above the forecasted capacity(예상 용량을 초과하는 버퍼 최대 용량)**에서 예상 용량이 최대 용량에 근접하거나 최대 용량을 초과하는 경우, 사용할 추가 용량을 선택합니다. 값은 예측 용량에 상대적인 백분율로 지정됩니다. 예컨대, 버퍼가 10이면 이는 10% 버퍼를 의미합니다. 따라서 예상 용량이 50이고 최대 용량이 40이라면 최대 유효 용량은 55입니다.
0으로 설정하면 Amazon EC2 Auto Scaling이 최대 용량보다 크게 용량을 조정할 수 있지만 예상 용량을 초과할 수 없습니다.
1. **예측 조정 정책 생성**을 선택합니다.
## 예측 조정 정책 생성(AWS CLI)
다음과 AWS CLI 같이를 사용하여 Auto Scaling 그룹에 대한 예측 조정 정책을 구성합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
지정 가능한 CloudWatch 지표에 대한 자세한 내용은 *Amazon EC2 Auto Scaling API 참조*의 [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)을 참조하세요.
### 예 1: 예측을 생성하지만 조정하지 않는 예측 조정 정책
다음 예 정책은 목표 사용률이 `40`인 예측 조정에 CPU 사용률 지표를 사용하는 전체 정책 구성을 보여 줍니다. `ForecastOnly` 모드는 사용할 모드를 명시적으로 지정하지 않는 한 기본적으로 사용됩니다. 이 구성을 `config.json` 파일에 저장합니다.
```
{
"MetricSpecifications": [
{
"TargetValue": 40,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
]
}
```
명령행에서 정책을 생성하려면 다음 예에 나와 있는 것처럼 지정된 구성 파일을 사용하여 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다.
```
aws autoscaling put-scaling-policy --policy-name cpu40-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
이 명령이 제대로 실행되면 정책의 Amazon 리소스 이름(ARN)을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/cpu40-predictive-scaling-policy",
"Alarms": []
}
```
### 예 2: 예측하여 조정하는 예측 조정 정책
Amazon EC2 Auto Scaling이 예상하여 조정할 수 있도록 허용하는 정책의 경우, 값이 `ForecastAndScale`인 속성 `Mode`를 추가합니다. 다음 예에서는 Application Load Balancer 요청 수 지표를 사용하는 정책 구성을 보여 줍니다. 목표 사용률은 `1000`이고 예측 조정은 `ForecastAndScale` 모드로 설정되어 있습니다.
```
{
"MetricSpecifications": [
{
"TargetValue": 1000,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ALBRequestCount",
"ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff"
}
}
],
"Mode": "ForecastAndScale"
}
```
이 정책을 생성하려면 다음 예에 나와 있는 것처럼 지정된 구성 파일을 사용하여 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다.
```
aws autoscaling put-scaling-policy --policy-name alb1000-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
이 명령이 제대로 실행되면 정책의 Amazon 리소스 이름(ARN)을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:19556d63-7914-4997-8c81-d27ca5241386:autoScalingGroupName/my-asg:policyName/alb1000-predictive-scaling-policy",
"Alarms": []
}
```
### 예 3: 최대 용량보다 높게 조정할 수 있는 예측 조정 정책
다음 예에서는 일반보다 높은 부하를 처리해야 할 때 그룹의 최대 크기 제한보다 높게 조정할 수 있는 정책을 생성하는 방법을 보여 줍니다. 기본적으로 Amazon EC2 Auto Scaling은 사용자가 정의한 최대 용량보다 높게 EC2 용량을 조정하지 않습니다. 그러나 성능 또는 가용성 문제를 피하기 위해 용량을 약간 늘려서 스케일 아웃하는 것이 도움이 될 수 있습니다.
용량이 그룹의 최대 크기에 도달했거나 매우 근접한 것으로 예상될 때 Amazon EC2 Auto Scaling을 위한 추가 용량을 프로비저닝할 수 있는 여유를 제공하려면 다음 예에 표시된 것처럼 `MaxCapacityBreachBehavior` 및 `MaxCapacityBuffer` 속성을 지정합니다. `MaxCapacityBreachBehavior`를 값 `IncreaseMaxCapacity`로 지정해야 합니다. 그룹에서 보유할 수 있는 최대 인스턴스 수는 `MaxCapacityBuffer`의 값에 따라 달라집니다.
```
{
"MetricSpecifications": [
{
"TargetValue": 70,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
],
"MaxCapacityBreachBehavior": "IncreaseMaxCapacity",
"MaxCapacityBuffer": 10
}
```
이 예에서는 10% 버퍼(`"MaxCapacityBuffer": 10`)를 사용하도록 구성되어 있습니다. 따라서 예상 용량이 50이고 최대 용량이 40이라면 최대 유효 용량은 55입니다. 최대 용량보다 높은 용량을 예측 용량을 초과하지 않고 예측 용량과 동일하게 조정할 수 있는 정책의 버퍼는 0입니다(`"MaxCapacityBuffer": 0`).
이 정책을 생성하려면 다음 예에 나와 있는 것처럼 지정된 구성 파일을 사용하여 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다.
```
aws autoscaling put-scaling-policy --policy-name cpu70-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
이 명령이 제대로 실행되면 정책의 Amazon 리소스 이름(ARN)을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:d02ef525-8651-4314-bf14-888331ebd04f:autoScalingGroupName/my-asg:policyName/cpu70-predictive-scaling-policy",
"Alarms": []
}
```
# 예측적 조정 정책 평가
예측적 조정 정책을 사용하여 Auto Scaling 그룹을 조정하기 전에 Amazon EC2 Auto Scaling 콘솔에서 정책에 대한 권장 사항과 기타 데이터를 검토합니다. 이는 예측의 정확성이 확인될 때까지 예측적 조정 정책이 실제 용량을 조정하는 것을 원하지 않기 때문에 중요합니다.
Auto Scaling 그룹이 신규인 경우, Amazon EC2 Auto Scaling에 24시간을 주어 첫 번째 예측을 생성합니다.
Amazon EC2 Auto Scaling은 예측을 생성할 때 기록 데이터를 사용합니다. Auto Scaling 그룹에 아직 최근 기록 데이터가 많지 않은 경우, Amazon EC2 Auto Scaling은 현재 사용 가능한 기록 집계에서 생성된 집계로 예측을 일시적으로 채울 수 있습니다. 정책 생성 날짜 전 최대 2주 동안 예측이 채워집니다.
**Topics**
+ [권장 사항 보기](#view-predictive-scaling-recommendations)
+ [모니터링 그래프 검토](#review-predictive-scaling-monitoring-graphs)
+ [CloudWatch를 사용한 지표 모니터링](monitor-predictive-scaling-cloudwatch.md)
## 예측적 조정 권장 사항 보기
효과적인 분석을 위해 Amazon EC2 Auto Scaling에 비교할 예측적 조정 정책이 2개 이상 있어야 합니다. (그러나 여전히 단일 정책에 대한 결과를 검토할 수 있습니다.) 여러 정책을 생성할 때 한 지표를 사용하는 정책을 다른 지표를 사용하는 정책과 비교하여 평가할 수 있습니다. 또한 다양한 대상 값과 지표 조합의 영향을 평가할 수 있습니다. 예측적 조정 정책이 생성된 후 Amazon EC2 Auto Scaling은 어느 정책이 그룹 조정 작업을 더 잘 수행할지 평가하기 시작합니다.
**Amazon EC2 Auto Scaling 콘솔에서 권장 사항 보기**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Auto scaling** 탭의 **예측적 조정 정책**에서 권장 사항과 함께 정책에 대한 세부 정보를 볼 수 있습니다. 권장 사항은 예측적 조정 정책이 사용하지 않는 것보다 더 나은 작업을 수행하는지 여부를 알려줍니다.
예측적 조정 정책이 그룹에 적합한지 확실하지 않은 경우, **가용성에 미치는 영향** 열과 **비용에 미치는 영향** 열을 검토하여 적합한 정책을 선택합니다. 각 열에 대한 정보는 정책의 영향을 알려줍니다.
+ **가용성에 미치는 영향**: 정책을 사용하지 않을 때와 비교하여 정책을 통해 워크로드를 처리하기에 충분한 인스턴스를 프로비저닝함으로써 가용성에 미치는 부정적인 영향을 방지할 수 있는지 여부를 설명합니다.
+ **비용에 미치는 영향**: 정책을 사용하지 않을 때와 비교하여 정책을 통해 인스턴스를 과다 프로비저닝하지 않음으로써 비용에 미치는 부정적인 영향을 방지할 수 있는지 여부를 설명합니다. 과다 프로비저닝하면 인스턴스가 충분히 사용되지 않거나 유휴 상태가 되어 비용에 미치는 영향만 가중됩니다.
정책이 여러 개인 경우, 더 낮은 비용으로 가장 많은 가용성 이점을 제공하는 정책 이름 옆에 **최상의 예측** 태그가 표시됩니다. 가용성 영향에 더 많은 가중치가 부여됩니다.
1. (옵션) 권장 사항 결과에 대해 원하는 기간을 선택하려면 **평가 기간** 드롭다운에서 원하는 값(**2일**, **1주**, **2주**, **4주**, **6주** 또는 **8주**)을 선택합니다. 기본적으로 평가 기간은 지난 2주입니다. 평가 기간이 길수록 권장 사항 결과에 더 많은 데이터 포인트가 제공됩니다. 그러나 로드 패턴이 변경된 경우(예: 예외적인 수요 기간 이후) 데이터 포인트를 더 추가해도 결과가 개선되지 않을 수 있습니다. 이 경우, 보다 최근 데이터를 살펴봄으로써 보다 집중적인 권장 사항을 얻을 수 있습니다.
**참고**
**예상 전용** 모드에 있는 정책에 대한 권장 사항만 생성됩니다. 권장 사항 기능은 평가 기간 내내 정책이 **예상 전용** 모드일 때 더 잘 작동합니다. **예상 및 조정** 모드에서 정책을 시작하고 나중에 **예상 전용** 모드로 전환하면 해당 정책에 대한 결과가 편향될 가능성이 높습니다. 이는 정책이 이미 실제 용량에 기여했기 때문입니다.
## 예측적 조정 모니터링 그래프 검토
Amazon EC2 Auto Scaling 콘솔에서 이전 날, 주 또는 달의 예측을 검토하여 시간이 지남에 따라 정책이 얼마나 잘 수행되는지 시각화할 수 있습니다. 정책을 통해 실제 용량을 조정할지 여부를 결정할 때 이 정보를 사용하여 예측의 정확성을 평가할 수도 있습니다.
**Amazon EC2 Auto Scaling 콘솔에서 예측적 조정 모니터링 그래프 보기**
1. **예측 크기 조정 정책** 목록에서 정책을 선택합니다.
1. **모니터링** 섹션에서 로드 및 용량 정책에 대한 과거 및 미래 예측을 실제 값과 비교하여 볼 수 있습니다. **로드** 그래프는 선택한 로드 지표에 대한 로드 예측 및 실제 값을 보여줍니다. **용량** 그래프에는 정책에서 예측한 인스턴스 수가 표시됩니다. 또한 시작된 실제 인스턴스 수도 포함됩니다. 수직선은 과거 값과 미래 예측을 구분합니다. 정책이 생성되면 바로 이 그래프를 사용할 수 있습니다.
1. (옵션) 차트에 표시된 기록 데이터 양을 변경하려면 페이지 상단의 **평가 기간** 드롭다운에서 원하는 값을 선택합니다. 평가 기간은 어떤 식으로든 이 페이지의 데이터를 변환하지 않으며, 표시되는 기록 데이터의 양만 변경합니다.
다음 이미지는 예측이 여러 번 적용된 경우의 **로드** 및 **용량** 그래프를 보여줍니다. 예측적 조정은 기록 로드 데이터에 근거하여 로드를 예측합니다. 애플리케이션에서 생성하는 로드는 Auto Scaling 그룹의 각 인스턴스에 대한 CPU 사용률, 네트워크 입/출력, 수신된 요청 또는 사용자 지정 지표의 합계로 표시됩니다. 예측적 조정은 로드 예측과 조정 지표에 대해 달성하려는 목표 사용률에 근거하여 향후 용량 요건을 계산합니다.
![\[예측적 조정 그래프\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/predictive-scaling-graphs.png)
****로드** 그래프의 데이터 비교**
각 수평선은 1시간 간격으로 보고되는 서로 다른 데이터 포인트 세트를 나타냅니다.
1. **실제 관찰된 로드**는 선택한 로드 지표에 대한 SUM 통계를 사용하여 과거의 총 시간별 로드를 보여줍니다.
1. **정책에 의해 예측되는 로드**는 시간별 로드 예측을 보여줍니다. 이 예측은 지난 2주간의 실제 로드 관찰에 근거하여 합니다.
****용량** 그래프의 데이터 비교**
각 수평선은 1시간 간격으로 보고되는 서로 다른 데이터 포인트 세트를 나타냅니다.
1. **실제 관측 용량**은 [GroupTotalInstances](ec2-auto-scaling-metrics.md#as-group-metrics) 지표가 활성화된 경우 Auto Scaling 그룹의 과거 실제 용량을 보여줍니다. 이 용량은 다른 규모 조정 정책과 선택한 기간 동안의 최소 그룹 크기에 따라 달라집니다.
1. **정책에서 예측한 용량**은 정책이 **예상 및 조정** 모드일 때 매 시간 시작 시 예상할 수 있는 기본 용량을 보여줍니다.
1. **추론된 필수 용량**은 선택한 대상 값에서 조정 지표를 유지하는 데 이상적인 용량을 보여줍니다.
1. **최소 용량**은 Auto Scaling 그룹의 최소 용량을 보여줍니다.
1. **최대 용량**은 Auto Scaling 그룹의 최대 용량을 보여줍니다.
추론된 필수 용량을 계산하기 위해 먼저 각 인스턴스가 지정된 대상 값에서 균등하게 사용된다고 가정합니다. 실제로 인스턴스는 균등하게 사용되지 않습니다. 그러나 사용률이 인스턴스 간에 균일하게 분산되어 있다고 가정하면 필요한 용량의 양을 예측할 수 있습니다. 그런 다음 용량 요건은 예측적 조정 정책에 사용한 조정 지표에 반비례하도록 계산됩니다. 즉, 용량이 증가함에 따라 동일한 백분율로 조정 지표가 감소합니다. 예컨대, 용량이 두 배로 증가하면 조정 지표는 절반으로 감소해야 합니다.
추론된 필수 용량에 대한 공식:
`sum of (actualCapacityUnits*scalingMetricValue)/(targetUtilization)`
예컨대, 지정된 시간에 대한 `actualCapacityUnits`(`10`) 및 `scalingMetricValue`(`30`)를 가져옵니다. 그런 다음 예측적 조정 정책(`60`)에 지정한 `targetUtilization`을 가져오고 같은 시간에 대해 추론된 필수 용량을 계산합니다. 이 예는 값 `5`를 반환합니다. 즉, 조정 지표의 대상 값에 반비례하여 용량을 유지하는 데 필요한 추론 용량은 5입니다.
**참고**
애플리케이션의 비용 절감 및 가용성을 조정하고 개선하기 위해 다양한 레버를 사용할 수 있습니다.
기준 용량과 동적 조정에 예측적 조정을 사용하여 추가 용량을 처리합니다. 동적 조정은 예측적 조정과 독립적으로 작동하며 현재 사용률에 따라 스케일 아웃되고 축소됩니다. 먼저 Amazon EC2 Auto Scaling은 각 동적 조정 정책에 권장되는 인스턴스 수를 계산합니다. 그런 다음 가장 많은 수의 인스턴스를 제공하는 정책에 따라 조정됩니다.
로드가 감소할 때 스케일인이 수행되도록 하려면 Auto Scaling 그룹에 스케일 인 부분이 활성화된 동적 조정 정책이 항상 하나 이상 있어야 합니다.
최소 및 최대 용량이 너무 제한적이지 않은지 확인하여 조정 성능을 개선할 수 있습니다. 권장 인스턴스 수가 최소 및 최대 용량 범위에 속하지 않는 정책은 스케일 인 및 스케일 아웃되지 않습니다.
# CloudWatch를 사용한 에측 조정 지표 모니터링
필요에 따라 Amazon EC2 Auto Scaling 콘솔 대신에 Amazon CloudWatch에서 예측 조정을 위한 모니터링 데이터에 액세스하는 것이 나을 수 있습니다. 예측 조정 정책을 생성하고 나면, 해당 정책이 미래의 로드와 용량을 예측하는 데 사용되는 데이터를 수집합니다. 수집된 데이터는 주기적으로 CloudWatch에 자동으로 저장됩니다. 그러면 CloudWatch를 사용하여 시간 경과에 따른 정책의 성능을 시각화할 수 있습니다. 또한 CloudWatch 경보를 생성하여, 성능 지표가 CloudWatch에서 정의한 한도를 초과하여 변화하는 경우에 이를 알릴 수 있습니다.
**Topics**
+ [기록 예측 데이터 시각화](#visualize-historical-forecast-data)
+ [지표 수식을 사용하여 정확도 지표 생성](#create-accuracy-metrics)
## 기록 예측 데이터 시각화
CloudWatch에서 예측 조정 정책의 로드 및 용량 예측 데이터를 볼 수 있습니다. 이는 단일 그래프에 다른 CloudWatch 지표에 대한 예측을 시각화할 때 유용할 수 있습니다. 또한 시간 경과에 따른 추세를 볼 수 있도록 넓은 시간 범위를 표시할 때 도움이 될 수 있습니다. 최대 15개월의 기록 지표에 액세스하여, 정책의 성능을 전반적으로 더 잘 파악할 수 있습니다.
자세한 설명은 [예측 조정 지표 및 차원](ec2-auto-scaling-metrics.md#predictive-scaling-metrics) 섹션을 참조하세요.
**CloudWatch 콘솔을 사용하여 기록 예측 데이터를 보려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표(Metrics)**를 선택한 다음 **모든 지표(All metrics)**를 선택합니다.
1. **Auto Scaling 그룹(Auto Scaling)** 지표 네임스페이스를 선택합니다.
1. 다음 옵션 중 하나를 선택하여 로드 예측 또는 용량 예측 지표를 봅니다.
+ **예측 조정 로드 예측**
+ **예측 조정 용량 예측**
1. 검색 필드에 예측 스케일링 정책의 이름 또는 Auto Scaling 그룹의 이름을 입력한 다음 Enter 키를 눌러 결과를 필터링합니다.
1. 측정치를 그래프로 표시하려면 측정치 옆에 있는 확인란을 선택합니다. 그래프 이름을 변경하려면 연필 아이콘을 선택합니다. 시간 범위를 변경하려면 제공되는 값 중 하나를 선택하거나 **사용자 지정**을 선택합니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*에서 [지표 그래프](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)를 참조하세요.
1. 기간을 변경하려면 **그래프로 표시된 지표** 탭을 선택합니다. 열 머리글이나 개별 값을 선택한 후 다른 통계를 선택합니다. 각 지표의 어떤 통계든 선택할 수 있지만, 모든 통계가 **PredictiveScalingLoadForecast** 지표와 **PredictiveScalingCapacityForecast** 지표에 유용한 것은 아닙니다. 예컨대 **Average**, **Minimum** 및 **Maximum** 통계는 유용하지만 **Sum** 통계는 유용하지 않습니다.
1. 그래프에 다른 지표를 추가하려면 **찾아보기(Browse)**에서 **모두(All)**를 선택하고 특정 지표를 찾은 다음 해당 지표 옆에 있는 확인란을 선택합니다. 최대 10개의 지표를 추가할 수 있습니다.
예컨대, 실제 CPU 사용률 값을 그래프에 추가하려면 **EC2** 네임스페이스를 선택한 다음 **By Auto Scaling Group**(Auto Scaling 그룹별)을 선택합니다. 그런 다음 **CPUUtilization** 지표의 확인란을 선택하고 특정 Auto Scaling 그룹을 선택합니다.
1. (옵션) 이 그래프를 CloudWatch 대시보드에 추가하려면 **작업(Actions)**, **대시보드에 추가(Add to dashboard)**를 선택합니다.
## 지표 수식을 사용하여 정확도 지표 생성
지표 수식을 사용하면 여러 CloudWatch 지표를 쿼리하고 수학 표현식을 활용함으로써 이러한 지표에 근거하여 새로운 시계열을 만들 수 있습니다. CloudWatch 콘솔에서 결과 시계열을 시각화하고 대시보드에 추가할 수 있습니다. 지표 수학에 대한 자세한 설명은 *Amazon CloudWatch 사용자 가이드*에서 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요.
지표 수식을 사용하면 Amazon EC2 Auto Scaling이 예측 조정을 위해 생성하는 데이터를 다양한 방식으로 그래프로 표시할 수 있습니다. 이는 시간 경과에 따른 정책 성능을 모니터링하고 지표 조합을 개선할 수 있는지 여부를 파악하는 데 도움이 됩니다.
예컨대, 지표 수학 표현식을 사용하여 [평균 절대 백분율 오차](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error)(MAPE)를 모니터링할 수 있습니다. MAPE 지표는 예측된 값과 지정된 예측 기간 동안 관찰된 실제 값의 차이를 모니터링하는 데 유용합니다. MAPE 값의 변화는 시간 경과에 따라 애플리케이션의 특성이 변경되면서 정책의 성능이 저하되는지 여부를 나타낼 수 있습니다. MAPE가 증가하면 예측된 값과 실제 값의 차이가 더 커진다는 것을 나타냅니다.
**예: 지표 수학 표현식**
이 유형의 그래프로 시작하려면, 다음 예에 표시된 것과 같은 지표 수학 표현식을 생성하면 됩니다.
```
{
"MetricDataQueries": [
{
"Expression": "TIME_SERIES(AVG(ABS(m1-m2)/m1))",
"Id": "e1",
"Period": 3600,
"Label": "MeanAbsolutePercentageError",
"ReturnData": true
},
{
"Id": "m1",
"Label": "ActualLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/EC2",
"MetricName": "CPUUtilization",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Period": 3600,
"Stat": "Sum"
},
"ReturnData": false
},
{
"Id": "m2",
"Label": "ForecastedLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/AutoScaling",
"MetricName": "PredictiveScalingLoadForecast",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
},
{
"Name": "PolicyName",
"Value": "my-predictive-scaling-policy"
},
{
"Name": "PairIndex",
"Value": "0"
}
]
},
"Period": 3600,
"Stat": "Average"
},
"ReturnData": false
}
]
}
```
단일 지표 대신, `MetricDataQueries`의 지표 데이터 쿼리 구조의 배열을 사용할 수 있습니다. `MetricDataQueries`의 각 항목은 지표를 가져오거나 수학 표현식을 수행합니다. 첫 번째 항목 `e1`은 수학 표현식입니다. 이 지정된 표현식은 `ReturnData` 파라미터를 `true`로 설정합니다. 이는 궁극적으로 단일 시계열을 생성합니다. 다른 모든 지표의 경우, `ReturnData` 값은 `false`입니다.
이 예에서 지정된 표현식은 실제 값과 예측된 값을 입력으로 사용하여 새 지표(MAPE)를 반환합니다. `m1`은 실제 로드 값을 포함하는 CloudWatch 지표입니다(CPU 사용률이 `my-predictive-scaling-policy`라는 정책에 대해 원래 지정된 로드 지표라고 가정). `m2`는 예측된 로드 값을 포함하는 CloudWatch 지표입니다. MAPE 지표의 수식 구문은 다음과 같습니다.
*(abs ((실제 - 예측)/(실제)))의 평균*
### 정확도 지표 시각화 및 경보 설정
정확도 지표 데이터를 시각화하려면 CloudWatch 콘솔에서 **지표(Metrics)** 탭을 선택합니다. 여기에서 데이터를 그래프로 표시할 수 있습니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*에서 [CloudWatch 그래프에 수학 표현식 추가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)를 참조하세요.
**지표(Metrics)** 섹션에서 모니터링하는 지표에 대해 경보를 설정할 수도 있습니다. **그래프로 표시된 지표(Graphed metrics)** 탭에서 **작업(Actions)** 열 아래에 있는 **경보 생성(Create alarm)** 아이콘을 선택합니다. 이 **경보 생성(Create alarm)** 아이콘은 작은 종 모양으로 표시됩니다. 자세한 내용과 알림 옵션은 *Amazon CloudWatch 사용 설명서*의 [지표 수학 표현식에 근거하여 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) 및 [경보 변경 시 사용자에게 알림](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)을 참조하세요.
또는 [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) 및 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)을 사용하여 지표 수식으로 계산을 수행하고 그 출력에 따라 경보를 생성할 수 있습니다.
# 예약된 작업을 사용하여 예측 값 재정의
경우에 따라 예상 계산에서 고려할 수 없는 향후 애플리케이션 필요량에 대한 추가 정보가 있을 수 있습니다. 예컨대, 예상 계산은 향후 마케팅 이벤트에 필요한 용량을 과소 평가할 수 있습니다. 예약된 작업을 사용하여 미래 기간에 대한 예상을 임시로 재정의할 수 있습니다. 예약된 작업은 반복적으로 실행되거나 일회성 수요 변동이 있는 특정 날짜 및 시간에 실행될 수 있습니다.
예컨대, 예상한 것보다 높은 최소 용량으로 예약된 작업을 생성할 수 있습니다. 런타임 시 Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 최소 용량을 업데이트합니다. 예측 조정은 용량에 맞게 최적화하므로 최소 용량이 예상 값보다 높은 예약된 작업이 적용됩니다. 이렇게 하면 용량이 예상보다 작아지는 것을 방지할 수 있습니다. 예상 재정의를 중지하려면 두 번째 예약된 작업을 사용하여 최소 용량을 원래 설정으로 되돌립니다.
다음 절차에서는 미래 기간의 예상을 재정의하는 단계를 간략하게 설명합니다.
**Topics**
+ [1단계: (옵션) 시계열 데이터 분석](#analyzing-time-series-data)
+ [2단계: 2개의 예약된 작업 생성](#scheduling-capacity)
**중요**
이 주제에서는 예측보다 더 큰 용량으로 확장하기 위해 예측을 재정의한다고 가정합니다. 예측 조정 정책의 간섭 없이 일시적으로 용량을 줄여야 하는 경우 *예측 전용* 모드를 대신 사용합니다. 예측 전용 모드에서 예측 조정은 계속 예측을 생성하지만 용량이 자동으로 증가하지는 않습니다. 그런 다음 리소스 사용률을 모니터링하고 필요에 따라 그룹의 크기를 수동으로 줄일 수 있습니다. 수동 조정에 대한 자세한 내용은 [Amazon EC2 Auto Scaling의 수동 조정](ec2-auto-scaling-scaling-manually.md) 섹션을 참조하세요.
## 1단계: (옵션) 시계열 데이터 분석
예상 시계열 데이터 분석으로 시작합니다. 이 단계는 선택 사항이지만 예상의 세부 정보를 파악하려는 경우, 유용합니다.
1. **예상 검색**
예상이 생성되면 예상에서 특정 기간을 쿼리할 수 있습니다. 쿼리의 목표는 특정 기간에 대한 시계열 데이터의 전체 보기를 얻는 것입니다.
쿼리에는 최대 2일간의 미래 예상 데이터가 포함될 수 있습니다. 예측 조정을 잠시 사용한 경우에도 과거 예상 데이터에 액세스할 수 있습니다. 그러나 시작 시간과 해지 시간 사이의 최대 기간은 30일입니다.
[get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI 명령을 사용하여 예측을 가져오려면 명령에 다음 파라미터를 제공합니다.
+ `--auto-scaling-group-name` 파라미터에 Auto Scaling 그룹의 이름을 입력합니다.
+ `--policy-name` 파라미터에 정책 이름을 입력합니다.
+ 지정한 시간 또는 그 이후의 예상 데이터만 반환하려면 `--start-time` 파라미터에 시작 시간을 입력합니다.
+ 지정한 시간 이전의 예상 데이터만 반환하려면 `--end-time` 파라미터에 해지 시간을 입력합니다.
```
aws autoscaling get-predictive-scaling-forecast --auto-scaling-group-name my-asg \
--policy-name cpu40-predictive-scaling-policy \
--start-time "2021-05-19T17:00:00Z" \
--end-time "2021-05-19T23:00:00Z"
```
이 작업이 성공하면 명령에서 다음 예와 비슷한 데이터가 반환됩니다.
```
{
"LoadForecast": [
{
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
153.0655799339254,
128.8288551285919,
107.1179447150675,
197.3601844551528,
626.4039934516954,
596.9441277518481,
677.9675713779869
],
"MetricSpecification": {
"TargetValue": 40.0,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
}
],
"CapacityForecast": {
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
2.0,
2.0,
2.0,
2.0,
4.0,
4.0,
4.0
]
},
"UpdateTime": "2021-05-19T01:52:50.118000+00:00"
}
```
응답에는 `LoadForecast` 및 `CapacityForecast`라는 두 가지 예측 값이 포함됩니다. `LoadForecast`는 시간별 로드 예측을 보여 주고 `CapacityForecast`는 40.0(평균 CPU 사용률 40%)의 `TargetValue`를 유지하는 동안 예측 로드를 처리하는 데 시간당 필요한 용량에 대한 예측 값을 보여 줍니다.
1. **대상 기간 식별**
일회성 수요 변동이 발생해야 하는 시간을 식별합니다. 예상에 표시된 날짜와 시간은 UTC입니다.
## 2단계: 2개의 예약된 작업 생성
다음으로, 애플리케이션의 예상 로드보다 높은 특정 기간에 대해 2개의 예약된 작업을 생성합니다. 예컨대, 제한된 기간에 사이트에 대한 트래픽을 높이는 마케팅 이벤트가 있는 경우, 이벤트 시작 시 최소 용량을 업데이트하는 일회성 작업을 예약할 수 있습니다. 그런 다음 이벤트가 해지 시 최소 용량을 원래 설정으로 되돌리도록 다른 작업을 예약합니다.
**일회성 이벤트에 대해 2개의 예약된 작업을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **자동 조정** 탭의 **Scheduled actions(예약된 작업)**에서 **Create scheduled action(예약된 작업 생성)**을 선택합니다.
1. 다음 예약된 작업 설정을 채웁니다.
1. 예약된 작업의 **이름**을 입력합니다.
1. **Min(최소)**에 Auto Scaling 그룹의 새 최소 용량을 입력합니다. **Min(최소)**은 그룹의 최대 크기보다 작거나 같아야 합니다. **Min(최소)**의 값이 그룹의 최대 크기보다 크면 **Max(최대)**를 업데이트해야 합니다.
1. **반복**에서 **1회(Once)**를 선택합니다.
1. **Time zone(표준 시간대)**에서 시간대를 선택합니다. 시간대를 선택하지 않으면 `ETC/UTC`가 기본적으로 사용됩니다.
1. **Specific start time(특정 시작 시간)**을 정의합니다.
1. **Create(생성)**를 선택합니다.
콘솔에 Auto Scaling 그룹에 대해 예약된 작업이 표시됩니다.
1. 이벤트 해지 시 원래 설정으로 되돌아 가도록 두 번째 예약된 작업을 구성합니다. 예측 조정은 **Min(최소)**에 대해 사용자가 설정한 값이 예상 값보다 작은 경우에만 용량을 조정합니다.
**일회성 이벤트에 대해 2개의 예약된 작업을 생성하려면(AWS CLI)**
AWS CLI 를 사용하여 예약된 작업을 생성하려면 [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령을 사용합니다.
예컨대, 5월 19일 오후 5시에 8시간 동안 최소 용량으로 인스턴스 3개를 유지하는 일정을 정의해 보겠습니다. 다음 명령은 이 시나리오를 구현하는 방법을 보여 줍니다.
첫 번째 [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령은 2021년 5월 19일 오후 5시(UTC)에 지정된 Auto Scaling 그룹의 최소 용량을 업데이트하도록 Amazon EC2 Auto Scaling에 지시합니다.
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
--auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```
두 번째 명령은 그룹의 최소 용량을 2021년 5월 20일 오전 1시(UTC)의 용량으로 설정하도록 Amazon EC2 Auto Scaling에 지시합니다.
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
--auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```
이러한 예약된 작업을 Auto Scaling 그룹에 추가하면 Amazon EC2 Auto Scaling은 다음을 수행합니다.
+ 2021년 5월 19일 오후 5시(UTC)에 첫 번째 예약된 작업이 실행됩니다. 현재 해당 그룹에 인스턴스가 3개 미만 있는 경우, 그룹은 인스턴스 3개로 스케일 아웃됩니다. 이 시간과 향후 8시간 동안 예측 용량이 실제 용량보다 높거나 동적 조정 정책이 적용되는 경우, Amazon EC2 Auto Scaling이 계속 스케일 아웃을 수행할 수 있습니다.
+ 2021년 5월 20일 오전 1시(UTC)에 두 번째 예약된 작업이 실행됩니다. 이렇게 하면 이벤트 해지 시 최소 용량이 원래 설정으로 돌아갑니다.
### 반복 일정에 따라 크기 조정
매주 동일한 기간에 대한 예상을 재정의하려면 두 개의 예약된 작업을 생성하고 cron 표현식을 사용하여 시간 및 날짜 로직을 제공합니다.
cron 표현식 형식은 다음과 같이 공백으로 구분된 다섯 개의 필드로 구성됩니다. [Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]. 필드에는 특수 문자를 포함하여 허용되는 모든 값을 포함할 수 있습니다.
예컨대, 다음 cron 표현식은 매주 화요일 오전 6시 30분에 작업을 실행합니다. 별표는 필드의 모든 값을 일치시키기 위한 와일드카드로 사용됩니다.
```
30 6 * * 2
```
### 다음 사항도 참조하세요.
예약된 작업을 생성, 열거, 편집 및 삭제하는 방법에 대한 자세한 설명은 [Amazon EC2 Auto Scaling에 예약된 조정](ec2-auto-scaling-scheduled-scaling.md) 섹션을 참조하세요.
# 사용자 정의 지표를 사용하는 고급 예측 조정 정책
예측적 조정 정책에서는 미리 정의된 지표나 사용자 정의 지표를 사용할 수 있습니다. 사용자 정의 지표는 미리 정의된 지표(CPU, 네트워크 I/O 및 Application Load Balancer 요청 수)가 애플리케이션 로드를 충분히 설명하지 못하는 경우에 유용합니다.
사용자 지정 지표를 사용하여 예측 조정 정책을 생성할 때에서 제공하는 다른 CloudWatch 지표를 지정 AWS하거나 직접 정의하고 게시하는 지표를 지정할 수 있습니다. 지표 수학을 사용하여 기존 지표를 집계하고 자동으로 추적되지 AWS 않는 새 시계열로 변환할 수도 있습니다. 예컨대, 새 합계 또는 평균을 계산하여 데이터의 값을 결합하는 것을 *집계*라고 합니다. 결과 데이터를 *집계*라고 합니다.
다음 섹션에는 정책의 JSON 구조를 구성하는 방법에 대한 모범 사례와 예가 나와 있습니다.
**Topics**
+ [모범 사례](#custom-metrics-best-practices)
+ [사전 조건](#custom-metrics-prerequisites)
+ [사용자 지정 지표를 위한 JSON 구성](construct-json-custom-metrics.md)
+ [예측 조정 정책에서 사용자 정의 지표 사용 시 고려 사항](custom-metrics-troubleshooting.md)
+ [제한 사항](#custom-metrics-limitations)
## 모범 사례
다음 모범 사례는 사용자 정의 지표를 보다 효과적으로 사용하는 데 도움이 될 수 있습니다.
+ 로드 지표 사양에서 가장 유용한 지표는 그룹의 용량에 관계없이 Auto Scaling 그룹 전체의 로드를 나타내는 지표입니다.
+ 조정 지표 사양의 경우, 가장 유용한 지표는 인스턴스당 평균 처리량 또는 사용률 지표입니다.
+ 조정 지표는 용량에 반비례해야 합니다. 즉, Auto Scaling 그룹의 인스턴스 수가 증가하면 조정 지표도 거의 같은 백분율로 감소해야 합니다. 예측적 조정이 예상대로 작동하게 하려면 로드 지표와 조정 지표도 서로 밀접한 상관 관계가 있어야 합니다.
+ 목표 사용률은 조정 지표 유형과 일치해야 합니다. CPU 사용률을 사용하는 정책 구성의 경우, 이는 목표 백분율입니다. 요청 또는 메시지 수와 같이 처리량을 사용하는 정책 구성의 경우, 이는 1분 간격 동안 인스턴스당 요청 또는 메시지의 대상 수입니다.
+ 이러한 권장 사항을 따르지 않으면 시계열의 예측된 미래 값이 정확하지 않을 수 있습니다. 데이터가 올바른지 검증하기 위해 Amazon EC2 Auto Scaling 콘솔에서 예측된 값을 볼 수 있습니다. 또는 예측적 조정 정책을 생성한 후 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_GetPredictiveScalingForecast.html) API 호출에서 반환된 `LoadForecast` 및 `CapacityForecast` 객체를 검사합니다.
+ 예측적 조정이 능동적으로 용량 조정을 시작하기 전에 예상을 평가할 수 있게 예상 전용 모드에서 예측적 조정을 구성하는 것이 좋습니다.
## 사전 조건
정책에서 사용자 지정 지표를 지정하려면 `cloudwatch:GetMetricData` 권한이 있어야 합니다.
에서 AWS 제공하는 지표 대신 자체 지표를 지정하려면 먼저 CloudWatch에 지표를 게시해야 합니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [사용자 정의 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)를 참조하세요.
자체 지표를 게시하는 경우, 최소 5분 간격으로 데이터 요소를 게시해야 합니다. Amazon EC2 Auto Scaling은 필요한 기간을 기준으로 CloudWatch에서 데이터 요소를 검색합니다. 예컨대, 로드 지표 사양은 시간별 지표를 사용하여 애플리케이션의 로드를 측정합니다. CloudWatch는 게시된 지표 데이터로 각 1시간 기간에 속하는 타임스탬프가 있는 모든 데이터 요소를 집계하여 1시간 기간 동안 단일 데이터 값을 제공합니다.
# 사용자 지정 지표를 위한 JSON 구성
다음 섹션에는 CloudWatch에서 데이터를 쿼리하도록 예측 조정을 구성하는 방법에 대한 예가 나와 있습니다. 이 옵션을 구성하는 방법에는 두 가지가 있으며 선택하는 방법에 따라 예측 조정 정책에 사용할 JSON을 구성하는 데 사용하는 형식이 달라집니다. 지표 수학을 사용하는 경우, JSON의 형식은 수행되는 지표 수학에 따라 더 달라집니다.
1. 에서 제공하는 다른 CloudWatch 지표 AWS 또는 CloudWatch에 게시하는 지표에서 직접 데이터를 가져오는 정책을 생성하려면 섹션을 참조하세요[사용자 지정 로드 및 조정 지표가 있는 예측 조정 정책의 예(AWS CLI)](#custom-metrics-ex1).
1. 여러 CloudWatch 지표를 쿼리하고 수학 표현식을 사용하여 이러한 지표에 근거하여 새 시계열을 생성할 수 있는 정책을 생성하려면 [지표 수학 표현식 사용](using-math-expression-examples.md)를 참조하세요.
## 사용자 지정 로드 및 조정 지표가 있는 예측 조정 정책의 예(AWS CLI)
를 사용하여 사용자 지정 로드 및 조정 지표를 사용하여 예측 조정 정책을 생성하려면 라는 JSON 파일에 `--predictive-scaling-configuration`에 대한 인수를 AWS CLI저장합니다`config.json`.
다음 예에서 교체 가능한 값을 지표 및 목표 사용률의 값으로 교체하여 사용자 지정 지표를 추가하기 시작합니다.
```
{
"MetricSpecifications": [
{
"TargetValue": 50,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "scaling_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyUtilizationMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Average"
}
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyLoadMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Sum"
}
}
]
}
}
]
}
```
자세한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)를 참조하세요.
**참고**
다음은 CloudWatch 지표에 대한 지표 이름, 네임스페이스, 차원 및 통계를 찾는 데 도움이 되는 몇 가지 추가 리소스입니다.
AWS 서비스에 사용할 수 있는 지표에 대한 자세한 내용은 Amazon [AWS CloudWatch 사용 설명서의 CloudWatch 지표를 게시하는 서비스를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) 참조하세요. *Amazon CloudWatch *
를 사용하여 CloudWatch 지표의 정확한 지표 이름, 네임스페이스 및 차원(해당하는 경우)을 가져오려면 [list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)를 AWS CLI참조하세요.
이 정책을 생성하려면 다음 예에 나와 있는 것처럼 JSON 파일을 입력으로 사용하여 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다.
```
aws autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
이 명령이 제대로 실행되면 정책의 Amazon 리소스 이름(ARN)을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
"Alarms": []
}
```
# 지표 수학 표현식 사용
다음 섹션에서는 정책에서 지표 수학을 사용하는 방법을 보여 주는 예측 조정 정책의 정보와 예를 제공합니다.
**Topics**
+ [지표 수학 이해](#custom-metrics-metric-math)
+ [지표 수학을 사용하여 지표를 결합하는 예측 조정 정책의 예(AWS CLI)](#custom-metrics-ex2)
+ [블루/그린 배치 시나리오에서 사용할 예측 조정 정책의 예(AWS CLI)](#custom-metrics-ex3)
## 지표 수학 이해
기존 지표 데이터를 집계하기만 하면 CloudWatch 지표 수학을 통해 CloudWatch에 다른 지표를 게시하는 데 드는 노력과 비용을 절약할 수 있습니다. 에서 AWS 제공하는 모든 지표를 사용할 수 있으며 애플리케이션의 일부로 정의한 지표를 사용할 수도 있습니다. 예컨대, 인스턴스당 Amazon SQS 대기열 백로그를 계산할 수 있습니다. 대기열에서 검색 가능한 대략적인 메시지 수를 가져와 Auto Scaling 그룹의 실행 용량으로 나누어 이를 수행할 수 있습니다.
자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요.
예측적 조정 정책에서 지표 수학 표현식을 사용하기로 선택한 경우, 다음 사항을 고려하세요.
+ 지표 수학 연산은 고유한 조합의 지표 이름, 네임스페이스 및 지표의 차원 키/값 페어의 데이터 요소를 사용합니다.
+ 산술 연산자(\$1 - \$1 / ^), 통계 함수(예: AVG 또는 SUM) 또는 CloudWatch에서 지원하는 기타 함수를 사용할 수 있습니다.
+ 수학 표현식의 공식에서 지표 및 다른 수학 표현식의 결과를 모두 사용할 수 있습니다.
+ 지표 수학 표현식은 다양한 집계로 구성될 수 있습니다. 그러나 최종 집계 결과에서 조정 지표에는 `Average`를 사용하고 로드 지표에는 `Sum`을 사용하는 것이 가장 좋습니다.
+ 지표 사양에 사용된 표현식은 결국 단일 시계열을 반환해야 합니다.
지표 수학을 사용하려면 다음을 수행합니다.
+ 하나 이상의 CloudWatch 지표를 선택합니다. 그런 다음 표현식을 생성합니다. 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요.
+ CloudWatch 콘솔 또는 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API를 사용하여 지표 수학 표현식이 유효한지 확인합니다.
## 지표 수학을 사용하여 지표를 결합하는 예측 조정 정책의 예(AWS CLI)
지표를 직접 지정하는 대신 어떤 방식으로든 해당 데이터를 먼저 처리해야 하는 경우가 있습니다. 예컨대, Amazon SQS 대기열에서 작업을 가져오는 애플리케이션이 있고 대기열의 항목 수를 예측적 조정의 기준으로 사용할 수 있습니다. 대기열의 메시지 수가 필요한 인스턴스 수를 단독으로 정의하지 않습니다. 따라서 인스턴스당 백로그를 계산하는 데 사용할 수 있는 지표를 생성하려면 더 많은 작업이 필요합니다. 자세한 설명은 [Amazon SQS 기반 조정 정책](as-using-sqs-queue.md) 섹션을 참조하세요.
다음은 이 시나리오에 대한 예측적 조정 정책의 예입니다. 대기열에서 검색할 수 있는 메시지 수인 Amazon SQS `ApproximateNumberOfMessagesVisible` 지표를 기준으로 하는 조정 및 로드 지표를 지정합니다. 또한 Amazon EC2 Auto Scaling `GroupInServiceInstances` 지표와 수학 표현식을 사용하여 조정 지표에 대한 인스턴스당 백로그를 계산합니다.
```
aws autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"MetricSpecifications": [
{
"TargetValue": 100,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "queue_size",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Get the group size (the number of running instances)",
"Id": "running_capacity",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "scaling_metric",
"Expression": "queue_size / running_capacity",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
],
},
"Stat": "Sum"
},
"ReturnData": true
}
]
}
}
]
}
```
이 예에서는 정책의 ARN을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
"Alarms": []
}
```
## 블루/그린 배치 시나리오에서 사용할 예측 조정 정책의 예(AWS CLI)
검색 표현식은 여러 Auto Scaling 그룹에서 지표를 쿼리하고 이에 대해 수학 표현식을 수행할 수 있는 고급 옵션을 제공합니다. 이는 특히 블루/그린 배치에 유용합니다.
**참고**
*블루/그린 배치*는 두 개의 별개이지만 동일한 Auto Scaling 그룹을 생성하는 배치 방법입니다. 그룹 중 하나만 프로덕션 트래픽을 수신합니다. 사용자 트래픽은 초기에 이전("블루") Auto Scaling 그룹으로 전달되는 반면 새 그룹("그린")은 새 버전의 애플리케이션 또는 서비스를 테스트하고 평가하는 데 사용됩니다. 새 배치가 테스트되고 수락되면 사용자 트래픽이 그린 Auto Scaling 그룹으로 이동됩니다. 그런 다음 배치가 성공한 후 블루 그룹을 삭제할 수 있습니다.
새로운 Auto Scaling 그룹이 블루/그린 배치의 일부로 생성되면 해당 지표 사양을 변경하지 않고도 각 그룹의 지표 기록이 예측적 조정 정책에 자동으로 포함될 수 있습니다. 자세한 내용은 AWS 컴퓨팅 블로그의 [블루/그린 배포와 함께 EC2 Auto Scaling 예측 조정 정책 사용을 참조하세요](https://aws.amazon.com/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/).
다음 예 정책은 이를 수행하는 방법을 보여줍니다. 이 예에서 정책은 Amazon EC2에서 내보낸 `CPUUtilization` 지표를 사용합니다. Amazon EC2 Auto Scaling `GroupInServiceInstances` 지표와 수학 표현식을 사용하여 인스턴스당 조정 지표 값을 계산합니다. 또한 `GroupInServiceInstances` 지표를 가져오기 위한 용량 지표 사양을 지정합니다.
검색 표현식은 지정된 검색 기준에 따라 여러 Auto Scaling 그룹에서 인스턴스의 `CPUUtilization`을 찾습니다. 나중에 동일한 검색 기준과 일치하는 새 Auto Scaling 그룹을 생성하면 새 Auto Scaling 그룹에 있는 인스턴스의 `CPUUtilization`이 자동으로 포함됩니다.
```
aws autoscaling put-scaling-policy --policy-name my-blue-green-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"MetricSpecifications": [
{
"TargetValue": 25,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 300))",
"ReturnData": false
},
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))",
"ReturnData": false
},
{
"Id": "weighted_average",
"Expression": "load_sum / capacity_sum",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 3600))"
}
]
},
"CustomizedCapacityMetricSpecification": {
"MetricDataQueries": [
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))"
}
]
}
}
]
}
```
이 예에서는 정책의 ARN을 반환합니다.
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-blue-green-predictive-scaling-policy",
"Alarms": []
}
```
# 예측 조정 정책에서 사용자 정의 지표 사용 시 고려 사항
사용자 정의 지표를 사용하는 동안 문제가 발생하면 다음을 수행하는 것이 좋습니다.
+ 오류 메시지가 제공되면 메시지를 읽고 가능한 경우, 보고된 문제를 해결하세요.
+ 블루/그린 배치 시나리오에서 검색 표현식을 사용하려고 할 때 문제가 발생하는 경우, 먼저 정확히 일치 대신 부분 일치를 찾는 검색 표현식을 생성하는 방법을 알고 있어야 합니다. 또한 쿼리가 특정 애플리케이션을 실행 중인 Auto Scaling 그룹만 찾는지 확인합니다. 검색 표현식 구문에 대한 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [CloudWatch 검색 표현식 구문](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)을 참조하세요.
+ 표현식을 사전에 검증하지 않은 경우, 조정 정책을 생성할 때 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 명령이 표현식을 검증합니다. 그러나 이 명령이 발견된 오류의 정확한 원인을 식별하지 못할 수도 있습니다. 문제를 해결하려면 [get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/get-metric-data.html) 명령에 대한 요청의 응답에서 수신하는 오류를 해결합니다. CloudWatch 콘솔에서 표현식의 문제를 해결할 수도 있습니다.
+ 콘솔에서 **로드(Load)** 및 **용량(Capacity)** 그래프를 볼 때 **용량(Capacity)** 그래프에 데이터가 표시되지 않을 수 있습니다. 그래프에 완전한 데이터가 있는지 확인하려면 Auto Scaling 그룹에 대해 그룹 지표를 일관되게 사용 설정해야 합니다. 자세한 설명은 [Auto Scaling 그룹 지표 활성화(콘솔)](ec2-auto-scaling-metrics.md#as-enable-group-metrics) 섹션을 참조하세요.
+ 용량 지표 사양은 수명 동안 서로 다른 Auto Scaling 그룹에서 실행되는 애플리케이션이 있는 경우, 블루/그린 배치에만 유용합니다. 이 사용자 정의 지표를 사용하면 여러 Auto Scaling 그룹의 총 용량을 제공할 수 있습니다. 예측적 조정은 이를 사용하여 콘솔의 **용량(Capacity)** 그래프에 기록 데이터를 표시합니다.
+ `MetricDataQueries`가 SUM()과 같은 수학 함수 없이 자체적으로 SEARCH() 함수를 지정하는 경우, `ReturnData`에 대해 `false`를 지정해야 합니다. 이는 검색 표현식이 여러 시계열을 반환할 수 있고 표현식에 근거하여 하는 지표 사양이 하나의 시계열만 반환할 수 있기 때문입니다.
+ 검색 표현식과 관련된 모든 지표는 해상도가 동일해야 합니다.
## 제한 사항
+ 하나의 지표 사양에서 최대 10개 지표의 데이터 요소를 쿼리할 수 있습니다.
+ 이 제한을 위해 하나의 표현식이 하나의 지표로 계산됩니다.
# 축소 시 해지할 Auto Scaling 인스턴스 제어
Amazon EC2 Auto Scaling은 종료 정책을 사용하여 인스턴스 종료 순서를 결정합니다. 사전 정의된 정책을 사용하거나 특정 요구 사항을 충족하는 사용자 지정 정책을 생성할 수 있습니다. 또한 사용자 지정 정책 또는 인스턴스 스케일 인 보호를 사용하면 Auto Scaling 그룹이 아직 종료할 준비가 되지 않은 인스턴스를 종료하지 못하게 할 수 있습니다.
**Topics**
+ [Amazon EC2 Auto Scaling에서 종료 정책을 사용하는 경우](#common-scenarios-termination)
+ [Amazon EC2 Auto Scaling의 종료 정책 구성](ec2-auto-scaling-termination-policies.md)
+ [Lambda를 사용하여 사용자 지정 해지 정책 생성](lambda-custom-termination-policy.md)
+ [인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어](ec2-auto-scaling-instance-protection.md)
+ [인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md)
## Amazon EC2 Auto Scaling에서 종료 정책을 사용하는 경우
다음 섹션에서는 Amazon EC2 Auto Scaling에서 해지 정책을 사용하는 시나리오에 대해 설명합니다.
**Topics**
+ [스케일 인 이벤트](#common-scenarios-termination-scale-in)
+ [인스턴스 새로 고침](#common-scenarios-termination-instance-refreshes)
+ [가용 영역 재조정](#common-scenarios-termination-rebalancing)
### 스케일 인 이벤트
Auto Scaling 그룹의 원하는 용량에 대한 새 값이 그룹의 현재 용량보다 작은 경우 스케일 인 이벤트가 발생합니다.
다음과 같은 시나리오에서 스케일 인 이벤트가 발생합니다.
+ 동적 조정 정책을 사용할 때 지표 값의 변화로 그룹 크기가 줄어드는 경우
+ 예약된 조정을 사용할 때 예약된 작업의 결과로 그룹 크기가 줄어드는 경우
+ 그룹의 크기를 수동으로 줄이는 경우
다음 예에서는 스케일 인 이벤트가 있을 때 종료 정책이 작동하는 방식을 보여줍니다.
1. 이 예의 Auto Scaling 그룹에는 인스턴스 유형 1개와 가용 영역 2개가 있고 원하는 용량은 인스턴스 2개입니다. 또한 리소스 사용률이 증가하거나 감소할 때 인스턴스를 추가 및 제거하는 동적 조정 정책이 있습니다. 이 그룹에 있는 인스턴스 2개는 다음 다이어그램에 표시된 것처럼 가용 영역 2개에 분산됩니다.
![\[인스턴스가 두 개인 기본 Auto Scaling 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/termination-policy-default-diagram.png)
1. Auto Scaling 그룹이 스케일 아웃되면 Amazon EC2 Auto Scaling은 새 인스턴스를 시작합니다. 이제 Auto Scaling 그룹에 있는 인스턴스 3개가 다음 다이어그램에 표시된 것처럼 가용 영역 2개에 분산됩니다.
![\[인스턴스 한 개로 스케일 아웃한 후의 Auto Scaling 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/termination-policy-default-2-diagram.png)
1. Auto Scaling 그룹이 축소되면 Amazon EC2 Auto Scaling이 인스턴스 중 하나를 해지합니다.
1. 그룹에 특정 해지 정책을 할당하지 않은 경우, Amazon EC2 Auto Scaling에서는 기본 해지 정책을 사용합니다. 인스턴스가 두 개인 가용 영역을 선택하고 시작 구성, 다른 시작 템플릿 또는 가장 오래된 버전의 현재 시작 템플릿에서 시작된 인스턴스를 종료합니다. 인스턴스가 동일한 시작 템플릿 및 버전에서 시작된 경우, Amazon EC2 Auto Scaling은 다음 청구 시간에 가장 근접한 인스턴스를 선택한 후 이를 종료합니다.
![\[인스턴스 한 개로 스케일 인한 후의 Auto Scaling 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/termination-policy-default-3-diagram.png)
### 인스턴스 새로 고침
인스턴스 새로 고침을 시작하여 Auto Scaling 그룹의 인스턴스를 업데이트할 수 있습니다. 인스턴스 새로 고침 중에 Amazon EC2 Auto Scaling은 그룹의 인스턴스를 해지한 다음 해지된 인스턴스에 대한 교체를 시작합니다. Auto Scaling 그룹의 해지 정책은 먼저 교체되는 인스턴스를 제어합니다.
### 가용 영역 재조정
Amazon EC2 Auto Scaling은 Auto Scaling 그룹에 대해 활성화된 가용 영역 전체에서 용량을 균등하게 조정합니다. 이를 통해 가용 영역 중단으로 인한 영향을 줄일 수 있습니다. 가용 영역 간 용량 분배가 균형이 맞지 않을 경우, Amazon EC2 Auto Scaling은 인스턴스 수가 가장 적은 활성 가용 영역에서 인스턴스를 시작하고 다른 곳에서 인스턴스를 해지하여 Auto Scaling 그룹의 용량 균형을 조정합니다. 해지 정책은 어떤 인스턴스를 가장 먼저 해지할지 우선순위를 제어합니다.
여러 가용 영역에 걸쳐 인스턴스 배치의 균형이 깨지는 데에는 여러 가지 이유가 있습니다.
인스턴스 제거
Auto Scaling 그룹에서 인스턴스를 분리하거나, 인스턴스를 대기 상태로 전환하거나, 인스턴스를 명시적으로 해지하고 원하는 용량을 줄이면 교체 인스턴스가 시작되지 않으므로 그룹의 균형이 깨질 수 있습니다. 이 경우, Amazon EC2 Auto Scaling이 가용 영역을 재조정하여 보상합니다.
원래 지정한 가용 영역과 다른 가용 영역 사용
추가 가용 영역을 포함하도록 Auto Scaling 그룹을 스케일 아웃하거나 사용할 가용 영역을 변경하면 Amazon EC2 Auto Scaling은 새 가용 영역에서 인스턴스를 시작하고 다른 영역의 인스턴스를 해지하여 인스턴스가 가용 영역에 고르게 분산되도록 합니다.
가용성 중단
가용성 중단은 거의 발생하지 않습니다. 그러나 하나의 가용 영역이 사용할 수 없게 되어 나중에 복구되면 Auto Scaling 그룹이 가용 영역 간에 불균형하게 분배될 수 있습니다. Amazon EC2 Auto Scaling은 그룹을 점진적으로 재조정하려고 시도하고 재조정 시 다른 영역의 인스턴스가 해지될 수 있습니다.
인스턴스 유형이 1개, 가용 영역이 2개가 있고, 원하는 용량이 인스턴스 2개인 Auto Scaling 그룹이 있는 경우를 예로 들어 보겠습니다. 하나의 가용 영역에 장애가 발생하는 경우, Amazon EC2 Auto Scaling은 정상 가용 영역에서 새 인스턴스를 자동으로 시작하여 비정상 가용 영역의 인스턴스를 교체합니다. 비정상 가용 영역이 나중에 건전 상태로 전환되면 Amazon EC2 Auto Scaling은 이 영역에서 새 인스턴스를 자동으로 시작합니다. 이로 인해 영향을 받지 않는 영역의 인스턴스가 해지됩니다.
**참고**
재조정 시 Amazon EC2 Auto Scaling에서는 이전 인스턴스를 해지하기 전에 새 인스턴스를 시작하여 재조정로 인해 애플리케이션의 성능이나 가용성이 저하되지 않도록 합니다.
Amazon EC2 Auto Scaling에서는 이전 인스턴스 해지 전에 새 인스턴스를 시작하려 하므로 지정된 최대 용량에 도달하거나 이에 근접하면 재조정 활동을 지연시키거나 완전히 중지할 수 있습니다. 이 문제를 피하기 위해 시스템에서는 재조정 활동 중에 그룹의 지정된 최대 용량을 10% 여유(또는 인스턴스 1개의 여유 중 큰 쪽)만큼 일시적으로 초과할 수 있습니다. 그룹이 최대 용량에 도달하거나 이에 근접하여 재조정가 필요한 경우, 또는 사용자 요청에 의한 영역 재조정이나 영역 가용성 문제에 대처하기 위한 경우에만 이 여유분만큼 스케일 아웃됩니다. 스케일 아웃은 그룹에 재조정가 필요한 동안에만 유지됩니다.
# Amazon EC2 Auto Scaling의 종료 정책 구성
종료 정책은 Amazon EC2 Auto Scaling이 특정 순서로 인스턴스를 종료하기 위해 따르는 기준을 제공합니다. 기본적으로 Amazon EC2 Auto Scaling은 오래된 구성을 사용하는 인스턴스를 먼저 종료하도록 설계된 종료 정책을 사용합니다. 종료 정책을 변경하여 먼저 종료하는 것이 가장 중요한 인스턴스를 제어할 수 있습니다.
Amazon EC2 Auto Scaling이 인스턴스를 종료하면 Auto Scaling 그룹에서 사용 가능한 가용 영역 간에 균형을 유지하려고 합니다. 영역 간 균형 유지가 종료 정책보다 우선합니다. 하나의 가용 영역에 다른 가용 영역보다 많은 인스턴스가 있는 경우 Amazon EC2 Auto Scaling은 먼저 불균형한 영역에 종료 정책을 적용합니다. 가용 영역이 균형을 이루면 모든 영역에 종료 정책을 적용합니다.
**Topics**
+ [기본 종료 정책의 작동 방식](#default-termination-policy)
+ [기본 해지 정책 및 혼합 인스턴스 그룹](#default-termination-policy-mixed-instances-groups)
+ [사전 정의된 종료 정책](#predefined-termination-policies)
+ [Auto Scaling 그룹의 종료 정책 변경](custom-termination-policy.md)
**참고**
Amazon EC2 Auto Scaling은 Auto Scaling 그룹에 의해 비정상으로 간주되지 않는 인스턴스에만 종료 정책을 적용합니다. 따라서 Auto Scaling 상태 확인에서 비정상으로 표시된 인스턴스는 종료 정책 평가를 우회합니다.
자세한 내용은 [인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md) 단원을 참조하십시오.
## 기본 종료 정책의 작동 방식
Amazon EC2 Auto Scaling이 인스턴스를 종료해야 하는 경우, 먼저 인스턴스가 가장 많고 스케일 인으로부터 보호되지 않는 인스턴스가 하나 이상 있는 가용 영역(또는 영역)을 식별합니다. 그런 다음, 다음과 같이 식별된 가용 영역 내에서 보호되지 않은 인스턴스를 평가합니다.
**오래된 구성을 사용하는 인스턴스**
+ **시작 템플릿을 사용하는 그룹** - 다음 순서대로 우선순위를 지정하여 인스턴스가 오래된 구성을 사용할지 여부를 결정합니다.
1. 먼저 시작 구성으로 시작된 인스턴스를 확인합니다.
1. 그런 다음 현재 시작 템플릿 대신 다른 시작 템플릿을 사용하여 시작된 인스턴스를 확인합니다.
1. 마지막으로 현재 시작 템플릿의 가장 오래된 버전을 사용하는 인스턴스를 확인합니다.
+ **시작 구성을 사용하는 그룹의** - 인스턴스 중 가장 오래된 시작 구성을 사용할지 여부를 결정합니다.
오래된 구성을 사용하는 인스턴스를 찾을 수 없거나 선택할 수 있는 인스턴스가 여러 개 있는 경우, Amazon EC2 Auto Scaling은 다음 청구 시간에 근접하는 인스턴스의 다음 기준을 고려합니다.
**다음 청구 시간에 근접하는 인스턴스**
이전 기준을 충족하는 인스턴스 중 다음 청구 시간에 가장 가까운 것이 있는지 확인합니다. 여러 인스턴스가 똑같이 닫히면 한 인스턴스를 무작위로 종료합니다. 시간제로 요금이 청구되는 인스턴스의 사용을 극대화하는 데 도움이 됩니다. 하지만 이제 대부분의 EC2 사용량이 초 단위로 청구되므로 이 최적화로 인한 이점이 감소합니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요.
다음 흐름도는 시작 템플릿을 사용하는 그룹의 기본 종료 정책이 작동하는 방식을 보여줍니다.
![\[Auto Scaling 그룹이 기본 종료 정책을 사용하여 인스턴스를 종료하는 방법을 보여주는 흐름도입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/termination-policy-default-flowchart-diagram.png)
## 기본 해지 정책 및 혼합 인스턴스 그룹
Amazon EC2 Auto Scaling은 [혼합 인스턴스 그룹](ec2-auto-scaling-mixed-instances-groups.md)에서 인스턴스를 종료할 때 추가 기준을 적용합니다.
Amazon EC2 Auto Scaling에서 인스턴스를 종료해야 하는 경우 먼저 그룹의 설정에 따라 종료해야 하는 구매 옵션(스팟 또는 온디맨드)을 식별합니다. 이렇게 하면 시간이 지남에 따라 그룹이 스팟 및 온디맨드 인스턴스의 지정된 비율을 향하는 추세를 보이게 됩니다.
그런 다음 각 가용 영역에서 종료 정책을 개별적으로 적용합니다. 가용 영역의 균형을 유지하기 위해 가용 영역을 종료할 스팟 또는 온디맨드 인스턴스를 결정합니다. 인스턴스 유형에 대해 정의된 가중치와 함께 혼합 인스턴스 그룹에도 동일한 논리가 적용됩니다.
각 영역 내에서 기본 종료 정책은 다음과 같이 작동하여 식별된 구매 옵션 내에서 종료할 수 있는 보호되지 않는 인스턴스를 결정합니다.
1. Auto Scaling 그룹에 대해 지정된 [할당 전략](allocation-strategies.md)에 따른 조정을 개선하기 위해 인스턴스를 종료할 수 있는지 여부를 결정합니다. 최적화할 인스턴스가 식별되지 않았거나 선택할 인스턴스가 여러 개 있는 경우, 평가가 계속됩니다.
1. 다음 순서대로 우선순위를 지정하여 인스턴스가 오래된 구성을 사용할지 여부를 결정합니다.
1. 먼저 시작 구성으로 시작된 인스턴스를 확인합니다.
1. 그런 다음 현재 시작 템플릿 대신 다른 시작 템플릿을 사용하여 시작된 인스턴스를 확인합니다.
1. 마지막으로 현재 시작 템플릿의 가장 오래된 버전을 사용하는 인스턴스를 확인합니다.
오래된 구성이 있는 인스턴스를 찾을 수 없거나 선택할 수 있는 인스턴스가 여러 개 있는 경우, 평가가 계속됩니다.
1. 인스턴스 중 다음 청구 시간에 가장 가까운 인스턴스가 있는지 확인합니다. 여러 인스턴스가 똑같이 가까운 경우 무작위로 하나를 선택합니다.
## 사전 정의된 종료 정책
다음과 같은 사전 정의된 종료 정책 중에서 선택합니다.
+ **`Default`** - 기본 종료 정책에 따라 인스턴스를 종료합니다.
+ **`AllocationStrategy`** - Auto Scaling 그룹의 인스턴스를 종료하여 종료 중인 인스턴스 유형(스팟 인스턴스 또는 온디맨드 인스턴스)에 대한 할당 전략에 나머지 인스턴스를 맞춥니다. 이 정책은 선호하는 인스턴스 유형이 변경된 경우, 유용합니다. 스팟 할당 전략이 `lowest-price`인 경우, 최저가 스팟 풀 N개 전체에서 스팟 인스턴스 배치를 점차 재조정할 수 있습니다. 스팟 할당 전략이 `capacity-optimized`인 경우, 사용 가능한 스팟 용량이 더 여유 있는 스팟 풀에서 스팟 인스턴스 배치를 점차 재조정할 수 있습니다. 또한 점차 우선순위가 낮은 유형의 온디맨드 인스턴스를 우선순위가 높은 유형의 온디맨드 인스턴스로 교체할 수 있습니다.
+ **`OldestLaunchTemplate`** - 가장 오래된 시작 템플릿이 있는 인스턴스를 종료합니다. 이 정책을 사용하는 경우, 최신이 아닌 시작 템플릿을 사용하는 인스턴스가 먼저 해지되고 나서 최신 시작 템플릿의 가장 오래된 버전을 사용하는 인스턴스가 해지됩니다. 이 정책은 그룹을 업데이트하고 이전 구성에서 인스턴스를 단계적으로 해지할 때 유용합니다.
+ **`OldestLaunchConfiguration`** - 가장 오래된 시작 구성이 있는 인스턴스를 종료합니다. 이 정책은 그룹을 업데이트하고 이전 구성에서 인스턴스를 단계적으로 해지할 때 유용합니다. 이 정책을 사용하는 경우, 최신이 아닌 시작 구성을 사용하는 인스턴스가 먼저 해지됩니다.
+ **`ClosestToNextInstanceHour`** - 다음 청구 시간에 가장 근접한 인스턴스를 종료합니다. 이 정책은 시간제로 요금이 청구되는 인스턴스의 사용을 극대화할 수 있도록 합니다.
+ **`NewestInstance`** - 그룹에서 가장 새로운 인스턴스를 종료합니다. 이 정책은 새로운 시작 구성을 테스트하지만 프로덕션 상태로 유지하고 싶지 않은 경우에 유용합니다.
+ **`OldestInstance`** - 그룹에서 가장 오래된 인스턴스를 종료합니다. 이 옵션은 Auto Scaling 그룹의 인스턴스를 새로운 EC2 인스턴스 유형으로 업그레이드할 때 유용합니다. 따라서 이전 유형의 인스턴스를 새로운 유형의 인스턴스로 점진적으로 교체할 수 있습니다.
**참고**
Amazon EC2 Auto Scaling은 사용 중인 해지 정책과 관계없이 항상 가용 영역 전반에서 인스턴스를 먼저 조정합니다. 따라서 일부 최신 인스턴스가 이전 인스턴스보다 먼저 해지되는 상황이 발생할 수 있습니다. 최근에 추가된 가용 영역이 있거나 가용 영역에 그룹에서 사용하는 다른 가용 영역 외에 추가 인스턴스가 있는 경우를 예로 들 수 있습니다.
# Auto Scaling 그룹의 종료 정책 변경
Auto Scaling 그룹의 종료 정책을 변경하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
Amazon EC2 Auto Scaling 콘솔에서 Auto Scaling 그룹을 처음 생성할 때는 종료 정책을 변경할 수 없습니다. 기본 해지 정책이 자동으로 사용됩니다. Auto Scaling 그룹을 생성한 후, 기본 정책을 적용해야 하는 순서대로 나열된 다른 종료 정책 또는 여러 종료 정책으로 바꿀 수 있습니다.
**Auto Scaling 그룹의 종료 정책을 변경하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보** 탭에서 **고급 구성**, **편집을** 선택합니다.
1. **해지 정책**에서 하나 이상의 해지 정책을 선택합니다. 여러 정책을 선택하는 경우, 평가하려는 순서대로 정책을 배치합니다.
필요에 따라 **사용자 정의 해지 정책(Custom termination policy)**을 선택한 다음 필요에 맞는 Lambda 함수를 선택할 수 있습니다. Lambda 함수에 대한 버전 및 별칭을 생성한 경우, **버전/별칭(Version/Alias)** 드롭다운에서 버전 또는 별칭을 선택할 수 있습니다. 게시되지 않은 버전의 Lambda 함수를 사용하려면 **버전/별칭(Version/Alias)**을 기본값으로 설정된 상태로 둡니다. 자세한 설명은 [Lambda를 사용하여 사용자 지정 해지 정책 생성](lambda-custom-termination-policy.md) 섹션을 참조하세요.
**참고**
여러 정책을 사용하는 경우, 해당 순서를 올바르게 설정해야 합니다.
**기본(Default)** 정책을 사용할 경우, 목록에서 기본 정책이어야 합니다.
**사용자 정의 해지 정책(Custom termination policy)**을 사용하는 경우, 목록의 첫 번째 정책이어야 합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
다른 정책을 지정하지 않으면 기본 해지 정책이 자동으로 사용됩니다.
**Auto Scaling 그룹의 종료 정책을 변경하려면**
다음 명령 중 하나를 사용합니다.
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)
해지 정책은 개별적으로 사용하거나 정책 목록으로 결합할 수 있습니다. 예컨대, 다음 명령으로 Auto Scaling 그룹을 업데이트하여 먼저 `OldestLaunchConfiguration` 정책을 사용한 다음 `ClosestToNextInstanceHour` 정책을 사용합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --termination-policies "OldestLaunchConfiguration" "ClosestToNextInstanceHour"
```
`Default` 해지 정책을 사용하는 경우, 이 정책이 해지 정책 목록의 맨 마지막에 오도록 합니다. 예를 들어 `--termination-policies "OldestLaunchConfiguration" "Default"`입니다.
사용자 지정 종료 정책을 사용하려면 먼저를 사용하여 종료 정책을 생성해야 합니다 AWS Lambda. 해지 정책으로 사용할 Lambda 함수를 지정하려면 해지 정책 목록의 첫 번째 항목을 지정합니다. 예를 들어 `--termination-policies "arn:aws:lambda:us-west-2:123456789012:function:HelloFunction:prod" "OldestLaunchConfiguration"`입니다. 자세한 설명은 [Lambda를 사용하여 사용자 지정 해지 정책 생성](lambda-custom-termination-policy.md) 섹션을 참조하세요.
------
# Lambda를 사용하여 사용자 지정 해지 정책 생성
Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 크기를 줄일 때(*스케일 인*이라고 함) 해지 정책을 사용하여 먼저 해지할 인스턴스의 우선순위를 지정합니다. Auto Scaling 그룹은 기본 해지 정책을 사용하지만, 사용자는 자체 해지 정책을 선택하거나 생성할 수 있습니다. 미리 정의된 해지 정책을 선택하는 방법에 대한 자세한 설명은 [Amazon EC2 Auto Scaling의 종료 정책 구성](ec2-auto-scaling-termination-policies.md) 섹션을 참조하세요.
이 주제에서는 Amazon EC2 Auto Scaling이 특정 이벤트에 대한 응답으로 호출하는 AWS Lambda 함수를 사용하여 사용자 지정 해지 정책을 생성하는 방법을 알아봅니다. 생성한 Lambda 함수는 Amazon EC2 Auto Scaling에서 전송한 입력 데이터의 정보를 처리하고 해지할 준비가 된 인스턴스 목록을 반환합니다.
사용자 지정 해지 정책은 해지되는 인스턴스와 해지 시점을 보다 효과적으로 제어할 수 있습니다. 예컨대, Auto Scaling 그룹이 축소되면 Amazon EC2 Auto Scaling은 중단되면 안 되는 워크로드가 실행 중인지 확인할 수 없습니다. Lambda 함수를 사용하면 해지 요청의 유효성을 검사하고 워크로드가 완료될 때까지 기다린 후 해지를 위해 인스턴스 ID를 Amazon EC2 Auto Scaling에 반환합니다.
**Topics**
+ [입력 데이터](#lambda-custom-termination-policy-input-data)
+ [응답 데이터](#lambda-custom-termination-policy-response-data)
+ [고려 사항](#lambda-termination-policy-considerations)
+ [Lambda 함수 생성](#lambda-custom-termination-policy-create-function)
+ [제한 사항](#lambda-custom-termination-policy-limitations)
## 입력 데이터
Amazon EC2 Auto Scaling은 스케일 인 이벤트에 대한 JSON 페이로드를 생성하며, 최대 인스턴스 수명 또는 인스턴스 새로 고침 기능으로 인해 인스턴스가 종료되려고 할 때도 이를 수행합니다. 또한 가용 영역에서 그룹을 재조정할 때 시작할 수 있는 스케일 인 이벤트에 대한 JSON 페이로드를 생성합니다.
이 페이로드에는 Amazon EC2 Auto Scaling이 해지하는 데 필요한 용량, 해지를 제안하는 인스턴스 목록 및 해지를 시작한 이벤트에 대한 정보가 포함되어 있습니다.
다음은 페이로드 예입니다.
```
{
"AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1::autoScalingGroup:d4738357-2d40-4038-ae7e-b00ae0227003:autoScalingGroupName/my-asg",
"AutoScalingGroupName": "my-asg",
"CapacityToTerminate": [
{
"AvailabilityZone": "us-east-1b",
"Capacity": 2,
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1b",
"Capacity": 1,
"InstanceMarketOption": "spot"
},
{
"AvailabilityZone": "us-east-1c",
"Capacity": 3,
"InstanceMarketOption": "on-demand"
}
],
"Instances": [
{
"AvailabilityZone": "us-east-1b",
"InstanceId": "i-0056faf8da3e1f75d",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1c",
"InstanceId": "i-02e1c69383a3ed501",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1c",
"InstanceId": "i-036bc44b6092c01c7",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
...
],
"Cause": "SCALE_IN"
}
```
페이로드에는 Auto Scaling 그룹의 이름, Amazon 리소스 이름(ARN) 및 다음 요소가 포함됩니다.
+ `CapacityToTerminate`는 지정된 가용 영역에서 해지되도록 설정된 스팟 또는 온디맨드 용량의 양을 지정합니다.
+ `Instances`는 `CapacityToTerminate`의 정보를 바탕으로 Amazon EC2 Auto Scaling에서 해지를 제안하는 인스턴스를 나타냅니다.
+ `Cause`는 해지를 야기한 이벤트를 지정합니다(`SCALE_IN`, `INSTANCE_REFRESH`, `MAX_INSTANCE_LIFETIME` 또는 `REBALANCE`).
다음 정보는 Amazon EC2 Auto Scaling이 입력 데이터에서 `Instances`를 생성하는 방법의 가장 중요한 요소를 설명합니다.
+ 스케일 인 이벤트 및 인스턴스 새로 고침 기반 종료로 인해 인스턴스가 종료되는 경우에는 가용 영역 간 균형 유지가 우선합니다. 가용 영역 하나의 인스턴스 수가 그룹에서 사용하는 그 외 가용 영역보다 많으면 입력 데이터에는 균형이 맞지 않는 가용 영역의 해지 대상 인스턴스만 포함됩니다. 그룹에서 사용하는 가용 영역이 균형 잡힌 경우, 입력 데이터에는 해당 그룹에 대한 모든 가용 영역의 인스턴스가 포함됩니다.
+ [혼합 인스턴스 정책](ec2-auto-scaling-mixed-instances-groups.md)을 사용하는 경우, 각 구매 옵션에 대해 원하는 백분율을 기준으로 스팟 및 온디맨드 용량을 균형 있게 유지하는 것이 우선합니다. 먼저 둘(스팟 또는 온디맨드) 중 어떤 유형이 해지되어야 하는지 확인합니다. 그런 다음 가용 영역의 균형을 가장 잘 유지하기 위해 어떤 가용 영역 내에서 (식별된 구매 옵션 내) 어떤 인스턴스를 해지할지 파악합니다.
## 응답 데이터
입력 데이터와 응답 데이터는 함께 작동하여 해지할 인스턴스 목록의 범위를 좁힙니다.
주어진 입력을 사용하면 Lambda 함수의 응답은 다음 예와 같아야 합니다.
```
{
"InstanceIDs": [
"i-02e1c69383a3ed501",
"i-036bc44b6092c01c7",
...
]
}
```
이 응답에서 `InstanceIDs`는 해지할 준비가 된 인스턴스를 나타냅니다.
또는 해지 준비가 된 다른 인스턴스 세트를 반환하여 입력 데이터의 인스턴스를 재정의할 수 있습니다. Lambda 함수가 호출될 때 해지할 준비가 된 인스턴스가 없으면 인스턴스를 반환하지 않도록 선택할 수도 있습니다.
해지할 준비가 된 인스턴스가 없는 경우, Lambda 함수의 응답은 다음 예와 같아야 합니다.
```
{
"InstanceIDs": [ ]
}
```
## 고려 사항
사용자 지정 해지 정책을 사용하는 경우, 다음 고려 사항에 유의하세요.
+ 응답 데이터에서 인스턴스를 먼저 반환한다고 해서 해당 인스턴스가 해지되는 것은 아닙니다. Lambda 함수를 호출할 때 필요한 수 이상의 인스턴스가 반환되는 경우, Amazon EC2 Auto Scaling은 Auto Scaling 그룹에 대해 지정한 다른 해지 정책을 기준으로 각 인스턴스를 평가합니다. 여러 해지 정책이 있는 경우에는 목록에 있는 그다음 해지 정책을 적용하려고 하고 해지해야 하는 것보다 인스턴스 수가 더 많으면 다음 해지 정책으로 이동합니다. 지정된 다른 해지 정책이 없는 경우, 기본 해지 정책을 사용하여 해지할 인스턴스를 결정합니다.
+ 인스턴스가 반환되지 않거나 Lambda 함수가 시간 초과되면 Amazon EC2 Auto Scaling은 잠시 기다렸다가 함수를 다시 호출합니다. 스케일 인 이벤트의 경우, 그룹의 원하는 용량이 현재 용량보다 작으면 계속 시도합니다. 인스턴스 새로 고침 기반 해지의 경우, 한 시간 동안 계속 시도합니다. 이후 계속해서 인스턴스를 해지하지 못하면 인스턴스 새로 고침 작업에 실패합니다. 최대 인스턴스 수명을 사용하는 경우, Amazon EC2 Auto Scaling은 최대 수명을 초과하는 것으로 식별된 인스턴스를 계속 해지하려고 시도합니다.
+ 함수가 반복적으로 다시 시도되므로 Lambda 함수를 사용자 지정 해지 정책으로 사용하기 전에 코드에서 영구적인 오류가 있는지 테스트하고 수정해야 합니다.
+ 해지할 자체 인스턴스 목록으로 입력 데이터를 재정의하고 해당 인스턴스를 해지해 가용 영역의 균형이 틀어진 경우, Amazon EC2 Auto Scaling은 가용 영역에 걸쳐 용량을 점차 재조정합니다. 먼저 Lambda 함수를 호출하여 해지 준비가 된 인스턴스가 있는지 확인해 재조정 여부를 결정할 수 있습니다. 해지할 준비가 된 인스턴스가 있으면 먼저 새 인스턴스를 시작합니다. 인스턴스 시작이 완료되면 그룹의 현재 용량이 원하는 용량보다 크다는 사실을 감지하고 스케일 인 이벤트를 시작합니다.
+ 사용자 지정 종료 정책은 스케일 인 보호를 사용하여 특정 인스턴스가 종료되지 않도록 보호하는 기능에도 영향을 미치지 않습니다. 자세한 내용은 [인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어](ec2-auto-scaling-instance-protection.md) 단원을 참조하십시오.
+ Lambda 함수가 인스턴스를 반환하지 않으면 모든 종료가 자동으로 방지되지는 않습니다. Amazon EC2 Auto Scaling은 종료 정책에 관계없이 Auto Scaling 상태 확인에서 비정상으로 간주되는 인스턴스를 계속 종료합니다.
## Lambda 함수 생성
Lambda 함수를 생성하여 시작합니다. 따라서 Auto Scaling 그룹의 해지 정책에서 해당 함수의 Amazon 리소스 이름(ARN)을 지정할 수 있습니다.
**Lambda 함수를 생성하려면(콘솔)**
1. Lambda 콘솔에서 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹을 생성할 때 사용한 것과 동일한 지역을 선택합니다.
1. **Create function(함수 생성)**과 **Author from scratch(새로 작성)**를 차례로 선택합니다.
1. **Basic information(기본 정보)**에서 **Function name(함수 이름)**에 함수 이름을 입력합니다.
1. **Create function(함수 생성)**을 선택합니다. 함수의 코드 및 구성으로 돌아갑니다.
1. 함수가 콘솔에 여전히 열려 있으면 **Function code(함수 코드)**에서 코드를 편집기에 붙여 넣습니다.
1. **Deploy(배치)**를 선택합니다.
1. 경우에 따라 **Versions(버전)** 탭을 선택한 다음 **Publish new version(새 버전 발행)**을 선택하여 Lambda 함수의 게시 버전을 생성합니다. Lambda의 버전 관리에 대한 자세한 설명은 *AWS Lambda 개발자 안내서*의 [Lambda 함수 버전](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)을 참조하세요.
1. 버전을 게시하도록 선택한 경우, Lambda 함수의 이 버전과 별칭을 연결하려면 **Aliases(별칭)** 탭을 선택합니다. Lambda의 별칭에 대한 자세한 설명은 *AWS Lambda 개발자 안내서*의 [Lambda 함수 별칭](https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html)을 참조하세요.
1. 그런 다음 **Configuration(구성)** 탭을 선택한 다음 **Permissions(권한)**를 선택합니다.
1. **Resource-based policy(리소스 기반 정책)**까지 스크롤한 다음 **Add permissions(권한 추가)**를 선택합니다. 리소스 기반 정책은 정책에 지정된 보안 주체에 함수를 호출하는 권한을 부여하는 데 사용됩니다. 이 경우, 보안 주체는 Auto Scaling 그룹과 연결된 [Amazon EC2 Auto Scaling 서비스 연결 역할](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html)입니다.
1. **Policy statement(정책 설명)** 섹션에서 권한을 구성합니다.
1. **AWS 계정**를 선택합니다.
1. **Principal(보안 주체)**에 호출 서비스 연결 역할의 ARN 입력합니다(예: **arn:aws:iam:::role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling**).
1. **Action(작업)**으로**lambda:InvokeFunction**을 선택합니다.
1. **Statement ID(설명 ID)**에 고유한 설명 ID를 입력합니다(예: **AllowInvokeByAutoScaling**).
1. **저장**을 선택합니다.
1. 이 지침을 따른 후에는 다음 단계로 Auto Scaling 그룹의 해지 정책에서 함수의 ARN 지정합니다. 자세한 내용은 [Auto Scaling 그룹의 종료 정책 변경](custom-termination-policy.md) 단원을 참조하십시오.
**참고**
Lambda 함수 개발을 위한 참조로 사용할 수 있는 예는 Amazon EC2 Auto Scaling에 대한 [GitHub 리포지토리](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)를 참조하세요.
## 제한 사항
+ Auto Scaling 그룹에 대한 해지 정책에는 Lambda 함수를 하나만 지정할 수 있습니다. 해지 정책이 여러 개 지정된 경우, Lambda 함수를 먼저 지정해야 합니다.
+ 정규화되지 않은 ARN(접미사 제외) 또는 버전 또는 별칭이 접미사로 있는, 정규화된 ARN을 사용하여 Lambda 함수를 참조할 수 있습니다. 정규화되지 않은 ARN이 사용되는 경우(예: `function:my-function`) 게시되지 않은 함수 버전에서 리소스 기반 정책을 생성해야 합니다. 정규화된 ARN이 사용되는 경우(예: `function:my-function:1` 또는 `function:my-function:prod`) 게시된 특정 함수 버전에서 리소스 기반 정책을 생성해야 합니다.
+ 접미사가 `$LATEST`인 정규화된 ARN은 사용할 수 없습니다. 접미사가 `$LATEST`인 정규화된 ARN 참조하는 사용자 지정 해지 정책을 추가하려고 하면 오류가 발생합니다.
+ 입력 데이터에 제공되는 인스턴스 수는 30,000개로 제한됩니다. 해지할 수 있는 인스턴스가 30,000개 이상인 경우, 입력 데이터에는 최대 인스턴스 수가 반환됨을 나타내는 `"HasMoreInstances": true`가 포함됩니다.
+ Lambda 함수의 최대 실행 시간은 2초(2,000밀리초)입니다. 예상 실행 시간에 근거하여 Lambda 함수의 제한 시간 값을 설정하는 것이 가장 좋습니다. Lambda 함수의 기본 제한 시간은 3초이지만 이 시간은 줄일 수 있습니다.
+ 런타임이 2초 제한을 초과하는 경우 런타임이 이 임곗값 아래로 떨어질 때까지 모든 스케일 인 작업이 보류됩니다. 런타임이 지속적으로 더 긴 Lambda 함수의 경우, 후속 Lambda 호출 중에 결과를 검색할 수 있는 캐싱과 같이 런타임을 줄일 방법을 찾습니다.
+ 교차 계정 Lambda 함수는 지원되지 않습니다. 사용자 지정 종료 정책으로 사용되는 Lambda 함수는 Auto Scaling 그룹 AWS 계정 과 동일한에 있어야 합니다. 이 페이지의 설정 안내는 동일한 계정 내 구성에 초점을 맞추고 있습니다.
+ 사용자 지정 종료 정책은 비정상 인스턴스에는 적용되지 않습니다. 비정상 인스턴스는 항상 종료 대상으로 간주되며 Lambda 함수는 나머지 인스턴스에 대한 종료 순서만 평가합니다.
# 인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어
인스턴스 스케일 인 보호는 종료할 수 있는 Amazon EC2 Auto Scaling 인스턴스를 제어합니다. 이러한 기능의 일반적인 사용 사례는 컨테이너 기반 워크로드를 조정하는 것입니다. 자세한 내용은 [인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md) 단원을 참조하십시오.
기본적으로 Auto Scaling 그룹을 생성할 때는 인스턴스 스케일 인 보호가 비활성화됩니다. 따라서 Amazon EC2 Auto Scaling은 그룹의 모든 인스턴스를 종료할 수 있습니다.
Auto Scaling 그룹에서 인스턴스 스케일 인 보호 설정을 활성화하여 인스턴스가 시작되는 즉시 보호할 수 있습니다. 인스턴스 상태가 `InService`이면 인스턴스 스케일 인 방비가 시작됩니다. 그런 다음 해지할 수 있는 인스턴스를 제어하려면 Auto Scaling 그룹 내의 개별 인스턴스에서 스케일 인 보호 설정을 비활성화합니다. 이렇게 하면 특정 인스턴스를 원치 않는 해지로부터 계속 보호할 수 있습니다.
**Topics**
+ [고려 사항](#instance-protection-considerations)
+ [Auto Scaling 그룹의 스케일 인 보호 변경](#instance-protection-group)
+ [인스턴스에 대한 스케일 인 보호 변경](#instance-protection-instance)
## 고려 사항
인스턴스 스케일 인 보호를 사용할 때 고려해야 할 사항은 다음과 같습니다.
+ Auto Scaling 그룹의 모든 인스턴스가 스케일 인으로부터 보호되고 스케일 인 이벤트가 발생하면 원하는 용량이 감소합니다. 그러나 Auto Scaling 그룹은 인스턴스 스케일 인 보호 설정이 비활성화될 때까지 필요한 수의 인스턴스를 종료하지 않습니다. 에서 Auto Scaling 그룹의 **활동 내역**에는 스케일 AWS Management Console인 이벤트가 발생할 때 Auto Scaling 그룹의 모든 인스턴스가 스케일 인으로부터 보호되는 경우 다음 메시지가 포함됩니다. `Could not scale to desired capacity because all remaining instances are protected from scale in.`
+ 스케일 인이 방지되는 인스턴스를 분리하면 인스턴스 스케일 인 보호 설정이 손실됩니다. 인스턴스를 그룹에 다시 연결하면 해당 그룹의 현재 인스턴스 스케일 인 보호 설정을 상속합니다. Amazon EC2 Auto Scaling이 새 인스턴스를 시작하거나 인스턴스를 웜 풀에서 Auto Scaling 그룹으로 이동할 때 인스턴스는 Auto Scaling 그룹의 인스턴스 스케일 인 보호 설정을 상속합니다.
+ 인스턴스 스케일 인 방비는 다음 경우에 Auto Scaling 인스턴스를 보호하지 않습니다.
+ 인스턴스가 건전성 체크를 통과하지 못한 경우, 건전성 체크 교체. 자세한 설명은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 섹션을 참조하세요.
+ 스팟 인스턴스 중단 스팟 인스턴스는 용량을 더 이상 사용할 수 없거나 스팟 가격이 최고가를 초과하는 경우, 해지됩니다.
+ 용량 블록 예약이 종료됩니다. Amazon EC2는 스케일 인으로부터 보호되는 경우에도 용량 블록 인스턴스를 회수합니다.
+ `terminate-instance-in-auto-scaling-group` 명령을 통해 수동으로 종료합니다. 자세한 내용은 [Auto Scaling 그룹에서 인스턴스 해지 (AWS CLI)](ec2-auto-scaling-scaling-manually.md#terminate-an-instance-aws-cli) 단원을 참조하십시오.
+ Amazon EC2 콘솔, CLI 명령, API 작업을 통해 수동으로 종료합니다. Auto Scaling 인스턴스를 수동으로 해지할 수 없도록 하려면 Amazon EC2 해지 방지 기능을 활성화합니다. (이것은 Amazon EC2 Auto Scaling이 인스턴스를 종료하거나 `terminate-instance-in-auto-scaling-group` 명령을 통해 수동으로 종료하는 것을 방지하지 않습니다.) 시작 템플릿에서 Amazon EC2 종료 방지를 활성화하는 방법에 대한 자세한 내용은 [고급 설정을 사용하여 시작 템플릿 생성](advanced-settings-for-your-launch-template.md) 섹션을 참조하세요.
## Auto Scaling 그룹의 스케일 인 보호 변경
Auto Scaling 그룹의 인스턴스 스케일 인 보호 설정을 활성화하거나 비활성화할 수 있습니다. 활성화하면 그룹에서 시작한 모든 새 인스턴스에 인스턴스 스케일 인 보호가 활성화됩니다.
Auto Scaling 그룹에 대해 이 설정을 활성화하거나 비활성화해도 기존 인스턴스에는 영향을 주지 않습니다.
------
#### [ Console ]
**새 Auto Scaling 그룹에 대한 스케일 인 보호를 활성화하려면**
Auto Scaling 그룹을 생성할 때 **그룹 크기 및 조정 정책 구성** 페이지의 **인스턴스 스케일 인 보호**에서 **인스턴스 스케일 인 보호 활성화** 확인란을 선택합니다.
**기존 그룹에 대한 스케일 인 보호를 활성화 또는 비활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보(Details)** 탭에서 **고급 구성(Advanced configurations)**, **편집(Edit)**을 선택합니다.
1. **인스턴스 스케일 인 보호**에서 **인스턴스 스케일 보호 활성화** 확인란을 선택하거나 선택 취소하여 필요에 따라 이 옵션을 활성화 또는 비활성화합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**새 Auto Scaling 그룹에 대한 스케일 인 보호를 활성화하려면**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 인스턴스 스케일 인 방비를 활성화합니다.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg --new-instances-protected-from-scale-in ...
```
**기존 그룹에 대한 스케일 인 보호를 활성화하려면**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용하여 지정된 Auto Scaling 그룹에 대한 인스턴스 스케일 인 보호를 활성화합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --new-instances-protected-from-scale-in
```
**기존 그룹에 대한 스케일 인 보호를 비활성화하려면**
다음 명령을 사용하여 지정된 그룹의 인스턴트 스케일 인 보호를 비활성화합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --no-new-instances-protected-from-scale-in
```
------
## 인스턴스에 대한 스케일 인 보호 변경
기본적으로 인스턴스는 속해 있는 Auto Scaling 그룹의 인스턴스 스케일 인 보호 설정을 가져옵니다. 그러나 인스턴스가 시작된 후에 개별 인스턴스의 인스턴스 스케일 인 보호를 언제든 활성화하거나 비활성화할 수 있습니다.
------
#### [ Console ]
**인스턴스에 대한 스케일 인 보호를 활성화 또는 비활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **인스턴스 관리(Instance management)** 탭의 **인스턴스(Instances)**에서 인스턴스를 선택합니다.
1. 인스턴스 스케일 인 보호를 활성화하려면 **작업(Actions)**, **스케일 인 보호 설정(Set scale-in protection)**을 선택합니다. 메시지가 표시되면 **스케일 인 보호 설정(Set scale-in protection)**을 선택합니다.
1. 인스턴스 스케일 인 보호를 비활성화하려면 **작업(Actions)**, **스케일 인 보호 제거(Remove scale-in protection)**를 선택합니다. 메시지가 표시되면 **스케일 인 보호 제거(Remove scale-in protection)**를 선택합니다.
------
#### [ AWS CLI ]
**인스턴스에 대한 스케일 인 보호를 활성화하려면**
다음 [set-instance-protection](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-protection.html) 명령을 사용하여 지정된 인스턴스의 인스턴스 스케일 인 스케일 인 방비를 활성화합니다.
```
aws autoscaling set-instance-protection --instance-ids i-5f2e8a0d --auto-scaling-group-name my-asg --protected-from-scale-in
```
**인스턴스에 대한 스케일 인 보호를 비활성화하려면**
다음 명령을 사용하여 지정된 인스턴스의 인스턴스 스케일 인 보호를 비활성화합니다.
```
aws autoscaling set-instance-protection --instance-ids i-5f2e8a0d --auto-scaling-group-name my-asg --no-protected-from-scale-in
```
------
**참고**
인스턴스 스케일 인 보호는 인적 오류(예: 누군가 Amazon EC2 콘솔 또는 AWS CLI를 사용하여 인스턴스를 수동으로 종료한 경우) 발생 시 인스턴스가 종료되지 않도록 보장하지 않는다는 점을 기억해야 합니다. 인스턴스가 실수로 해지되지 않도록 방지하려면, Amazon EC2 해지 방지를 사용합니다. 그러나 해지 방지 및 인스턴스 스케일 인 방비가 활성화된 경우에도 건전성 체크 시 인스턴스가 비정상이라고 판단되거나 그룹 자체가 실수로 삭제된 경우, 인스턴스 스토리지에 저장된 데이터가 손실될 수 있습니다. 다른 환경과 마찬가지로 가장 좋은 방법은 데이터를 자주 백업하거나 비즈니스 연속성 요건에 따라 적절하게 백업하는 것입니다.
# 인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계
이 주제에서는 Amazon EC2 Auto Scaling 그룹이 아직 종료할 준비가 되지 않은 Amazon EC2 인스턴스를 종료하지 못하도록 하는 데 사용할 수 있는 기능에 대해 설명합니다. 기본적으로 Auto Scaling은 인스턴스에서 실행되는 애플리케이션을 볼 수 없습니다. 애플리케이션이 할당된 작업을 정상적으로 종료하거나 완료하기 전에 인스턴스를 종료할 수 있습니다. 이러한 기능을 통해 애플리케이션은 인스턴스 종료 전에 진행 중인 작업을 완료하거나, 상태를 전송하거나, 정리를 수행할 수 있습니다. 애플리케이션의 요구 사항에 따라 개별적으로 또는 조합하여 사용할 수 있습니다.
이러한 기능은 플릿의 각 인스턴스가 다른 인스턴스와 다른 데이터, 작업 또는 상태를 보유하는 상태 저장 워크로드에 특히 유용합니다. 정상적인 종료 없이 상태 저장 인스턴스를 종료하면 처음부터 장기 실행 작업이 다시 시작되고, 데이터 중복 또는 데이터 손실이 줄어들고, 진행 중인 트랜잭션 또는 계산이 중단될 수 있습니다. 상태 저장 인스턴스를 정상적으로 종료하려면 워크로드를 드레이닝(현재 할당된 모든 작업 완료)하거나 전송(작업, 데이터 또는 구성을 다른 활성 인스턴스로 이동)해야 합니다.
**Topics**
+ [해지 수명 주기 후크](#gracefully-handle-instance-termination-lifecycle-hooks)
+ [인스턴스 스케일 인 보호](#gracefully-handle-instance-termination-scale-in-protection)
+ [사용자 지정 해지 정책](#gracefully-handle-instance-termination-custom-termination-policy)
+ [인스턴스 수명 주기 정책](#gracefully-handle-instance-termination-instance-lifecycle-policy)
+ [종료를 모두 일시 중지합니다.](#gracefully-handle-instance-termination-suspend-terminate)
+ [제한 사항](#gracefully-handle-instance-termination-limitations)
+ [예제 시나리오](#gracefully-handle-instance-termination-examples)
## 해지 수명 주기 후크
종료 수명 주기 후크는 이미 종료 대상으로 선택된 Amazon EC2 인스턴스의 수명을 연장합니다. 인스턴스에 현재 할당된 진행 중인 작업을 완료하거나 진행 상황을 저장하고 작업을 다른 인스턴스로 전송할 수 있는 추가 시간을 제공합니다.
많은 워크로드의 경우 종료 수명 주기 후크만으로도 종료 대상으로 선택된 인스턴스에서 애플리케이션을 정상적으로 종료할 수 있습니다. 이는 최선의 방법이며 종료 수명 주기 작업이 중단되는 경우 종료를 방지하는 데 사용할 수 없습니다. 워크로드에서 종료 수명 주기 작업 실패에 대한 허용 오차가 낮은 경우 [ 종료 수명 주기 후크와 함께 인스턴스 수명 주기 정책을 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-lifecycle-policy.html) 구성하여 인스턴스를 유지합니다.
종료 수명 주기 후크를 사용하려면 인스턴스가 종료 대상으로 선택되는 시기를 알아야 합니다. 이를 알 수 있는 방법은 다음 두 가지입니다:
| 옵션 | 설명 | 가장 적합한 용도 | 설명서 링크 |
| --- | --- | --- | --- |
| 인스턴스 내부 | 인스턴스 메타데이터 서비스(IMDS)는 인스턴스에서 직접 인스턴스의 상태를 폴링할 수 있는 안전한 엔드포인트입니다. 메타데이터가 Terminated(으)로 돌아오면 인스턴스가 해지되도록 예약된 것입니다. | 인스턴스가 해지되기 전에 인스턴스에서 작업을 수행해야 하는 애플리케이션. | [ 대상 수명 주기 상태 검색 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/retrieving-target-lifecycle-state-through-imds.html) |
| 인스턴스 외부 | 인스턴스가 해지되면 이벤트 알림이 생성됩니다. Amazon EventBridge, Amazon SQS, Amazon SNS 또는를 사용하여 규칙을 생성 AWS Lambda 하여 이러한 이벤트를 캡처하고 Lambda 함수와 같은 응답을 호출할 수 있습니다. | 인스턴스 외부에서 작업을 수행해야 하는 애플리케이션. | [ 알림 대상 구성 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/prepare-for-lifecycle-notifications.html#lifecycle-hook-notification-target) |
수명 주기 후크를 사용하려면 또한 해당 인스턴스가 언제 완전히 해지될 준비가 되는지를 알아야 합니다. Amazon EC2 Auto Scaling은 [ CompleteLifecycleAction ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API 호출을 수신하거나 제한 시간이 경과할 때까지 중 먼저 발생하는 시점까지 인스턴스를 종료하지 않습니다.
기본적으로 인스턴스는 해지 수명 주기 후크로 인해 1시간 동안 계속 실행될 수 있습니다(하트비트 타임아웃). 1시간이 수명 주기 작업을 완료하는 데 충분하지 않은 경우, 기본 시간 제한을 구성할 수 있습니다. 수명 주기 작업이 진행 중이면 [ RecordLifecycleActionHeartbeat ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html) API 호출을 사용하여 제한 시간을 연장할 수 있습니다.
자세한 내용은 [Amazon EC2 Auto Scaling 수명 주기 후크](lifecycle-hooks.md) 단원을 참조하십시오.
## 인스턴스 스케일 인 보호
인스턴스 스케일 인 보호를 사용하여 스케일 인 이벤트 중에 종료할 인스턴스를 제어할 수 있습니다. 특히 장기 실행 작업을 적극적으로 처리하는 인스턴스가 종료되지 않도록 할 수 있습니다. 예를 들어 컨테이너화된 워크로드를 실행할 때 모든 인스턴스를 보호하고 현재 또는 예약된 작업이 없는 인스턴스에 대해서만 보호를 제거하는 것이 일반적입니다. 인스턴스는 새 작업에 대한 폴링을 계속하고 새 작업이 할당되면 보호를 다시 활성화할 수 있습니다.
Auto Scaling 그룹 수준 및 인스턴스 수준에서 스케일 인 보호를 활성화할 수 있습니다. Auto Scaling 그룹 수준에서 스케일 인 보호를 활성화하면 새 인스턴스가 생성될 때만 보호됩니다. 기존 인스턴스의 경우 개별적으로 보호를 활성화할 수 있습니다.
애플리케이션은 인스턴스 자체 또는 각 인스턴스를 종료할 수 있는지 여부를 관리하는 중앙 집중식 컨트롤 플레인에서 보호를 설정할 수 있습니다. 대규모 플릿의 경우 또는 보호를 자주 전환해야 하는 경우 중앙 집중식 접근 방식을 사용하는 것이 좋습니다. [ SetInstanceProtection](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_SetInstanceProtection.html)에 대한 호출을 일괄 처리하고 API 제한 문제를 방지할 수 있기 때문입니다.
자세한 내용은 [인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어](ec2-auto-scaling-instance-protection.md) 단원을 참조하십시오.
## 사용자 지정 해지 정책
인스턴스 스케일 인 보호와 마찬가지로 사용자 지정 종료 정책은 Amazon EC2 Auto Scaling 그룹이 특정 EC2 인스턴스를 종료하는 것을 방지하는 데 도움이 됩니다. 사용자 지정 종료 정책에 관계없이 비정상 인스턴스를 계속 종료할 수 있습니다.
Auto Scaling 그룹은 기본 종료 정책을 사용하여 먼저 종료할 Amazon EC2 인스턴스를 결정합니다. 먼저 종료할 인스턴스를 더 잘 제어하려면 Lambda 함수를 사용하여 사용자 지정 종료 정책을 구현할 수 있습니다. Auto Scaling은 종료할 인스턴스를 선택해야 할 때마다이 함수를 호출하며 함수가 반환하는 인스턴스만 종료합니다. 함수가 오류, 시간 초과 또는 빈 목록을 반환하는 경우 인스턴스가 비정상이 아닌 한 Auto Scaling은 인스턴스를 종료하지 않습니다.
사용자 지정 종료 정책은 애플리케이션이 유휴 상태이거나 종료하기에 안전한 인스턴스를 식별할 수 있는 경우에 유용합니다. 여기에는 일반적으로 그룹 전반의 워크로드를 추적하는 컨트롤 플레인이 필요합니다.
자세한 내용은 [Lambda를 사용하여 사용자 지정 해지 정책 생성](lambda-custom-termination-policy.md) 단원을 참조하십시오.
## 인스턴스 수명 주기 정책
인스턴스 수명 주기 정책은 종료 수명 주기 작업이 중단될 때 Amazon EC2 Auto Scaling 종료에 대한 보호를 제공합니다. 수명 주기 후크와 달리 인스턴스 수명 주기 정책은 정상적인 종료 절차가 성공적으로 완료되지 않을 때 인스턴스가 유지 상태로 전환되도록 설계되었습니다.
Auto Scaling이 종료할 인스턴스를 선택하면 구성된 종료 수명 주기 후크가 호출되고 애플리케이션이 정상적인 종료 절차를 시작합니다. 를 사용하여 종료 수명 주기 작업이 성공적으로 완료되면 인스턴스`CONTINUE`가 정상적으로 종료됩니다. 그러나 어떤 이유로든 종료 수명 주기 작업이 중단되는 경우 인스턴스 수명 주기 정책은 인스턴스를 종료하는 대신 유지 상태로 인스턴스를 이동합니다. 보관된 인스턴스는 Auto Scaling 그룹의 원하는 용량에 포함되지 않으므로 대체 인스턴스가 자동으로 시작됩니다. [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API를 사용하여 보존된 인스턴스를 수동으로 종료할 때까지 보존된 인스턴스와 대체 인스턴스 모두에 대해 표준 Amazon EC2 요금이 발생합니다.
이 기능을 사용하려면 `TerminateHookAbandon` 보존 트리거가 로 설정된 인스턴스 수명 주기 정책과 `retain`하나 이상의 종료 수명 주기 후크를 모두 구성해야 합니다. 보관된 인스턴스에는 지속적인 Amazon EC2 비용이 발생하고 수동 작업이 필요하므로 모니터링이 중요합니다. 와 같은 CloudWatch 지표를 활성화`GroupTerminatingRetainedInstances`하고 CloudWatch 경보를 생성하여 인스턴스가 보존 상태로 전환될 때 알림을 보내야 합니다.
자세한 내용은 [인스턴스 수명 주기 정책을 사용하여 인스턴스 보존 제어](instance-lifecycle-policy.md) 단원을 참조하십시오.
## 종료를 모두 일시 중지합니다.
Amazon EC2 Auto Scaling 그룹 내의 모든 EC2 인스턴스 종료를 완전히 제어해야 하는 경우 `Terminate` 프로세스를 일시 중지합니다. Amazon EC2 위의 옵션이 서비스에 필요한 제어 기능을 제공하지 않는 경우에만이 옵션을 사용하는 것이 좋습니다. 프로세스를 일시 중지하기 위해 [ SuspendProcesses](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_SuspendProcesses.html)를 호출하면 사용자가 TerminateInstanceInAutoScalingGroup API에 요청한 경우를 제외하고 Auto Scaling이 어떤 이유로든 종료를 시도하지 `Terminate` 못하게 됩니다. [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html)
자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
## 제한 사항
**중요**
Amazon EC2 Auto Scaling에서 인스턴스 종료를 정상적으로 처리하도록 애플리케이션을 설계할 때는 다음 제한 사항에 유의하세요.
### 비정상 인스턴스는 일부 보호를 우회합니다.
인스턴스가 비정상인 경우 사용자 지정 종료 정책 또는 축소 보호 기능이 있더라도 Amazon EC2 Auto Scaling은 인스턴스를 종료하기 시작합니다. Auto Scaling을 통한 비정상 인스턴스 교체를 방지하는 유일한 방법은 `HealthCheck`, `ReplaceUnhealthy`또는 `Terminate` 프로세스를 일시 중지하는 것입니다. 수명 주기 후크와 인스턴스 수명 주기 정책을 사용하여 애플리케이션이 정상적으로 종료되도록 허용하거나 비정상 인스턴스가 종료되기 전에 복구해야 하는 데이터를 복사할 수 있습니다.
| 기능 | 정상 인스턴스 제어 | 비정상 인스턴스 제어 |
| --- | --- | --- |
| 사용자 지정 종료 정책 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/negative_icon.svg) 아니요 |
| Scale-in Protection | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/negative_icon.svg) 아니요 |
| HealthCheck, ReplaceUnhealthy또는 Terminate 프로세스 일시 중지 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 |
| 수명 주기 후크 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 |
| 인스턴스 수명 주기 정책 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 | ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/success_icon.svg) 예 |
### 수명 주기 후크만으로는 정상적인 종료를 보장하지 않습니다.
기본적으로 종료 수명 주기 후크는 최선을 다해 작동합니다. 종료 수명 주기 작업이 중단되면 Amazon EC2 Auto Scaling은 인스턴스를 즉시 종료합니다. 종료 수명 주기 작업이 중단될 때 종료 수명 주기 후크를 인스턴스 수명 주기 정책과 결합하여 인스턴스를 유지할 수 있습니다. 이 조합의 경우:
+ Auto Scaling이 인스턴스 종료를 트리거하고 구성된 Elastic Load Balancing 로드 밸런서에서 드레이닝이 완료된 후 종료 수명 주기 후크가 애플리케이션을 정상적으로 종료하려고 시도합니다.
+ 어떤 이유로든 종료 수명 주기 작업이 중단되면 인스턴스는 종료되는 대신 유지 상태로 전환됩니다.
+ 보관된 인스턴스는 현재 Amazon EC2 상태로 유지되므로 종료 절차를 수동으로 완료하거나 실패를 조사할 수 있습니다.
+ 필요한 작업을 완료한 후 [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API를 호출하여 보관된 인스턴스를 수동으로 종료할 수 있습니다.
자세한 내용은 [인스턴스 수명 주기 정책을 사용하여 인스턴스 보존 제어](instance-lifecycle-policy.md) 단원을 참조하십시오.
### 특정 인스턴스 시장 옵션은 제한된 공지로 중단될 수 있습니다.
Auto Scaling 그룹에서 스팟 인스턴스 및 중단 가능한 용량 예약과 같은 인스턴스 시장 옵션을 사용하는 경우 Amazon EC2는 언제든지 인스턴스를 중단 및 회수할 수 있습니다. 이러한 중단은 다음을 포함한 모든 Amazon EC2 Auto Scaling 보호 메커니즘을 우회합니다.
+ 해지 수명 주기 후크
+ 인스턴스 스케일 인 보호
+ 사용자 지정 종료 정책
+ 인스턴스 수명 주기 정책
+ 일시 중지된 프로세스
스팟 인스턴스가 중단 알림을 받으면 약 2분 동안 정상적인 종료 작업을 수행할 수 있습니다. 종료 수명 주기 후크를 사용하여 스팟 인스턴스 중단에 대응할 수 있지만 수명 주기 후크가 아직 진행 중인 경우에도 2분 기간이 끝나면 인스턴스가 강제로 종료됩니다. 또한 인스턴스 수명 주기 정책은 스팟 인스턴스 중단을 방지할 수 없습니다.
스팟 인스턴스 중단 처리에 대한 자세한 내용은 Amazon EC2 사용 설명서의 [ 스팟 인스턴스 중단 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) 및 Amazon EC2 스팟 모범 사례를 참조하세요. [ Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) *Amazon EC2 *
### 직접 Amazon EC2 종료는 모든 보호를 우회합니다.
Amazon EC2 [ TerminateInstances ](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TerminateInstances.html) API를 사용하여 Auto Scaling 그룹의 인스턴스를 직접 종료하면 종료 시 모든 Amazon EC2 Auto Scaling 보호 메커니즘이 우회됩니다.
구성된 보호를 준수하면서 Auto Scaling 그룹의 인스턴스를 종료하려면 대신 [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API를 사용합니다.
## 예제 시나리오
Amazon EC2 Auto Scaling을 사용하는 경우 플릿 관리 Auto Scaling이 사용자를 대신하여 처리하는 양과 EC2 인스턴스 종료 결정을 직접 제어하는 정도를 선택할 수 있습니다. 워크로드가 인스턴스 종료에 더 민감할수록 더 많은 제어를 유지할 수 있습니다. 다음 예제에서는 허용 오차 수준이 서로 다른 워크로드와 권장 구성을 설명합니다.
### 예제 1: 분산 데이터베이스 노드(저내성)
각 EC2 인스턴스가 복제 인수가 3인 데이터 파티션을 보유하는 분산 데이터베이스를 실행합니다. 동일한 파티션의 복제본이 있는 여러 인스턴스를 분실하면 데이터가 손실되거나 해당 파티션을 사용할 수 없게 될 수 있습니다.
**해결 과제:** Auto Scaling은 데이터를 다른 노드에 다시 복제하는 것보다 더 빠르게 인스턴스를 종료할 수 있으며, 종료하면 복제 인수를 유지하는 데 필요한 것보다 용량이 줄어들 수 있습니다.
다음 구성을 고려하세요.
+ 모든 데이터베이스 [ 인스턴스에서 인스턴스 스케일 인 보호를 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) 활성화합니다. 데이터가 다른 곳에 안전하게 복제되었는지 확인한 후에만 프로그래밍 방식으로 제거합니다.
+ 데이터 전송이 완료될 수 있도록 인스턴스 [ 수명 주기 정책과 함께 연장된 제한 시간으로 종료 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)를 구성합니다.
+ 최소 정상 백분율이 100%인 [ 인스턴스 유지 관리 정책을 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-maintenance-policy.html) 설정하여 필요한 용량을 유지합니다.
### 예제 2: 장기 실행 작업 처리(중간 허용치)
장기 실행 작업에 대한 수신 메시지를 수집하는 Amazon SQS 대기열이 있습니다. 새 메시지가 도착하면 EC2 인스턴스가 메시지를 검색하고 처리하는 데 3시간이 걸리는 작업을 시작합니다. 대기열이 커지면 Auto Scaling은 조정 정책에 따라 인스턴스를 추가합니다. 대기열이 축소되면 Auto Scaling은 인스턴스를 종료합니다.
**해결 과제:** Auto Scaling은 유휴 인스턴스가 아닌 작업을 처리하는 데 3시간이 걸리는 인스턴스를 종료할 수 있습니다. 다른 인스턴스에서 작업을 다시 시작할 수 있지만 상당한 진행 상황을 잃게 됩니다.
다음 구성을 고려하세요.
+ 유휴 인스턴스를 먼저 종료하는 우선 순위를 지정하는 [ 사용자 지정 종료 정책을 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lambda-custom-termination-policy.html) 구성합니다.
+ [ 종료 수명 주기 후크를 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 사용하여 진행 중인 작업을 완료할 수 있습니다.
+ [ 인스턴스가 작업을 시작할 때 프로그래밍 방식으로 인스턴스 스케일 인 보호를 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) 활성화하고 작업이 완료되면 제거합니다.
### 예제 3: 테스트 환경을 위한 작업자 플릿(고내성)
자동화된 테스트, CI/CD 파이프라인 작업 또는 개발 워크로드를 실행하는 EC2 인스턴스 플릿을 실행합니다. 이러한 작업자 인스턴스는 대기열에서 작업을 가져오며, 작업이 실패하면 테스트 결과를 다시 생성할 수 있습니다.
**해결 과제:** 스케일 인 이벤트 중에 테스트 작업이 중단될 수 있지만, 영향 없이 테스트를 재시도할 수 있으므로 중단 없는 가용성이 아닌 비용과 단순성을 위해 최적화해야 합니다.
다음 구성을 고려하세요.
+ [ 종료 수명 주기 후크를 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 사용하여 진행 중인 요청을 완료할 수 있습니다.
+ 비용 절감을 위해 용량 최적화 할당 전략과 함께 [ 스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 사용하는 것이 좋습니다.
# Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개
이 주제에서는 Auto Scalin 그룹의 프로세스를 하나 이상 일시 중지한 다음 재개하여 특정 작업을 일시적으로 비활성화하는 방법을 설명합니다.
프로세스 일시 중지는 조정 정책 또는 예약된 작업으로 인한 방해 없이 문제를 조사하거나 해결해야 할 때 유용할 수 있습니다. Auto Scaling 그룹을 변경하는 동안 Amazon EC2 Auto Scaling이 인스턴스를 비정상으로 표시하고 교체하는 것을 방지하는 데에도 도움이 됩니다.
**Topics**
+ [프로세스 유형](#process-types)
+ [고려 사항](suspend-resume-considerations.md)
+ [프로세스 일시 중지](suspend-processes.md)
+ [프로세스 재개](resume-processes.md)
+ [일시 중지 프로세스가 다른 프로세스에 미치는 영향](understand-how-suspending-processes-affects-other-processes.md)
**참고**
사용자가 시작하는 일시 중지 외에, Amazon EC2 Auto Scaling에서도 인스턴스 시작에 반복적으로 실패하는 Auto Scaling 그룹의 프로세스를 일시 중지할 수 있습니다. 이를 *관리적 일시 중지*라고도 합니다. 관리적 일시 중지는 24시간 이상 인스턴스를 시작하려고 했지만 시작하지 못한 Auto Scaling 그룹에 가장 흔히 적용됩니다. 사용자는 Amazon EC2 Auto Scaling에서 관리상의 이유로 일시 중지한 프로세스를 재개할 수 있습니다.
## 프로세스 유형
일시 중지 후 재개 기능은 다음 프로세스를 지원합니다.
+ `Launch` - 그룹이 스케일 아웃될 때 또는 Amazon EC2 Auto Scaling이 웜 풀에 인스턴스를 추가하는 경우와 같은 다른 이유로 인스턴스를 시작하도록 선택할 때 Auto Scaling 그룹에 인스턴스를 추가합니다.
+ `Terminate` - 그룹이 스케일 인될 때 또는 Amazon EC2 Auto Scaling이 최대 수명 기간을 초과하거나 상태 확인에 실패하여 인스턴스가 종료되는 경우와 같은 다른 이유로 인스턴스를 종료하도록 선택할 때 Auto Scaling 그룹에서 인스턴스를 제거합니다.
+ `AddToLoadBalancer` - 인스턴스가 시작될 때 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer에 인스턴스를 추가합니다. 자세한 내용은 [Auto Scaling 그룹에 들어오는 애플리케이션 트래픽을 분산하기 위해 Elastic Load Balancing 사용](autoscaling-load-balancer.md) 단원을 참조하십시오.
+ `AlarmNotification` - 동적 조정 정책과 연결된 CloudWatch 경보의 알림을 수락합니다. 자세한 내용은 [Amazon EC2 Auto Scaling의 동적 조정](as-scale-based-on-demand.md) 단원을 참조하십시오.
+ `AZRebalance` - 이전에 사용할 수 없었던 가용 영역이 정상 상태로 돌아오는 경우와 같이 그룹의 균형이 깨질 때 그룹 내 EC2 인스턴스의 수를 지정된 모든 가용 영역에 고르게 분산시켜 균형을 잡습니다. 자세한 내용은 [재조정 활동](auto-scaling-benefits.md#AutoScalingBehavior.InstanceUsage) 단원을 참조하십시오.
+ `HealthCheck` - Amazon EC2 또는 Elastic Load Balancing에서 해당 인스턴스가 정상 상태가 아니라고 Amazon EC2 Auto Scaling에 알리는 경우, 인스턴스의 상태를 확인하고 인스턴스에 비정상 표시를 합니다. 이 프로세스로 사용자가 수동으로 설정한 인스턴스의 상태를 재정의할 수 있습니다. 자세한 내용은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 단원을 참조하십시오.
+ `InstanceRefresh` - 인스턴스 새로 고침 기능을 사용하여 인스턴스를 종료하고 교체합니다. 자세한 내용은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md) 단원을 참조하십시오.
+ `ReplaceUnhealthy` - 비정상으로 표시된 인스턴스를 종료한 다음 새로운 인스턴스를 생성하여 이를 교체합니다. 자세한 내용은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 단원을 참조하십시오.
+ `ScheduledActions` - 사용자가 생성한 예약된 조정 작업 또는 사용자가 AWS Auto Scaling 조정 계획을 생성하고 예측 조정을 활성화할 때 생성된 예약된 조정 작업을 수행합니다. 자세한 내용은 [Amazon EC2 Auto Scaling에 예약된 조정](ec2-auto-scaling-scheduled-scaling.md) 단원을 참조하십시오.
# 프로세스 일시 중지 시 고려 사항
프로세스를 일시 중지하기 전에 다음 사항을 고려하세요.
+ `AlarmNotification`을 일시 중지하면 조정 정책이나 그와 연결된 CloudWatch 경보를 삭제하지 않고 그룹의 대상 추적, 단계 및 단순 조정 정책을 일시적으로 중지할 수 있습니다. 대신 개별 조정 정책을 일시적으로 중지하려면 [Auto Scaling 그룹에 대한 조정 정책 비활성화](as-enable-disable-scaling-policy.md) 섹션을 참조하세요.
+ Amazon EC2 Auto Scaling이 상태 확인에 근거하여 인스턴스를 종료하지 않고 인스턴스를 재부팅하기 위해 `HealthCheck` 및 `ReplaceUnhealthy` 프로세스를 일시 중지하도록 선택할 수 있습니다. Amazon EC2 Auto Scaling이 나머지 인스턴스에 대한 상태 확인을 계속 수행해야 하는 경우, 대기 기능을 대신 사용합니다. 자세한 내용은 [Auto Scaling 그룹에서 일시적으로 인스턴스 제거](as-enter-exit-standby.md) 단원을 참조하십시오.
+ `Launch` 및 `Terminate` 프로세스나 `AZRebalance`를 일시 중지한 다음 인스턴스 분리, 지정된 가용 영역 변경 등의 Auto Scaling 그룹 변경 작업을 수행하면 가용 영역 간에 그룹의 균형이 깨질 수 있습니다. 이 경우, 일시 중지된 프로세스를 재개하면 Amazon EC2 Auto Scaling이 가용 영역 간에 인스턴스를 점진적으로 고르게 재조정합니다.
+ `Terminate` 프로세스를 일시 중지해도 강제 삭제 옵션과 함께 [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) 명령을 사용하여 인스턴스를 강제로 종료할 수 있습니다.
+ `Terminate` 프로세스 일시 중지는 현재 `InService` 상태에 있는 인스턴스에만 적용됩니다. `Pending`과 같은 다른 상태의 인스턴스 또는 대기 상태에서 제대로 재개되지 않은 인스턴스는 종료 방지가 되지 않습니다.
+ AWS CLI 또는 SDK를 사용하여 Auto Scaling 그룹을 설명하기 위한 호출에 프로세스가 있는 경우 `RemoveFromLoadBalancerLowPriority` 프로세스를 무시할 수 있습니다. SDKs 이 프로세스는 더 이상 사용되지 않으며 이전 버전과의 호환성을 위해서만 유지됩니다.
# 프로세스 일시 중지
Auto Scaling 그룹에 대한 프로세스를 일시 중지하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**프로세스를 일시 중지하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보(Details)** 탭에서 **고급 구성(Advanced configurations)**, **편집(Edit)**을 선택합니다.
1. **Suspended processes(일시 중지된 프로세스)**에서 일시 중지할 프로세스를 선택합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
다음 [suspend-processes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/suspend-processes.html) 명령을 사용하여 개별 프로세스를 일시 중지합니다.
```
aws autoscaling suspend-processes --auto-scaling-group-name my-asg --scaling-processes HealthCheck ReplaceUnhealthy
```
프로세스를 모두 일시 중지하려면 다음과 같이 `--scaling-processes` 옵션을 생략합니다.
```
aws autoscaling suspend-processes --auto-scaling-group-name my-asg
```
------
# 프로세스 재개
Auto Scaling 그룹에 대해 일시 중지된 프로세스를 재개하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**일시 중지된 프로세스를 재개하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보(Details)** 탭에서 **고급 구성(Advanced configurations)**, **편집(Edit)**을 선택합니다.
1. **일시 중지된 프로세스(Suspended processes)**에서 일시 중지된 프로세스를 제거합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
일시 중지된 프로세스를 재개하려면 다음 [resume-processes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/resume-processes.html) 명령을 사용합니다.
```
aws autoscaling resume-processes --auto-scaling-group-name my-asg --scaling-processes HealthCheck
```
일시 중지된 프로세스를 모두 재개하려면 다음과 같이 `--scaling-processes` 옵션을 생략합니다.
```
aws autoscaling resume-processes --auto-scaling-group-name my-asg
```
------
# 일시 중지 프로세스가 다른 프로세스에 미치는 영향
다음 섹션에서는 서로 다른 프로세스를 개별적으로 일시 중지할 때 발생하는 상황을 설명합니다.
**Topics**
+ [`Launch` 일시 중지됨](#launch-is-suspended)
+ [`Terminate` 일시 중지됨](#terminate-is-suspended)
+ [`AddToLoadBalancer` 일시 중지됨](#addtoloadbalancer-is-suspended)
+ [`AlarmNotification` 일시 중지됨](#alarmnotification-is-suspended)
+ [`AZRebalance` 일시 중지됨](#azrebalance-is-suspended)
+ [`HealthCheck` 일시 중지됨](#healthcheck-is-suspended)
+ [`InstanceRefresh` 일시 중지됨](#instancerefresh-is-suspended)
+ [`ReplaceUnhealthy` 일시 중지됨](#replaceunhealthy-is-suspended)
+ [`ScheduledActions` 일시 중지됨](#scheduledactions-is-suspended)
+ [추가 고려 사항](#other-considerations)
## `Launch` 일시 중지됨
+ `AlarmNotification`이 여전히 활성 상태이지만 Auto Scaling 그룹이 위반 상태의 경보에 대해 스케일 아웃 활동을 시작할 수 없습니다.
+ `ScheduledActions`가 활성 상태이지만 Auto Scaling 그룹이 수행되는 예약된 작업에 대해 스케일 아웃 활동을 시작할 수 없습니다.
+ `AZRebalance`가 그룹 재조정을 중지합니다.
+ `ReplaceUnhealthy`가 비건전 인스턴스를 계속 해지하지만 교체를 시작하지는 않습니다. `Launch` 프로세스를 재개하면 Amazon EC2 Auto Scaling은 `Launch`가 일시 중지된 시간 동안 해지된 모든 인스턴스를 즉시 교체합니다.
+ `InstanceRefresh`가 인스턴스를 교체하지 않습니다.
## `Terminate` 일시 중지됨
+ `AlarmNotification`이 여전히 활성 상태이지만 Auto Scaling 그룹이 위반 상태의 경보에 대해 스케일 인 활동을 시작할 수 없습니다.
+ `ScheduledActions`가 활성 상태이지만 Auto Scaling 그룹이 수행되는 예약된 작업에 대해 스케일 인 활동을 시작할 수 없습니다.
+ `AZRebalance`는 여전히 활성이지만 정상적으로 작동하지 않습니다. 오래된 인스턴스를 해지하지 않고도 새 인스턴스를 시작할 수 있습니다. 이로 인해 Auto Scaling 그룹은 최대 크기보다 최대 10% 더 크게 스케일 아웃될 수 있습니다. 재조정 활동 중에 일시적으로 허용되기 때문입니다. 그리고 Auto Scaling 그룹은 `Terminate` 프로세스를 재개할 때까지 최대 크기 이상으로 유지될 수 있습니다.
+ `ReplaceUnhealthy`는 비활성 상태이지만 `HealthCheck`는 아닙니다. `Terminate`가 재개되면 `ReplaceUnhealthy` 프로세스는 즉시 실행되기 시작합니다. `Terminate`가 일시 중지된 동안 건전하지 않은 것으로 표시되었던 인스턴스는 즉시 교체됩니다.
+ `InstanceRefresh`가 인스턴스를 교체하지 않습니다.
## `AddToLoadBalancer` 일시 중지됨
+ Amazon EC2 Auto Scaling은 인스턴스를 시작하지만 로드 밸런서 대상 그룹 또는 Classic Load Balancer에 추가하지는 않습니다. `AddToLoadBalancer` 프로세스를 재개하면 이 프로세스는 인스턴스 시작 시 로드 밸런서에 해당 인스턴스를 다시 추가하기 시작합니다. 하지만 이 프로세스가 일시 중지되면 인스턴스가 시작되어도 인스턴스가 추가되지 않습니다. 따라서 이러한 인스턴스를 수동으로 등록해야 합니다.
## `AlarmNotification` 일시 중지됨
+ CloudWatch 경보 임계값이 위반되면 Amazon EC2 Auto Scaling은 조정 정책을 호출하지 않습니다. `AlarmNotification`을 재개하면 Amazon EC2 Auto Scaling은 현재 위반 상태인 경보 임계값으로 정책을 평가합니다.
## `AZRebalance` 일시 중지됨
+ Amazon EC2 Auto Scaling은 특정 이벤트 후 인스턴스를 재조정하려고 하지 않습니다. 그러나 스케일 아웃 또는 스케일 인 이벤트가 발생하는 경우, 조정 프로세스는 계속해서 가용 영역의 균형을 맞추려고 시도합니다. 예컨대 스케일 아웃 시에는 최소한의 인스턴스로 가용 영역의 인스턴스를 시작합니다. `AZRebalance`가 일시 중지된 동안 그룹의 균형이 깨어졌고 사용자가 이를 재개하는 경우, Amazon EC2 Auto Scaling은 그룹을 재조정하려고 합니다. 이를 위해 먼저 `Launch`를 호출한 다음 `Terminate`를 호출합니다.
+ `AZRebalance`가 일시 중단되더라도 웜 풀에는 영향을 주지 않습니다.
## `HealthCheck` 일시 중지됨
+ Amazon EC2 Auto Scaling은 EC2 및 Elastic Load Balancing 상태 검사에 따라 인스턴스에 비정상 표시를 하던 동작을 중지합니다. 사용자 지정 건전성 체크은 계속 정상적으로 이루어집니다. `HealthCheck`를 일시 중지한 뒤 필요하면 그룹 내 인스턴스의 상태 검사를 수동으로 설정하고 `ReplaceUnhealthy`에서 이를 교체하도록 할 수 있습니다.
## `InstanceRefresh` 일시 중지됨
+ Amazon EC2 Auto Scaling은 인스턴스 새로 고침의 결과로 인스턴스 교체를 중지합니다. 진행 중인 인스턴스 새로 고침이 있는 경우, 작업을 취소하지 않고 일시 중지합니다.
## `ReplaceUnhealthy` 일시 중지됨
+ Amazon EC2 Auto Scaling은 건전하지 않은 것으로 표시된 인스턴스를 교체하던 동작을 중지합니다. EC2 또는 Elastic Load Balancing 상태 검사에 실패한 인스턴스는 여전히 건전하지 않은 것으로 표시됩니다. 사용자가 `ReplaceUnhealthy` 프로세스를 재개하는 즉시 Amazon EC2 Auto Scaling은 이 프로세스가 중지된 동안 건전하지 않은 것으로 표시되었던 인스턴스를 교체합니다. `ReplaceUnhealthy` 프로세스는 먼저 `Terminate`를 호출한 다음 `Launch`를 호출합니다.
## `ScheduledActions` 일시 중지됨
+ Amazon EC2 Auto Scaling은 일시 중지 기간에 실행되도록 예약된 작업을 실행하지 않습니다. `ScheduledActions`를 재개하면 Amazon EC2 Auto Scaling은 예약 시간이 아직 경과하지 않은 예약된 작업만 평가합니다.
## 추가 고려 사항
또한 `Launch` 또는 `Terminate`가 일시 중지되면 다음 기능이 제대로 작동하지 않을 수 있습니다.
+ **최대 인스턴스 수명** - `Launch` 또는 `Terminate`가 일시 중지된 경우, 최대 인스턴스 수명 기능이 인스턴스를 교체할 수 없습니다.
+ **스팟 인스턴스 중단** - `Terminate`가 일시 중지되고 Auto Scaling 그룹에 스팟 인스턴스가 있는 경우, 더 이상 사용 가능한 스팟 용량이 없어도 종료할 수 있습니다. `Launch`가 일시 중지된 동안 Amazon EC2 Auto Scaling은 다른 스팟 인스턴스 풀이나 동일한 스팟 인스턴스 풀이 다시 사용 가능해져도 이러한 풀에서 교체 인스턴스를 시작할 수 없습니다.
+ **용량 재조정** - `Terminate`가 일시 중지되고 용량 재조정을 사용하여 스팟 인스턴스 중단을 처리하는 경우, 스팟 용량을 더 이상 사용할 수 없으면 Amazon EC2 스팟 서비스가 인스턴스를 계속 종료할 수 있습니다. `Launch`가 일시 중지된 경우, Amazon EC2 Auto Scaling은 다른 스팟 인스턴스 풀이나 동일한 스팟 인스턴스 풀이 다시 사용 가능해져도 이러한 풀에서 교체 인스턴스를 시작할 수 없습니다.
+ **인스턴스 연결 및 분리** - `Launch` 및 `Terminate`가 일시 중지된 경우, Auto Scaling 그룹에 연결된 인스턴스를 분리할 수 있지만 `Launch`가 일시 중지된 동안에는 새 인스턴스를 그룹에 연결할 수 없습니다.
+ **대기 인스턴스** - `Launch` 및 `Terminate`가 일시 중지되면 인스턴스를 `Standby` 상태로 둘 수 있지만 `Launch`가 일시 중지된 동안에는 `Standby` 상태의 인스턴스를 서비스 상태로 되돌릴 수 없습니다.