AWS Lambda によるデータ処理

は、イベントが起きたときにだけコードを実行するのコンピューティングサービスです。データパイプラインでは、にファイルが届いたときの変換、・ Streams・のレコードの処理、のワークフローの1ステップ、の裏側の処理など、短く軽い処理を担います。DEA では、イベントソースマッピングの設定、数の調整、メモリとタイムアウト、ストレージのマウントが出題されます。

Point

イベントソースマッピング (ESM) は、Lambda がストリームやキューを自分で読みに行き (ポーリング)、まとめて関数を呼ぶ仕組みです。S3 や EventBridge のように相手から呼ばれる方式とは違います。
Concurrency (同時実行数) は、同じ瞬間に動いている実行環境の数です。
和訳
- Concurrency: 同時に起こること、並行性
- Weblio英和辞書「concurrency」

概要

呼び出し方	例	失敗時の扱い
同期	、	呼び出し元がエラーを受け取り、再試行を決める
非同期	イベント通知、、	が再試行し、失敗したら送信先 (、SNS、EventBridge、Lambda) やへ
イベントソースマッピング	、 Streams、SQS、	ESM の設定 (再試行、二分割、失敗時の送信先、部分的なバッチの失敗) で制御

主な上限	値
タイムアウト	最大 900 秒 (15 分)
メモリ	128 MB〜10,240 MB (1 MB 単位)。はメモリに比例し、1,769 MB で 1 vCPU 相当
/tmp (エフェメラルストレージ)	512 MB〜10,240 MB
数	あたり既定 1,000 (引き上げ可)
ペイロード	同期は要求・応答それぞれ 6 MB、非同期は 1 MB
レイヤー	1関数あたり 5 つまで

主要技術

①Lambda が向くデータ処理と向かない処理 ⚠️ 頻出

向く	向かない
届いたファイルを1つずつ軽く変換・検証	15 分を超える処理
ストリームのレコードの変換・振り分け・通知	数十 GB を超えるデータの結合や集計 (、)
ワークフローの短いステップ (メタデータの更新、の投入)	長いウィンドウを持つな集計 ()
の裏側でデータを返す	常に高い負荷が続く処理 (やの方が安いことがある)

⚠️ 頻出: 「処理に 30 分かかる変換」にを選ぶのは誤りです。Glue、EMR、/、を選ぶか、処理を分割しての分散マップで並列に動かします。

②Kinesis・DynamoDB Streams からの呼び出し ⚠️ 頻出

ストリームのイベントソースマッピングは、ごとにバッチを作り、順序を保って関数を呼びます。

設定	内容
BatchSize (最大 10,000) と MaximumBatchingWindowInSeconds (最大 300 秒)	1回で処理する量と、ためる時間
ParallelizationFactor (1〜10)	1シャードを並行に処理する数。単位の順序は保たれる
BisectBatchOnFunctionError	失敗したバッチを二分割して再試行し、不正なレコードを特定する
MaximumRetryAttempts、MaximumRecordAgeInSeconds	再試行の回数とレコードの最大経過時間 (既定は無制限)
失敗時の送信先	かに、処理を諦めたバッチの情報を送る
ReportBatchItemFailures	失敗したレコードだけを報告し、成功したレコードを再処理しない
StartingPosition	TRIM_HORIZON、LATEST、AT_TIMESTAMP

関数がエラーを返し続けると、そのシャードは期限切れまで止まります。本番では、再試行の上限、二分割、失敗時の送信先を必ず設定します。ストリームを読むコンシューマーが多い場合は、ののコンシューマーを ESM のソースにすると、他のコンシューマーと帯域を奪い合いません。

イベントソースマッピングにはフィルター条件 (FilterCriteria) も設定できます。レコードの値 (例: Streams の NewImage の状態) が条件に一致するものだけで関数を呼び、一致しないレコードは関数を呼ばずに読み飛ばすため、関数の中で判定して何もせず終わる呼び出しをなくせます。Kinesis、DynamoDB Streams、SQS、などのソースで使えます。

③SQS からの呼び出し

設定	内容
バッチサイズとバッチウィンドウ	まとめて処理してコストと呼び出し回数を減らす
最大数 (2〜1,000)	この ESM が使う同時実行数の上限。下流の DB を守る、1つのキューが関数の同時実行を使い切るのを防ぐ
ReportBatchItemFailures	失敗したメッセージだけをキューに戻す
	関数のタイムアウトより十分長くする。短いと処理中のメッセージが再び見え、重複処理になる
(キュー側の設定)	何度も失敗したメッセージを別のキューへ退避する

キューでは、同じメッセージグループのメッセージを順番に処理します。同時実行の数は、メッセージグループの数で頭打ちになります。

④同時実行数の設定 ⚠️ 頻出

設定	内容	使いどころ
予約数	関数のために同時実行数を確保し、同時にその関数の上限にもなる	重要な関数の枠を確保する。下流 ( など) を守るために上限を決める
プロビジョンド同時実行数	実行環境を事前に初期化しておく (追加の料金)	コールドスタートの遅れを許せない
アカウントの同時実行数	で共有する上限 (既定 1,000)	足りなければ引き上げを申請

関数ごとの拡張の速さにも上限があり、10 秒ごとに 1,000 の実行環境まで増やせます。

