メニュー
AWS Elastic Beanstalk
開発者ガイド (API Version 2010-12-01)

ワーカー環境

アプリケーションで、完了するまでに長い時間がかかるオペレーションまたはワークフローを実行する場合、それらのタスクを専用のワーカー環境にオフロードできます。ブロックオペレーションを実行するプロセスからウェブアプリケーションのフロントエンドを分離することは、アプリケーションに負荷がかかっていても応答性を保つための一般的な方法です。

長い時間実行されるタスクとは、イメージやビデオの処理、E メールの送信、ZIP アーカイブの生成など、リクエストの完了までの時間を実質的に増やすタスクです。これらのオペレーションの完了には 1~2 秒しかかからない場合がありますが、数秒の遅延であっても、それ以外の場合は 500 ms 以下で完了するウェブリクエストにとっては大きなものです。

1 つのオプションでは、ワーカープロセスをローカルにスポーンし、成功を返して、タスクを非同期的に処理します。インスタンスが、それに送信されたすべてのタスクに追い付くことができれば、この方法は有効です。ただし、高い負荷がかかった場合、インスタンスはバックグラウンドタスクを処理しきれなくなり、より優先度の高いリクエストに応答しなくなる可能性があります。個別のユーザーが複数のタスクを生成できる場合、負荷の増加はユーザーの増加に対応できず、ウェブサーバー層を効果的にスケールアウトすることが困難になる可能性があります。

長い時間ローカルに実行されるタスクを回避するため、プログラミング言語で AWS SDK を使用し、Amazon Simple Queue Service キューに送信して、インスタンスの異なるセットでそれらを行うプロセスを実行できます。ワーカーインスタンスは、それらを行うキャパシティーがある場合のみキューから項目を取り出し、処理しきれなくなるのを防ぎます。

Elastic Beanstalk は Amazon SQS キューを管理し、キューから読み取る各インスタンスでデーモンプロセスを自動的に実行することで、このプロセスを簡略化します。デーモンがキューから項目を取得すると、キューメッセージのコンテンツを本文に含めて、HTTP POST リクエストをローカルに http://localhost/ に送信します。アプリケーションに必要なのは、POST に応じて長い時間がかかるタスクを実行することです。デーモンを設定し、別のパスに送信する、application/JSON 以外の MIME タイプを使用する、既存のキューに接続する、または接続、タイムアウト、再試行をカスタマイズすることができます。

 Elastic Beanstalk ワーカー環境枠での Amazon SQS メッセージの処理

定期的なタスクでは、cron スケジュールに基づいてメッセージをキューに入れるようワーカーデーモンを設定することもできます。定期的な各タスクでは、別のパスに POST できます。各タスクのスケジュールおよびパスを定義するソースコードに YAML ファイルを含めて、定期的なタスクを有効にします。

ワーカー環境 SQS デーモン

ワーカー環境は、Elastic Beanstalk が提供すプロセスデーモンを実行します。このデーモンは定期的に更新され、機能の追加とバグの修正が行われます。デーモンの最新バージョンを取得するには、最新のプラットフォームバージョンに更新します。

機能

リリース日

説明

拡張ヘルスレポート

2015 年 8 月 11 日

環境の状態をより詳細に正確にモニタリングします。

定期的なタスク

2015 年 2 月 17 日

アプリケーションソースコードの cron.yaml ファイルで、cron ジョブを実行します。

デッドレターキュー

2014 年 5 月 27 日

トラブルシューティングのために、失敗したジョブをデッドレターキューに送信します。

デフォルトの可視性タイムアウトを 30 秒から 300 秒に変更しました。

ワーカー環境内のアプリケーションが 200 OK 応答を返して、リクエストを受信し、正常に処理したことを確認すると、デーモンが DeleteMessage 呼び出しを SQS キューに送信し、そのメッセージがキューから削除されます。アプリケーションが 200 OK 以外の応答を返した場合は、Elastic Beanstalk は、設定済みの ErrorVisibilityTimeout 期間の経過後にメッセージをキューに戻します。応答がない場合は、Elastic Beanstalk は、処理中の別の試行でそのメッセージを使用できるように、InactivityTimeout 期間の経過後にメッセージをキューに戻します。

注記

Amazon SQS キューのプロパティ (メッセージの順序、少なくとも 1 回の配信、およびメッセージのサンプリング) は、ワーカー環境のウェブアプリケーションをどのように設計するかに影響を与える可能性があります。詳細については、Amazon Simple Queue Service Developer GuideProperties of Distributed Queues を参照してください。

SQS では、キューにあるメッセージが、設定した RetentionPeriod を超過すると自動的に削除されます。

デーモンは以下の HTTP ヘッダーを設定します。

[HTTP Headers]

