156-AWS SAP AWS 「理論・実践・一問道場」Lambda Docker イメージをデプロイメントパッケージ

type

status

date

slug

summary

理論

AWS Lambda 関連の問題に対処するには、Lambda のアーキテクチャ、コードのデプロイ方法、およびライブラリやカスタムクラスの再利用についての本質的な知識が重要です。

AWS Lambda のアーキテクチャとコードのデプロイ

1. AWS Lambda の基本構造

AWS Lambda は、イベント駆動型でサーバーレスのコンピューティングサービスです。Lambda 関数は以下のような要素で構成されます。

コード: ビジネスロジックを含むスクリプトやアプリケーションコード。

ランタイム: 関数を実行するための環境（例: Python、Node.js、Java）。

依存関係: ライブラリやモジュールなど、コードが必要とする外部パッケージ。

2. コードのデプロイ方法

Lambda 関数をデプロイする際の一般的な方法は次のとおりです。

Zip パッケージ: 関数コードと依存関係をまとめて圧縮し、直接アップロード。

コンテナイメージ: Docker を使用して関数コードと依存関係をまとめ、Amazon Elastic Container Registry（ECR）にアップロード。

Zip パッケージはシンプルですが、依存関係が多い場合はコンテナイメージの使用が推奨されます。

共有ライブラリとカスタムクラスの再利用

1. Lambda レイヤー

Lambda レイヤーは、共有ライブラリやカスタムクラスを複数の Lambda 関数で再利用するための仕組みです。

利点: コードの重複を減らし、関数のパッケージサイズを小さくできる。

作成方法: 共有ライブラリを Zip 圧縮してアップロードし、Lambda レイヤーとして登録。

制約: レイヤーのサイズ制限は 50 MB（Zip ファイル、未圧縮時は 250 MB）。

2. Docker イメージの活用

AWS Lambda は、50 MB を超える依存関係を持つ場合や、カスタムランタイムが必要な場合に Docker コンテナイメージをサポートしています。

Docker イメージにすべてのコードと依存関係を含めることで、カスタム環境を作成。

Amazon Elastic Container Registry（ECR）を使用してイメージを管理。

ケース別ソリューションの選択

1. Zip パッケージ vs. コンテナイメージ

Zip パッケージ: 軽量で、依存関係が少ないプロジェクトに適している。

コンテナイメージ: 依存関係が多い、または特殊なランタイムが必要な場合に有効。

2. Lambda レイヤーの使用シナリオ

複数の Lambda 関数で同じライブラリを再利用する場合に最適。

頻繁に更新される依存関係を分離して管理することで、デプロイの効率を向上。

実際のデプロイ戦略

A. 共有ライブラリが少ない場合

Zip パッケージとして依存関係をまとめ、必要に応じて Lambda レイヤーを作成。

B. 複雑な依存関係がある場合

Docker イメージを使用し、すべての依存関係をコンテナ内に統合。ECR に保存して関数に適用。

C. カスタムランタイムが必要な場合

Docker イメージを使用してランタイムをカスタマイズし、特定の要件を満たす。

実践

略

一問道場

質問 #156

トピック 1

ある企業が、Amazon API Gateway と AWS Lambda を使用して新しいサーバーレス API を開発しています。この企業は、Lambda 関数を API Gateway と統合し、複数の共有ライブラリとカスタムクラスを使用しています。

ソリューションアーキテクトは、このソリューションのデプロイを簡素化し、コードの再利用を最適化する必要があります。

この要件を満たすソリューションはどれですか？

A. 共有ライブラリとカスタムクラスを Docker イメージにデプロイします。このイメージを S3 バケットに保存します。Docker イメージをソースとする Lambda レイヤーを作成します。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージが Lambda レイヤーを使用するように設定します。

B. 共有ライブラリとカスタムクラスを Docker イメージにデプロイします。このイメージを Amazon Elastic Container Registry（Amazon ECR）にアップロードします。Docker イメージをソースとする Lambda レイヤーを作成します。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージが Lambda レイヤーを使用するように設定します。

C. 共有ライブラリとカスタムクラスを AWS Fargate 起動タイプを使用して Amazon Elastic Container Service（Amazon ECS）の Docker コンテナにデプロイします。API の Lambda 関数を Zip パッケージとしてデプロイし、そのパッケージがデプロイされたコンテナを Lambda レイヤーとして使用するように設定します。

D. 共有ライブラリ、カスタムクラス、および API の Lambda 関数のコードを Docker イメージにデプロイします。このイメージを Amazon Elastic Container Registry（Amazon ECR）にアップロードします。API の Lambda 関数がこの Docker イメージをデプロイメントパッケージとして使用するように設定します。

解説

問題のポイント

コードの再利用性: 共有ライブラリやカスタムクラスを複数の Lambda 関数で効率的に再利用する方法が求められています。

デプロイの簡素化: Lambda 関数とその依存関係を管理しやすくする仕組みが必要です。

最適なツールの選択: AWS Lambda の機能（Zip パッケージ、Lambda レイヤー、Docker イメージ）や関連サービス（ECR、S3、ECS）の適切な組み合わせが求められます。

選択肢の検討

選択肢 A:

「共有ライブラリとカスタムクラスを Docker イメージにデプロイし、S3 バケットに保存する」

評価:

Lambda レイヤーとして Docker イメージを直接使用するのは現時点ではサポートされていません。
S3 は Zip パッケージや Lambda レイヤーの保存場所として適していますが、Docker イメージの保存場所としては不適切です。

結論: 不正解。

選択肢 B:

「共有ライブラリとカスタムクラスを Docker イメージにデプロイし、ECR にアップロードする」

評価:

Docker イメージを ECR に保存するのは一般的なアプローチですが、「Docker イメージを Lambda レイヤーとして使用する」という部分が現実的ではありません。Lambda レイヤーは Zip ファイルで管理されます。
Docker イメージの直接利用を考慮する場合、この方法は冗長になります。