AWS

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

スポンサーリンク
EC2 Auto Scaling - CPU使用率に基づいてステップスケーリング AWS
スポンサーリンク
スポンサーリンク

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

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

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

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

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

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

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

構築する環境

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

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

  • 最小数:1
  • 最大数:4
  • 希望数:1

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

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

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

CloudFormationテンプレートファイル

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

awstut-fa/088 at main · awstut-an-r/awstut-fa
Contribute to awstut-an-r/awstut-fa development by creating an account on GitHub.

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

本ページは、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 PolicyStep AdjustmentMetricIntervalLowerBoundMetricIntervalUpperBoundScalingAdjustment
ScalingPolicy110.020.01
ScalingPolicy1220.02
ScalingPolicy210.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つ作成されたことがわかります。

Detail of Auto Scaling 4.

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

動作確認

通常時

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

Detail of ALB 2.

インスタンスにアクセスできました。
確かに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使用率を確認します。

Detail of Auto Scaling 5.

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

Detail of Auto Scaling 6.

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

Detail of Auto Scaling 7.

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

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

Detail of Auto Scaling 8.

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

Detail of Auto Scaling 9.

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

Detail of Auto Scaling 10.

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

スケールイン1

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

Detail of Auto Scaling 11.

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

Detail of Auto Scaling 12.

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

Detail of Auto Scaling 13.

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

スケールアウト2

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

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

Detail of Auto Scaling 14.

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

Detail of Auto Scaling 15.

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

Detail of Auto Scaling 16.

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

Detail of Auto Scaling 17.

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

スケールイン2

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

Detail of Auto Scaling 18.

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

Detail of Auto Scaling 19.

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

Detail of Auto Scaling 20.

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

まとめ

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

タイトルとURLをコピーしました