Amazon EC2 Auto Scaling (日本語)
ユーザーガイド

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

このセクションでは、Amazon Simple Queue Service (Amazon SQS) キューの需要の変化に応じて Auto Scaling グループをスケールする方法を説明します。Amazon SQS は、分散されたソフトウェアシステムとコンポーネントを統合および分離することができる、安全で耐久性があり、利用可能なホストされたキューを提供します。Amazon SQS がよくわからない場合は、「Amazon Simple Queue Service 開発者ガイド」で詳細を参照してください。

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

このアーキテクチャは、イメージのアップロード数が時間の経過とともに変化しない場合はうまく機能します。それでは、アップロードレベルが変わるとどうなるでしょうか。 アップロードが予測可能なスケジュールで増減する場合は、これらの規模の拡大や縮小を実行する日時を指定できます。詳細については、「Amazon EC2 Auto Scaling のスケジュールに基づくスケーリング」を参照してください。ポリシーに基づくスケーリングは、Auto Scaling グループをより動的にスケーリングする方法であり、スケーリングプロセスを制御するパラメータを定義できます。たとえば、アップロードの平均数が特定のレベルに達したときは常に EC2 インスタンスのフリートを拡大するポリシーを作成できます。この方法は、いつ条件が変化するかが不明である場合に、変化する条件に応じてスケーリングするために役立ちます。

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

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

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

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

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


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

効果的なメトリクスとターゲット値の選択

Amazon SQS キューにあるメッセージの数のみでは、必要なインスタンスの数は定義されません。実際には、フリート内のインスタンスの数は複数の要因によって決まります。たとえば、メッセージを処理するためにかかる時間や、許容されるレイテンシー (キュー遅延) の量などです。

解決策は、インスタンスあたりのバックログのメトリクスを使用して、ターゲット値を維持するインスタンスあたりの適正バックログにすることです。これらの数は以下のように計算できます。

  • インスタンスあたりのバックログ: インスタンスあたりのバックログを決定するには、まず Amazon SQS メトリックス ApproximateNumberOfMessages を使用して SQS キューの長さ (このキューから取得できるメッセージ数) を決定します。その数をフリートの実行キャパシティーで割ります。Auto Scaling グループの場合、これは InService 状態にあるインスタンスの数です。これでインスタンスあたりのバックログを得ることができます。

  • インスタンスあたりの適正バックログ: ターゲット値を決定するには、まずレイテンシーの点でアプリケーションが受け付けることができる数を計算します。次に、適切なレイテンシー値を取ってそれを EC2 インスタンスがメッセージを処理する平均所要時間で割ります。

例で説明すると、現在の ApproximateNumberOfMessages は 1500 であり、フリートの実行キャパシティーは 10 です。メッセージあたりの平均処理時間が 0.1 秒であり、最長許容レイテンシーが 10 秒の場合、インスタンスあたりの適正バックログは 10/0.1、つまり 100 です。つまり、100 がターゲット追跡ポリシーのターゲット値です。インスタンスあたりバックログは現在 150 (1500/10) であるため、フリートはターゲット値との比例を維持するために 5 インスタンス分スケールアウトします。

以下の例では、この計算に基づいて Auto Scaling グループをスケーリングするように設定する、カスタムメトリクスとターゲット追跡ポリシーを作成します。

Amazon SQS のスケーリングの設定

以下のセクションでは、AWS CLI を使用して SQS キューの自動スケーリングを設定する方法について説明します。この手順は、キュー (標準または FIFO)、Auto Scaling グループ、キューを使用するアプリケーションを実行している EC2 インスタンスがあることを前提としています。

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

カスタム集計メトリクスを作成します。まず、AWS アカウントからメトリクスを読み取ります。次に、前のセクションで推奨されたインスタンスメトリクスごとにバックログを計算します。最後に、この数字を CloudWatch に 1 分間隔で発行します。

可能な限り、1 分間隔で EC2 インスタンスメトリクスをスケールします (詳細モニタリングとも呼ばれます)。これにより、使用率の変化に迅速に対応できます。5 分間隔でメトリクスをスケーリングすると、応答時間が低速になり、古いメトリクスデータに基づいてスケーリングすることになる可能性があります。デフォルトでは、EC2 インスタンスで基本モニタリングが有効になります。つまり、インスタンスのメトリクスデータは 5 分間隔で利用できます。詳細モニタリングを有効にして、1 分間隔でインスタンスのメトリクスデータを取得できます。詳細については、「Amazon CloudWatch を使用した Auto Scaling グループとインスタンスのモニタリング」を参照してください。

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

  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. ApproximateNumberOfMessages メトリックスをフリートの実行キャパシティーメトリックスで割って、インスタンスあたりのバックログを計算します。

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

    以下に CLI put-metric-data コマンドの例を示します。

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

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

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

次に、アプリケーションの負荷が変化したときにグループ内で実行中の EC2 インスタンスの数を動的に増減するように Auto Scaling グループに指示する、ターゲット追跡スケーリングポリシーを作成できます。ターゲット追跡スケーリングポリシーを使用できるのは、スケーリングメトリクスがグループの容量に比例して増減する使用率メトリクスであるためです。

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

  1. 以下のコマンドを使用して、ホームディレクトリの config.json ファイルにスケーリングポリシーのターゲット値を指定します。

    TargetValue には、インスタンスあたりの適正バックログメトリックスを計算して、それを入力します。この数を計算するには、通常のレイテンシー値を決定し、メッセージの処理にかかる平均時間で割ります。

    $ cat ~/config.json { "TargetValue":100, "CustomizedMetricSpecification":{ "MetricName":"MyBacklogPerInstance", "Namespace":"MyNamespace", "Dimensions":[ { "Name":"MyOptionalMetricDimensionName", "Value":"MyOptionalMetricDimensionValue" } ], "Statistic":"Average", "Unit":"None" } }
  2. 前のステップで作成した config.json ファイルと共に put-scaling-policy コマンドを使用して、スケーリングポリシーを作成します。

    aws autoscaling put-scaling-policy --policy-name my-scaling-policy --auto-scaling-group-name my-asg \ --policy-type TargetTrackingScaling --target-tracking-configuration file://~/config.json

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

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

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

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

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

    この変更により CloudWatch アラームがトリガーされるまで数分かかる場合があります。

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

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

スケールイン機能をテストするには

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

    この変更により CloudWatch アラームがトリガーされるまで数分かかる場合があります。

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

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