# Amazon SQS イベントソースマッピングの作成と管理
Lambda で Amazon SQS メッセージを処理するには、キューを適切に設定し、Lambda イベントソースマッピングを作成します。
**Topics**
+ [Lambda で使用するキューの設定](#events-sqs-queueconfig)
+ [Lambda 実行ロールのアクセス許可の設定](#events-sqs-permissions)
+ [SQS イベントソースマッピングの作成](#events-sqs-eventsource)
## Lambda で使用するキューの設定
既存の Amazon SQS キューがない場合は、Lambda 関数のイベントソースとして機能する[キューを作成します](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html)。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要がありますが、[異なる AWS アカウント](with-sqs-cross-account-example.md)にすることができます。
関数がレコードの各バッチを処理する時間を確保するには、ソースキューの[可視性タイムアウト](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)を、関数の[設定タイムアウト](configuration-timeout.md)の少なくとも 6 倍に設定します。追加の時間は、関数が前のバッチの処理中にスロットリングされた場合に、Lambda が再試行することを可能にします。
**注記**
関数のタイムアウトは、キューの可視性タイムアウト以下である必要があります。Lambda は、イベントソースマッピングを作成または更新するときにこの要件を検証し、関数のタイムアウトがキューの可視性タイムアウトを超えた場合にエラーを返します。
デフォルトでは、Lambda がバッチを処理しているときにエラーが発生すると、そのバッチ内のすべてのメッセージがキューに戻ります。[可視性タイムアウト](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)の後、メッセージは再び Lambda に表示されるようになります。[部分的なバッチレスポンス](services-sqs-errorhandling.md#services-sqs-batchfailurereporting)を使用するようにイベントソースマッピングを設定することで、失敗したメッセージのみがキューに戻るようにすることができます。さらに、関数が 1 つのメッセージの処理に複数回失敗する場合、Amazon SQS はそのメッセージを[デッドレターキュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)に送信できます。ソースキューの[再処理ポリシー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues)で、`maxReceiveCount` を少なくとも 5 に設定することをお勧めします。これにより、Lambda は、失敗したメッセージをデッドレターキューに直接送信する前に再試行を数回行う機会を確保できます。
## Lambda 実行ロールのアクセス許可の設定
[AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS マネージドポリシーには、Lambda が Amazon SQS キューから読み取るために必要なアクセス許可が含まれています。関数の実行ロールに[このマネージドポリシーを追加](lambda-intro-execution-role.md)できます。
オプションで、暗号化されたキューを使用している場合は、実行ロールに次の権限を追加する必要もあります。
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## SQS イベントソースマッピングの作成
イベントソースマッピングを作成し、キューから Lambda 関数に項目を送信するように Lambda に通知します。1 つの関数で複数のキューの項目を処理するには、複数のイベントソースマッピングを作成します。Lambda がターゲットの関数を呼び出すと、このイベントには設定可能な*バッチサイズ*までの複数の項目が含まれている可能性があります。
Amazon SQS から読み取るように関数を設定するには、[AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS マネージドポリシーを実行ロールにアタッチします。次に、以下の手順を使用して、コンソールから **SQS** イベントソースマッピングを作成します。
**アクセス許可を追加してトリガーを作成するには**
1. Lambda コンソールの[関数ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数の名前を選択します。
1. **[設定]** タブを開き、次に **[アクセス権限]** をクリックします。
1. **[実行ロール]** で、実行ロールのリンクを選択します。このリンクを選択すると、IAM コンソールでロールが開きます。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/execution-role.png)
1. **[アクセス許可を追加]**、**[ポリシーをアタッチ]** の順に選択します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/attach-policies.png)
1. [検索] フィールドに `AWSLambdaSQSQueueExecutionRole` を入力します。実行ロールにポリシーを追加 これは、関数が Amazon SQS キューから読み取るために必要なアクセス許可を含む AWS 管理ポリシーです。このポリシーの詳細については、「*AWS マネージドポリシーリファレンス*」の「[AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)」を参照してください。
1. Lambda コンソールの関数に戻ります。**[関数の概要]** で **[トリガーを追加]** をクリックします。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/add-trigger.png)
1. トリガーのタイプを選択します。
1. 必須のオプションを設定し、[**Add**] (追加) を選択します。
Lambda は、Amazon SQS イベントソースに対して以下の設定オプションをサポートしています。
**SQS キュー**
レコードの読み取り元である Amazon SQS キュー。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要がありますが、[異なる AWS アカウント](with-sqs-cross-account-example.md)にすることができます。
**トリガーの有効化**
イベントソースマッピングのステータス。**[Enable trigger]** (トリガーの有効化) はデフォルトで選択されています。
**バッチサイズ**
各バッチで関数に送信されるレコードの最大数。標準キューの場合、最大 10,000 レコードまで可能です。FIFO キューの場合、最大値は 10 です。バッチサイズが 10 を超える場合は、バッチウィンドウ (`MaximumBatchingWindowInSeconds`) も 1 秒以上に設定する必要があります。
[関数のタイムアウト](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts)は、バッチの項目すべてを処理するために十分な時間を確保できるように設定します。項目の処理に長時間かかる場合には、より少ないバッチサイズを選択します。バッチサイズを大きくするとワークロードの効率を向上させることができ、非常に高速になるか、多くのコストがかかります。関数で[予約された同時実行数](configuration-concurrency.md)を設定すると、同時実行数を 5 以上に設定した場合に、Lambda が関数を呼び出したときにスロットリングエラーが発生する可能性が少なくなります。
Lambda は、イベントの合計サイズが同期呼び出しの[呼び出しペイロードサイズのクォータ](gettingstarted-limits.md) (6 MB) を超えない限り、バッチ内のすべてのレコードを単一の呼び出しで関数に渡します。Lambda と Amazon SQS の両方が、レコードごとにメタデータを生成します。この追加のメタデータは合計ペイロードサイズに計上され、1 つのバッチで送信されるレコードの総数が設定されたバッチサイズよりも少なくなる可能性があります。Amazon SQS が送信するメタデータフィールドは可変長にすることができます。Amazon SQS メタデータフィールドの詳細については、「*Amazon Simple Queue Service API リファレンス*」の「[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)」API 操作のドキュメントを参照してください。
**バッチウィンドウ**
関数を呼び出すまでのレコード収集の最大時間 (秒) です。これが適用されるのは標準キューのみです。
0 秒を超えるバッチウィンドウを使用している場合は、キューの[可視性タイムアウト](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)に処理時間の増加を考慮する必要があります。キューの可視性タイムアウトは、[関数のタイムアウト](configuration-timeout.md)の 6 倍に `MaximumBatchingWindowInSeconds` の値を加えた時間に設定することをお勧めします。これによりスロットリングエラーが発生した場合に Lambda 関数がイベントの各バッチを処理し、再試行する時間が許容されます。
メッセージが使用可能になると、Lambda はメッセージのバッチ処理を開始します。Lambda は、関数を 5 回同時に呼び出すことで、一度に 5 つのバッチの処理を開始します。メッセージがまだ利用可能な場合、Lambda は関数の同時呼び出しを 1 分あたり最大 300 回まで追加し、最大 1,250 回の同時呼び出しまで増やします。プロビジョンドモードを使用する場合、各イベントポーラーは最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または 1 秒あたり最大 10 の Amazon SQS ポーリング API コールを処理できます。Lambda は、設定された最小値と最大値の間でイベントポーラーの数をスケールし、1 分あたり最大 1,000 回の同時呼び出しをすばやく追加することで、Amazon SQS イベントの低レイテンシー処理を実現します。これらの最小および最大イベントポーラー設定を使用して、スケーリングと同時実行を制御します。関数のスケーリングと同時実行の詳細については、「[Lambda 関数のスケーリングについて](lambda-concurrency.md)」を参照してください。
より多くのメッセージを処理するには、Lambda 関数を最適化してスループットを向上させることができます。詳細については、「[AWS Lambda が Amazon SQS 標準キューでどのようにスケールするかを理解する](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)」を参照してください。
**フィルター条件**
フィルター条件を追加して、Lambda が処理のために関数に送信するイベントを制御します。詳細については、「[Lambda が関数に送信するイベントを制御する](invocation-eventfiltering.md)」を参照してください。
**最大同時実行数**
イベントソースが呼び出せる同時関数の最大数。プロビジョンドモードを有効にして使用することはできません。詳細については、「[Amazon SQS イベントソースの最大同時実行数の設定](services-sqs-scaling.md#events-sqs-max-concurrency)」を参照してください。
**プロビジョンドモード**
有効にすると、イベントソースマッピング専用のポーリングリソースを割り当てます。イベントポーラーの最小数 (2～200) と最大数 (2～2,000) を設定できます。各イベントポーラーは、最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または 1 秒あたり最大 10 の Amazon SQS ポーリング API コールを処理できます。
注: プロビジョンドモードと最大同時実行数を一緒に使用することはできません。プロビジョンドモードが有効になっている場合は、最大ポーラー設定を使用して同時実行数を制御します。