← AWSサービスの内部原理 コース
24. デプロイの実体 — zipとコンテナイメージは何をどこに置くのか
「Lambdaにデプロイする」とは、コードというファイルを実行ホストへ運べる1つの塊に固めて置くこと——その塊の作り方(zip/コンテナイメージ)、置き場所、そして運ぶコストが効く瞬間を図で追います。
① デプロイの正体 — 「運べる1つの塊」を作って置く
あなたのコードただのファイル
依存関係ライブラリ等
1つの塊に固める(パッケージ化)
zip形式.zipアーカイブ
コンテナイメージECRに保存
配布(コピー)
実行ホストメモリに載って初めてCPUが実行できる
プログラムは最終的にファイルであり、CPUが実行するには実行ホストのメモリまで物理的に運ぶ必要があります。zipもコンテナイメージも「固め方と置き場所」が違うだけで、目的は同じ『実行ホストへ運べる1つの塊にする』ことです。
② サイズ上限 — 「運ぶサイズ」と「広げたサイズ」は別物
zip形式圧縮50MB / 展開後250MB
50MB超は一度S3に置き、その場所を指定コンテナイメージ非圧縮・全レイヤー込みで最大10GB
本体はLambda管理ストレージではなくAmazon ECRに保存- 圧縮50MB=API/SDK/コンソール経由の直接アップロード上限
- 展開後250MB=レイヤーやカスタムランタイムを含めた合計
- 10GBのコンテナイメージは、OSレベルのライブラリや大きなモデルファイルの同梱向き
zipには圧縮50MB・展開250MBという2つの数字が併存します。ネットワークで運ぶときのサイズと、実行ホスト上でファイルとして広げたときのサイズが別物だからです。
③ 保存場所は「元本の置き場所」— 実行時に毎回取りに行く経路ではない
zipをアップロード
元本(コピー)の保存
Lambda管理ストレージ既定。リージョンごと300GBまで
各関数バージョン・各レイヤーバージョンが容量を消費自己管理S3コードストレージ設定変更で選択。コピーを持たずあなたのS3から読む
どちらの場合でも別途作られる
内部の最適化された表現invoke(呼び出し)にはこちらを使う
- コールドスタートのたびに元のzipやS3オブジェクトを取りに行っているわけではない
zipの元本がLambda管理ストレージにあっても自分のS3にあっても、Lambdaは呼び出し用に内部の最適化された表現を別途作ります。公式ドキュメントも「S3上のソースコードはコールドスタートのたびにアクセスされるわけではない」と明記しています。
④ コールドスタート — 「運んで・広げて・読む」物理コストがInitに直結
新しいmicroVMを用意他の関数と非共有・再利用なし
① 運ぶ
最適化された配布物をmicroVMへ大きいほど運ぶバイト数が増える
② 広げる
ファイルとして展開ディスクに書く量が増える
③ 読む
ランタイム起動・コード読み込みInitフェーズ(上限10秒)
- 抽象的なペナルティではなく『ファイルを運んで広げてメモリに読む』物理コストそのもの
新しい実行環境(=1つのmicroVM。他の関数と共有されず再利用もされない)を用意するたび、この3ステップが走ります。パッケージが大きいほど各ステップの量が増え、上限10秒のInitフェーズが重くなって初回応答が遅くなります。
⑤ レイヤー — 配布物の「整理・共有・重複排除」の道具(高速化の道具ではない)
関数コード本体コアのロジック
レイヤー共通ライブラリ等の別zip
1関数あたり5つまで・zip形式の関数のみ実行環境で
コードは通常どおり配置
/opt に展開ランタイムはここ経由で依存を参照
- 公式が挙げる利点: パッケージを小さく保つ / ロジックと依存の分離 / 複数関数で共有 / コンソールのコードエディタが使える / 埋め込みSDKのバージョン固定
- コンテナイメージ形式ではレイヤーは使えず、依存はイメージのビルド時に同梱
- コンテナイメージがレイヤー構造とキャッシュで同じ層の再取得を避けるのと同じ発想を、zipの世界で実現したもの
レイヤーは共通ライブラリを関数コードから切り離した別のzipで、実行環境の/optに展開されてランタイムが参照します。切り出しても結局/optに展開して読み込むため、運んで広げる総量は根本的に減らず、公式が挙げる利点にも『初期化を速くする』は含まれていません。