Lambdaレイヤーとコンテナイメージ — 依存ライブラリの管理戦略

Lambdaレイヤーの概要

Lambdaレイヤーは関数コードから依存ライブラリを分離し、複数の関数で共有する仕組みだ。

レイヤーなし:
  関数A: [コード + numpy + pandas + requests] (50MB)
  関数B: [コード + numpy + pandas + requests] (50MB)
  → 重複した依存関係を各関数に含める必要がある

レイヤーあり:
  共有レイヤー: [numpy + pandas + requests] (45MB)
  関数A: [コード] (5MB) + 共有レイヤー参照
  関数B: [コード] (5MB) + 共有レイヤー参照
  → デプロイサイズ削減、更新が一元化

レイヤーの作成と使用

# レイヤーのディレクトリ構造（Python）
# python/lib/python3.12/site-packages/ 配下にパッケージを配置
mkdir -p layer/python/lib/python3.12/site-packages
pip install requests -t layer/python/lib/python3.12/site-packages/
cd layer && zip -r ../my-layer.zip .

# レイヤーのアップロード
aws lambda publish-layer-version \
  --layer-name my-dependencies \
  --description "Common Python dependencies" \
  --compatible-runtimes python3.12 \
  --zip-file fileb://my-layer.zip

# 関数にレイヤーを追加
aws lambda update-function-configuration \
  --function-name my-function \
  --layers arn:aws:lambda:ap-northeast-1:123456789012:layer:my-dependencies:1

レイヤーの制限:
  最大レイヤー数: 1関数あたり5レイヤーまで
  展開後のサイズ上限: 250MB（レイヤー合計 + 関数コード）
  1レイヤーのzipサイズ: 最大50MB（直接アップロード）、250MB（S3経由）

ディレクトリ構造:
  Python: python/ または python/lib/python3.x/site-packages/
  Node.js: nodejs/node_modules/
  Java:    java/lib/
  Ruby:    ruby/gems/

レイヤーの共有

# レイヤーを別アカウントに公開
aws lambda add-layer-version-permission \
  --layer-name my-dependencies \
  --version-number 1 \
  --statement-id "allow-all-accounts" \
  --principal "*" \
  --action lambda:GetLayerVersion

# 特定アカウントのみに許可
aws lambda add-layer-version-permission \
  --layer-name my-dependencies \
  --version-number 1 \
  --statement-id "allow-account-123" \
  --principal "123456789012" \
  --action lambda:GetLayerVersion

コンテナイメージのデプロイ

zipデプロイの250MB制限を超える場合、コンテナイメージ（最大10GB）を使う。

# Lambdaコンテナイメージの例（Python）
FROM public.ecr.aws/lambda/python:3.12

# 依存ライブラリのインストール
COPY requirements.txt ${LAMBDA_TASK_ROOT}
RUN pip install -r requirements.txt

# 関数コードのコピー
COPY app.py ${LAMBDA_TASK_ROOT}

# ハンドラーの指定
CMD ["app.lambda_handler"]

# ECRへのビルド・プッシュ
aws ecr create-repository --repository-name my-lambda-repo
aws ecr get-login-password | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com

docker build -t my-lambda .
docker tag my-lambda:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-lambda-repo:latest
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-lambda-repo:latest

# コンテナイメージを使ったLambda関数の作成
aws lambda create-function \
  --function-name my-container-function \
  --package-type Image \
  --code ImageUri=123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-lambda-repo:latest \
  --role arn:aws:iam::123456789012:role/lambda-role

zipデプロイ vs コンテナイメージ

zip デプロイ:
  デプロイサイズ上限: 50MB（直接）/ 250MB（展開後）
  コールドスタート: 速い（zipの解凍が速い）
  レイヤー: 使用可能
  ローカル再現: 困難
  
コンテナイメージ:
  デプロイサイズ上限: 10GB（ECRから）
  コールドスタート: やや遅い（イメージ取得）
  レイヤー: 使用不可（代わりにDockerレイヤー）
  ローカル再現: Dockerで完全再現可能
  
コンテナを選ぶ場合:
  → 依存ライブラリが250MBを超える（機械学習モデル等）
  → ローカル開発環境との一致が必要
  → 既存のDockerワークフローを活用したい

Lambda拡張機能（Extensions）

Lambda Extensionsの用途:
  → サードパーティのセキュリティエージェント
  → 監視ツール（Datadog, New Relic等）
  → シークレット取得の事前キャッシュ
  
動作モード:
  Internal Extensions: 関数と同じプロセス内
  External Extensions: 別プロセスとして実行
  
Layerとの組み合わせ:
  Extensions もレイヤーとして配布可能
  レイヤー内の /opt/extensions/ に配置

試験頻出ポイント

シナリオ	回答
複数Lambda関数で共通ライブラリを使う	Lambdaレイヤー
1関数に追加できるレイヤー数	最大5レイヤー
250MBを超える依存関係	コンテナイメージデプロイ（最大10GB）
コンテナイメージの保存先	ECR（Amazon Elastic Container Registry）
ローカルのDockerと同じ環境でLambda実行	コンテナイメージデプロイ

まとめ

Lambdaレイヤーは共通ライブラリを関数間で共有しデプロイサイズを削減する。依存関係が大きい場合（機械学習等）はコンテナイメージ（最大10GB）を使う。コンテナイメージはローカル環境の完全再現ができる利点もある。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感