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

イベントソースマッピングは、ストリームおよびキューベースのサービスからアイテムを読み取り、レコードのバッチを使用して関数を呼び出す Lambda リソースです。イベントソースマッピング内では、イベントポーラーと呼ばれるリソースが新しいメッセージをアクティブにポーリングし、関数を呼び出します。デフォルトでは、Lambda はイベントポーラーを自動的にスケーリングしますが、特定のイベントソースタイプでは、プロビジョニングモードを使用して、イベントソースマッピング専用のイベントポーラーの最小数と最大数を制御できます。

以下のサービスは、イベントソースマッピングを使用して Lambda 関数を呼び出します。

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

一部の AWS のサービスは、トリガーを使用して Lambda 関数を直接呼び出すことができます。これらのサービスはイベントを Lambda にプッシュし、指定されたイベントが発生すると即時に関数が呼び出されます。トリガーは、個別のイベントやリアルタイム処理に適しています。Lambda コンソールを使用してトリガーを作成すると、コンソールは対応する AWS サービスと連携して、そのサービスでイベント通知を設定します。実際には、トリガーは Lambda ではなく、イベントを生成するサービスによって保存および管理されます。トリガーを使用して Lambda 関数を呼び出すサービスの例をいくつか示します。

イベントソースマッピングは、Lambda サービス内で作成および管理される Lambda リソースです。イベントソースマッピングは、大量のストリーミングデータやキューからのメッセージを処理できるように設計されています。ストリームまたはキューからのレコードをバッチで処理すると、レコードを個別に処理するよりも効率的です。

バッチ処理動作

デフォルトで、イベントソースマッピングは、Lambda が関数に送信する単一のペイロードにレコードをまとめてバッチ処理します。バッチ処理の動作を微調整するには、バッチ処理ウィンドウ (MaximumBatchingWindowInSeconds) とバッチサイズ (BatchSize) を設定します。バッチ処理ウィンドウとは、レコードを単一のペイロードにまとめるための最大時間です。バッチサイズとは、単一のバッチ内にあるレコードの最大数です。Lambda は、以下の 3 つの条件のいずれかが満たされたときに関数を呼び出します。

以下の図は、これら 3 つの条件を説明するものです。バッチ処理ウィンドウが t = 7 秒で開始されるとします。最初のシナリオでは、バッチ処理ウィンドウが 5 個のレコードを蓄積した後、t = 47 秒の時点で最大値の 40 秒に到達します。2 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前にバッチサイズが 10 個になるため、バッチ処理ウィンドウが早く終了します。3 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前に最大ペイロードサイズに到達するため、バッチ処理ウィンドウが早く終了します。

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

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

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

プロビジョニングモード

Lambda イベントソースマッピングは、イベントポーラーを使用して、新しいメッセージのイベントソースをポーリングします。デフォルトでは、Lambda はメッセージ量に応じてこれらのポーラーの自動スケーリングを管理します。メッセージトラフィックが増加すると、Lambda は負荷に対応するためにイベントポーラーの数を自動的に増やし、トラフィックが減少すると減らします。

プロビジョニングモードでは、プロビジョニングされるイベントポーラーの数の下限と上限を定義することで、イベントソースマッピングのスループットを微調整できます。これにより、Lambda はイベントポーラーの最小数と最大数の間でイベントソースマッピングをレスポンシブにスケーリングします。これらのプロビジョニングされたイベントポーラーは、イベントソースマッピング専用であり、イベントの予期しない急増を処理する機能を強化します。

Lambda のイベントポーラーは最大 5 MBps のスループットを処理できるコンピューティングユニットです。例えば、イベントソースの平均ペイロードが 1 MB で、平均関数所要時間が 1 秒であるとします。ペイロードで変換 (フィルタリングなど) が発生しない場合、1 つのポーラーが 5 MBps のスループットと 5 つの同時 Lambda 呼び出しをサポートできます。プロビジョニングモードを使用すると、追加コストが発生します。料金の見積もりについては、「AWS Lambda 料金」を参照してください。

プロビジョニングモードは、Amazon MSK およびセルフマネージド Apache Kafka イベントソースでのみサポートされます。同時実行設定では関数のスケーリングを制御できますが、プロビジョニングモードではイベントソースマッピングのスループットを制御できます。最大のパフォーマンスを確保するには、両方の設定を個別に調整する必要がある場合があります。プロビジョニングモードの設定の詳細については、以下のセクションを参照してください。

プロビジョニングモードを設定すると、ProvisionedPollers メトリクスをモニタリングすることで、ワークロードのイベントポーラーの使用状況を確認できます。詳細については、「イベントソースマッピングメトリクス」を参照してください。

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

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