Amazon SQS に基づくスケーリング - Amazon EC2 Auto Scaling
適切なメトリクスを用いたターゲット追跡を使用する制限事項と前提条件 Amazon SQS に基づくスケーリングを設定Amazon SQS とインスタンスのスケールイン保護

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon SQS に基づくスケーリング

重要

以下の情報と手順は、にカスタムメトリックスとして公開する前に、キュー属性を使用してインスタンスごとの Amazon SQS ApproximateNumberOfMessages キューバックログを計算する方法を示しています。 CloudWatchただし、Metric Math を使用することで、独自のメトリクスを公開するコストと労力を節約できるようになりました。詳細については、「Metric Math を使用する、Amazon EC2 Auto Scaling のターゲット追跡スケーリングポリシーを作成する」を参照してください。

このセクションでは、Amazon Simple Queue Service (Amazon SQS) キュー内のシステムロードの変化に応じて Auto Scaling グループをスケーリングする方法について説明します。Amazon SQS の使用方法の詳細については、「Amazon Simple Queue Service 開発者ガイド」をご参照ください。

Amazon SQS キューのアクティビティに応じたスケーリングを検討するシナリオはいくつかあります。例えば、ユーザーがイメージをアップロードしてオンラインで使用できるウェブアプリがあるとします。このシナリオでは、各イメージはサイズ変更されエンコードされてから公開されます。このアプリケーションは、標準的なアップロード速度を処理するように設定された Auto Scaling グループ内の EC2 インスタンスで実行されます。異常なインスタンスは終了され置き換えられて、常に現在のインスタンスレベルが維持されます。このアプリは処理のためイメージの raw ビットマップデータを SQS キューに配置します。イメージが処理され、処理されたイメージはユーザーから確認できる場所に発行されます。このシナリオのアーキテクチャは、イメージのアップロード数が時間の経過とともに変化しない場合に有効です。ただし、アップロード数が時間の経過とともに変化する場合は、動的スケーリングを使用して Auto Scaling グループのキャパシティーを拡張することを検討してください。

適切なメトリクスを用いたターゲット追跡を使用する

カスタム Amazon SQS キューメトリクスに基づくターゲット追跡スケーリングポリシーを使用する場合、動的スケーリングはアプリケーションの需要曲線に合わせてより効果的に調整できます。ターゲット追跡のメトリクスの選択の詳細については、「メトリクスを選択する」を参照してください。

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 グループを設定するターゲット追跡スケーリングポリシーを作成する方法を示しています。

重要

コストを削減するには、必ず代わりに Metric Math を使用してください。詳細については、「Metric Math を使用する、Amazon EC2 Auto Scaling のターゲット追跡スケーリングポリシーを作成する」を参照してください。

この設定は 3 つの主要な部分で構成されます。

  • SQS キューからのメッセージを処理するために EC2 インスタンスを管理する Auto Scaling グループ。

  • Amazon CloudWatch に送信するカスタムメトリックス。Auto Scaling グループの EC2 インスタンスごとにキュー内のメッセージ数を測定します。

  • カスタムメトリックスと設定されたターゲット値に基づいてスケーリングするように Auto Scaling グループを設定するターゲット追跡ポリシー。 CloudWatch アラームはスケーリングポリシーを呼び出します。

次の図は、この設定のアーキテクチャを示しています。

キューを使用する Amazon EC2 Auto Scaling アーキテクチャ図

制限事項と前提条件

この設定を使用するには、次の制限事項に注意する必要があります。

  • AWS CLI または SDK を使用してカスタムメトリックスを公開する必要があります。 CloudWatchその後、を使用してメトリクスをモニタリングできます AWS Management Console。

  • Amazon EC2 Auto Scaling コンソールには、カスタムメトリックスを使用するターゲット追跡スケーリングポリシーはありません。 AWS CLI または SDK を使用してスケーリングポリシーのカスタムメトリックスを指定する必要があります。

以下のセクションでは、 AWS CLI を実行する必要のあるタスクにを使用するように指示しています。たとえば、キューの現在の使用状況を反映するメトリックデータを取得するには、SQS get-queue-attributesコマンドを使用します。CLI がインストールされ、設定されていることを確認します。

開始する前に、使用する Amazon SQS キューが必要です。以下のセクションは、キュー (標準または FIFO)、Auto Scaling グループ、キューを使用するアプリケーションを実行している EC2 インスタンスがあることを前提としています。Amazon SQS の詳細については、「Amazon Simple Queue Service Developer Guide」を参照してください。

Amazon SQS に基づくスケーリングを設定

ステップ 1: CloudWatch カスタムメトリクスを作成する

カスタムメトリックスは、選択したメトリックス名と名前空間を使用して定義されます。カスタムメトリクスの名前空間を AWS/ で始めることはできません。カスタムメトリクスの公開について詳しくは、Amazon CloudWatch ユーザーガイドの「カスタムメトリクスの公開」トピックを参照してください。

次の手順に従い、 AWS まずアカウントから情報を読んでカスタムメトリクスを作成します。次に、前のセクションで推奨されたようにインスタンスメトリクスごとにバックログを計算します。最後に、この数値を CloudWatch 1 分単位で公開します。可能な限り、システム負荷の変化に迅速に対応できるように、メトリクスを 1 分単位でスケーリングすることを強くお勧めします。

