Lambda の仕組み

Lambda 関数は、Lambda アプリケーションの構築に使用する基本的な構成要素です。関数を記述するには、Lambda プログラミングモデルを構成する主要な概念とコンポーネントを理解することが不可欠です。このセクションでは、Lambda を使用してサーバーレスアプリケーションの構築を開始するために必要な基本的な要素について説明します。

Lambda 関数と関数ハンドラー

Lambda では、関数はアプリケーションの作成に使用する基本的な構成要素です。Lambda 関数は、ユーザーがウェブサイトのボタンをクリックしたり、Amazon Simple Storage Service (Amazon S3) バケットにファイルがアップロードされたりなど、イベントに応答して実行されるコードです。関数は、次のプロパティを持つ自己完結型プログラムの一種として考えることができます。Lambda 関数ハンドラーは、イベントを処理する関数コード内のメソッドです。イベントに応答して関数が実行されると、Lambda は関数ハンドラーを実行します。関数の実行の原因となったイベントに関するデータは、ハンドラーに直接渡されます。Lambda 関数のコードには複数のメソッドまたは関数を含めることができますが、Lambda 関数には 1 つのハンドラーしか含めることができません。

Lambda 関数を作成するには、関数コードおよびその依存関係をデプロイパッケージにバンドルします。Lambda は、.zip ファイルアーカイブとコンテナイメージの 2 種類のデプロイパッケージをサポートします。

Lambda 実行環境とランタイム

Lambda 関数は、安全で隔離された実行環境内で実行されます。Lambda により、ユーザーに代わってこれが管理されます。この実行環境では、関数の実行に必要なプロセスおよびリソースが管理されます。関数が最初に呼び出されると、Lambda は関数を実行するために新しい実行環境を作成します。関数の実行が完了すると、Lambda は実行環境をすぐに停止しません。関数が再度呼び出された場合、Lambda は既存の実行環境を再利用できます。

Lambda 実行環境には、ランタイムも含まれています。このランタイムは、Lambda と関数の間でイベント情報やレスポンスを中継する言語固有の環境です。Lambda は、最も人気のあるプログラミング言語向けに多数のマネージドランタイムを提供します。または、ユーザー独自のランタイムを作成することもできます。

マネージドランタイムの場合、Lambda はランタイムを使用する関数にセキュリティ更新プログラムおよびパッチを自動的に適用します。

イベントとトリガー

Lambda コンソール、AWS CLI、AWS Software Development Kit (SDK) のいずれかを使用し、Lambda 関数を直接呼び出すこともできます。本番稼働用アプリケーションでは、特定のイベントに応じて、関数が別の AWS のサービス によって呼び出されるのが一般的です。例えば、項目が Amazon DynamoDB テーブルに追加されるたびに関数を実行する必要があるとします。

関数がイベントに応答するようにするには、トリガーを設定します。トリガーは関数をイベントソースに接続します。関数には複数のトリガーを設定できます。イベントが発生すると、Lambda は JSON ドキュメント形式のイベントデータを受信し、コードが処理できるオブジェクトに変換します。イベントに次の JSON 形式を定義すると、Lambda ランタイムはこの JSON ドキュメントをオブジェクトに変換してから関数のハンドラに渡します。

{
  "Location": "SEA",
  "WeatherData":{
    "TemperaturesF":{
      "MinTempF": 22,
      "MaxTempF": 78
    },
    "PressuresHPa":{
      "MinPressureHPa": 1015,
      "MaxPressureHPa": 1027
    }
  }
}

Amazon Kinesis や Amazon SQS などのストリームおよびキューサービスでは、Lambda は標準トリガーの代わりにイベントソースマッピングを使用します。イベントソースマッピングは、ソースをポーリングして新しいデータを検索し、レコードをまとめてバッチ処理し、バッチイベントで関数を呼び出します。

トリガーの仕組みを理解するには、Amazon S3 トリガーの使用に関するチュートリアルから始めるか、トリガーの使用に関する一般的な概要と Lambda コンソールを使用したトリガーの作成手順を「他のサービスの統合」で確認してください。

