Open2

感想を書きませんか?|AWSのLambdaってなんやねん

みふうみふう

本の感想や質問、ご指摘やアドバイスをお気軽にコメントしてください!!

技術的なご指摘・アドバイスを受け入れ本書を修正することは他の読者の為になり、
文章的なご指摘・アドバイスを受け入れ本書を修正することは他の読者の読みやすさに繋がります。

お気軽にご意見いただければと思います!

「読みやすかった!理解できた!」といったコメントは僕が喜ぶのでめちゃくちゃお待ちしてます!!^^

https://zenn.dev/mi_01_24fu/books/d91d10985a5a1a

Tomoya IwataTomoya Iwata

こちらのBook読ませて頂きました。

いくつか気になる点があったのでコメントさせて頂きます。ご確認下さい。

Chapter 04 「Lambda関数のコード」はどこで保存する?S3・ECR・Lambdaに直接配置?

Lambdaのデプロイパッケージの保存先に「直接配置」という概念はなく、デプロイパッケージの保存先はS3もしくはECRのいずれかです。デプロイパッケージがZIPファイルアーカイブ形式の場合はS3に、コンテナイメージ形式の場合はECRに保存されます。

※ECRもS3を使っているので、広義ではデプロイパッケージの保存先はS3のみとも言えます。

マネコン上で直接コード編集する場合などCreateFunctionAPIのCodeZipFileを指定する場合を指して「直接配置」と表現されているのだと思いますが、この場合もデプロイパッケージはAWSが管理するS3バケット上に保存されます。同様にCodeS3Bucketを指定した場合であっても最終的なデプロイパッケージはAWSが管理するS3バケット上に保存されます。

このS3バケットやオブジェクトキーはaws lambda get-function --function-name <Lambda関数名> | jq .Code.Locationのようなコマンドで確認可能です。

Lambdaに配置できるコードのMB上限

Lambdaに直接配置できるコードのサイズには以下の制限がありますが、S3やECRを使用する場合はこの制約が適用されません

前述の通りデプロイパッケージがZIPファイルアーカイブ形式の場合は全てS3を使用することになるので、「S3を使用する場合」をCodeS3Bucketを指定する場合と読み替えて考えます。この場合ZIP形式のサイズ上限50MBという制約は無くなりますが、解凍後のサイズ250MBの上限は依然として残り続けます。そのため「制約が適用されません」とするのは誤りです。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html

Lambdaにコードをデプロイするメリット・デメリット

S3やECRにコードがある場合、まずコードの取得(S3の場合はZIPファイルのダウンロード、ECRの場合はコンテナイメージのプル)をするためLambdaにコードを直接デプロイしている場合と比べて実行開始までの時間が長くなる

前述の通り「直接配置」という概念は存在しません。CodeZipFileを指定した場合であってもデプロイパッケージの保存先はS3になるので、ZIPファイルのダウンロードが不要になりコードのロード時間が短くなるといったことはありません。

※話を単純化するためキャッシュのことは無視して考えます

S3を利用するメリット・デメリット

サイズ制限がない

前述の通り解凍後250MBの制限があります。

  • S3からコードをロードする際の初期ロード時間が、Lambdaに直接コードを配置した場合よりも長くなる可能性がある
    • 理由としてはS3からのデータ転送とコードの解凍プロセスに追加の時間がかかるため

前述の通りこちらの記述も誤りです

Chapter 07 Lambdaの同期・非同期処理の理解

Lambdaの「内部キュー」とは?

Lambdaの内部キューはSQSとは関係ないが、概念は一緒

SQSと無関係ではなく、SQSを利用しています

https://dev.classmethod.jp/articles/reinvent2019-svs405/

Chapter 09 実践編 S3にコードをアップロードして実行

Chapter 04 と同様「直接配置」に関する誤りがあります