Lambda共通処理の管理

Transcript

1. Lambdaの共通処理 どんな管理にするのがよい？ 2026/10/22 ささやん
2. 自己紹介 ささやん（佐々谷 厚生） ・3年目 ・バックエンドエンジニア、AI開発推進（1、2年目） ・AWSを利用した基盤構築 ← NEW！ ・2026 Japan AWS Jr.Champions ・Meetup Kansai運営
3. 話すこと ・共通処理の管理方式 ・各方式の一般的なメリデメ ・性能検証 話さないこと ・共通処理の具体的な実装方法、コード
4. Lambdaの共通処理 Lambda関数A Lambda関数B ユーザ登録 ユーザ参照 共通処理 共通処理 共通処理 ログ出力、DB接続、エラー処理、入力値チェック どう管理しましょ？
5. 共通処理の方式 同梱方式 共通処理を各Lambdaのパッケージに含める Lambda関数A ユーザ登録 Layer方式 共通処理を別パッケージとして共有 Lambda関数A ユーザ登録 共通処理 Lambda関数B ユーザ参照 共通処理 Lambda関数B ユーザ参照 Layer 共通処理
6. 各方式のメリデメ 比較観点 同梱方式 Layer方式 共通処理の更新 △ 利用する全Lambda関数の再デプロイ が必要 ◦ Layerを1回デプロイし、各Lambda関 数の参照設定を更新 業務処理の更新 ◦ 業務処理と共通処理をまとめてデプ ロイ ◎ 業務処理のみをデプロイ可能 パッケージ効率 △ 各Lambda関数に共通処理を含むため、 ◎ 共通処理をLayerとして共有でき、各 関数数に応じて配布量が増加 Lambda関数のパッケージを軽量化 依存関係の管理 ◎ Lambda関数ごとにライブラリやバー ジョンを柔軟に管理可能 ◦ ライブラリを共通管理可能。ただし、 各Lambda関数との互換性に注意 運用管理の負荷 ◦ Lambda関数単位で管理が完結 △ Layerのバージョンや各Lambda関数の 参照設定など、管理対象が増加
7. 性能に違いはあるの？？
8. 検証してみる 同梱方式とLayer方式で以下を検証 ・デプロイ時間 ・呼び出し時間 前提条件 項目 条件 リージョン ap-northeast-1 Runtime Python 3.12 アーキテクチャ x86_64 メモリ 256MB 外部I/O なし
9. 検証してみた 検証条件 条件 条件 共通機能の容量 4.8KB 業務関数の数 1関数 デプロイ回数（共通機能のみ変更） 5回 コールドスタート実行数 ウォームスタート実行数 同梱方式40件／Layer方式38件 100件 初期化処理が発生した呼び出しだけを コールドスタートとして集計。 Layer方式は2件ほど実行環境が再利用されたので除外
10. 検証してみた デプロイ時間 方式 同梱方式 平均 47.695s Layer方式 75.267s 呼び出し時間 方式 同梱方式 コールドスタート平均 ウォームスタート平均 101.925ms 99.376ms Layer方式 97.914ms 97.924ms ⇒呼び出しに差はなく、デプロイに差が表れた
11. 1関数だけの比較、意味なくね？
12. 検証してみた② 検証条件 条件 共通機能の容量 条件 200MiB 業務関数の数 10関数 デプロイ回数（共通機能のみ変更） 3回 コールドスタート実行数 10件 ウォームスタート実行数 10件 容量も増やしてみた
13. 検証してみた② デプロイ時間 方式 同梱方式 平均 204.511s Layer方式 97.646s 倍近く差が出た 呼び出し時間 方式 同梱方式 コールドスタート平均 ウォームスタート平均 91.256ms 100.061ms Layer方式 95.994ms ⇒デプロイに大きな差が表れた 100.428ms
14. まとめ ・共通機能の呼び出しに性能差はなさそう ・共通機能を利用する関数が多い場合、 Layer方式だとデプロイ時間を大きく短縮できる ・コンパクトな関数だと同梱方式の採用もあり ・Layer方式の真の価値は共通機能の管理と更新の効率化