Lambda のアクセス許可とロール

Lambda の場合、設定する必要があるアクセス許可には 2 つの主なタイプがあります。

次のセクションでは、これらのアクセス許可タイプの両方について説明し、最小特権のアクセス許可を適用するためのベストプラクティスについて説明します。

関数がその他の AWS リソースにアクセスするためのアクセス許可

多くの場合、Lambda 関数はその他の AWS リソースにアクセスし、アクションを実行する必要があります。例えば、関数は DynamoDB テーブルから項目を読み取ったり、オブジェクトを S3 バケットに保存したり、Amazon SQS キューに書き込んだりすることがあります。これらのアクションを実行するために関数に必要なアクセス許可を付与するには、実行ロールを使用します。

Lambda 実行ロールは特別な種類の AWS Identity and Access Management (IAM) ロールのであり、ポリシーで定義された特定のアクセス許可が関連付けられているアカウントで作成する ID です。

すべての Lambda 関数には実行ロールが必要であり、1 つのロールが複数の関数によって使用できます。関数が呼び出されると、Lambda は関数の実行ロールを引き受け、ロールのポリシーで定義されたアクションを実行するアクセス許可が付与されます。

Lambda コンソールで関数を作成するとき、Lambda は関数に対して自動的に実行ロールを作成します。ロールのポリシーは、Amazon CloudWatch Logs にログ出力を書き込むために、関数に基本的なアクセス許可を付与します。その他の AWS リソースにアクションを実行するためのアクセス許可を関数に付与するには、ロールを編集して追加のアクセス許可を追加する必要があります。アクセス許可を追加する最も簡単な方法は、AWS マネージドポリシーを使用することです。マネージドポリシーは AWS によって作成および管理され、多くの一般的なユースケースにアクセス許可を付与します。例えば、関数が DynamoDB テーブルに CRUD オペレーションを実行する場合、AmazonDynamoDBFullAccess ポリシーをロールに追加できます。

他のユーザーとリソースが関数にアクセスするためのアクセス許可

Lambda 関数にアクセスするために他の AWS のサービスアクセス許可を付与するには、リソースベースのポリシーを使用します。IAM では、リソースベースのポリシーがリソース (この場合は Lambda 関数) にアタッチされ、リソースにアクセスできるユーザーおよび許可されるアクションを定義します。

別の AWS のサービスがトリガーを介して関数を呼び出すには、関数のリソースベースのポリシーが、そのサービスに lambda:InvokeFunction アクションを使用するためのアクセス許可を付与する必要があります。コンソールを使用してトリガーを作成した場合、Lambda はユーザーに代わってこのアクセス許可を自動的に追加します。

他の AWS ユーザーに関数へのアクセス許可を付与するには、別の AWS のサービスまたはリソースの場合とまったく同じ方法で、関数のリソースベースのポリシーでこれを定義できます。ユーザーに関連付けられている ID ベースのポリシーを使用することもできます。

Lambda のアクセス許可のベストプラクティス

IAM ポリシーを使用してアクセス許可を設定する際、タスクの実行に必要なアクセス許可のみを付与することがセキュリティ上のベストプラクティスです。これは最小特権の原則と呼ばれます。関数にアクセス許可の付与を開始するには、AWS マネージドポリシーの使用を選択できます。マネージドポリシーは、タスクを実行するためにアクセス許可を付与するうえで最も迅速で簡単な方法ですが、不要なアクセス許可が他にも含まれる場合もあります。初期の開発からテストおよび本番稼働に移行する際は、独自のカスタマー管理ポリシーを定義することで、必要なアクセス許可のみに減らすことをお勧めします。

リソースベースのポリシーを使用し、関数にアクセスするためのアクセス許可を付与するときにも、同じ原則が適用されます。例えば、関数を呼び出すアクセス許可を Amazon S3 に付与する場合、S3 サービスに一括のアクセス許可を付与するのではなく、個々のバケットまたは特定の AWS アカウントのバケットへのアクセスを制限することが、ベストプラクティスです。