Amazon Web Services ブログ

Amazon EC2 Auto Scaling ターゲット追跡スケーリングの高速化

本稿は、2024 年 11 月 29 日に公開された “Faster scaling with Amazon EC2 Auto Scaling Target Tracking” を翻訳したものです。

はじめに

AWS クラウドの主な利点の 1 つは弾力性です。これにより、ユーザーは必要なリソース分だけをプロビジョニングして利用できます。ユーザーは弾力性の利点を最大限に活用するために、自動化された幅広く簡単に操作できるメカニズムを必要としていました。Amazon EC2 Auto Scaling は、変化するワークロードの需要に合わせて Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの数を自動的にスケーリングできるようにすることで、これらの課題を解決できます。また、インスタンスのライフサイクルを管理するための幅広い機能を提供しています。

Auto Scaling グループ（ASG）をスケーリングするには、ユーザーはスケーリングポリシーを作成する必要があります。スケーリングポリシーは、ワークロードの需要に合わせて Amazon EC2 の容量を調整するためのガイドラインを ASG に提供します。スケーリングポリシーにはさまざまな種類があり、それぞれ容量を管理するアプローチが異なります。 ポリシーの 1 つとしてターゲット追跡スケーリングポリシーがあります。これは、自動的にスケーリングするためのより簡単で効果的な方法です。これを使用するには、ユーザーは使用率メトリクスを定義し、維持する目標値を設定する必要があります。たとえば、平均 CPU 使用率 60％ というポリシーを設定すると、ASG は EC2 インスタンス全体にわたってメトリクスをできるだけその値に近づけます。

この投稿では、最近リリースされたターゲット追跡スケーリングのアップデートについて説明します。また、新機能を使用するターゲット追跡スケーリングポリシーを作成する手順を説明し、新機能がもたらす利点についても説明します。

ターゲット追跡スケーリングポリシーの新機能

ユーザーがアプリケーションをモダナイズするにつれ、私たちは動的な Auto Scaling ソリューションを当初のターゲット追跡スケーリングポリシーの実装を超えて拡張する必要があることを学びました。

まず、ユーザーは、ターゲット追跡スケーリングが需要の急増に対応するのに数分かかると、短期的にパフォーマンスが低下する可能性があることに気付きました。多くのユーザーが、ランニングキャパシティをバッファリングすることでこの課題を軽減しましたが、これはコストの増加につながりました。次に、ワークロードが異なればスケーリング要件も異なります。つまり、ユーザーはワークロードごとに調整されたスケーリングポリシーを作成する必要があります。これは、パフォーマンスとコストを最適化するために、時間がかかり、エラーが発生しやすく、運用上もコストがかかる作業です。

これらのユーザーの課題に対処するために、合理的で応答性の高いターゲット追跡スケーリングポリシーをリリースしました。ターゲット追跡スケーリングは、個々のアプリケーションの固有の使用パターンに合わせて応答性を自動的に調整し、アプリケーションの需要を綿密に監視して、スケーリングの決定をより迅速に行えるようになりました。また、自動チューニングにより、ユーザーはワークロードごとに調整されたスケーリングポリシーを作成しなくても、アプリケーションのパフォーマンスを向上させ、Amazon EC2 リソースの使用率を高く維持してコストを削減できます。ユーザーは維持したい目標使用率を指定するだけで、ターゲット追跡スケーリングは追加設定なしにスケーリングできるようになりました。

自動スケーリングを迅速に行うために、ユーザーは Amazon CloudWatch の高解像度メトリクスを使用してターゲット追跡スケーリングポリシーを設定できます。このきめ細かい監視により、ターゲット追跡スケーリングは変化する需要を分単位ではなく数秒単位で検出して対応します。この機能は、クライアントサービス API、ライブストリーミングサービス、e コマース Web サイト、オンデマンドデータ処理など、需要パターンが不安定なアプリケーションに最適です。

新しいターゲット追跡スケーリングポリシーの始め方