症状	対処
429 (TooManyRequestsException) で	アカウントの上限の引き上げ、予約同時実行数の見直し
下流の DB の接続数が上限に達する	予約同時実行数や ESM の最大同時実行数で上限を決める、RDS Proxy
初回の呼び出しが遅い (コールドスタート)	プロビジョンド同時実行数、パッケージを小さくする
処理が遅い ( が足りない)	メモリを増やす (CPU も比例して増える)

⑤ストレージの使用とマウント ⚠️ 頻出

ストレージ	特徴	使いどころ
/tmp (エフェメラルストレージ)	512 MB〜10,240 MB。実行環境ごとに独立し、環境が消えると消える	ダウンロードしたファイルの一時的な展開、中間ファイル
	関数に EFS のアクセスポイントをマウントする (/mnt/…)。複数の関数や実行環境で共有でき、永続する	大きな参照データやモデルの共有、関数間でファイルを受け渡す
	で読み書きする。永続し、他のサービスと共有できる	入力と出力の保管
レイヤー	ライブラリや共通のコードを関数とは別に配布する (5つまで、展開後の合計 250 MB まで)	pandas などの大きなライブラリ、共通の処理
イメージ	最大 10 GB のイメージとしてデプロイ	ライブラリが大きく、ZIP の上限に収まらない

EFS をマウントするには、関数をに接続し、EFS のマウントターゲットに届くとを設定します。

は、Amazon S3 Files のファイルシステムもマウントできます。S3 Files は、S3 のオブジェクトをファイルとして読み書きできるようにする S3 の機能で、EFS と同じく VPC 内のマウントターゲットへ (ポート 2049) で接続し、/mnt/ で始まるパスにマウントします。データの正本を S3 に置いたまま、ファイルの API で扱いたいときに使います。1つの関数に設定できるのは EFS と S3 Files のどちらか一方です。

⚠️ 頻出: 「複数の Lambda 関数で大きなファイルを共有し、呼び出しをまたいで残したい」は EFS のマウントです。「1回の処理で 5 GB の一時ファイルを展開したい」は /tmp を増やします。

⑥データ処理の自動化とサーバーレスワークフロー

パターン	構成
ファイル到着で変換	→ () → → S3 の別プレフィックスへで書く
定期処理	EventBridge Scheduler → Lambda ( からの取り込み、の起動)
多段の処理	が Lambda、、を順に呼ぶ (エラー処理と再試行は Step Functions で)
大量のファイルの並列処理	Step Functions の分散マップで、S3 のオブジェクトごとに Lambda を並列実行
の投入	Lambda から Data API や Athena の API を非同期に呼ぶ

S3 のイベントで起動した関数が、出力を同じの同じプレフィックスへ書くと、その書き込みが再び関数を起動する無限ループになります。Lambda は、S3、、EventBridge のカスタムイベントバスを含むループを検知し、同じきっかけで約 16 回呼ばれると次の呼び出しを止めますが、費用の無駄を防ぐには出力先を別のプレフィックスやバケットに分け、イベント通知を入力のプレフィックスに絞ります。

S3 や EventBridge からの非同期の呼び出しは、失敗すると Lambda が既定で 2 回まで再試行します (再試行の回数は 0〜2、イベントの最大経過時間は最長 6 時間で調整)。それでも失敗したイベントは、失敗時の送信先 (SQS、SNS、EventBridge、Lambda など) かに送れば失われず、原因を直した後で再処理できます。

Lambda、Step Functions、などのの部品は、でまとめて定義・デプロイできます (「 (・・SAM)」の章)。

⑦セキュリティと設定

項目	内容
実行ロール	関数がアクセスする、、などの権限を最小限に付ける
接続	VPC 内のやへ接続する。インターネットへはゲートウェイ、AWS サービスへは VPC
環境変数	設定値を渡す (合計 4 KB まで)。秘密情報はや Parameter Store から取る
ログ	Logs へ出力。構造化ログ () にすると検索しやすい

試験対策

①判断マトリクス

問題文のキーワード	選ぶ設定・構成
のレコードをで処理	イベントソースマッピング
Lambda がストリームの書き込みに追いつかない	ParallelizationFactor を上げる
1件の不正なレコードで止まる	二分割、再試行の上限、失敗時の送信先
バッチの一部だけ失敗、成功分は再処理しない	ReportBatchItemFailures
からの処理で DB を過負荷にしない	ESM の最大数、予約同時実行数
重要な関数の同時実行の枠を確保	予約同時実行数
コールドスタートを避けたい	プロビジョンド同時実行数
が足りず処理が遅い	メモリを増やす
大きな一時ファイルを展開	/tmp を増やす (最大 10,240 MB)
関数間でファイルを共有・永続化	のマウント ( 接続が必要)
共通ライブラリの配布	レイヤー
15 分を超える処理	Lambda 以外 (、、/、Batch)
が短く重複処理	関数のタイムアウトより長くする

②よくある誤答

15 分を超える処理をで行うこと。
/tmp を関数間の共有や永続化に使うこと。実行環境ごとに独立し、消えます。
数を増やせば DB への書き込みも速くなると考えること。DB の接続数が先に尽きます。
ESM の再試行を既定 (無制限) のまま本番で使うこと。が止まります。