どんな場面で検討するか
ファイル到着、キューの受信、HTTP 呼出しなどに応じて、CSV の検査や通知生成を小さな処理単位で実行したい場合。常時サーバーを維持せず、処理量の増減に合わせて実行する用途。
組織で使う条件
ランタイムのサポート期限、権限、タイムアウト、予約同時実行数、失敗率と実行時間を管理する。外部接続にはタイムアウトを置き、失敗が同時実行枠を占有し続けないようにする。 再配送・部分失敗・毒メッセージを識別し、成功件数と失敗件数を区別して記録する。Managed Instances の同時処理では要求ごとの状態分離とスレッド安全性も確認する。
採用前に試すこと
- 正常データを検証キューから処理し、メモリ・時間・入力件数・確定件数を記録する。
- 同一 ID と不正データを投入し、接続先の一時失敗も合成して再試行と隔離を確認する。
- 負荷を段階的に増やし、同時実行上限・接続数・再処理を確認し、必要な実行方式と費用を比較する。
合格と判断する条件
- 正常 100 件の期待結果に一致し、タイムアウトとメモリ不足が 0 件。個人情報や認証情報をログに出さない。
- 注文の二重確定が 0 件。不正 5 件を失敗先で特定でき、失敗を成功や 0 件に置換しない。
- キューの滞留とスロットリングを検知でき、再処理後の総件数が一致する。メモリ量・呼出し数・実行時間から見積りを再現できる。
見落としたくない点
- 通常の Lambda の単一呼出しは最大 15 分で、長い一括バッチをそのまま載せる判断は避ける。Managed Instances の非同期・一部イベントソースは最大 90 分に対応するが、全呼出し共通の上限ではない。 常時接続やホスト制御が必要な処理、大きなローカル状態に依存する処理では ECS・EC2 等と比較する。長時間処理は分割やワークフロー方式の方が再試行しやすい場合もある。
- 通常の Lambda の単一呼出しは最大 15 分で、長い一括バッチをそのまま載せる判断は避ける。Managed Instances の非同期・一部イベントソースは最大 90 分に対応するが、全呼出し共通の上限ではない。
- 常時接続やホスト制御が必要な処理、大きなローカル状態に依存する処理では ECS・EC2 等と比較する。長時間処理は分割やワークフロー方式の方が再試行しやすい場合もある。
根拠となる資料
Serverless Computing – AWS Lambda
Configure Lambda function timeout