すでにターゲット追跡スケーリングポリシーを使用している場合は、自動的に調整されるターゲット追跡スケーリングにアップグレードするためのアクションは必要ありません。ターゲット追跡スケーリングポリシーは、ターゲットメトリクスの履歴を定期的に分析し、スケールアウトとスケールインを開始するための適切な感度レベルを決定します。さらに、可用性とコスト削減の両方を最適化するために追加または削除する必要がある容量も決めます。これらの決定は、需要の変化の範囲や頻度、使用量の急増が長期的か短期的かなど、アプリケーションの需要パターンの固有の特性によって異なります。ターゲット追跡スケーリングは継続的に学習し、特定のアプリケーションや需要パターンに自動的に適応するように自動的に再評価されます。

ターゲット追跡スケーリングの迅速な応答を有効にする

さらに、ターゲット追跡スケーリングポリシーからの迅速な対応を可能にするために、ユーザーは Amazon CloudWatch に 1 分未満の精度で発行されたメトリクス（高解像度メトリクスとも呼ばれます）を追跡できます。ユーザーは、既存のターゲット追跡スケーリングポリシーを更新したり、カスタマイズされたメトリクス（CustomizedMetricSpecification）の一部として高解像度メトリクスを含む新しいポリシーを作成したりできます。ユーザーは、Amazon CloudWatch にメトリクスを発行するときに作成された同じメトリクス名前空間、メトリクス名、および任意のディメンションやユニットを記述する必要があります。また、ターゲット追跡スケーリングがメトリクスを評価するために、メトリクスの粒度を示すメトリクス期間も定義する必要があります。次のステップでは、AWS マネジメントコンソールで ASG を使う方法を説明します。

ステップ 1: ASG の選択

Amazon EC2 コンソールで ASG の名前を選択します。すると次の図に示すように詳細ページに移動します。

Amazon EC2 コンソールの Auto Scaling セクションで表示される ASG の一覧

図 1: Amazon EC2 コンソールでスケーリングしたい ASG を選択

次の図に示すようにオートスケーリングタブを選択してください。動的スケーリングポリシーを作成するボタンが表示されます。

動的スケーリングポリシーを作成する図 2: 選択した ASG のオートスケーリングタブ

ステップ 2: 動的スケーリングポリシーの作成

ポリシータイプとしてターゲット追跡スケーリングを選択してください。メトリクスタイプには、カスタム CloudWatch メトリクスを選択してください。これは事前に入力された JSON スニペットを示しています。次の図に示すように、CloudWatch メトリクスの発行に使用したターゲット追跡スケーリングポリシーを使用して、スケーリングするメトリクスのメトリクス名、名前空間、ディメンションを編集できます。

更新された CustomizedMetricSpecification セクション

図 3: 更新された CustomizedMetricSpecification セクション

サポートされている最小期間は 10 秒です。10 秒のメトリクス期間を使用するには、メトリクスは 10 秒以上の解像度、たとえば 1 秒で発行する必要があります。ただし、1 秒間隔で発行すると、CloudWatch のコストが大幅に増加する可能性があります。コストに関する考慮事項については、この記事の後半で説明します。Auto Scaling では、ターゲット追跡スケーリングが使用量の急増を迅速に監視して対応できるように、60 秒の制限を設けています。

この 2 つのステップにより、ターゲット追跡スケーリングを高解像度のメトリクスでスケーリングできるようになります。

より迅速なスケーリングを可能にする

前述の手順により、ASG は使用率の変化をより迅速に検出できるため、需要が急増したときにより多くのインスタンスを追加できます。

次の図は、ターゲット追跡スケーリングポリシーがデフォルトである 60 秒の期間で構成された環境と 10 秒の期間で構成されている環境に対して、同じ負荷テストを実行した結果を示しています。各ポリシーの目標値は 60% の CPU 使用率です。負荷テストでは、需要の急増をシミュレートするために、それぞれ http リクエストを送信するたびに、3 分間で最大 20 スレッドまで増加しています。60 秒のケース（左の図）では、アプリケーションが CPU 使用率の目標である 60％（青い線）を 3 分間上回っていたことがわかります。容量（緑の線）は、システムの CPU 使用率が 100% のピークに達した後にのみ増加しました。これはアプリケーションのパフォーマンスの問題につながる可能性があり、それを回避するには、より多くの容量をプロビジョニングできるように使用率を下げることを目指さなければならず、コストが増加します。しかし、10 秒のケース（右の図）では、アプリケーションへの影響を避けるために迅速にスケーリングが行われました。容量は 1 分後に増加しましたが、その間 CPU 使用率は 60% 近くにとどまり、100% のピークレベルには達しませんでした。これにより、ユーザーはリソース使用レベルをより高くすることができ、アプリケーションのパフォーマンスに影響を与えずにコストを節約できます。