カスタムメトリクス () CloudWatch を作成するにはAWS CLI

  1. SQS get-queue-attributesコマンドを使用して、キューで待機しているメッセージの数を取得します (ApproximateNumberOfMessages)。

    aws sqs get-queue-attributes --queue-url https://sqs.region.amazonaws.com/123456789/MyQueue \
  --attribute-names ApproximateNumberOfMessages

  2. describe-auto-scaling-groupsコマンドを使用して、グループの実行容量、InServiceつまりライフサイクル状態にあるインスタンスの数を取得します。このコマンドは、Auto Scaling グループのインスタンスとそのライフサイクル状態を返します。

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg

  3. キューからの取得に使用できるメッセージの概数をグループの実行キャパシティで除算して、インスタンスあたりのバックログを算出します。

  4. 1 分ごとに実行されるスクリプトを作成して、インスタンスごとのバックログ値を取得し、 CloudWatch カスタムメトリックスに公開します。カスタムメトリクスを公開する際は、そのメトリクスの名前、名前空間、単位、値、および 0 以上のディメンションを指定します。ディメンションには、そのディメンションの名前と値を含みます。

    カスタムメトリクスを公開するには、イタリック体のプレースホルダー値を任意のメトリック名、メトリックの値、名前空間 (」AWS「で始まらない限り)、ディメンション (オプション)」に置き換え、次のコマンドを実行します。put-metric-data

    aws cloudwatch put-metric-data --metric-name MyBacklogPerInstance --namespace MyNamespace \
  --unit None --value 20 --dimensions MyOptionalMetricDimensionName=MyOptionalMetricDimensionValue

アプリケーションが目的のメトリクスを出力すると、データがに送信されます。 CloudWatch CloudWatch メトリクスはコンソールに表示されます。 CloudWatch にログインしてページに移動するとアクセスできます。 AWS Management Console その後、メトリクスを表示するには、メトリクスページに移動するか、検索ボックスを使用してメトリクスを検索します。メトリックスの表示については、Amazon CloudWatch ユーザーガイドの「使用可能なメトリックスを表示する」を参照してください。

ステップ 2: ターゲット追跡スケーリングポリシーを作成する

この時点で、作成したメトリクスをターゲット追跡スケーリングポリシーに追加できるようになっています。

ターゲット追跡スケーリングポリシーを作成するには (AWS CLI)

  1. 以下の cat コマンドを使用して、スケーリングポリシーのターゲット値と、カスタムメトリクスの仕様を指定する JSON ファイル (名前: config.json) をホームディレクトリに保存します。各ユーザー入力プレースホルダーを独自の情報に置き換えます。TargetValue には、インスタンスあたりの適正バックログメトリックスを計算して、それを入力します。この数を計算するには、上記のセクションで説明しているとおり、標準のレイテンシー値を決定し、その値をメッセージの処理にかかる平均時間で割ります。

    ステップ 1 で作成したメトリクスにディメンションを指定しなかった場合は、カスタムメトリクスの仕様にディメンションを含めないでください。

    $ cat ~/config.json
{
   "TargetValue":100,
   "CustomizedMetricSpecification":{
      "MetricName":"MyBacklogPerInstance",
      "Namespace":"MyNamespace",
      "Dimensions":[
         {
            "Name":"MyOptionalMetricDimensionName",
            "Value":"MyOptionalMetricDimensionValue"
         }
      ],
      "Statistic":"Average",
      "Unit":"None"
   }
}

  2. put-scaling-policyconfig.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

    これにより、2 つのアラーム (スケールアウトとスケールイン) が作成されます。また、登録されているポリシーの Amazon リソースネーム (ARN) も返されます。これにより CloudWatch CloudWatch 、メトリクスのしきい値を超えるとスケーリングが呼び出されます。

ステップ 3: スケーリングポリシーをテストする

設定が完了したら、スケーリングポリシーが機能していることを確認します。SQS キュー内のメッセージ数を増やし、Auto Scalingグループが追加の EC2 インスタンスを起動したことを確認することによってテストできます。SQS キュー内のメッセージ数を減らし、Auto Scaling グループが EC2 インスタンスを終了したことを確認することによってもテストできます。

スケールアウト機能をテストするには

  1. 「Amazon SQS 標準キューを作成してメッセージを送信する」または「Amazon SQS FIFO キューを作成してメッセージを送信する」の手順に従って、キューにメッセージを追加します。インスタンスあたりのバックログメトリックスがターゲット値を超えるようにキュー内のメッセージ数を増やしたことを確認します。

    この変更により、アラームの呼び出しに数分かかる場合があります。

  2. describe-auto-scaling-groupsコマンドを使用して、グループがインスタンスを起動したことを確認します。

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
スケールイン機能をテストするには

  1. 「メッセージの受信と削除 (コンソール)」の手順に従って、キューからメッセージを削除します。インスタンスあたりのバックログメトリックスがターゲット値を下回るようにキュー内のメッセージ数を減らしたことを確認します。

    この変更により、アラームの呼び出しに数分かかる場合があります。

  2. describe-auto-scaling-groupsコマンドを使用して、グループがインスタンスを終了したことを確認します。

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg

Amazon SQS とインスタンスのスケールイン保護

インスタンスの削除時に処理されていなかったメッセージは、SQS キューに戻され、まだ実行中である別のインスタンスで処理されます。長時間実行されるタスクが実行されるアプリケーションでは、オプションでインスタンススケールイン保護を使用して、Auto Scaling グループのスケールイン時に終了するキューワーカーを制御できます。

次の擬似コードは、長時間実行されるキュー駆動のワーカープロセスをスケールイン終了から保護する方法の 1 つを示しています。

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

詳細については、「インスタンスの終了を正常に処理するために、Amazon EC2 Auto Scaling でアプリケーションを設計する」を参照してください。