EC2 Auto Scaling – CPU使用率に基づいてステップスケーリング

以下のページでEC2 Auto Scalingの基本事項を取り上げました。

本ページでは、動的スケーリングの挙動を確認します。
EC2 Auto Scalingの動的スケーリングには以下の3種類があります。

シンプルスケーリング
ステップスケーリング
ターゲット追跡スケーリング

今回はステップスケーリングの挙動を確認します。
CPU使用率に基づいてインスタンス数をスケーリングします。

なおシンプルスケーリングに関しては、以下のページをご確認ください。

ターゲット追跡スケーリングに関しては、以下のページをご確認ください。

構築する環境

Diagram of EC2 Auto Scaling - Step Scaling based on CPU utilization.

ALBを作成し、プライベートサブネット内のEC2 Auto Scalingをアタッチします。

Auto Scalingのインスタンス数は以下の通りに設定します。

最小数：1
最大数：4
希望数：1

スケーリングはCPU使用率に応じて実行されるように設定します。
CPU使用率が50~70%場合は1台分、70%を超える場合は2台分スケールアウトします。
CPU使用率が50%未満の場合は、１台分スケールインします。

Auto Scalingグループ内で起動するEC2インスタンスですが、最新版のAmazon Linux 2とします。
S3上のyumリポジトリからApacheをインストールし、Webサーバとして動作するように設定します。

起動したインスタンスにアクセスするために、SSM Session Managerを使用します。

CloudFormationテンプレートファイル

上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置しています。

https://github.com/awstut-an-r/awstut-fa/tree/main/088

テンプレートファイルのポイント解説

本ページは、EC2 Auto Scalingにおいてステップスケーリングを設定する方法を中心に取り上げます。

プライベートサブネット内のリソースをALBにアタッチする方法については、以下のページをご確認ください。

プライベートサブネット内のインスタンスでyumを実行する方法については、以下のページをご確認ください。

(参考)起動テンプレート

Resources:
  LaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        IamInstanceProfile:
          Arn: !GetAtt InstanceProfile.Arn
        ImageId: !Ref ImageId
        InstanceType: !Ref InstanceType
        SecurityGroupIds:
          - !Ref InstanceSecurityGroup
        UserData: !Base64 |
          #!/bin/bash -xe
          yum update -y
          yum install -y httpd
          systemctl start httpd
          systemctl enable httpd
          ec2-metadata -i > /var/www/html/index.html
      LaunchTemplateName: !Sub "${Prefix}-LaunchTemplate"
Code language: YAML (yaml)

起動テンプレートはAuto Scalingグループ内で起動するEC2インスタンスの設定情報に関するリソースです。
EC2 Auto Scalingを構成する上で、起動テンプレートまたは起動設定を作成する必要があります。
ただし現在、起動設定を使用してAuto Scalingを構成することは非推奨となっています。

起動設定を使用しないことを強くお勧めします。Amazon EC2 Auto Scaling または Amazon EC2 には完全な機能を提供していません。起動設定に関する情報は、起動設定から起動テンプレートにまだ移行していないお客様向けに提供しています。
起動設定

基本的にはEC2インスタンスと同様の設定項目です。
例えばImageIdやInstanceTypeプロパティで、起動させるインスタンスのAMIやインスタンスタイプを指定します。

UserDataプロパティでユーザデータを設定できます。
今回はApacheをインストールおよび有効化し、HTMLファイルにインスタンスIDを書き込み、Apacheのルートページに設定します。

Auto Scalingグループ

Resources:
  AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: !Sub "${Prefix}-AutoScalingGroup"
      DesiredCapacity: !Ref DesiredCapacity
      LaunchTemplate:
        LaunchTemplateId: !Ref LaunchTemplate
        Version: !GetAtt LaunchTemplate.LatestVersionNumber
      MaxSize: !Ref MaxSize
      MinSize: !Ref MinSize
      VPCZoneIdentifier:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
      TargetGroupARNs:
        - !Ref ALBTargetGroup
Code language: YAML (yaml)

ステップスケーリングを構成する上で、Auto Scalingグループに特別な設定は不要です。

グループ内に作成するインスタンス数を、以下の通り設定します。
DesiredCapacityプロパティで希望数を1に設定します。
MaxSizeプロパティで最大数を4に設定します。
MinSizeプロパティで最小数を1に設定します。

スケーリングポリシー