名前 バリュー

User-Agent

aws-sqsd

aws-sqsd/1.11

X-Aws-Sqsd-Msgid

メッセージストーム (異常に多数の新規メッセージなど) を検出するために使用される SQS メッセージ ID

X-Aws-Sqsd-Queue

SQS キューの名前

X-Aws-Sqsd-First-Received-At

メッセージを最初に受信したときの ISO 8601 形式の UTC 時間。

X-Aws-Sqsd-Receive-Count

SQS メッセージの受信件数

X-Aws-Sqsd-Attr-message-attribute-name

処理されるメッセージに割り当てられたカスタムメッセージ属性。message-attribute-name は実際のメッセージ属性名です。文字列と数値のメッセージ属性はすべてヘッダーに追加されますが、バイナリ属性は破棄され、ヘッダーに含まれません。

Content-Type

Mime タイプ設定、デフォルトでは application/json

デッドレターキュー

Elastic Beanstalk ワーカー環境では Amazon Simple Queue Service(SQS)デッドレターキューがサポートされています。 デッドレターキューは、何らかの理由で正常に処理できなかったメッセージを他の(送信元)キューが送信できるキューです。デッドレターキューを使用することの主なメリットは、正常に処理されなかったメッセージを対象から外して隔離することができることです。その後、デッドレターキューに送信されたメッセージを分析し、正常に処理されなかった理由を調べることができます。

ワーカー環境の作成時に、自動生成された Amazon SQS キューを指定した場合、そのワーカー環境ではデッドレターキューがデフォルトで有効になっています。ワーカー環境に対して既存の SQS キューを選択した場合、SQS を使用してデッドレターキューを個別に設定する必要があります。SQS を使用してデッドレターキューを設定する方法については、「Amazon SQS デッドレターキューの使用」を参照してください。

デッドレターキューを無効にすることはできません。配信できないメッセージは、最終的には必ずデッドレターキューに送信されます。ただし、この機能を無効にできます。そのためには、MaxRetries オプションを有効な最大値 100 に設定します。

注記

Elastic Beanstalk の MaxRetries オプションは、SQS の MaxReceiveCount オプションと同じです。ワーカー環境が自動生成された SQS キューを使用しない場合は、SQS で MaxReceiveCount オプションを使用してデッドレターキューを無効にできます。詳細については、「Amazon SQS デッドレターキューの使用」を参照してください。

SQS メッセージのライフサイクルの詳細については、「メッセージのライフサイクル」を参照してください。

定期的なタスク

ソースバンドルで cron.yaml という名前のファイルに定期的なタスクを定義し、定期的な間隔でワーカー環境のキューにジョブを自動的に追加できます。

たとえば、次の cron.yaml ファイルは 2 つの定期的なタスクを作成します。1 つは 12 時間ごとに実行され、もう 1 つは毎日午後 11 時 (UTC) に実行されます。

例 cron.yaml

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

名前は、各タスクに対して一意である必要があります。URL は、ジョブをトリガーするために POST リクエストを送信するパスです。スケジュールは、タスクをいつ実行するかを決定する CRON 式です。

タスクを実行すると、デーモンは実行する必要があるジョブを示すヘッダーとともに環境の SQS キューにメッセージをポストします。環境の任意のインスタンスはメッセージを取得し、ジョブを処理できます。

Elastic Beanstalk はリーダーの選択を使用して、ワーカー環境で定期的なタスクをキューに入れるインスタンスを決定します。各インスタンスは、DynamoDB テーブルに書き込むことでリーダーになろうとします。成功する最初のインスタンスはリーダーであり、リーダーのステータスを維持するには、テーブルに書き込み続ける必要があります。リーダーがサービス停止状態となった場合、すぐに別のインスタンスに置き換えられます。

定期的なタスクでは、ワーカーデーモンは以下の追加のヘッダーを設定します。

[HTTP Headers]

名前 バリュー

X-Aws-Sqsd-Taskname

定期的なタスクでは、実行するタスクの名前。

X-Aws-Sqsd-Scheduled-At

定期的なタスクが予定されている時刻

X-Aws-Sqsd-Sender-Id

メッセージの送信者の AWS アカウント番号

ワーカー環境枠での Auto Scaling のための Amazon CloudWatch の使用

Auto Scaling と CloudWatch は連動して、ワーカー環境で実行されているインスタンスの CPU 使用率をモニタリングします。CPU 処理能力の Auto Scaling 制限の設定により、SQS キューにあるメッセージのスループットを適切に管理するため Auto Scaling グループが実行するインスタンスの数が決定されます。それぞれの EC2 インスタンスから、その CPU の使用状況メトリクスが CloudWatch へ発行されます。Auto Scaling は、CloudWatch から、ワーカー環境内のすべてのインスタンスの平均 CPU 使用率を取得します。CPU 能力に応じて、追加または終了するインスタンスの数、および上限と下限のしきい値を設定します。Auto Scaling によって、指定した CPU 処理能力の上限しきい値に達したことが検出されると、Elastic Beanstalk がワーカー環境に新しいインスタンスを作成します。これらのインスタンスは、CPU 負荷がしきい値未満に戻ると削除されます。

