AWS Lambda 関数の実行の仕組みを知ろう !

図で示されているように、自分たちでサーバーを用意してアプリケーションの実行環境を構築する場合は、そのサーバーの運用管理も自分たちで行っていく必要があります。また、アプリケーションを実行するために必要な ミドルウェア のインストールや構成も自分たちで行う必要があります。

図で示しているように、サーバーレスコンピューティングの場合は、サーバーのプロビジョニングやその後の運用管理、ミドルウェアの構成などは、クラウドサービスの機能でカバーされるため、利用者はアプリケーションの開発にリソースを集中させやすくなるメリットがあります。

また、サーバーレスコンピューティングでは基本的にサーバーが動いている時間ではなく、アプリケーションが実行された時間に対して支払いが発生します。つまり、アプリケーションがアイドル状態の時間に対して支払いを行う必要がないのも特長の一つになります。

このサーバーレスコンピューティングを実現するための代表的なサービスが AWS Lambda です。

では次に、AWS Lambda にフォーカスしていきましょう。AWS Lambda では Lambda 関数をアプリケーションとして実行できます。次の図を見てみましょう。

この図のように、開発者は Lambda 関数として実行するコードを用意し、そのコードの実行に関する設定を行います。また、複数の Lambda 関数で共通的に使用するパッケージやライブラリを Lambda レイヤーとして切り出すことができます。

作成した Lambda 関数は、様々なイベントによって呼び出すことができます。このイベントの発行元のことをイベントソースといいます。

次の図では、いくつかのイベントソースを例に Lambda 関数を呼び出すイメージを表しています。

この図のように、イベントソースによって同期的、非同期的、またはポーリングによって呼び出されるのかが異なります。この図以外のサービスについては、AWS Lambda のドキュメントの「他のサービスで AWS Lambda を使用する」に記載がありますので、興味があればご参照ください。

また、AWS Lambda と他のサービスとを組み合わせたユースケースやパターンについては「形で考えるサーバーレス設計」にまとめられています。さらに「サーバーレスアプリケーション開発におけるエラーハンドリング」ではエラーハンドリングのパターンやベストプラクティスについてもわかりやすく解説されていますので、これらも参考にしてみてください !

次に Lambda 関数のコードについてみてきましょう。AWS Lambda は下記のランタイムをサポートしており、これらのランタイムで実行できるコードを使用して Lambda 関数を作成できます。

• Python
• Node.js
• Java
• .NET
• Ruby
• Go

またカスタムランタイムを作成することで、上記以外のプログラミング言語を使用して Lambda 関数を作成できます。

例として Python で記述した シンプルな Lambda 関数のコードをみてみましょう。

このコードでは lambda_handler という名前の Python の関数が定義されています。これは、この Lambda 関数におけるハンドラーになります。ハンドラーは、Lambda 関数が呼び出された時に最初に実行されるエントリーポイントです。ハンドラーとなる関数名またはメソッド名は、Lambda 関数の設定として指定する必要があります。

ハンドラーとなる関数またはメソッドは、イベントオブジェクトとコンテキストオブジェクトを引数として受け取る形にする必要があります。これらの引数のオブジェクトは、実行時に AWS Lambda により渡され、コードの中で参照できます。

• イベントオブジェクト
  • Lambda 関数に処理させたいデータや、イベントソースから渡されたデータを含んでいます。
  • 例えば、Amazon S3 バケットにオブジェクトが Put されたイベントにより Lambda 関数が実行された場合は、その S3バケット名やオブジェクトのキーなどが含まれます。
• コンテキストオブジェクト
  • ランタイムの環境の情報が含まれています。
  • 例えば Lambda 関数の名前や Amazon リソースネーム (ARN) 、設定されている メモリ容量などが含まれています。

AWS マネジメントコンソールや AWS CLI を用いて、任意のイベントオブジェクトを指定して Lambda 関数を実行できます。上記のサンプルの Lambda 関数に、次の JSON 形式のデータをイベントオブジェクトに指定して実行してみます。

すると、Lambda 関数が次のような結果を戻します。

この結果から、サンプルの Lambda 関数のハンドラーの 2 行目の event['first_name'] や event['last_name'] で イベントオブジェクトからデータを読み取れていることが確認できますね。

ハンドラーのコードを記述する上で、下記の 2 つをおさえておきましょう。

• ハンドラーの実行時間は最長 15 分まで
  • 1 回の呼出しにより 15 分を超えるような処理の場合、AWS Lambda の関数としては適用ができないため、処理を分割するか、もしくは AWS Lambda 以外のサービスをご検討ください。「コンテナとサーバレスの使い分け」の資料も参考になりますので、ご参照ください !