CPU 使用率と Auto Scaling InService Capacity の 2 つのグラフは、60 秒と 10 秒単位のスケーリングを比較しています。60 秒のケースでは、CPU が数分間 100％ に近づいてから、スケーリングが発生して CPU がダウンします。一方、10 秒の期間では CPU は 2 分かけて増加しますが、全体を通して目標の 60% に近い状態が続きました。

図 4: 60 秒と 10 秒のメトリクス期間で設定されたターゲット追跡スケーリングポリシー

考慮事項

高解像度のカスタムメトリクスを適用する前に、コストに影響する可能性があるため、次の要素を考慮することをお勧めします。

メトリクスタイプ: ターゲット追跡スケーリングは、メトリクスが ASG のインスタンス数に比例して変化することを前提としています。ターゲット追跡スケーリングポリシーを成功させるには、適切なメトリクスを選択することが重要です。詳細については、ターゲット追跡スケーリングポリシーのドキュメントを参照してください。

料金: これらの新機能を含め、EC2 Auto Scaling に追加料金はかかりません。ユーザーは、アプリケーションの実行に必要な AWS リソースと CloudWatch モニタリング料金のみを支払います。ただし、これらの機能に関連する CloudWatch の 3 つの請求項目を理解しておく必要があります。

1) 高解像度アラーム

2) API コール

3) カスタムメトリクス

ターゲット追跡スケーリングでは、少なくとも 2 つのアラームが生成されます。アラームはそれぞれ、使用率の高い値と低い値を追跡し、それらのしきい値の間にバッファーを配置して変動を減らします。メトリクス期間が 60 秒未満の場合、これらのアラームは高解像度のアラームとして請求されます。この記事を書いている時点で、AWS アジアパシフィック（東京）リージョンの高解像度アラームの価格は、アラームメトリクスあたり 0.30 ドルですが、標準解像度のアラームの価格はアラームメトリクスあたり 0.10 ドルです。

CloudWatch エージェントを使用している場合は、CloudWatch エージェントは metrics_collection_interval の設定値に基づいて各インスタンスから API コールを送信します。各インスタンスは、間隔ごとに 1 回 API コールを Amazon CloudWatch に送信します。Amazon CloudWatch では、メトリクスは名前空間、メトリクス名、ディメンション（オプション）、単位（オプション）のユニークな組み合わせとして定義されます。CloudWatch エージェントからプッシュされたディメンションのユニークな組み合わせは、すべてカスタムメトリックとして請求されます。

以下は、無料利用枠を過ぎて有料利用枠の第 1 段階にあるアカウントで、東京リージョンを利用して予想される月額料金（USD）の例です。この例では、1 つのターゲット追跡スケーリングポリシーで、メトリクスとアラームが 10 秒間隔に設定されている ASG で、1 か月に平均 10 個のインスタンスが実行されていることを前提としています。

1) 高解像度アラーム:

2 つのアラーム * $0.30/アラームメトリクス = $0.60/月

2) API コール:

10 インスタンス * 30 日 * 24 時間 * 3,600 秒 / 10 秒間隔 = 2,592,000 API コール

2,592,000 API コール * $0.01/1,000 リクエスト = $25.92/月

3) カスタムメトリクス:

1 つの ASG に集約されたメトリクス * $0.30/月 = $0.30/月

合計見積もり: $26.82/月（ASG で 10 個のインスタンスを実行する前提）

1 回の PutMetricData API コールで複数のメトリクスをプッシュできます。複数の AutoScalingGroupName メトリクスを発行するように CloudWatch エージェントを設定した場合、API の料金は PutMetricData のサイズ制限に達するまで同じままになり、カスタムメトリクスの料金のみが増加します。

たとえば、ASG が c8g.xlarge インスタンスを実行している場合、これらの機能によって使用率が高くなるため、実行するインスタンスを 1 つ減らすと、東京リージョンでの毎月のコスト削減は次のようになります。

1 個 c8g.xlarge インスタンス $0.15896/時間 * 30 日 * 24 時間 = $114.45/月

CloudWatch の推定コストである月額 26.82 ドルを差し引くと、ASG あたり月額 117.18 ドルの節約になります。この例では、EC2 のコストをほぼ 8% 節約できます。

