翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Elastic Beanstalk ワーカー環境
AWS Elastic Beanstalk アプリケーションが、完了までに時間がかかるオペレーションまたはワークフローを実行する場合は、それらのタスクを専用の*ワーカー環境に*オフロードできます。ブロックオペレーションを実行するプロセスからウェブアプリケーションのフロントエンドを分離することは、アプリケーションに負荷がかかっていても応答性を保つための一般的な方法です。
長い時間実行されるタスクとは、イメージやビデオの処理、E メールの送信、ZIP アーカイブの生成など、リクエストの完了までの時間を実質的に増やすタスクです。これらのオペレーションの完了には 1～2 秒しかかからない場合がありますが、数秒の遅延であっても、それ以外の場合は 500 ms 以下で完了するウェブリクエストにとっては大きなものです。
1 つのオプションでは、ワーカープロセスをローカルにスポーンし、成功を返して、タスクを非同期的に処理します。インスタンスが、それに送信されたすべてのタスクに追い付くことができれば、この方法は有効です。ただし、高い負荷がかかった場合、インスタンスはバックグラウンドタスクを処理しきれなくなり、より優先度の高いリクエストに応答しなくなる可能性があります。個別のユーザーが複数のタスクを生成できる場合、負荷の増加はユーザーの増加に対応できず、ウェブサーバー層を効果的にスケールアウトすることが困難になる可能性があります。
長時間実行されるタスクをローカルで実行しないようにするには、プログラミング言語の AWS SDK を使用して Amazon Simple Queue Service (Amazon SQS) キューに送信し、別のインスタンスセットで実行するプロセスを実行できます。次に、ワーカーインスタンスにキャパシティーがある場合に限り、キューから項目を取り出して実行することで、処理能力を超えないようにします。
Elastic Beanstalk のワーカー環境では、このプロセスを簡素化するために Amazon SQS キューを管理し、キューから読み取る各インスタンスで[デーモンプロセス](#worker-daemon)を自動的に実行します。デーモンは、キューから項目を取得すると、キューメッセージの内容を本文に含めて、HTTP POST リクエストをローカルにポート 80 の `http://localhost/` に送信します。アプリケーションに必要なのは、POST に応じて実行時間が長いタスクを実行することだけです。[デーモンを設定](#using-features-managing-env-tiers-worker-settings)し、別のパスに送信する、application/JSON 以外の MIME タイプを使用する、既存のキューに接続する、または接続 (最大の同時リクエスト数)、タイムアウト、再試行をカスタマイズすることができます。
![\[Elastic Beanstalk ワーカー環境での Amazon SQS メッセージの処理\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/aeb-messageflow-worker.png)
[定期的なタスク](#worker-periodictasks)では、cron スケジュールに基づいてメッセージをキューに入れるようワーカーデーモンを設定することもできます。定期的な各タスクでは、別のパスに POST できます。各タスクのスケジュールおよびパスを定義するソースコードに YAML ファイルを含めて、定期的なタスクを有効にします。
**注記**
[Windows Server プラットフォームの .NET](create_deploy_NET.md) はワーカー環境をサポートしていません。
**Topics**
+ [ワーカー環境 SQS デーモン](#worker-daemon)
+ [デッドレターキュー](#worker-deadletter)
+ [定期的なタスク](#worker-periodictasks)
+ [ワーカー環境枠での自動スケーリングのための Amazon CloudWatch の使用](#worker-scaling)
+ [ワーカー環境の設定](#using-features-managing-env-tiers-worker-settings)
## ワーカー環境 SQS デーモン
ワーカー環境は、Elastic Beanstalk から提供されるプロセスデーモンを実行します。このデーモンは定期的に更新され、機能の追加とバグの修正が行われます。デーモンの最新バージョンを取得するには、最新の[プラットフォームバージョン](concepts.platforms.md)に更新します。
ワーカー環境内のアプリケーションが `200 OK` レスポンスを返し、リクエストを受信して正常に処理したことを確認すると、デーモンが `DeleteMessage` 呼び出しを Amazon SQS キューに送信し、そのメッセージをキューから削除します。アプリケーションが `200 OK` 以外の応答を返した場合、Elastic Beanstalk は、設定済みの `ErrorVisibilityTimeout` 期間の経過後にメッセージをキューに戻します。応答がない場合、Elastic Beanstalk は、処理中の別の試行でそのメッセージを使用できるように、`InactivityTimeout` 期間の経過後にメッセージをキューに戻します。
**注記**
Amazon SQSキューのプロパティ (メッセージの順序、少なくとも 1 回の配信、およびメッセージのサンプリング) は、ワーカー環境のウェブアプリケーションをどのように設計するかに影響する可能性があります。詳細については、[Amazon Simple Queue Service デベロッパーガイド](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/Welcome.html)の「[Properties of Distributed Queues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/DistributedQueues.html) (分散キューのプロパティ)」を参照してください。
Amazon SQS では、キューにあるメッセージが、設定した `RetentionPeriod` を超過すると自動的に削除されます。
デーモンは以下の HTTP ヘッダーを設定します。
****
| **HTTP ヘッダー** |
| --- |
| **名前** | **値** |
| --- |--- |
| `User-Agent` | `aws-sqsd` `aws-sqsd/1.1`1 |
| `X-Aws-Sqsd-Msgid` | メッセージストーム (異常に多数の新規メッセージなど) を検出するために使用される SQS メッセージ ID |
| `X-Aws-Sqsd-Queue` | SQS キューの名前。 |
| `X-Aws-Sqsd-First-Received-At` | メッセージを最初に受信したときの [ISO 8601 形式](http://www.w3.org/TR/NOTE-datetime)の 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 (Amazon SQS) のデッドレターキューがサポートされています。デッドレターキューは、何らかの理由で正常に処理できなかったメッセージを他の（送信元）キューが送信できるキューです。デッドレターキューを使用することの主なメリットは、正常に処理されなかったメッセージを対象から外して隔離することができることです。その後、デッドレターキューに送信されたメッセージを分析し、正常に処理されなかった理由を調べることができます。
ワーカー環境の作成時に、自動生成された Amazon SQS キューを指定した場合、そのワーカー環境ではデッドレターキューがデフォルトで有効になっています。ワーカー環境に対して既存の SQS キューを選択した場合、SQS を使用してデッドレターキューを個別に設定する必要があります。SQS を使用してデッドレターキューを設定する方法については、「[Amazon SQS デッドレターキューの使用](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSDeadLetterQueue.html)」を参照してください。
デッドレターキューを無効にすることはできません。配信できないメッセージは、最終的には必ずデッドレターキューに送信されます。ただし、実質的にはこの機能を無効にできます。そのためには、`MaxRetries` オプションを有効な最大値 100 に設定します。
ワーカー環境の Amazon SQS キューにデッドレターキューが設定されていない場合、Amazon SQS は保持期間が終了するまでメッセージをキューに保持します。保存期間の設定の詳細については、「[ワーカー環境の設定](#using-features-managing-env-tiers-worker-settings)」を参照してください。
**注記**
Elastic Beanstalk の `MaxRetries` オプションは、SQS の `MaxReceiveCount` オプションと同じです。ワーカー環境が自動生成された SQS キューを使用しない場合は、SQS で `MaxReceiveCount` オプションを使用してデッドレターキューを無効にできます。詳細については、「[Amazon SQS デッドレターキューの使用](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSDeadLetterQueue.html)」を参照してください。
SQS メッセージのライフサイクルの詳細については、「[メッセージのライフサイクル](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/MessageLifecycle.html)」を参照してください。
## 定期的なタスク
ソースバンドルで `cron.yaml` という名前のファイルに定期的なタスクを定義し、定期的な間隔でワーカー環境のキューにジョブを自動的に追加できます。
たとえば、次の `cron.yaml` ファイルは 2 つの定期的なタスクを作成します。最初のタスクは 12 時間ごとに実行され、2 番目のタスクは毎日午後 11 時 (UTC) に実行されます。
**Example cron.yaml**
```
version: 1
cron:
- name: "backup-job"
url: "/backup"
schedule: "0 */12 * * *"
- name: "audit"
url: "/audit"
schedule: "0 23 * * *"
```
**name** は、各タスクに対して一意である必要があります。URL は、ジョブをトリガーするために POST リクエストを送信するパスです。スケジュールは、タスクをいつ実行するかを決定する [CRON 式](http://en.wikipedia.org/wiki/Cron#CRON_expression)です。
タスクを実行すると、デーモンは実行する必要があるジョブを示すヘッダーとともに環境の SQS キューにメッセージをポストします。環境の任意のインスタンスはメッセージを取得し、ジョブを処理できます。
**注記**
既存の SQS キューを使用し、[Amazon SQS FIFO キュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html)を選択してワーカー環境を構成している場合、定期的なタスクはサポートされません。
Elastic Beanstalk はリーダーの選択を使用して、ワーカー環境で定期的なタスクをキューに入れるインスタンスを決定します。各インスタンスは、Amazon DynamoDB テーブルに書き込むことで、リーダーになろうとします。成功する最初のインスタンスはリーダーであり、リーダーのステータスを維持するには、テーブルに書き込み続ける必要があります。リーダーがサービス停止状態となった場合、すぐに別のインスタンスに置き換えられます。
定期的なタスクでは、ワーカーデーモンは以下の追加のヘッダーを設定します。
****
| **HTTP ヘッダー** |
| --- |
| **名前** | **値** |
| --- |--- |
| `X-Aws-Sqsd-Taskname` | 定期的なタスクでは、実行するタスクの名前。 |
| `X-Aws-Sqsd-Scheduled-At` | 定期的なタスクが予定されている時刻 |
| `X-Aws-Sqsd-Sender-Id` | AWS メッセージの送信者の アカウント番号 |
## ワーカー環境枠での自動スケーリングのための 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 を使用する」](AWSHowTo.cloudwatch.md)」および「[ステップスケーリングポリシーを使用して Auto Scaling グループを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html#policy-creating-asg-console)」を参照してください。
## ワーカー環境の設定
ワーカー環境の設定は、[環境マネジメントコンソール](environments-console.md)で、環境の **[Configuration]** (設定) ページの **[Worker]** (ワーカー) カテゴリを編集することで管理できます。
![\[Elastic Beanstalk コンソールの [ワーカーの変更] 設定ページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/aeb-config-worker.png)
**注記**
ワーカーキューメッセージを送信する URL パスを設定できますが、IP ポートを設定することはできません。Elastic Beanstalk は、常にワーカーキューメッセージをポート 80 に送信します。ワーカー環境アプリケーションまたはそのプロキシは、ポート 80 をリッスンする必要があります。
**ワーカーデーモンを設定するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**ワーカー**] 設定カテゴリで、[**編集**] を選択します。
[**ワーカー変更]** 設定ページには、次のオプションがあります。
[**キュー**] セクションで、次の操作を行います。
+ [**ワーカーキュー**] – デーモンにより読み込まれる Amazon SQS キューを指定します。既存のキューがあればそれを選択することができます。[**自動生成されたキュー**] を選択すると、Elastic Beanstalk によって新しい Amazon SQS キューおよび対応する [**ワーカーキュー URL**] が作成されます。
**注記**
[**自動生成されたキュー**] を選択した場合、Elastic Beanstalk によって作成されるキューは[標準](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html)の Amazon SQS キューです。既存のキューを選択する場合は、標準キューまたは [FIFO](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) Amazon SQS キューのいずれかを指定できます。FIFO キューを指定する場合、[定期的なタスク](#worker-periodictasks)はサポートされないことに注意してください。
+ [**ワーカーキュー URL**] – 既存の [**ワーカーキュー**] を選択すると、その Amazon SQS キューに関連付けられている URL が表示されます。
[**メッセージ**] セクションで、次の操作を行います。
+ [**HTTP パス**] – Amazon SQS キューからデータを受け取るアプリケーションの相対パスを指定します。このデータは HTTP POST メッセージのメッセージ本文に挿入されます。デフォルト値は `/` です。
+ [**MIME タイプ**] – HTTP POST メッセージで使用される MIME タイプを示します。デフォルト値は `application/json` です。ただし、独自の MIME タイプを作成し、指定できるため、どのような値でも有効になります。
+ [**HTTP 接続**] – Amazon EC2 インスタンス内でデーモンが任意のアプリケーションに同時接続できる最大数を指定します。デフォルトは **50** です。**1** ～ **100** を指定できます。
+ [**可視性タイムアウト**] – Amazon SQS キューからの着信メッセージが処理のためにロックされる時間を秒数で示します。設定した時間が経過すると、メッセージが再びキューに表示され、他のデーモンが読み込めるようになります。アプリケーションがメッセージ処理に必要とする予測秒数より長い値 (最大 **43200** 秒) を選択します。
+ [**エラー可視性タイムアウト**] – 明示的なエラーで処理が失敗した後、Elastic Beanstalk が Amazon SQS キューにメッセージを返すまでの経過時間を秒数で示します。**0** ～ **43200** 秒を指定できます。
[**Advanced options (アドバンスドオプション)**] セクションで、以下の操作を行います。
+ [**最大再試行回数**] - メッセージが[デッドレターキュー](#worker-deadletter)に移動されるまでに Elastic Beanstalk が Amazon SQS キューにメッセージを送信する試行回数の最大数を指定します。デフォルト値は **10** です。**1** ～ **100** を指定できます。
**注記**
**[Max retries]** (最大再試行回数) のオプションは、デッドレターキューで設定された Amazon SQS キューにのみ適用されます。デッドレターキューで設定されていない Amazon SQS キューの場合、Amazon SQS はメッセージをキューに保持し、**[Retention period]** (保持期間) オプションで指定された期間が終了するまでこれを処理します。
+ [**接続タイムアウト**] – アプリケーションに正常に接続するまでの待機時間を秒数で示します。デフォルト値は **5** です。**1** ～ **60** 秒を指定できます。
+ [**アイドル状態のタイムアウト**] – アプリケーションへの既存の接続が応答するまでの待機時間を秒数で示します。デフォルト値は **180** です。**1** ～ **36000** 秒を指定できます。
+ [**保持期間**] – メッセージが有効であり、アクティブに処理される時間を秒数で示します。デフォルト値は **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 の設定を比較して、メッセージが適切に削除されたことを確認してください。