Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法 - AWS Lambda
イベントソースマッピングとトリガーバッチ処理動作イベントソースマッピング API

Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法

イベントソースマッピングは、ストリームおよびキューベースのサービスからアイテムを読み取り、レコードのバッチを使用して関数を呼び出す Lambda リソースです。以下のサービスは、イベントソースマッピングを使用して Lambda 関数を呼び出します。

警告

Lambda イベントソースマッピングは各イベントを少なくとも 1 回処理し、レコードの重複処理が発生する可能性があります。重複するイベントに関連する潜在的な問題を避けるため、関数コードを冪等にすることを強くお勧めします。詳細については、 AWS ナレッジセンターの「Lambda 関数を冪等にするにはどうすればよいですか?」を参照してください。

イベントソースマッピングと直接トリガーの違い

一部の AWS サービスは、トリガーを使用して Lambda 関数を直接呼び出すことができます。これらのサービスはイベントを Lambda にプッシュし、指定されたイベントが発生すると即時に関数が呼び出されます。トリガーは、個別のイベントやリアルタイム処理に適しています。Lambda コンソールを使用してトリガーを作成すると、コンソールは対応する AWS サービスと連携して、そのサービスでイベント通知を設定します。実際には、トリガーは Lambda ではなく、イベントを生成するサービスによって保存および管理されます。トリガーを使用して 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 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前に最大ペイロードサイズに到達するため、バッチ処理ウィンドウが早く終了します。

バッチ処理ウィンドウの期限が切れるのは、最大時間に達した場合、バッチサイズが満たされた場合、またはペイロードが 6 MB に達した場合です

バッチおよびレコードの各種サイズのテストにより、関数がタスクを完了できるスピードに合わせて各イベントソースのポーリング間隔を調整することをおすすめします。CreateEventSourceMapping BatchSize パラメータは、各呼び出しで関数に送信できるレコードの最大数を制御します。通常、バッチサイズが大きいほど、大きなレコードセット全体での呼び出しのオーバーヘッドをより効率的に吸収し、スループットを増大できます。

Lambda は、設定された拡張機能の完了を待たずに、次のバッチを処理のために送信します。つまり、Lambda がレコードの次のバッチを処理する間も拡張機能を実行し続けることができます。アカウントの同時実行設定または制限に違反すると、スロットリングの問題が発生する可能性があります。これが潜在的な問題であるかどうかを検出するには、関数を監視し、イベントソースマッピングで予想よりも高い同時実行メトリクスが表示されているかどうかを確認します。呼び出しの間隔が短いため、Lambda はシャードの数よりも高い同時実行使用量を一時的に報告する場合があります。これは、拡張機能のない Lambda 関数にも当てはまります。

関数がエラーを返す場合は、デフォルトで、イベントソースマッピングは関数が成功するまで、またはバッチ内の項目の期限が切れるまでバッチ全体を再処理します。処理が順序正しく行われることを確実にするため、イベントソースマッピングは、エラーが解決されるまで影響を受けたシャードの処理を一時停止します。ストリームソース (DynamoDB と Kinesis) については、関数がエラーを返すときに Lambda が再試行する最大回数を設定できます。バッチが関数に到達しないサービスエラーまたはスロットルは、再試行としてカウントされません。イベントバッチを破棄したときに呼び出しレコードを送信先に送信するように、イベントソースマッピングを設定することもできます。

イベントソースマッピング API

AWS Command Line Interface (AWS CLI) または AWS SDK を使用してイベントソースを管理するには、以下の API 操作を使用できます。