注記

インスタンスの削除時に処理されていなかったメッセージは、キューに戻され、まだ実行中であるインスタンスの別のデーモンで処理されます。

また、必要に応じて AWS マネジメントコンソール、CLI、またはオプションのファイルを使用して、別の CloudWatch アラームを設定することもできます。詳細については、「Amazon CloudWatch で Elastic Beanstalk を使用する」および「Use Auto Scaling Policies and Amazon CloudWatch Alarms for Dynamic Scaling」を参照してください。

ワーカー環境の設定

ワーカー環境の設定は、環境マネジメントコンソールで、環境の [Configuration] ページの [Worker Configuration] を編集することによって管理できます。

 [Elastic Beanstalk Worker Details Configuration] ウィンドウ

ワーカーデーモンを設定するには

  1. Elastic Beanstalk コンソールを開きます。

  2. お客様の環境の管理ページに移動します。

  3. [Configuration] を選択します。

  4. [Worker Configuration] を選択します。

[Worker Details] ページには次のオプションがあります。

  • [Worker queue] – デーモンにより読み込まれる Amazon SQS キューを指定します。既存のキューがあればそれを選択することができます。[Autogenerated queue] を選択すると、Elastic Beanstalk によって新しい Amazon SQS キューおよび対応する [Worker queue URL] が作成されます。

  • [Worker queue URL] – 既存の [Worker queue] を選択すると、その Amazon SQS キューに関連付けられている URL が表示されます。

  • [HTTP path] – Amazon SQS キューからデータを受け取るアプリケーションの相対パスを指定します。このデータは HTTP POST メッセージのメッセージ本文に挿入されます。デフォルト値は / です。

  • [MIME type] – HTTP POST メッセージで使用される MIME タイプを示します。デフォルト値は application/json です。ただし、独自の MIME タイプを作成し、指定できるため、どのような値でも有効になります。

  • [Max retries] - メッセージがデッドレターキューに移動されるまでに Elastic Beanstalk が Amazon SQS キューにメッセージを送信する試行回数の最大数を指定します。デフォルト値は 10 です。1 から 1000 までの値を指定できます。

  • [HTTP connections] – Amazon EC2 インスタンス内でデーモンが任意のアプリケーションに同時接続できる最大数を指定します。デフォルトは 50 です。1 から 100 までの値を指定できます。

  • [Connection timeout] – アプリケーションに正常に接続するまでの待機時間を秒数で示します。デフォルト値は 5 です。1 秒から 60 秒までの値を指定できます。

  • [Inactivity timeout] – アプリケーションへの既存の接続が応答するまでの待機時間を秒数で示します。デフォルト値は 180 です。1 秒から 36000 秒までの値を指定できます。

  • [Visibility timeout] – Amazon SQS キューからの着信メッセージが処理のためにロックされる時間を秒数で示します。設定した時間が経過すると、メッセージが再びキューに表示され、他のデーモンが読み込めるようになります。アプリケーションがメッセージ処理に必要とする予測秒数より長い値 (最大43200秒) を選択します。

  • [Error visibility timeout] – 明示的なエラーで処理が失敗した後、Elastic Beanstalk が Amazon SQS キューにメッセージを返すまでの経過時間を秒数で示します。0 から 43200 までの値を指定できます。

  • [Retention period] – メッセージが有効であり、アクティブに処理される時間を秒数で示します。デフォルト値は 345600 です。60 から 1209600 までの値を指定できます。

既存の Amazon SQS キューを使用する場合、ワーカー環境の作成時に行った設定が、Amazon SQS で直接行った設定と競合することがあります。たとえば、ワーカー環境の RetentionPeriod の値を、Amazon SQS で設定した MessageRetentionPeriod の値より高く設定した場合、MessageRetentionPeriod が経過すると、メッセージは Amazon SQS によって削除されます。

また、ワーカー環境で設定した RetentionPeriod の値が Amazon SQS で設定した MessageRetentionPeriod の値より低い場合、Amazon SQS がメッセージを削除する前にデーモンがメッセージを削除します。VisibilityTimeout については、ワーカー環境で設定したデーモンの値が Amazon SQS の VisibilityTimeout の設定をオーバーライドします。Elastic Beanstalk の設定と Amazon SQS の設定を比較して、メッセージが適切に削除されたことを確認します。