# Amazon SQS での Lambda の使用
**注記**
Lambda 関数以外のターゲットにデータを送信したい、または送信する前にデータをエンリッチしたいという場合は、「[Amazon EventBridge Pipes](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)」を参照してください。
Amazon Simple Queue Service (Amazon SQS) キュー内のメッセージを処理するには、Lambda 関数を使用することができます。Lambda は、[イベントソースマッピング](invocation-eventsourcemapping.md)で、[標準キュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html)と[ファーストイン、ファーストアウト (FIFO) キュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html)の両方をサポートしています。プロビジョンドモードを使用して、Amazon SQS イベントソースマッピング専用のポーリングリソースを割り当てることもできます。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要がありますが、[異なる AWS アカウント](with-sqs-cross-account-example.md)にすることができます。
Amazon SQS メッセージを処理するときは、部分的なバッチレスポンスロジックを実装して、バッチ内の一部のメッセージが失敗した場合に正常に処理されたメッセージが再試行されないようにする必要があります。Powertools for AWS Lambda の[バッチプロセッサユーティリティ](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/)は、部分的なバッチレスポンスロジックを自動的に処理して開発時間を短縮し、信頼性を向上させることで、この実装を簡素化します。
**Topics**
+ [Amazon SQS イベントソースマッピングのポーリングとバッチ処理の動作を理解する](#sqs-polling-behavior)
+ [Amazon SQS イベントソースマッピングでのプロビジョンドモードの使用](#sqs-provisioned-mode)
+ [Amazon SQS イベントソースマッピングのプロビジョンドモードを設定する](#sqs-configuring-provisioned-mode)
+ [標準キューメッセージイベントの例](#example-standard-queue-message-event)
+ [FIFO キューメッセージイベントの例](#sample-fifo-queues-message-event)
+ [Amazon SQS イベントソースマッピングの作成と管理](services-sqs-configure.md)
+ [SQS イベントソースマッピングのスケーリング動作の設定](services-sqs-scaling.md)
+ [Lambda での SQS イベントソースのエラーの処理](services-sqs-errorhandling.md)
+ [Amazon SQS イベントソースマッピング用の Lambda パラメータ](services-sqs-parameters.md)
+ [Amazon SQS イベントソースでのイベントフィルタリングの使用](with-sqs-filtering.md)
+ [チュートリアル: Amazon SQS での Lambda の使用](with-sqs-example.md)
+ [チュートリアル: クロスアカウント Amazon SQS キューをイベントソースとして使用する](with-sqs-cross-account-example.md)
## Amazon SQS イベントソースマッピングのポーリングとバッチ処理の動作を理解する
Amazon SQS イベントソースマッピングでは、Lambda はキューをポーリングし、イベントと共に関数を[同期的に](invocation-sync.md)呼び出します。各イベントには、キューからの複数のメッセージのバッチを含めることができます。Lambda は、これらのイベントをバッチとして (一度に 1 バッチずつ) 受け取り、バッチごとに関数を 1 回呼び出します。関数が正常にバッチを処理すると、Lambda はキューからそのメッセージを削除します。
Lambda がバッチを受け取ると、メッセージはキューに留まりますが、キューの[可視性タイムアウト](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)の期間中は非表示になります。関数がバッチ内のすべてのメッセージを正常に処理すると、Lambda はそのメッセージをキューから削除します。デフォルトでは、バッチの処理中に関数でエラーが発生すると、可視性タイムアウトの期限が切れた後に、そのバッチ内のすべてのメッセージが再びキューに表示されます。このため、関数コードは、意図しない副次的影響を及ぼすことなく同じメッセージを複数回処理できるようにする必要があります。
**警告**
Lambda イベントソースマッピングは各イベントを少なくとも 1 回処理し、レコードの重複処理が発生する可能性があります。重複するイベントに関連する潜在的な問題を避けるため、関数コードを冪等にすることを強くお勧めします。詳細については、AWS ナレッジセンターの「[Lambda 関数を冪等にするにはどうすればよいですか?](https://repost.aws/knowledge-center/lambda-function-idempotent)」を参照してください。
Lambda がメッセージを複数回処理しないようにするには、関数レスポンスに[バッチアイテムの失敗](services-sqs-errorhandling.md#services-sqs-batchfailurereporting)を含めるようにイベントソースマッピングを設定するか、[DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html) API を使用して、Lambda 関数がメッセージを正常に処理した場合にそれらをキューから削除することができます。
Lambda が SQS イベントソースマッピングでサポートする設定パラメータの詳細については、「[SQS イベントソースマッピングの作成](services-sqs-configure.md#events-sqs-eventsource)」を参照してください。
## Amazon SQS イベントソースマッピングでのプロビジョンドモードの使用
イベントソースマッピングのスループットを微調整する必要があるワークロードでは、プロビジョンドモードを使用できます。プロビジョンドモードでは、プロビジョニングされたイベントポーラーの最小数と最大数を定義します。これらのプロビジョニングされたイベントポーラーは、イベントソースマッピング専用であり、応答性の高い自動スケーリングによって予期しないメッセージスパイクを処理できます。プロビジョンドモードで設定された Amazon SQS イベントソースマッピングは、デフォルトの Amazon SQS イベントソースマッピング機能よりも 3 倍高速 (1 分あたり最大 1,000 回の同時呼び出し) に動作し、16 倍高い同時実行 (最大 20,000 回の同時呼び出し) をサポートします。マーケットデータフィードを処理する金融サービス会社、リアルタイムのパーソナライズされたレコメンデーションを提供する e コマースプラットフォーム、ライブプレイヤーインタラクションを管理するゲーム会社など、高精度なパフォーマンス要件を持つ Amazon SQS イベント駆動型ワークロードには、プロビジョンドモードを使用することをお勧めします。プロビジョニングモードを使用すると、追加コストが発生します。料金の詳細については、「[AWS Lambda の料金](https://aws.amazon.com/lambda/pricing/)」を参照してください。
プロビジョンドモードの各イベントポーラーは、最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または 1 秒あたり最大 10 回の Amazon SQS ポーリング API コールを処理できます。イベントポーラーの最小数 (MinimumPollers) の許容値の範囲は 2～200 で、デフォルトは 2 です。イベントポーラーの最大数 (MaximumPollers) の許容値の範囲は 2～2,000 で、デフォルトは 200 です。MaximumPollers は MinimumPollers より大きな数でなければなりません。
### 必要なイベントポーラーの決定
SQS ESM にプロビジョンドモードを使用するときに最適なメッセージ処理パフォーマンスを確保するために必要なイベントポーラーの数を推定するには、アプリケーションの次のメトリクスを収集します。低レイテンシー処理を必要とする 1 秒あたりのピーク SQS イベント、平均 SQS イベントペイロードサイズ、平均 Lambda 関数期間、および設定されたバッチサイズ。
まず、次の式を使用して、ワークロードのイベントポーラーでサポートされている SQS イベント/秒 (EPS) の数を見積もることができます。
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
次に、以下の式を使用して、必要な最小ポーラーの数を計算できます。この計算により、ピークトラフィック要件を処理するのに十分な容量をプロビジョニングできます。
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
デフォルトのバッチサイズが 10、平均イベントサイズが 3 KB、平均関数期間が 100 ミリ秒、1 秒あたり 1,000 イベントを処理する必要があるワークロードを考えてみましょう。このシナリオでは、各イベントポーラーは 1 秒あたり約 100 イベント (EPS) をサポートします。したがって、ピークトラフィック要件を適切に処理するには、最小ポーラーを 10 に設定する必要があります。ワークロードの特性は同じですが、平均関数時間が 1 秒の場合、各ポーラーは 10 回の EPS のみをサポートするため、低レイテンシーで 1 秒あたり 1,000 イベントをサポートするように 100 回の最小ポーラーを設定する必要があります。
プロビジョンドモードイベントポーラーの効率を最大化するには、デフォルトのバッチサイズ 10 かそれ以上を使用することをお勧めします。バッチサイズを大きくすると、各ポーラーは呼び出しごとにより多くのイベントを処理することができ、スループットとコスト効率が向上します。イベントポーラー容量を計画するときは、トラフィックの急増の可能性を考慮し、バッファを持たせるために minimumPollers 値を計算された最小値よりわずかに高く設定することを検討してください。さらに、最適なパフォーマンスとコスト効率を維持するために、メッセージサイズ、関数の期間、またはトラフィックパターンの変更によりイベントポーラー設定の調整が必要になる場合があるため、ワークロードの特性を経時的にモニタリングします。正確なキャパシティプランニングを行うには、特定のワークロードをテストして、各イベントポーラーが駆動できる実際の EPS を決定することをお勧めします。
## Amazon SQS イベントソースマッピングのプロビジョンドモードを設定する
Amazon SQS イベントソースマッピングのプロビジョンドモードを設定するには、コンソールまたは Lambda API を使用できます。
**既存の Amazon SQS イベントソースマッピングに対してプロビジョンドモードを設定する手順 (コンソール)**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. プロビジョンドモードを設定する Amazon SQS イベントソースマッピングを持つ関数を選択します。
1. **[設定]** タブを選択し、**[トリガー]** を選択します。
1. プロビジョンドモードを設定する Amazon SQS イベントソースマッピングを選択し、**[編集]** をクリックします。
1. **[イベントソースマッピング設定]** で、**[プロビジョンドモードの設定]** を選択します。
+ **[最小イベントポーラー数]** に、2～200 の値を入力します。値を指定しない場合、Lambda はデフォルト値 2 を選択します。
+ **[最大イベントポーラー数]** に、2～2,000 の値を入力します。この値は、**[最小イベントポーラー数]** の値以上である必要があります。値を指定しない場合、Lambda はデフォルト値 200 を選択します。
1. **[保存]** を選択します。
プロビジョンドモードは、`EventSourceMappingConfiguration` の `ProvisionedPollerConfig` オブジェクトを使用してプログラムで設定できます。例えば、次の `UpdateEventSourceMapping` CLI コマンドは、`MinimumPollers` 値を 5、`MaximumPollers` 値を 100 に設定します。
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
プロビジョニングモードを設定すると、`ProvisionedPollers` メトリクスをモニタリングすることで、ワークロードのイベントポーラーの使用状況を確認できます。詳細については、「イベントソースマッピングメトリクス」を参照してください。
プロビジョンドモードを無効にしてデフォルト (オンデマンド) モードに戻すには、次の `UpdateEventSourceMapping` CLI コマンドを使用できます。
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**注記**
プロビジョンドモードは、最大同時実行数設定と組み合わせて使用することはできません。プロビジョンドモードを使用する場合、イベントポーラーの最大数を通じて最大同時実行数を制御します。
プロビジョンドモードの設定の詳細については、「[Amazon SQS イベントソースマッピングの作成と管理](services-sqs-configure.md)」を参照してください。
## 標準キューメッセージイベントの例
**Example Amazon SQS メッセージイベント (標準キュー)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
デフォルトでは、Lambda はキュー内の最大 10 個のメッセージを一度にポーリングし、そのバッチを関数に送信します。少数のレコードで関数が呼び出されることを回避するには、バッチウィンドウを設定することで、最大 5 分間レコードをバッファリングするようにイベントソースに指示できます。関数を呼び出す前に、Lambda は、バッチ処理ウィンドウの期限が切れる、[呼び出しペイロードサイズのクォータ](gettingstarted-limits.md)に到達する、または設定された最大バッチサイズに到達するまで、標準キューからのメッセージのポーリングを継続します。
バッチウィンドウを使用していて、SQS キューのトラフィックがきわめて少ない場合、Lambda は関数を呼び出す前に最大 20 秒間待機することがあります。これは、バッチウィンドウを 20 秒未満に設定した場合であっても同様です。
**注記**
Java では、JSON を逆シリアル化するときに null ポインタエラーが発生することがあります。これは、「Records」と「eventSourceARN」のケースが JSON オブジェクトマッパーによってどのように変換されるかに起因している可能性があります。
## FIFO キューメッセージイベントの例
FIFO キューの場合、レコードには、重複除外と順序付けに関連する追加属性が含まれます。
**Example Amazon SQS メッセージイベント (FIFO キュー)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# 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 コールを処理できます。
注: プロビジョンドモードと最大同時実行数を一緒に使用することはできません。プロビジョンドモードが有効になっている場合は、最大ポーラー設定を使用して同時実行数を制御します。
# SQS イベントソースマッピングのスケーリング動作の設定
Amazon SQS イベントソースマッピングのスケーリング動作は、最大同時実行数の設定またはプロビジョンドモードを有効にすることで制御できます。これらは相互に排他的なオプションです。
デフォルトでは、Lambda はメッセージ量に基づいてイベントポーラーを自動的にスケーリングします。プロビジョンドモードを有効にすると、予想されるトラフィックパターンを処理する準備ができている専用ポーリングリソースの最小数と最大数を割り当てます。これにより、イベントソースマッピングのパフォーマンスを 2 つの方法で最適化できます。
+ 標準モード (デフォルト): Lambda は、少数のポーラーから始めてスケーリングを自動的に管理し、ワークロードに基づいてスケールアップまたはスケールダウンします。
+ プロビジョンドモード: 最小制限と最大制限で専用ポーリングリソースを設定し、スケーリングを 3 倍高速化、処理容量を最大 16 倍拡張できます。
標準キューの場合、Lambda は[ロングポーリング](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling)を使用して、キューがアクティブになるまでキューをポーリングします。メッセージが利用可能な場合、Lambda は、関数を 5 回同時に呼び出すことで、一度に 5 つのバッチの処理を開始します。メッセージがまだ利用可能な場合、Lambda はバッチを読み込むプロセスの数を 1 分あたり最大 300 インスタンスまで増やします。イベントソースマッピングによって同時に処理できるバッチの最大数は 1,250 です。トラフィックが少ない場合、Lambda は処理を 5 つの同時実行呼び出しにスケールバックして、わずか 2 つの同時実行呼び出しに最適化できるため、Amazon SQS 呼び出しとそれに対応するコストを削減することができます。ただし、この最適化は、最大同時実行数設定を有効にしている場合には使用できません。
FIFO キューの場合、Lambda は、受信した順序でメッセージを関数に送信します。FIFO キューにメッセージを送信する場合、[メッセージグループ ID](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) を指定します。Amazon SQS は、同じグループ内のメッセージが Lambda に順番に配信されるようにします。Lambda がメッセージをバッチに読み込むとき、各バッチには複数のメッセージグループからのメッセージが含まれることがありますが、メッセージの順序は維持されます。関数がエラーを返す場合、その関数は、Lambda が同じグループから追加のメッセージを受信する前に、対象メッセージですべての再試行を試みます。
プロビジョンドモードを使用する場合、各イベントポーラーは最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または最大 10 の Amazon SQS ポーリング API コールを処理できます。Lambda は、設定された最小値と最大値の間でイベントポーラーの数をスケーリングし、1 分あたり最大 1,000 個の同時実行数をすばやく追加して、Amazon SQS イベントの一貫した低レイテンシー処理を提供します。プロビジョニングモードを使用すると、追加コストが発生します。料金の詳細については、「[AWS Lambda の料金](https://aws.amazon.com/lambda/pricing/)」を参照してください。各イベントポーラーは、1 秒あたり最大 10 [のポーリングで SQS キューへのロング](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html)ポーリングを使用します。これにより、SQS API リクエストのコストが発生します。詳細については、「[Amazon SQS の料金](https://aws.amazon.com/sqs/pricing/ )」を参照してください。これらのオプションは一緒に使用できないため、最大同時実行設定を使用するのではなく、これらの最小および最大イベントポーラー設定を使用してスケーリングと同時実行を制御します。
**注記**
最大同時実行数設定とプロビジョンドモードを同時に使用することはできません。プロビジョンドモードを有効にすると、イベントポーラーの最小数と最大数を通じて Amazon SQS イベントソースマッピングのスケーリングと同時実行を制御します。
## Amazon SQS イベントソースの最大同時実行数の設定
最大同時実行数の設定を使用して、SQS イベントソースのスケーリング動作を制御できます。最大同時実行数は、プロビジョンドモードを有効にして使用することはできません。最大同時実行数設定は、Amazon SQS イベントソースが呼び出せる関数の同時インスタンス数を制限します。最大同時実行数は、イベントソースレベルの設定です。1 つの関数に複数の Amazon SQS イベントソースをマップしている場合は、各イベントソースに個別の最大同時実行数を設定できます。最大同時実行数は、1 つのキューが関数の[予約された同時実行](configuration-concurrency.md)のすべてを使用したり、[アカウントの同時実行クォータ](gettingstarted-limits.md)の残りのすべてを使用したりしないようにするために使用できます。Amazon SQS イベントソースでの最大同時実行数の設定に料金はかかりません。
重要なのは、最大同時実行数と予約された同時実行は、2 つの独立した設定であるということです。最大同時実行数を、関数の予約された同時実行よりも多い数に設定しないでください。最大同時実行数を設定する場合は、関数の予約された同時実行数が、関数にマップされたすべての Amazon SQS イベントソースの合計最大同時実行数以上になるようにしてください。合計数未満になった場合は、Lambda がメッセージをスロットルする可能性があります。
ご使用のアカウントの同時実行クォータがデフォルト値の 1,000 に設定されている場合、最大同時実行数を指定しない限り、Amazon SQS イベントソースマッピングは、関数インスタンスの呼び出し数がこの値に達するまでスケールできます。
アカウントのデフォルトの同時実行クォータを引き上げると、Lambda が同時実行の関数インスタンスを新しいクォータまで呼び出せない場合があります。Lambda はデフォルトで、Amazon SQS イベントソースマッピングに対する同時実行の関数インスタンスの呼び出し数が最大の 1,250 に達するまでスケールできます。デフォルト値がユースケースに不十分な場合は、AWS サポートへ連絡し、ご使用のアカウントにおける Amazon SQS イベントソースマッピングの同時実行数の増加についてご相談ください。
**注記**
FIFO キューの場合、同時呼び出しの上限は、[メッセージグループ ID](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) の数 (`messageGroupId`) または最大同時実行数の設定 (どちらか小さい方) です。例えば、メッセージグループ ID が 6 つあり、最大同時実行数が 10 に設定されている場合、関数は最大 6 回の同時呼び出しを行うことができます。
新規および既存の Amazon SQS イベントソースマッピングに最大同時実行数を設定できます。
**Lambda コンソールを使用して最大同時実行数を設定する**
1. Lambda コンソールの[関数ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数の名前を選択します。
1. **[Function overview]** (関数の概要) で **[SQS]** を選択します。選択すると、**[Configuration]** (設定) タブが開きます。
1. Amazon SQS トリガーを選択し、**[Edit]** (編集) を選択します。
1. **[Maximum concurrency]** (最大同時実行数) には、2 から 1,000 までの数値を入力します。最大同時実行数をオフにするには、ボックスを空のままにします。
1. **[保存]** を選択します。
**AWS Command Line Interface(AWS CLI) を使用して最大同時実行数を設定する**
`--scaling-config` オプション付きの [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) コマンドを使用します。例:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
最大同時実行数をオフにするには、`--scaling-config` に空の値を入力します。
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Lambda API を使用して最大同時実行数を設定する**
[ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html) オブジェクトを指定した [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) アクションまたは [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) アクションを使用します。
# Lambda での SQS イベントソースのエラーの処理
SQS イベントソースに関連するエラーを処理する際に、Lambda はバックオフ戦略を備えた再試行戦略を自動的に使用します。また、[部分的なバッチレスポンス](#services-sqs-batchfailurereporting)を返すように SQS イベントソースマッピングを設定することで、エラー処理の動作をカスタマイズすることもできます。
## 失敗した呼び出しに対するバックオフ戦略
呼び出しが失敗すると、Lambda はバックオフ戦略の実装中に呼び出しの再試行を試みます。バックオフ戦略は、Lambda で発生した障害が関数コード内のエラーによるものか、スロットリングによるものかに応じて若干異なります。
+ **関数コード**が原因でエラーが発生した場合、Lambda は呼び出しの処理と再試行を停止します。その間、Lambda は Amazon SQS イベントソースマッピングに割り当てられた同時実行数を減らすことで、再試行を徐々にバックオフします。キューの可視性タイムアウトがタイムアウトすると、メッセージが再びキューに表示されます。
+ **スロットリング**が原因で呼び出しが失敗する場合、Lambda は Amazon SQS イベントソースマッピングに割り当てられた同時実行数を減らすことで、再試行を徐々にバックオフします。Lambda は、メッセージのタイムスタンプがキューの可視性タイムアウトを超過するまでメッセージを再試行し続けますが、タイムアウトした時点でメッセージをドロップします。
## 部分的なバッチレスポンスの実装
Lambda 関数がバッチを処理しているときにエラーが発生すると、デフォルトでそのバッチ内のすべてのメッセージが再度キューに表示され、これには Lambda が正常に処理したメッセージも含まれます。その結果、関数が同じメッセージを複数回処理することになる場合があります。
失敗したバッチ内の正常に処理されたメッセージを再処理しないようにするために、失敗したメッセージのみを再び表示するようにイベントソースマッピングを設定できます。これを部分的なバッチレスポンスと呼びます。部分的なバッチレスポンスをオンにするには、イベントソースマッピングを設定するときに [FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes) アクション用に `ReportBatchItemFailures` を指定します。そうすると、関数が部分的な成功を返すようになるため、レコードでの不必要な再試行回数を減らすことができます。
**注記**
Powertools for AWS Lambda の[バッチプロセッサユーティリティ](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/)は、すべての部分的なバッチレスポンスロジックを自動的に処理します。このユーティリティは、バッチ処理パターンの実装を簡素化し、バッチ項目の障害を正しく処理するために必要なカスタムコードを削減します。Python、Java、Typescript、および .NET で使用できます。
`ReportBatchItemFailures` がアクティブ化されている場合、Lambda は、関数の呼び出しが失敗したときに[メッセージポーリングをスケールダウン](#services-sqs-backoff-strategy)しません。一部のメッセージが失敗することが想定され、それらの失敗によってメッセージの処理レートに影響が及ばないようにする場合は、`ReportBatchItemFailures` を使用します。
**注記**
部分的なバッチレスポンスを使用する場合は、次の点に注意してください。
関数が例外をスローする場合、バッチ全体が完全な失敗とみなされます。
この機能を FIFO キューで使用している場合、関数は最初の失敗後にメッセージの処理を停止し、`batchItemFailures` で失敗したメッセージと未処理のメッセージのすべてを返します。これは、キュー内のメッセージの順序を維持するのに役立ちます。
**部分的なバッチレポートをアクティブ化するには**
1. [部分的なバッチレスポンスを実装するためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html)を確認します。
1. 次のコマンドを実行して、関数用に `ReportBatchItemFailures` をアクティブ化します。イベントソースマッピングの UUID を取得するには、[list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI コマンドを実行します。
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. 関数コードを更新して、すべての例外をキャッチし、失敗したメッセージを `batchItemFailures` JSON レスポンスで返します。`batchItemFailures` レスポンスには、メッセージ ID のリストが `itemIdentifier` JSON 値として含まれている必要があります。
例えば、メッセージ ID が `id1`、`id2`、`id3`、`id4`、および `id5` である 5 つのメッセージのバッチがあるとします。関数は、`id1`、`id3`、`id5` を正常に処理します。メッセージ `id2` および `id4` がキューで再び表示されるようにするには、関数が次のレスポンスを返す必要があります。
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
バッチで失敗したメッセージ ID のリストを返す関数コードの例を次に示します。
------
#### [ .NET ]
**SDK for .NET**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
.NET を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**SDK for Go V2**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Go を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK for Java 2.x**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Java を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK for JavaScript (v3)**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
JavaScript を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
TypeScript を使用して Lambda で SQS バッチ項目の失敗を報告します。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**SDK for PHP**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
PHP を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK for Python (Boto3)**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Python を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**SDK for Ruby**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Ruby を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK for Rust**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Rust を使用した Lambda での SQS バッチアイテム失敗のレポート。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
失敗したイベントがキューに戻らない場合は、AWS ナレッジセンターの「[Lambda 関数 SQS ReportBatchItemFailures をトラブルシューティングするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/)」を参照してください。
### 成功条件と失敗の条件
関数が以下のいずれかを返す場合、Lambda はバッチを完全な成功として扱います。
+ 空の `batchItemFailures` リスト
+ null の `batchItemFailures` リスト
+ 空の `EventResponse`
+ null の `EventResponse`
関数が以下のいずれかを返す場合、Lambda はバッチを完全な失敗として扱います。
+ 無効な JSON レスポンス
+ 空の文字列 `itemIdentifier`
+ ヌル `itemIdentifier`
+ 不正なキー名を持つ `itemIdentifier`
+ 存在しないメッセージ ID を持つ `itemIdentifier` 値
### CloudWatch メトリクス
関数がバッチ項目の失敗を正しく報告しているかどうかを判断するために、Amazon SQS メトリクスの `NumberOfMessagesDeleted` および `ApproximateAgeOfOldestMessage` を Amazon CloudWatch でモニタリングできます。
+ `NumberOfMessagesDeleted` は、キューから削除されたメッセージの数を追跡します。これが 0 になるということは、関数レスポンスが失敗したメッセージを正しく返していないことを示唆しています。
+ `ApproximateAgeOfOldestMessage` は、最も古いメッセージがキューに残っている期間を追跡します。このメトリクスの急激な増加は、関数が失敗したメッセージを正しく返していないことを示唆している可能性があります。
### Powertools for AWS Lambda バッチプロセッサを使用する
Powertools for AWS Lambda のバッチプロセッサユーティリティは、部分的なバッチレスポンスロジックを自動的に処理するため、バッチ障害レポートの実装の複雑さが軽減されます。バッチプロセッサを使用した例を次に示します。
**Python**
詳細な例とセットアップ手順については、[バッチプロセッサのドキュメント](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/)を参照してください。
AWS Lambda バッチプロセッサを使用した Amazon SQS メッセージの処理。
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
詳細な例とセットアップ手順については、[バッチプロセッサのドキュメント](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/)を参照してください。
AWS Lambda バッチプロセッサを使用した Amazon SQS メッセージの処理。
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Amazon SQS イベントソースマッピング用の Lambda パラメータ
すべての Lambda イベントソースタイプは、同じ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) および [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) API オペレーションを共有しています。ただし、Amazon SQS に適用されるのは一部のパラメータのみです。
| [Parameter] (パラメータ) | 必須 | デフォルト | メモ |
| --- | --- | --- | --- |
| BatchSize | N | 10 | 標準キューの場合、最大値は 10,000 です。FIFO キューの場合、最大値は 10 です。 |
| 有効 | N | true | なし |
| EventSourceArn | Y | 該当なし | データストリームまたはストリーミングコンシューマーの ARN。 |
| FunctionName | Y | 該当なし | なし |
| FilterCriteria | N | 該当なし | [Lambda が関数に送信するイベントを制御する](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | 該当なし | 関数がバッチ内の特定の失敗を報告できるようにするには、`FunctionResponseTypes` に値 `ReportBatchItemFailures` を含めます。詳細については、[部分的なバッチレスポンスの実装](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) を参照してください。 |
| MaximumBatchingWindowInSeconds | N | 0 | バッチ処理ウィンドウは FIFO キューではサポートされていません |
| ProvisionedPollerConfig | N | 該当なし | SQS イベントソースマッピングの専用イベントポーラーの最小数 (2～200) と最大数 (2～2,000) を設定します。各ポーラーは、最大 1 MB/秒のスループットと 10 回の同時呼び出しを処理できます。 |
| ScalingConfig | N | 該当なし | [Amazon SQS イベントソースの最大同時実行数の設定](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Amazon SQS イベントソースでのイベントフィルタリングの使用
イベントフィルタリングを使用して、Lambda が関数に送信するストリームまたはキューからのレコードを制御することができます。イベントフィルタリングの仕組みに関する一般情報については、「[Lambda が関数に送信するイベントを制御する](invocation-eventfiltering.md)」を参照してください。
このセクションでは、Amazon SQS イベントソースのイベントフィルタリングに焦点を当てます。
**注記**
Amazon SQS イベントソースマッピングは、 `body` キーでのフィルタリングのみをサポートします。
**Topics**
+ [Amazon SQS イベントフィルタリングの基本](#filtering-SQS)
## Amazon SQS イベントフィルタリングの基本
Amazon SQS キューに次の JSON 形式のメッセージが含まれているとします。
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
このキューのレコード例は次のようになります。
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Amazon SQS メッセージの内容に基づいてフィルタリングするには、Amazon SQS メッセージレコードの `body` キーを使用します。Amazon SQS メッセージの `RequestCode` が「BBBB」のレコードのみを処理するとします。`FilterCriteria` オブジェクトは次のようになります。
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
以下は、わかりやすくするためにプレーン JSON で展開したフィルターの `Pattern` の値を記載しています。
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
コンソール、AWS CLI、または AWS SAM テンプレートを使用してフィルターを追加できます。
------
#### [ Console ]
コンソールを使用してこのフィルターを追加するには、[イベントソースマッピングへのフィルター条件のアタッチ (コンソール)](invocation-eventfiltering.md#filtering-console) の指示に従って **[フィルター条件]** に次の文字列を入力します。
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
AWS Command Line Interface (AWS CLI) を使用してこれらのフィルター条件を持つ新しいイベントソースマッピングを作成するには、以下のコマンドを実行します。
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
これらのフィルター条件を既存のイベントソースマッピングに追加するには、次のコマンドを実行します。
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
AWS SAM を使用してこのフィルターを追加するには、イベントソースの YAML テンプレートに次のスニペットを追加します。
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
関数が、`RecordNumber` が 9999 を超えるレコードのみを処理するとします。`FilterCriteria` オブジェクトは次のようになります。
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
以下は、わかりやすくするためにプレーン JSON で展開したフィルターの `Pattern` の値を記載しています。
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
コンソール、AWS CLI、または AWS SAM テンプレートを使用してフィルターを追加できます。
------
#### [ Console ]
コンソールを使用してこのフィルターを追加するには、[イベントソースマッピングへのフィルター条件のアタッチ (コンソール)](invocation-eventfiltering.md#filtering-console) の指示に従って **[フィルター条件]** に次の文字列を入力します。
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
AWS Command Line Interface (AWS CLI) を使用してこれらのフィルター条件を持つ新しいイベントソースマッピングを作成するには、以下のコマンドを実行します。
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
これらのフィルター条件を既存のイベントソースマッピングに追加するには、次のコマンドを実行します。
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
AWS SAM を使用してこのフィルターを追加するには、イベントソースの YAML テンプレートに次のスニペットを追加します。
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Amazon SQS では、メッセージ本文は任意の文字列にすることができます。`body` が有効な JSON フォーマットであることが `FilterCriteria` で想定されている場合は、これが問題になる可能性があります。逆の場合も同様です。着信メッセージの本文が JSON 形式であっても、フィルター条件が `body` をプレーン文字列であると想定する場合、意図しない動作が発生する可能性があります。
この問題を回避するには、`FilterCriteria` の本文の形式がキューで受信するメッセージで想定する `body` の形式と一致することを確認してください。メッセージをフィルタリングする前に、Lambda は着信メッセージの本文の形式および `body` のフィルターパターンの形式を自動的に評価します。一致しない場合、Lambda はメッセージを除外します。この評価のまとめは、以下の表のとおりです。
| 着信メッセージの `body` の形式 | フィルターパターンの `body` の形式 | 結果として生じるアクション |
| --- | --- | --- |
| プレーン文字列 | プレーン文字列 | Lambda がフィルター条件に基づいてフィルタリングを実行します。 |
| プレーン文字列 | データプロパティのフィルターパターンがない | Lambda がフィルター条件に基づいて (他のメタデータプロパティのみを) フィルタリングします。 |
| プレーン文字列 | 有効な JSON | Lambda はメッセージを除外します。 |
| 有効な JSON | プレーン文字列 | Lambda はメッセージを除外します。 |
| 有効な JSON | データプロパティのフィルターパターンがない | Lambda がフィルター条件に基づいて (他のメタデータプロパティのみを) フィルタリングします。 |
| 有効な JSON | 有効な JSON | Lambda がフィルター条件に基づいてフィルタリングを実行します。 |
# チュートリアル: Amazon SQS での Lambda の使用
このチュートリアルでは、[Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) キューからのメッセージを消費する Lambda 関数を作成します。Lambda 関数は、新しいメッセージがキューに追加されるたびに実行されます。この関数は、メッセージを Amazon CloudWatch Logs ストリームに書き込みます。次の図は、チュートリアルを完了するために使用する AWS リソースを示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_resources.png)
このチュートリアルを完了するには、次のステップを実行します。
1. CloudWatch Logs にメッセージを書き込む Lambda 関数を作成します。
1. Amazon SQS キューを作成します。
1. Lambda イベントソースマッピングを作成します。イベントソースマッピングは Amazon SQS キューを読み取り、新しいメッセージが追加されたときに Lambda 関数を呼び出します。
1. キューにメッセージを追加して設定をテストし、CloudWatch Logs で結果をモニタリングします。
## 前提条件
### AWS Command Line Interface のインストール
AWS Command Line Interface をまだインストールしていない場合は、「[最新バージョンの AWS CLI のインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」にある手順に従ってインストールしてください。
このチュートリアルでは、コマンドを実行するためのコマンドラインターミナルまたはシェルが必要です。Linux および macOS では、任意のシェルとパッケージマネージャーを使用してください。
**注記**
Windows では、Lambda でよく使用される一部の Bash CLI コマンド (`zip` など) が、オペレーティングシステムの組み込みターミナルでサポートされていません。Ubuntu および Bash の Windows 統合バージョンを取得するには、[Windows Subsystem for Linux をインストール](https://docs.microsoft.com/en-us/windows/wsl/install-win10)します。
## 実行ロールを作成する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps1.png)
[実行ロール](lambda-intro-execution-role.md)とは、AWS のサービス およびリソースに対するアクセス許可を Lambda 関数に付与する AWS Identity and Access Management (IAM) のロールです。関数が Amazon SQS から項目を読み取れるようにするには、**AWSLambdaSQSQueueExecutionRole** 許可ポリシーをアタッチします。
**実行ロールを作成して Amazon SQS 許可ポリシーをアタッチする方法**
1. IAM コンソールの[ロールページ](https://console.aws.amazon.com/iam/home#/roles)を開きます。
1. [**ロールの作成**] を選択してください。
1. **[信頼できるエンティティタイプ]** で、**[AWS サービス]** を選択します。
1. **[ユースケース]** で、**[Lambda]** を選択します。
1. [**次へ**] を選択します。
1. **[許可ポリシー]** 検索ボックスに **AWSLambdaSQSQueueExecutionRole** と入力します。
1. **AWSLambdaSQSQueueExecutionRole** ポリシーを選択し、**[Next]** を選択します。
1. **[Role details]** で **[Role name]** に **lambda-sqs-role** を入力してから、**[Create role]** を選択します。
ロールを作成したら、実行ロールの Amazon リソースネーム (ARN) を書き留めてください。これは、後のステップで必要になります。
## 関数を作成する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps2.png)
Amazon SQS メッセージを処理する Lambda 関数を作成します。この関数コードは、Amazon SQS メッセージの本文を CloudWatch Logs に記録します。
このチュートリアルでは Node.js 24 ランタイムを使用しますが、他のランタイム言語のサンプルコードも提供しています。次のボックスでタブを選択すると、関心のあるランタイムのコードが表示されます。このステップで使用する JavaScript コードは、**[JavaScript]** タブに表示されている最初のサンプルにあります。
------
#### [ .NET ]
**SDK for .NET**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
.NET を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**SDK for Go V2**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Go を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK for Java 2.x**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Java を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK for JavaScript (v3)**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
JavaScript を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
TypeScript を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**SDK for PHP**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
PHP を使用した Lambda での SQS イベントの消費。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK for Python (Boto3)**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Python を使用した Lambda での SQS イベントの消費。
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**SDK for Ruby**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Ruby を使用した Lambda での SQS イベントの消費。
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK for Rust**
GitHub には、その他のリソースもあります。[サーバーレスサンプル](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda)リポジトリで完全な例を見つけて、設定と実行の方法を確認してください。
Rust を使用して Lambda で SQS イベントを消費します。
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Node.js Lambda 関数を作成する方法**
1. プロジェクト用のディレクトリを作成し、そのディレクトリに切り替えます。
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. サンプル JavaScript コードを `index.js` という名前の新しいファイルにコピーします。
1. 以下の `zip` コマンドを使用して、デプロイパッケージを作成します。
```
zip function.zip index.js
```
1. [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) AWS CLI コマンドを使用して、Lambda 関数を作成します。`role`パラメータには、前に作成した実行ロールの ARN を入力します。
**注記**
Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要があります。
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## 関数をテストする
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps3.png)
`invoke` AWS CLI コマンドおよびサンプルの Amazon SQS イベントを使用して、手動で Lambda 関数を呼び出します。
**サンプルイベントで Lambda 関数を呼び出す方法**
1. 次の JSON をファイル名 `input.json` で保存します。この JSON は、Amazon SQS が Lambda 関数に送信する可能性のあるイベントをシミュレートするもので、`"body"` にはキューからの実際のメッセージが含まれます。この例では、メッセージは `"test"` です。
**Example Amazon SQS イベント**
これはテストイベントです。メッセージやアカウント番号を変更する必要はありません。
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. 次の [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) AWS CLI コマンドを実行します。このコマンドは、レスポンスで CloudWatch ログを返します。ログの取得の詳細については、「[AWS CLI を使用したログへのアクセス](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli)」を参照してください。
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、バージョン 2 の AWS Command Line Interface ユーザーガイドの「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
1. レスポンス内にある `INFO` ログを探します。このログは Lambda 関数がメッセージ本文を記録する場所です。次のようなログが表示されます。
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Amazon SQS キュー を作成する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps4.png)
Lambda 関数がイベントソースとして使用できる Amazon SQS キューを作成します。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要があります。
**キューを作成するには**
1. [Amazon SQS コンソール](https://console.aws.amazon.com/sqs) を開きます。
1. **[キューの作成]** を選択します。
1. キューの名前を入力します。その他のオプションはすべて、デフォルト設定のままにしておきます。
1. [**キューの作成**] を選択します。
キューを作成したら、その ARN を書き留めます。こちらは、次のセクションでキューを Lambda 関数と関連付ける際に必要になります。
## イベントソースを設定する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps5.png)
[イベントソースマッピング](invocation-eventsourcemapping.md)を作成して、Amazon SQS キューを Lambda 関数に接続します。イベントソースマッピングは Amazon SQS キューを読み取り、新しいメッセージが追加されたときに Lambda 関数を呼び出します。
Amazon SQS キューと Lambda 関数の間でマッピングを作成するには、[create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI コマンドを使用します。例:
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
イベントソースマッピングのリストを取得するには、[list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html) コマンドを使用します。例:
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## テストメッセージを送信する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps6.png)
**Amazon SQS メッセージを Lambda 関数に送信する方法**
1. [Amazon SQS コンソール](https://console.aws.amazon.com/sqs)を開きます。
1. 先ほど作成したキューを選択します。
1. **[メッセージの送信と受信]** を選択します。
1. **メッセージ本文**に、「これはテストメッセージです」などとテストメッセージを入力します。
1. **[メッセージの送信]** を選択します。
Lambdaがキューにアップデートをポーリングします。新しいメッセージがあると、Lambda はキューからのこの新しいイベントデータを使用して関数を呼び出します。 関数ハンドラーが例外をスローせずに正常に戻った場合、Lambda はメッセージが正しく処理されたと見なし、キュー内の新しいメッセージの読み取りを開始します。メッセージが正常に処理された後、Lambda はメッセージをキューから自動的に削除します。ハンドラーが例外をスローした場合、Lambda はメッセージの バッチが正常に処理されなかったと見なし、Lambdaは同じメッセージのバッチで関数を呼び出します。
## CloudWatch のログを確認する
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/sqs_tut_steps7.png)
**関数がメッセージを処理したことを確認する方法**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. **ProcessSQSRecord** 関数を選択します。
1. [**モニター**] を選択します。
1. **[CloudWatch Logs を表示]** を選択します。
1. CloudWatch コンソールで、関数の**ログストリーム**を選択します。
1. `INFO` ログを探します。このログは Lambda 関数がメッセージ本文を記録する場所です。Amazon SQS キューから送信したメッセージが表示されるはずです。例:
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## リソースのクリーンアップ
このチュートリアル用に作成したリソースは、保持しない場合は削除できます。使用しなくなった AWS リソースを削除することで、AWS アカウント アカウントに請求される料金の発生を防ぎます。
**実行ロールを削除する**
1. IAM コンソールの [[ロール]](https://console.aws.amazon.com/iam/home#/roles) ページを開きます。
1. 作成した実行ロールを選択します。
1. **[削除]** を選択します。
1. テキスト入力フィールドにロールの名前を入力し、**[削除]** を選択します。
**Lambda 関数を削除するには**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 作成した関数を選択します。
1. **[アクション]** で、**[削除]** を選択します。
1. テキスト入力フィールドに **confirm** と入力し、**[Delete]** (削除) を選択します。
**Amazon SQS キューを削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon SQS コンソール ([https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)) を開きます。
1. 作成したキューを選択します。
1. **[削除]** を選択します。
1. テキスト入力フィールドに **confirm** を入力します。
1. **[Delete]** (削除) をクリックします。
# チュートリアル: クロスアカウント Amazon SQS キューをイベントソースとして使用する
このチュートリアルでは、別のAWSアカウントで、 Amazon Simple Queue Service (Amazon SQS) キューからのメッセージを使用する Lambda 関数を作成します。 このチュートリアルには 2 つのAWSアカウントが含まれています: **アカウント A** Lambda 関数を含むアカウントを参照します。**アカウント B** Amazon SQS キューを含むアカウントを参照します。
## 前提条件
### AWS Command Line Interface のインストール
AWS Command Line Interface をまだインストールしていない場合は、「[最新バージョンの AWS CLI のインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」にある手順に従ってインストールしてください。
このチュートリアルでは、コマンドを実行するためのコマンドラインターミナルまたはシェルが必要です。Linux および macOS では、任意のシェルとパッケージマネージャーを使用してください。
**注記**
Windows では、Lambda でよく使用される一部の Bash CLI コマンド (`zip` など) が、オペレーティングシステムの組み込みターミナルでサポートされていません。Ubuntu および Bash の Windows 統合バージョンを取得するには、[Windows Subsystem for Linux をインストール](https://docs.microsoft.com/en-us/windows/wsl/install-win10)します。
## 実行ロールを作成する (アカウント A)
**アカウント A** で、必要なAWSリソースにアクセスするためのアクセス許可を関数に付与する[実行ロール](lambda-intro-execution-role.md)を作成します。
**実行ロールを作成するには**
1. AWS Identity and Access Management (IAM) コンソールの [[Roles page (ロールページ)](https://console.aws.amazon.com/iam/home#/roles)] を開きます。
1. **[ロールの作成]** を選択します。
1. 次のプロパティでロールを作成します。
+ **信頼されたエンティティ** - **AWS Lambda**
+ **アクセス許可** - **AWSLambdaSQSQueueExecutionRole**
+ **[ロール名]** – **cross-account-lambda-sqs-role**
**AWSLambdaSQSQueueExecutionRole** ポリシーには、Amazon SQS から項目を読み取り、Amazon CloudWatch Logs にログを書き込むために関数が必要とするアクセス許可があります。
## 関数を作成する (アカウント A)
**[アカウント A]** で、Amazon SQS メッセージを処理する Lambda 関数を作成します。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要があります。
次の Node.js コード例は、各メッセージを CloudWatch Logs のログに書き込みます。
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**関数を作成するには**
**注記**
以下の手順を実行すると、Node.js 関数が作成されます。他の言語では、手順は似ていますが、いくつかの詳細が異なります。
1. サンプルコードをファイル名 `index.mjs` で保存します。
1. デプロイパッケージを作成します。
```
zip function.zip index.mjs
```
1. `create-function` AWS Command Line Interface (AWS CLI) コマンドを使用して関数を作成します。`arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` を、先ほど作成した実行ロールの ARN に置き換えます。
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## 関数をテストする (アカウント A)
**アカウント A** で、`invoke` AWS CLIコマンドおよびサンプルの Amazon SQS イベントを使用して、手動で Lambda 関数をテストします。
ハンドラーが例外をスローせずに正常に戻る場合、Lambda はメッセージが正しく処理されたと見なし、キュー内の新しいメッセージの読み取りを開始します。メッセージが正常に処理された後、Lambda はメッセージをキューから自動的に削除します。ハンドラーが例外をスローした場合、Lambda はメッセージの バッチが正常に処理されなかったと見なし、Lambdaは同じメッセージのバッチで関数を呼び出します。
1. 次の JSON をファイル名 `input.txt` で保存します。
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
`"body"`にキューからの実際のメッセージが含まれている場合、先行する JSON は、Amazon SQS が Lambda 関数に送信する可能性のあるイベントをシミュレートします。
1. 次の `invoke` AWS CLI コマンドを実行します。
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、「*AWS Command Line Interface バージョン 2 用ユーザーガイド*」の「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
1. `outputfile.txt` ファイルで出力を確認します。
## Amazon SQS キュー を作成する (アカウント B)
**アカウント B** で、**アカウント A** の Lambda 関数がイベントソースとして使用できる Amazon SQS キューを作成します。Lambda 関数と Amazon SQS キューは同じ AWS リージョンに存在する必要があります。
**キューを作成するには**
1. [Amazon SQS コンソール](https://console.aws.amazon.com/sqs) を開きます。
1. **[キューの作成]** を選択します。
1. 次のプロパティでキューを作成します。
+ **タイプ** – **スタンダード**
+ **名前** – **LambdaCrossAccountQueue**
+ **設定** – デフォルト設定のままにします。
+ **アクセスポリシー** – [**Advanced (アドバンスト)**] を選択します。次の JSON ポリシーに貼り付けます。以下の値を置き換えます:
+ `111122223333`: **アカウント A** の AWS アカウント ID
+ `444455556666`: **アカウント B** の AWS アカウント ID
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
このポリシーは、**アカウント A** で Lambda 実行ロールに、この Amazon SQS キューからのメッセージを使用するアクセス許可を付与します。
1. キューの作成後、Amazon リソースネーム (ARN)を記録します。こちらは、次のセクションでキューを Lambda 関数と関連付ける際に必要になります。
## イベントソースを設定する (アカウント A)
**[アカウント A]** で、**[アカウント B]** の Amazon SQS キューと Lambda 関数の間に、次の `create-event-source-mapping` AWS CLIコマンドを実行してイベントソースマッピングを作成します。`arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` を、前のステップで作成した Amazon SQS キューの ARN に置き換えます。
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
次のコマンドを実行して、イベントソースのマッピングのリストを取得できます。
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## セットアップをテストする
これにより、次のようにセットアップをテストできます。
1. **アカウント B** で [Amazon SQS コンソール](https://console.aws.amazon.com/sqs)を開きます。
1. 前に作成した [**LambdaCrossAccountQueue**] を選択します。
1. **[メッセージの送信と受信]** を選択します。
1. **[メッセージ本文]** にテストメッセージを入力します。
1. **[メッセージの送信]** を選択します。
**[アカウント A]** の Lambda 関数がメッセージを受信します。Lambda はキューに更新をポーリングし続けます。新しいメッセージがあると、Lambda はキューからのこの新しいイベントデータを使用して関数を呼び出します。 関数が実行され、Amazon CloudWatch にログが作成されます。[CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)でログを表示できます。
## リソースのクリーンアップ
このチュートリアル用に作成したリソースは、保持しない場合は削除できます。使用しなくなった AWS リソースを削除することで、AWS アカウント アカウントに請求される料金の発生を防ぎます。
**[アカウント A]** で、実行ロールと Lambda 関数をクリーンアップします。
**実行ロールを削除する**
1. IAM コンソールの [[ロール]](https://console.aws.amazon.com/iam/home#/roles) ページを開きます。
1. 作成した実行ロールを選択します。
1. **[削除]** を選択します。
1. テキスト入力フィールドにロールの名前を入力し、**[削除]** を選択します。
**Lambda 関数を削除するには**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 作成した関数を選択します。
1. **[アクション]** で、**[削除]** を選択します。
1. テキスト入力フィールドに **confirm** と入力し、**[削除]** を選択します。
**[アカウント B]** で、Amazon SQS キューをクリーンアップします。
**Amazon SQS キューを削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon SQS コンソール ([https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)) を開きます。
1. 作成したキューを選択します。
1. **[削除]** を選択します。
1. テキスト入力フィールドに **confirm** を入力します。
1. **[Delete]** (削除) をクリックします。