コンテナでLambdaをデプロイするときに知っておきたかったこと

Transcript

1. コンテナでLambdaをデプロイするときに 知っておきたかったこと 2025/3/26 クラウド食堂#2 ~AWSネタでLT会~ @_takahash こ、こいつ…動くぞ！
2. 自己紹介 • Hiroki Takahshi (@_takahash) • CCoE的なお仕事してます • 社内AWS基盤の運用 • ガイドライン整備 • クラウド人材育成 • Like • CDK, ECS, EKS • Others • 2024 Japan AWS Top Engineers 2
3. もくじ • 概要 • アーキテクチャ • つかいかた • 注意点 • まとめ
4. 概要
5. Lambda関数のデプロイ形式 zipアーカイブとコンテナイメージの2つ パッケージフォーマット サイズ上限 備考 zipアーカイブ 50MB（展開前） 250MB（展開後） マネジメントコンソールか らコードを編集してデプロ イした場合はこちら コンテナイメージ 10GB Lambda関数作成時にECRリ ポジトリ内のコンテナイ メージを参照。
6. どうしてコンテナイメージで？ • コンテナでオペレーションプロセスを統一したい • すでにコンテナでCI/CDの運用が回っている。zipアーカイブ独自の CI/CDを管理するオーバヘッドを避けたい • zipアーカイブの制約を回避したい • 250MBの制約で機械学習のライブラリが入らない • Amazon Linux 2023以外の独自のベースイメージを使いたい • 複雑な実行環境を管理したい • 多数のライブラリやネイティブバイナリが必要で依存関係が複雑 • 一貫性のある実行環境を維持していきたい
7. アーキテクチャ
8. コンテナのサイズが最大10GB…!? Lambdaのコールドスタートにかかる時間が不安…
9. コンテナイメージの特性を利用した 高速化が図られています！
10. Our analysis shows that pulling packages accounts for 76% of container start time, but only 6.4% of that data is read. [Harter, et al., 2016] コンテナイメージの特性 イメージ内の読み込まれるデータはごくわずか（6.4%）
11. オンデマンドロード（1/2） Lambdaがコンテナで作成されるとデータはチャンクに分割される Layer1.tar.gz Layer2.tar.gz … LayerX.tar.gz / /var/task /var/runtime /opt/ … [0-1] Chunk0 [2-3] Chunk1 [4-5] Chunk2 [6-7] Chunk3 […-…] ChunkX イメージのレイヤー ファイルシステム 展開 分割 512KiB 512KiB 512KiB 512KiB
12. Worker Per-function resources ②実際にはファイルが必要になったタイミングで 必要なチャンクをロードしに行く 512KiB 512KiB 512KiB 512KiB [0-1] Chunk0 [2-3] Chunk1 [4-5] Chunk2 [6-7] Chunk3 […-…] ChunkX チャンクは必要となったタイミングではじめてロードされる Worker Local Cache Local Agent Firecracker Micro VM “slot” Guest Linux Kernel ext4 Filesystem Customer Code λ Shim オンデマンドロード（2/2） ①Lambdaからはファイルが ローカルにあるように見える AZ Local Cache
13. Worker Per-function resources ②実際にはファイルが必要になったタイミングで 必要なチャンクをロードしに行く 512KiB 512KiB 512KiB 512KiB [0-1] Chunk0 [2-3] Chunk1 [4-5] Chunk2 [6-7] Chunk3 […-…] ChunkX チャンクは必要となったタイミングではじめてロードされる Worker Local Cache Local Agent Firecracker Micro VM “slot” Guest Linux Kernel ext4 Filesystem Customer Code λ Shim オンデマンドロード（2/2） ①Lambdaからはファイルが ローカルにあるように見える AZ Local Cache コンテナイメージは利用されているが コンテナが実行されているわけではない
14. 参考：同じ特性を利用してコンテナ起動を高速化する技術もある Seekable OCI (SOCI) によるコンテナ起動の高速化 – Speaker Deck (@_takahash) Seekable OCI（ECS/Fargateで利用可能）
15. つかいかた
16. 既存のコンテナイメージはそのままでは実行できない Lambda Serviceと会話をするための仕組みが必要 Lambda Logs APIを使用する - AWS Lambdaデベロッパーガイド
17. コンテナイメージ構築の選択肢 方法 RIC を含む RIE を含む 備考 LambdaのAWSベースイメージの 利用 〇 〇 PythonやNode, Java, .NET, Rubyなどを ベースイメージとして使用したい場合 AWSのOS専用ベースイメージの 利用 × 〇 AL2023、またはAL2をベースイメージと して使用したい場合 非AWSベースイメージの利用 × × 独自のベースイメージを使用したい場合 RIC（Runtime Interface Client） ：Lambdaサービスとの会話を行えるクライアント（OSS) RIE（Runtime Interface Emulator）：ローカルでLambdaをテストしたいときに使うエミュレータ（OSS)
18. LambdaのAWSベースイメージを利用する場合のDockerfile RICのインストールは不要 ベースイメージのハマりポイント • Python3.12等、AL2023が利用されているベースイメージにパッケージ を追加したい場合はyumではなくmicrodnfを利用する必要がある
19. 非AWSベースイメージを利用する場合のDockerfile RICをインストールし、ENTRYPOINTに指定
20. 個人開発では：AWS CDKの利用がおすすめ イメージのBuild/Pushと関数のデプロイをcdk deployで同時に行える
21. アプリとインフラが分かれた開発では： パラメータストア経由でイメージタグをアプリからインフラに渡すと良い CDKのコード例 Push時にイメージタグを格納
22. 注意点
23. Inactive状態への遷移 数週間程度Lambdaを起動しないと、しばらく呼び出しが失敗する Active プロビジョニングが完了 正常に呼び出しに応答 Pending プロビジョニング中 呼び出しはすべて失敗 Inactive アイドル状態が継続 呼び出しはすべて失敗 Failed プロビジョニング失敗 呼び出しはすべて失敗 Lambda関数の状態 – AWS Lambdaデベロッパーガイド
24. Inactive状態の回避方法 • Provisioned Concurrencyを設定する • 料金が発生してしまう点に注意 • 定期的にLambdaを実行する • EventBridge Schedulerなどを利用する
25. まとめ
26. まとめ • コンテナでLambdaを動かす際の概要、アーキテクチャ、つか いかた、注意点を解説しました • 何かのお役に立てば幸いです！