メトリクスの発行とスケーリングポリシーを更新するテンプレート

高解像度のメトリクスの公開を始めるのに役立つように、AWS CloudFormation のサンプルテンプレートを用意しました。このテンプレートは、既存の ASG の新しいより速いスケーリング期間を検証するためのサンプルです。これには、CloudWatch エージェントをインストールし、ASG インスタンスの CPU 使用率を高解像度で Amazon CloudWatch に発行することが含まれます。このテンプレートには、この記事で説明されているようにターゲット追跡スケーリングポリシーも含まれています。

デプロイとカスタマイズの要件に関する説明は、AWS Samples リポジトリの Faster Scaling with EC2 Auto Scaling にあります。テンプレートにはお伝えしたいコードスニペットがいくつかあります。

まず、CloudWatch エージェントをインストールするために、テンプレートは ASG で使用される起動テンプレートの UserData を更新します。

UserData: 
          Fn::Base64: 
            !Sub |
              #!/bin/bash
              yum install amazon-cloudwatch-agent -y
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c ssm:/cw-agent-asg-aggregate-cpu -s

このコマンドは、Cloudwatch エージェントの設定を保持する AWS Systems Manager のパラメータを参照しています。

AWS Systems Manager のパラメータの次のスニペットは、10 秒間隔で CPU 使用率メトリクスを FasterScalingDemo というカスタム名前空間に報告します。このメトリクスは、Amazon CloudWatch で簡単に参照できるように、ASG の名前をディメンションとして集計されます。

CloudWatchMetricsSSMParameter:
    Type: AWS::SSM::Parameter
    Properties:
      Name: cw-agent-asg-aggregate-cpu
      Type: String
      Value: '{"agent":{"metrics_collection_interval":10,"run_as_user":"cwagent"},"metrics":{"force_flush_interval":10,"aggregation_dimensions":[["AutoScalingGroupName"]],"append_dimensions":{"AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"namespace":"FasterScalingDemo","metrics_collected":{"cpu":{"drop_original_metrics":["cpu_usage_active"],"measurement":[{"name":"cpu_usage_active","rename":"CPUUtilization"}]}}}}'
      Tier: Intelligent-Tiering
      Description: Custom metric specification for CloudWatch Agent

次に、テンプレートには更新された AWS Identity and Access Management（IAM）の IAM ロールと対応する IAM インスタンスプロファイルも含まれています。このプロファイルには、Amazon CloudWatch への PutMetricData へのアクセス権と、エージェントを設定するために以前に作成した Systems Manager パラメータを取得する権限があります。

IAMInstanceRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - ec2.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      Policies:
        - PolicyName: FasterScalingDemo
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - cloudwatch:PutMetricData
                  - ec2:DescribeTags
                  - ssm:GetParameter
                Resource: '*'
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}_IAMROLE

最後に、CloudFormation テンプレートによってデプロイされたアーキテクチャを示します。

ASG を備えた Amazon VPC は 3 つのアベイラビリティーゾーンでインスタンスを起動し、高解像度メトリクスを Amazon CloudWatch に発行します

図 5: CloudFormation テンプレートによって作成された AWS リソース

選択した ASG に対してでプレートをデプロイしたら、ターゲット追跡スケーリングを高解像度のメトリクスでテストする準備が整っているはずです。負荷テストを実行し、ターゲット追跡スケーリングが動作していることを確認できます。負荷テストがアプリケーションの使用パターンに近いほど、これらの機能の利点を判断するテストの信頼性が高まります。

まとめ

このブログでは、お客様の需要と Amazon EC2 の処理能力をより正確に一致させるために、ターゲット追跡スケーリングに追加された新機能の概要を説明しました。具体的には、高解像度の CloudWatch メトリクスをターゲット追跡スケーリングで使用し、需要に合わせて Auto Scaling レートを上げて可用性を向上させ、リソースをより有効に活用できることを示しました。高解像度メトリクスを使ったスケーリングを適用する前にこの機能をテストし、この投稿で概説されている考慮事項を検討することをお勧めします。これらの新機能の詳細については、ターゲット追跡スケーリングポリシーのドキュメントをご覧ください。

翻訳はソリューションアーキテクトの 阿部 純一郎 が担当しました。