🐯

Lambdaの機能あれこれメモ

2024/01/21に公開

Lambdaのイベントハンドラ（Python）

def myfunc_handler(event, context):
    — 関数の処理 — 
  return 戻り値

イベントの情報とは、イベントから渡される任意の値のこと
S3やSESなどで発生するイベントをトリガーとして、各イベントに関連する情報が格納されて呼び出される
イベントの情報は、ほとんどJSON形式の文字列であるが、Lambda関数の引数として渡される時はパース済みである
=> そのため以下のようなイベントデータをLambda関数で受け取る際は

{“x” : 10, “y” : 2}

パースされてPythonのオブジェクトに変換されて、以下のように取得できる

event[“x”] = 10
event[“y”] = 2

コンテキストの情報は、実行環境の情報である（Lambda関数はAWSが提供するLambda実行環境内で実行される）

Lambdaはイベントのたびにランタイム環境を用意するのではなく、一度作成したLambda実行環境をしばらく破棄せずにとっておく。次にLambda関数が実行された時に再利用することで、2回目以降のLambda関数の実行を高速化する。

例えば、一時ファイルを/tmpに書き込む処理があった場合、前に実行したデータが残っていることで「同名のファイルが存在する」というエラーが発生する可能性がある。
=> Lambda関数を、常にまっさらな状態であることを前提として書くと、処理が失敗する可能性がある

イベントが発生した時に、呼び出されることが保証されているのはイベントハンドラのみ。グローバルな場所にコードを書くこともできるが、そのプログラムがロードされた時の初回だけしか実行されない。

Lambdaは関数はメモリを多く割り当てるとその分だけ処理能力が向上するが、実行した時間あたりの課金体系で、割り当てたメモリが多いほど単価が高くなる

Lambda関数は、初回の実行にはランタイム環境の準備に時間がかかる（準備にかかる時間はログのInit Durationという項目に書かれている）。こうした準備の時間を省き、即座にLambda関数を実行するのがプロビジョニング機能。
プロビジョニング構成にするとランタイム環境がその場で作られ、スタンバイの状態になり、初期化処理を省ける。（AWSによるとプロビジョニングしておくことで、Lambda関数は2桁ミリ秒以内に応答するようになる）
プロビジョニングする場合、Lambda関数を実行しなくてもプロビジョニングしている時間あたりの課金が発生する
Lambda関数の呼び出し回数が頻繁にある場合は、利用を検討する価値があるが、そうでないならコストが高くなる可能性がある
対してプロビジョニングしない構成のことを「オンデマンド」という

arn:aws:lambda:ap-northeast-1:XXXXXXX:function:hogeFunction

関数ARNは、バージョニングに対応しており、バージョンづけして切り替えて利用ができる。「ステージング版から本番環境版にする」という時には「新しいバージョンを発行」という操作をする
新しいバージョンを発行すると現在の環境のスナップショットが作られ、そのスナップショットに対して「バージョン１」「バージョン２」のように、連番のバージョン番号が付けられる
バージョン付けした時に、それぞれのバージョンの関数ARNは、後ろに「:バージョン番号」を付けたものになる。最新版は「:以降が省略されたもの」になる
バージョンのうち、編集可能なものは最新版だけ。それ以外の版は、新しいバージョンの発行操作をした時のスナップショットであり、構成の変更はできない

エイリアスは特定のバージョンの関数ARNへのショートカットであり、「数値」の代わりに「:任意の名称」を付けたもの
イベントとLambda関数を結び付けるときに、関数ARNを直接指定するのではなく、エイリアス名を作っておいて、そのエイリアスと結びつければ、開発版や本番などを簡単に切り替えれる
運用を考える際は、積極的にエイリアスARNを利用すべき