コンテナでLambdaをデプロイするときに 知っておきたかったこと 2025/3/26 クラウド食堂#2 ~AWSネタでLT会~ @_takahash こ、こいつ…動くぞ！ 

自己紹介 • Hiroki Takahshi (@_takahash) • CCoE的なお仕事してます • 社内AWS基盤の運用 • ガイドライン整備 • クラウド人材育成 • Like • CDK, ECS, EKS • Others • 2024 Japan AWS Top Engineers 2 

もくじ • 概要 • アーキテクチャ • つかいかた • 注意点 • まとめ 

概要 

Lambda関数のデプロイ形式 zipアーカイブとコンテナイメージの2つ パッケージフォーマット サイズ上限 備考 zipアーカイブ 50MB（展開前） 250MB（展開後） マネジメントコンソールか らコードを編集してデプロ イした場合はこちら コンテナイメージ 10GB Lambda関数作成時にECRリ ポジトリ内のコンテナイ メージを参照。 

どうしてコンテナイメージで？ • コンテナでオペレーションプロセスを統一したい • すでにコンテナでCI/CDの運用が回っている。zipアーカイブ独自の CI/CDを管理するオーバヘッドを避けたい • zipアーカイブの制約を回避したい • 250MBの制約で機械学習のライブラリが入らない • Amazon Linux 2023以外の独自のベースイメージを使いたい • 複雑な実行環境を管理したい • 多数のライブラリやネイティブバイナリが必要で依存関係が複雑 • 一貫性のある実行環境を維持していきたい 

アーキテクチャ 

コンテナのサイズが最大10GB…!? Lambdaのコールドスタートにかかる時間が不安… 

コンテナイメージの特性を利用した 高速化が図られています！ 

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%） 

オンデマンドロード（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 

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 

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 コンテナイメージは利用されているが コンテナが実行されているわけではない 

参考：同じ特性を利用してコンテナ起動を高速化する技術もある Seekable OCI (SOCI) によるコンテナ起動の高速化 – Speaker Deck (@_takahash) Seekable OCI（ECS/Fargateで利用可能） 

つかいかた 

既存のコンテナイメージはそのままでは実行できない Lambda Serviceと会話をするための仕組みが必要 Lambda Logs APIを使用する - AWS Lambdaデベロッパーガイド 

コンテナイメージ構築の選択肢 方法 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) 

LambdaのAWSベースイメージを利用する場合のDockerfile RICのインストールは不要 ベースイメージのハマりポイント • Python3.12等、AL2023が利用されているベースイメージにパッケージ を追加したい場合はyumではなくmicrodnfを利用する必要がある 

非AWSベースイメージを利用する場合のDockerfile RICをインストールし、ENTRYPOINTに指定 

個人開発では：AWS CDKの利用がおすすめ イメージのBuild/Pushと関数のデプロイをcdk deployで同時に行える 

アプリとインフラが分かれた開発では： パラメータストア経由でイメージタグをアプリからインフラに渡すと良い CDKのコード例 Push時にイメージタグを格納 

注意点 

Inactive状態への遷移 数週間程度Lambdaを起動しないと、しばらく呼び出しが失敗する Active プロビジョニングが完了 正常に呼び出しに応答 Pending プロビジョニング中 呼び出しはすべて失敗 Inactive アイドル状態が継続 呼び出しはすべて失敗 Failed プロビジョニング失敗 呼び出しはすべて失敗 Lambda関数の状態 – AWS Lambdaデベロッパーガイド 

Inactive状態の回避方法 • Provisioned Concurrencyを設定する • 料金が発生してしまう点に注意 • 定期的にLambdaを実行する • EventBridge Schedulerなどを利用する 

まとめ 

まとめ • コンテナでLambdaを動かす際の概要、アーキテクチャ、つか いかた、注意点を解説しました • 何かのお役に立てば幸いです！