Elastic Beanstalk ワーカー環境

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

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

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

長時間実行されるタスクをローカルで実行しないようにするには、プログラミング言語の AWS SDK を使用して Amazon Simple Queue Service (Amazon SQS) キューに送信し、別のインスタンスセットで実行するプロセスを実行できます。次に、ワーカーインスタンスにキャパシティーがある場合に限り、キューから項目を取り出して実行することで、処理能力を超えないようにします。

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

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

ワーカー環境 SQS デーモン

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

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

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

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

デッドレターキュー

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

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

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

ワーカー環境の Amazon SQS キューにデッドレターキューが設定されていない場合、Amazon SQS は保持期間が終了するまでメッセージをキューに保持します。保存期間の設定の詳細については、「ワーカー環境の設定」を参照してください。

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

定期的なタスク

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

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

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

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

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

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

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

ワーカー環境枠での自動スケーリングのための Amazon CloudWatch の使用

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

また、必要に応じて Elastic Beanstalk コンソール、CLI、またはオプションのファイルを使用して、別の CloudWatch アラームを設定することもできます。詳細については、「「Amazon CloudWatch で Elastic Beanstalk を使用する」」および「ステップスケーリングポリシーを使用して Auto Scaling グループを作成する」を参照してください。

ワーカー環境の設定

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

[ワーカー変更] 設定ページには、次のオプションがあります。

[キュー] セクションで、次の操作を行います。

[メッセージ] セクションで、次の操作を行います。

[Advanced options (アドバンスドオプション)] セクションで、以下の操作を行います。

既存の 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 の設定を比較して、メッセージが適切に削除されたことを確認してください。