Dynamic Scaling Policies

Target Tracking Scaling

• 가장 간단하고 쉬운 방법이다.
• 예를 들면, ASG의 평균 CPU가 40% 언저리에 있도록 설정할 수 있다.

Simple / Step Scaling

• CloudWatch 알람을 생성할 때는 한 번에 추가하거나 제거할 인스턴스의 수를 단계적으로 설정해야 한다.
• 예를 들면,
  - CPU > 70% 일 때 CloudWatch 알람을 트리거 -> 2개 추가
  - CPU < 30% 일 때 CloudWatch 알람을 트리거 -> 1개 삭제

Scheduled Actions

• 사용 패턴을 기준으로 scaling 여부를 예측할 수 있다.
• 예를 들어, 금요일 5시마다 최소 용량을 10으로 올리라고 설정할 수 있다.

Predictive Scaling

Predictive scaling이란 지속적으로 부하를 예측하고 이를 통해 다음 스케일링을 예측한다.

스케일링의 기반이 되는 좋은 지표(metrics)

• CPUUtilization
  - 여러 인스턴스들에 대한 평균 CPU 사용량
• RequestCountPerTarget
  - 인스턴스 당 갖는 요청의 수가 안정성을 유지하도록 하기 위해 측정하는 지표이다.
  • 아래의 경우 인스턴스 당 RequestCountPerTarget는 3이 된다.
    
• Average Network In / Out
  - 만약 사용하는 애플리케이션에 네트워크가 연결되어 있는 경우 사용
  - 예를 들어 업로드와 다운로드 수가 많아 EC2 인스턴스에 대해 병목 현상이 발생할 것으로 판단 된다면 평균 네트워크 입출력량을 기반으로 스케일링을 설정 해서 특정 임계값에 도달할 때 스케일링을 수행하도록 설정할 수 있다.
• 커스텀 지표
  - CloudWatch에서 애플리케이션을 기반으로 지표를 생성하고 이를 통해 스케일링 정책을 바꿀 수 있다.

Scaling Cooldowns

• 스케일링이 발생한 다음, cooldown period가 생긴다.
  - 즉, 5분 혹은 300초의 휴지 기간을 갖는 것이다(기본이 300초이다).
• cooldown 주기 동안에는 ASG는 새로운 인스턴스를 시작하거나 종료할 수 없다(새로 만들어진 인스턴스에 대한 지표가 안정되도록 하기 위함이다).
• 이 기능을 사용하지 않을 수도 있다.
  
• 즉시 사용이 가능한 AMI를 구성해 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 빠르게 처리하는 것이 좋다.
  - 왜냐하면, 인스턴스 구성에 할애되는 시간이 적으면 즉시 적용이 가능하게 되고, 활성화 시간이 빨라지면 휴지 기간 역시 단축 되어 ASG 상에서 더 많은 동적 스케일링이 가능해진다.