22. 呼び出しの3経路(2) イベントソースマッピング — Lambdaが自分でポーリングする

イベントソースマッピングは「Lambdaが自分でポーリングして、レコードをバッチにまとめてから関数を呼ぶ」プル型の呼び出し経路です。その仕組みを5つの図で追います。

① 主導権の逆転 — プッシュではなくプル(ポーリング)

SQS

Kinesis

DynamoDB Streams

Kafka (MSK)自分からLambdaを呼ばない

レコードをバッチにまとめて起動

イベントソースマッピングLambdaが管理するリソース(内部にイベントポーラー)

Lambda関数

同期呼び出し(前回)= 呼ぶ側がInvoke APIを叩き、受け取った瞬間に起動するプッシュ型
この経路の最大の特徴は「呼び出しの主導権が送る側→受ける側(Lambda)に移る」こと

同期呼び出しは送る側がInvoke APIで押し込む「プッシュ」でしたが、キュー・ストリームでは受ける側のLambdaが自分から問い合わせる「プル」に主導権が移ります。

② なぜポーリング? — バッチ処理でオーバーヘッドを償却

レコード

レコード…大量に連続して流れてくる

1バッチ = 関数を1回だけ起動

1つのバッチ起動コストをレコード数で割り算(償却)

Lambda関数

バッチサイズを大きくするほど1回の起動コストを多くのレコードで割れてスループットが上がる
プッシュ型トリガー(S3・SNS)= 1イベント即時1起動の「個別・リアルタイム向き」
イベントソースマッピング = 「高スループットの一括処理向き」の設計

1レコードごとに1回起動すると起動・ネットワークのオーバーヘッドがレコード数だけ発生して割に合わないため、ポーラーは複数レコードを1バッチにまとめ、1バッチ=関数1回だけ呼びます。

③ バッチの締め切り — invokeが発火する3条件

バッチウィンドウ満了MaximumBatchingWindowInSeconds。デフォルト0秒、0〜300秒(1秒刻み)

バッチサイズ到達最大レコード数。最小1、上限はソース依存

ペイロード6MB到達Lambdaの受け取り上限のため変更不可

invoke発火関数を1回呼ぶ

デフォルト0秒(Kinesis・DynamoDB・SQS)= レコードが来次第すぐ呼ぶ
「待ち時間・件数・データ量のどれかで区切る」がポーリングの締め切りロジック

待ち時間・件数・データ量という3つの上限のどれか1つでも満たされた瞬間にバッチが確定し、関数が呼ばれます。

④ ストリーム系だけの制約 — 順序を守るためシャードごと止まる

シャードAレコードは順番どおりに処理

シャードB他のシャードは影響を受けず進む

成功 or レコード期限切れまで繰り返し。詰まり対策は…

シャードAだけ停止同じバッチを繰り返し再処理

エラー時の破棄先(デスティネーション)を用意毒メッセージ対策の定石

「順序保証はパーティション単位でしか成立しない」原則の実装(基礎で学んだ内容)
ストリーム系ではリトライ回数を設定可能。関数に届かないサービスエラーやスロットルはリトライ回数に数えない
1つの毒メッセージがシャード全体を詰まらせ得る

DynamoDB StreamsとKinesisは同じシャード内の順序保持が必須なので、バッチがエラーになるとそのシャードだけ処理を止め、成功するかレコードが期限切れになるまで同じバッチを再処理し続けます。

⑤ 配信は at-least-once — 「重複は前提」で冪等に作る

レコード #421回目

レコード #422回目(重複)— バッチ再処理やスケーリングで発生

実装例

冪等な関数同じ入力で何度呼ばれても結果が変わらない

処理済みIDを記録

既に見たIDならスキップ

AWSも公式に「関数コードを冪等(idempotent)に作ること」を強く推奨
二重処理されても壊れない設計にしておくことがこの呼び出し経路を安全に使う鍵

同じレコードが2回以上届くことは正常な範囲で起こり得るため、同じ入力で何度呼ばれても結果が変わらない「冪等」な関数コードにしておくことが、この経路を安全に使う鍵です。

サンプルコード(フレームワーク環境が必要なため表示のみ)

# SQSをソースにイベントソースマッピングを作る例
# BatchSize=最大レコード数 / MaximumBatchingWindowInSeconds=バッチウィンドウ(秒)
aws lambda create-event-source-mapping \
  --function-name my-func \
  --event-source-arn arn:aws:sqs:ap-northeast-1:111122223333:my-queue \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 20

公式ドキュメントで詳しく ↗