• ハンドラーの関数やメソッド内に全てのコードを記述する必要はない
  • ハンドラーはあくまで Lambda 関数のコードの中で最初に実行する関数またはメソッドであり、その中にすべてのコードを記述する必要はありません。上記のサンプルのように短いコードであれば別ですが、必要に応じてハンドラーから他の関数を呼び出したり、他のオブジェクトのメソッドを呼び出すような設計にしましょう。そうすることで、コードの可読性を向上でき、関数やメソッド単位の単体テストも実施しやすくなります。

では、AWS Lambda において Lambda 関数が実行される仕組みをみていきましょう !

次のアニメーションは、Amazon API Gateway と Lambda 関数 を統合している環境を例に、Lambda 関数が呼び出された時の動きを示したものです。

このアニメーションから、Lambda 関数の実行環境は呼出しに応じて自動的に用意されることがわかりますね。

ただし、Lambda 関数を作成・更新した直後では、まず実行環境が作成され、初期化処理を経てハンドラーが実行されます。このような流れで Lambda 関数が実行されることを、一般的に「コールドスタート」と呼びます。ハンドラーのコードを実行する以外に、実行環境を作成して初期化処理を行う時間が必要になるので、その分のレイテンシーが発生することを把握しておきましょう。

コールドスタートを経て Lambda 関数の実行環境が作成されますが、作成されハンドラーが実行された後も、その実行環境はすぐには削除されず、残っています。次のアニメーションをご覧ください。

このアニメーションのように、実行環境が残っている期間内に再び同じ Lambda 関数を呼び出すと、その環境が再利用されることがあります。再利用された場合は、実行環境も作成済で初期化処理も完了しているので、ハンドラーだけが実行されます。 このような流れで Lambda 関数が実行されることを、一般的に「ウォームスタート」と呼びます。ウォームスタートの場合は、コールドスタートと比較すると実行環境作成や初期化処理は必要ないので、その分処理時間を短縮できます。

コールドスタートとウォームスタートは、「お風呂に最初に入る」か「2 番目以降に入る」かで例えるとわかりやすいかもしれません。お風呂に最初に入る場合は、湯船に湯がためて適温になるまで待つ必要がありますが、 2 番目に入る人はすでに湯船に適温のお湯があるので、待たずにそのまま入れますよね。

さて、実行環境は最終的にどうなるのでしょう ? 次のアニメーションをご覧ください。

実行環境を使わない状況が続くと、いずれ AWS Lambda サービスより不要と判断され、シャットダウン処理を経て自動的に実行環境が削除されます。その後、再び呼び出されるとコールドスタートを経て実行環境が作成される、というライフサイクルを繰り返します。

次に同じ Lambda 関数で複数の呼び出しが発生した場合の動作をアニメーションでみてみましょう。

このアニメーションが示しているように、AWS Lambda は Lambda 関数の呼び出し数や、現在使用中の実行環境の数に応じて、自動的に実行環境の数を増やします。

ただし、すでにコールドスタートを経て実行環境が複数残っている場合、同じクライアントが再び 同じ Lambda 関数を呼び出したとしても、前回と同じ実行環境が使用されるとは限りません。次のアニメーションをみてみましょう。

よって、Lambda 関数の実行環境内にセッションデータ (特定のクライアントの固有データ) を保存するべきではありません。つまり、Lambda 関数のコードはステートレスにする必要があることを理解しておきましょう !

さて、これまでの説明で Lambda 関数の実行環境は自動的にスケーリングすることを、ご理解いただけたと思います。ただ、Lambda 関数の実行環境は無制限にスケールアウトで増やせるわけではありません。

AWS Lambda では サービスの制限値として、その AWS アカウントで同時に実行環境を作成できる数がリージョン毎に決められています。これは、AWS Service Quotas というサービスから AWS Lambda の Concurrent executions の値で確認できます。

これはリージョン単位の値なので、例えば 東京リージョンに Lambda 関数を A, B, C と 3 つ作成した場合、その A, B, C の合計の同時実行数が 1,000 までということになります。

また、Lambda 関数単位で同時に作成できる実行環境数を設定できます。この設定は「予約済同時実行数」または「Reserved Concurrency」と呼ばれます。次のアニメーションをみてみましょう。

このアニメーションで示しているように、1 つの Lambda 関数に対して同時に多くのリクエストが発生し、設定した予約済同時実行数を超える場合は、超えた分はエラー (ステータスコード: 429 エラーコード： TooManyRequestsException) になります。この状態をスロットリングといいます。極端な例として、予約済同時実行数に 0 を設定すると、その Lambda 関数はいくらリクエストがきても、一切実行されないということになります。

また、東京リージョンの同時実行数がデフォルト 1,000 なので、例えば Lambda 関数 X の予約済同時実行数もそれに合わせて 1,000 にしておく、ということもできません。リージョン内のすべての Lambda 関数の予約済同時実行数の合計は、最大でリージョンの同時実行数 -100 の値までしか設定できません。つまり東京リージョンでいうとすべての Lambda 関数の予約済同時実行数の合計は 900 までしか設定できないので、注意しておきましょう。