Resources:
  ScalingPolicy1:
    Type: AWS::AutoScaling::ScalingPolicy
    Properties:
      AdjustmentType: ChangeInCapacity
      AutoScalingGroupName: !Ref AutoScalingGroup
      MetricAggregationType: Average
      PolicyType: StepScaling
      StepAdjustments:
        - MetricIntervalLowerBound: !Ref MetricIntervalLowerBound1
          MetricIntervalUpperBound: !Ref MetricIntervalUpperBound1
          ScalingAdjustment: !Ref ScalingAdjustment1
        - MetricIntervalLowerBound: !Ref MetricIntervalLowerBound2
          ScalingAdjustment: !Ref ScalingAdjustment2

  ScalingPolicy2:
    Type: AWS::AutoScaling::ScalingPolicy
    Properties:
      AdjustmentType: ChangeInCapacity
      AutoScalingGroupName: !Ref AutoScalingGroup
      MetricAggregationType: Average
      PolicyType: StepScaling
      StepAdjustments:
        - MetricIntervalUpperBound: !Ref MetricIntervalUpperBound2
          ScalingAdjustment: !Ref ScalingAdjustment3
Code language: YAML (yaml)

ステップスケーリングを構成するためには、2つのスケーリングポリシーを作成します。
1つ目はスケールアウト、2つ目はスケールインするためのポリシーです。

PolicyTypeプロパティにスケーリングポリシーの種類を設定します。
今回はステップスケーリングですから、「StepScaling」を指定します。

MetricAggregationTypeプロパティでCloudWatchメトリクスの集約タイプを設定できます。
今回は平均値を意味する「Average」を指定します。

StepAdjustmentsプロパティでステップスケーリングの設定を行います。
ステップスケーリングの設定は、ステップ調整を定義するという形を取ります。
ステップ調整の説明はAWS公式ページに詳しいですが、3つの要素で構成されています。

閾値を基準としたメトリクス値の下限：MetricIntervalLowerBoundプロパティ
閾値を基準としたメトリクス値の上限：MetricIntervalUpperBoundプロパティ
増減するインスタンス数：ScalingAdjustmentプロパティ

CloudWatchアラームの項目で説明しますが、今回は50%を閾値とします。
今回は以下の通りに設定します。

Scaling Policy	Step Adjustment	MetricIntervalLowerBound	MetricIntervalUpperBound	ScalingAdjustment
ScalingPolicy1	1	0.0	20.0	1
ScalingPolicy1	2	20.0	–	2
ScalingPolicy2	1	–	0.0	-1

スケールアウト用ポリシーでは2ステップを定義します。
1つ目はCPU使用率が50~70%の時に、1台分インスタンスを追加するための設定です。
2つ目はCPU使用率が70%以上の時に、2台分インスタンスを追加するための設定です。

スケールイン用ポリシーでは1ステップを定義します。
CPU使用率が50%以下の時に、1台分インスタンスを削除するための設定です。

AdjustmentTypeプロパティでスケーリング調整タイプを設定します。
今回は「ChangeInCapacity」を指定します。このタイプの説明は以下に引用した通りです。

ChangeInCapacity – 指定した値だけ現在のキャパシティーを増減させます。正の調整値は現在のキャパシティーを増やし、負の調整値は現在のキャパシティーを減らします。たとえば、グループの現在のキャパシティーが 3 で、調整値が 5 の場合、このポリシーが実行されると、キャパシティーユニットが 5 個キャパシティーに追加され、合計 8 個のキャパシティーユニットになります。
スケーリング調整タイプ

CloudWatchアラーム

Resources:
  Alarm1:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmActions:
        - !Ref ScalingPolicy1
      AlarmName: !Sub "${Prefix}-Alarm1"
      ComparisonOperator: GreaterThanOrEqualToThreshold
      Dimensions:
        - Name: AutoScalingGroupName
          Value: !Ref AutoScalingGroup
      EvaluationPeriods: !Ref AlarmEvaluationPeriod
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Period: !Ref AlarmPeriod
      Statistic: Average
      Threshold: !Ref AlarmThreshold

  Alarm2:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmActions:
        - !Ref ScalingPolicy2
      AlarmName: !Sub "${Prefix}-Alarm2"
      ComparisonOperator: LessThanOrEqualToThreshold
      Dimensions:
        - Name: AutoScalingGroupName
          Value: !Ref AutoScalingGroup
      EvaluationPeriods: !Ref AlarmEvaluationPeriod
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Period: !Ref AlarmPeriod
      Statistic: Average
      Threshold: !Ref AlarmThreshold
Code language: YAML (yaml)

CloudWatchアラームはスケーリングポリシーが動作するきっかけとして作用します。
アラームはスケーリングポリシーごとに作成します。

1つ目のアラームはスケールアウトポリシー用、2つ目のアラームはスケールインポリシー用です。
これはAlarmActionsプロパティで指定します。

Dimensionsプロパティでメトリックを計測する対象を設定します。
今回はAuto ScalingグループのCPU使用率を計測するために、Nameに「AutoScalingGroupName」を、ValueにグループのIDを指定します。

今回はCPU使用率に応じてスケーリングが開始されるように設定します。
MetricNameプロパティに「CPUUtilization」、Namespaceプロパティに「AWS/EC2」、Statisticプロパティに「Average」を指定することによって、Auto Scalingグループ全体のCPU使用率の平均値を計測します。

