Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法
イベントソースマッピングは、ストリームおよびキューベースのサービスからアイテムを読み取り、レコードのバッチを使用して関数を呼び出す Lambda リソースです。以下のサービスは、イベントソースマッピングを使用して Lambda 関数を呼び出します。
警告
Lambda イベントソースマッピングは各イベントを少なくとも 1 回処理し、レコードの重複処理が発生する可能性があります。重複するイベントに関連する潜在的な問題を避けるため、関数コードを冪等にすることを強くお勧めします。詳細については、 AWS ナレッジセンターの「Lambda 関数を冪等にするにはどうすればよいですか?
イベントソースマッピングと直接トリガーの違い
一部の AWS サービスは、トリガーを使用して Lambda 関数を直接呼び出すことができます。これらのサービスはイベントを Lambda にプッシュし、指定されたイベントが発生すると即時に関数が呼び出されます。トリガーは、個別のイベントやリアルタイム処理に適しています。Lambda コンソールを使用してトリガーを作成すると、コンソールは対応する AWS サービスと連携して、そのサービスでイベント通知を設定します。実際には、トリガーは Lambda ではなく、イベントを生成するサービスによって保存および管理されます。トリガーを使用して Lambda 関数を呼び出すサービスの例をいくつか示します。
-
Amazon Simple Storage Service (Amazon S3): オブジェクトがバケット内で作成、削除、または変更されたときに関数を呼び出します。詳細については、「チュートリアル: Amazon S3 トリガーを使用して Lambda 関数を呼び出す」を参照してください。
-
Amazon Simple Notification Service (Amazon SNS): メッセージが SNS トピックに発行されたときに関数を呼び出します。詳細については、「チュートリアル: Amazon Simple Notification Service での AWS Lambda の使用」を参照してください。
-
Amazon API Gateway: API リクエストが特定のエンドポイントに対して行われたときに関数を呼び出します。詳細については、「Amazon API Gateway エンドポイントを使用した Lambda 関数の呼び出し」を参照してください。
イベントソースマッピングは、Lambda サービス内で作成および管理される Lambda リソースです。イベントソースマッピングは、大量のストリーミングデータやキューからのメッセージを処理できるように設計されています。ストリームまたはキューからのレコードをバッチで処理すると、レコードを個別に処理するよりも効率的です。
バッチ処理動作
デフォルトで、イベントソースマッピングは、Lambda が関数に送信する単一のペイロードにレコードをまとめてバッチ処理します。バッチ処理の動作を微調整するには、バッチ処理ウィンドウ (MaximumBatchingWindowInSeconds) とバッチサイズ (BatchSize) を設定します。バッチ処理ウィンドウとは、レコードを単一のペイロードにまとめるための最大時間です。バッチサイズとは、単一のバッチ内にあるレコードの最大数です。Lambda は、以下の 3 つの条件のいずれかが満たされたときに関数を呼び出します。
-
バッチ処理ウィンドウが最大値に到達した。デフォルトのバッチ処理ウィンドウの動作は、特定のイベントソースによって異なります。
Kinesis、DynamoDB、および Amazon SQS イベントソースの場合: デフォルトのバッチ処理ウィンドウは 0 秒です。これは、バッチサイズが満たされた場合、またはペイロードサイズ制限に達した場合にのみ、Lambda が関数にバッチを送信することを意味します バッチ処理ウィンドウを設定するには、
MaximumBatchingWindowInSeconds
を設定します。このパラメータは、秒単位で 0 秒から 300 秒までの任意の値に設定できます。バッチ処理ウィンドウを設定する場合、前の関数の呼び出しが完了するとすぐに次のウィンドウが開始されます。Amazon MSK、セルフマネージド Apache Kafka、Amazon MQ、および Amazon DocumentDB イベントソースの場合: バッチ処理ウィンドウはデフォルトで 500 ミリ秒に設定されます。
MaximumBatchingWindowInSeconds
は、秒単位で 0 秒から 300 秒までの任意の値に設定できます。バッチ処理ウィンドウは、最初のレコードが到着するとすぐに開始されます。注記
MaximumBatchingWindowInSeconds
は秒単位の増分でしか変更できないため、いったん変更すると、デフォルトのバッチ処理ウィンドウである 500 ミリ秒に戻すことはできません。デフォルトのバッチ処理ウィンドウを復元するには、新しいイベントソースマッピングを作成する必要があります。
-
バッチサイズに適合した。最小バッチサイズは 1 です。デフォルトのバッチサイズと最大バッチサイズは、イベントソースに応じて異なります。これらの値の詳細については、
CreateEventSourceMapping
API オペレーションの BatchSize の仕様を参照してください。 -
ペイロードサイズが 6 MB に到達した。この上限を変更することはできません。
以下の図は、これら 3 つの条件を説明するものです。バッチ処理ウィンドウが t = 7
秒で開始されるとします。最初のシナリオでは、バッチ処理ウィンドウが 5 個のレコードを蓄積した後、t = 47
秒の時点で最大値の 40 秒に到達します。2 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前にバッチサイズが 10 個になるため、バッチ処理ウィンドウが早く終了します。3 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前に最大ペイロードサイズに到達するため、バッチ処理ウィンドウが早く終了します。
イベントソースマッピング API
AWS Command Line Interface (AWS CLI) または AWS SDK