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

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

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 グループ内のインスタンスの数は複数の要因によって決まります。例えば、メッセージを処理するためにかかる時間や、許容されるレイテンシー (キュー遅延) の量などです。

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

例として、現在、10 個のインスタンスを持つ Auto Scaling グループがあり、キュー (ApproximateNumberOfMessages) にある可視メッセージの数が 1,500 であるとします。メッセージあたりの平均処理時間が 0.1 秒で、最長許容レイテンシーが 10 秒の場合、インスタンスあたりの許容バックログは 10/0.1、つまり 100 メッセージとなります。つまり、100 がターゲット追跡ポリシーのターゲット値です。インスタンスあたりのバックログがターゲット値に達すると、スケールアウトイベントが発生します。インスタンスあたりのバックログが既に 150 メッセージ (1,500 メッセージ/10 インスタンス) あるため、グループは、ターゲット値との比例を維持するために 5 インスタンス分スケールアウトします。

次の手順は、カスタムメトリクスを公開し、これらの計算に基づいてスケーリングするように Auto Scaling グループを設定するターゲット追跡スケーリングポリシーを作成する方法を示しています。

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

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

制限

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

以下のセクションでは、実行する必要があるタスク AWS CLI に を使用します。例えば、キューの現在の使用状況を反映するメトリックスデータを取得するには、SQS get-queue-attributes コマンドを使用します。

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

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

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

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

詳細については、「インスタンスの終了を的確に処理するようにアプリケーションを設計する」を参照してください。