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 は負荷に対応するためにイベントポーラーの数を自動的に増やし、トラフィックが減少すると減らします。

プロビジョニングモードでは、引き続き予想されるトラフィックパターンを処理する準備ができている専用ポーリングリソースの最小制限と最大制限を定義することで、イベントソースマッピングのスループットをファインチューニングできます。これらのリソースは、イベントトラフィックの急増を処理するために 3 倍速く自動スケーリングされ、数百万のイベントを処理を可能にする 16 倍の処理容量を提供します。これにより、厳格なパフォーマンス要件を持つ、応答性の高いイベント駆動型ワークロードを構築できます。

Lambda では、イベントポーラーは、イベントソースタイプによって異なるスループット機能を備えたコンピューティングユニットです。Amazon MSK およびセルフマネージド Apache Kafka の場合、各イベントポーラーは最大 5 MB/秒のスループットまたは最大 5 個の同時呼び出しを処理できます。例えば、イベントソースが 1 MB の平均ペイロードを生成し、関数の平均時間が 1 秒の場合、単一の Kafka イベントポーラーは 5 MB/秒のスループットと 5 個の同時 Lambda 呼び出しをサポートできます (ペイロード変換がないと仮定)。Amazon SQS の場合、各イベントポーラーは最大 1 MB/秒のスループットまたは最大 10 個の同時呼び出しを処理できます。プロビジョンドモードを使用すると、イベントポーラーの使用状況に基づいて追加コストが発生します。料金の詳細については、「AWS Lambda の料金表」を参照してください。

プロビジョンドモードは、Amazon MSK、セルフマネージド Apache Kafka、および Amazon SQS のイベントソースで利用可能です。同時実行設定では関数のスケーリングを制御できますが、プロビジョニングモードではイベントソースマッピングのスループットを制御できます。最大のパフォーマンスを確保するには、両方の設定を個別に調整する必要がある場合があります。

プロビジョンドモードは、マーケットデータフィードを処理する金融サービス会社、リアルタイムでパーソナライズされたお薦め情報を提供する e コマースプラットフォーム、ライブプレイヤーインタラクションを管理するゲーム会社など、安定したイベント処理レイテンシーが求められるリアルタイムアプリケーションに最適です。

イベントポーラーごとに異なるスループットキャパシティがサポートされます。

Amazon SQS イベントソースマッピングでは、ポーラーの最小数は 2〜200 の範囲で設定でき、デフォルトは 2、最大数は 2～2,000 の範囲で設定でき、デフォルトは 200 になります。Lambda は、設定された最小値と最大値の間でイベントポーラーの数をスケーリングし、1 分あたり最大 1,000 個の同時実行数をすばやく追加して、一貫した低レイテンシーのイベント処理を実現します。

Kafka イベントソースマッピングでは、ポーラーの最小数を 1～200 の範囲で設定でき、デフォルトは 1、最大数を 1～2,000 の範囲に設定でき、デフォルトは 200 になります。Lambda は、トピック内のイベントバックログに基づいて、設定された最小値と最大値の間でイベントポーラーの数をスケーリングし、低レイテンシーのイベントの処理を実現します。

Amazon SQS イベントソースの場合、最大同時実行数の設定をプロビジョニングモードで使用することはできないことにご留意ください。プロビジョンドモードを使用する場合、最大イベントポーラー設定を使用して同時実行を制御します。

プロビジョニングモードの設定の詳細については、以下のセクションを参照してください。

プロビジョンドモードでレイテンシーを最小限に抑えるには、MaximumBatchingWindowInSeconds を 0 に設定します。この設定は、現在の関数呼び出しの完了後、Lambda が直ちに次のバッチの処理を開始することを確実にします。低レイテンシー処理の詳細については、「低レイテンシー Apache Kafka」を参照してください。

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

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

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