CPU使用率の計測期間はPeriodプロパティで設定します。
今回は「60」を指定して、1分ごとに計測します。

ComparisonOperator・Threshold・EvaluationPeriodsプロパティで閾値を設定します。
アラーム1では、それぞれ「GreaterThanOrEqualToThreshold」、「50.0」、「2」を指定して、CPU使用率が2回連続で50%以上になった場合に発動します。
アラーム2では、それぞれ「LessThanOrEqualToThreshold」、「50.0」、「2」を指定して、CPU使用率が2回連続で50%以下になった場合に発動します。

環境構築

CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。

CloudFormationスタックを作成し、スタック内のリソースを確認する

CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください。

各スタックのリソースを確認した結果、今回作成された主要リソースの情報は以下の通りです。

ALB：fa-088-ALB
ALBのDNS名：fa-088-alb-1899073536.ap-northeast-1.elb.amazonaws.com
ALBのターゲットグループ：fa-088-ALBTargetGroup
起動テンプレート：fa-088-LaunchTemplate
EC2 Auto Scalingグループ：fa-088-AutoScalingGroup
CloudWatchアラーム1：fa-088-Alarm1
CloudWatchアラーム2：fa-088-Alarm2

作成されたリソースをAWS Management Consoleから確認します。
ALBを確認します。

ALBのDNS名等が確認できます。

Auto Scalingグループを確認します。

希望数・最小数が1、最大数が4です。つまりAuto Scalingグループ内に、通常時は1つ、スケールアウト時は最大4つのインスタンスが起動します。

スケーリングポリシーを確認します。

2つのスケーリングポリシーが作成されていることがわかります。
スケールアウト/イン用のポリシーです。
2つのポリシーが動作するきっかけであるCloudWatchアラームが発動する条件も確認することができます。

Auto Scalingグループのアクティビティ履歴を見ると、空だったグループ内にインスタンスが1つ作成されたことがわかります。

グループ内のインスタンスを確認すると、確かにインスタンスが1つ起動していることがわかります。

動作確認

通常時

準備が整いましたので、ALBにアクセスします。

インスタンスにアクセスできました。
確かにALBにAuto Scalingグループがアタッチされていることがわかります。

スケールアウト1

スケールアウト時の挙動を確認します。
SSM Session Managerを使用して、Auto Scalingグループ内のインスタンスにアクセスします。

% aws ssm start-session --target i-07284c0f4ed6c97e4

Starting session with SessionId: root-0d5c2cb28ca211e00
sh-4.2$
Code language: Bash (bash)

SSM Session Managerの詳細につきましては、以下のページをご確認ください。

yesコマンドを使用して、インスタンスのCPU使用率を高めます。

sh-4.2$ yes > /dev/null &
Code language: Bash (bash)

CPU使用率を確認します。

CPU使用率が50%を超えました。
これでスケールアウトが開始される条件を満たしました。

Auto Scalingグループのアクティビティ履歴を見ると、新たなインスタンスが起動したことがわかります。

グループ内のインスタンスを確認すると、確かにインスタンスが1台追加されていることがわかります。
CPU使用率が50~70%のため、ステップ1、つまりインスタンス1台分が追加されたということです。

引き続きyesコマンドを継続し、CPU使用率が50~70%を維持します。

しばらく待機するとスケールアウトが継続して実行されます。

スケールアウトが実施され続けました。
1台ずつインスタンスが増大していることがわかります。

最終的にAuto Scalingグループの最大数である4台までスケールアウトが実行されました。

スケールイン1

インスタンス数が増えたことで、Auto Scalingグループ全体におけるCPU使用率の平均値が50%を下回ります。

CPU使用率が50以下となりましたので、スケールアウトが開始される条件を満たしました。

スケールインポリシーに従い、1台ずつインスタンスが削除されていることがわかります。

最終的にAuto Scalingグループの最小数である1台のみが残りました。

スケールアウト2

今度はステップ2でのスケールアウトの挙動を確認します。

先ほどと同様に、バックグラウンドで何度かyesコマンドを実行して、CPU使用率が70%を超えるように仕向けます。

これでステップ2でスケールアウトが開始される条件を満たしました。

確かに1度のスケールアウトで2台のインスタンスが追加されていることが確認できます。

さらにスケールアウトが進むと、Auto Scalingグループの最大数である4つまでインスタンスが追加されます。

確かにAuto Scalingグループ内に4つのインスタンスが作成されていることがわかります。

スケールイン2

再びインスタンス数が増えたことで、Auto Scalingグループ全体におけるCPU使用率の平均値が50%を下回ります。

CPU使用率が50以下となりましたので、スケールアウトが開始される条件を満たしました。

スケールインポリシーに従い、1台ずつインスタンスが削除されていることがわかります。

最終的にAuto Scalingグループの最小数である1台のみが残りました。

まとめ

EC2 Auto Scalingの動的スケーリングの一種であるステップスケーリングの挙動を確認しました。