翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon に基づくポリシーのスケーリング SQS
重要
以下の情報とステップは、カスタムメトリクスとして に発行する前に、SQSキュー属性を使用してインスタンスごとに Amazon ApproximateNumberOfMessages
キューバックログを計算する方法を示しています CloudWatch。ただし、Metric Math を使用することで、独自のメトリクスを公開するコストと労力を節約できるようになりました。詳細については、「Metric Math を使用してターゲット追跡スケーリングポリシーを作成する」を参照してください。
このセクションでは、Amazon Simple Queue Service (Amazon SQS) キューのシステム負荷の変化に応じて Auto Scaling グループをスケーリングする方法について説明します。Amazon の使用方法の詳細についてはSQS、「Amazon Simple Queue Service デベロッパーガイド」を参照してください。
Amazon SQSキューのアクティビティに応じてスケーリングを検討するシナリオがいくつかあります。例えば、ユーザーがイメージをアップロードしてオンラインで使用できるウェブアプリがあるとします。このシナリオでは、各イメージはサイズ変更されエンコードされてから公開されます。アプリケーションは Auto Scaling グループのEC2インスタンスで実行され、一般的なアップロードレートを処理するように設定されています。異常なインスタンスは終了され置き換えられて、常に現在のインスタンスレベルが維持されます。アプリケーションは、処理のために画像の未加工のビットマップデータを 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 を使用してターゲット追跡スケーリングポリシーを作成する」を参照してください。
この設定は 3 つの主要な部分で構成されます。
-
SQS キューからのメッセージを処理する目的でEC2インスタンスを管理する Auto Scaling グループ。
-
Auto Scaling グループのEC2インスタンスごとにキュー内のメッセージ数 CloudWatch を測定する Amazon に送信するカスタムメトリクス。
-
カスタムメトリクスと設定されたターゲット値. CloudWatch alarms に基づいてスケーリングするように Auto Scaling グループを設定するターゲット追跡ポリシーは、スケーリングポリシーを呼び出します。
次の図は、この設定のアーキテクチャを示しています。
制限事項と前提条件
この設定を使用するには、次の制限事項に注意する必要があります。
-
カスタムメトリクスを SDKに発行するには、 AWS CLI または を使用する必要があります CloudWatch。その後、 を使用してメトリクスをモニタリングできます AWS Management Console。
-
Amazon EC2 Auto Scaling コンソールは、カスタムメトリクスを使用するターゲット追跡スケーリングポリシーをサポートしていません。スケーリングポリシーのカスタムメトリクスSDKを指定するには、 AWS CLI または を使用する必要があります。
以下のセクションでは、実行する必要のあるタスク AWS CLI に を使用する方法について説明します。例えば、キューの現在の使用状況を反映するメトリクスデータを取得するには、 SQS get-queue-attributes コマンドを使用します。CLI がインストールされ、設定されていることを確認します。
開始する前に、使用する Amazon SQSキューが必要です。以下のセクションでは、キュー (標準 または FIFO)、Auto Scaling グループ、およびキューを使用するアプリケーションを実行しているEC2インスタンスが既にあることを前提としています。Amazon の詳細についてはSQS、「Amazon Simple Queue Service デベロッパーガイド」を参照してください。
Amazon SQSとインスタンスのスケールイン保護
インスタンスの終了時に処理されていないメッセージはSQSキューに返され、実行中の別のインスタンスで処理できます。長時間実行されるタスクが実行されるアプリケーションでは、オプションでインスタンススケールイン保護を使用して、Auto Scaling グループのスケールイン時に終了するキューワーカーを制御できます。
次の擬似コードは、長時間実行されるキュー駆動のワーカープロセスをスケールイン終了から保護する方法の 1 つを示しています。
while (true) { SetInstanceProtection(False); Work = GetNextWorkUnit(); SetInstanceProtection(True); ProcessWorkUnit(Work); SetInstanceProtection(False); }
詳細については、「インスタンスの終了を適切に処理するようにアプリケーションを設計する」を参照してください。