Lambda の実行
Lambda がユーザーに代わって関数を実行する際、コードの実行に必要となる基盤のシステムのプロビジョニングと設定の両方が Lambda によって管理されます。これにより、デベロッパーは基盤となるシステムの管理ではなく、ビジネスロジックやコードの記述に集中できます。
Lambda サービスはコントロールプレーンとデータプレーンに分割されています。各プレーンは、サービスで別々の役割を果たします。コントロールプレーンは、管理 API (CreateFunction、UpdateFunctionCode、PublishLayerVersion など) を提供し、すべての AWS のサービスとの統合を管理します。Lambda のコントロールプレーンへの通信は、転送中に TLS により保護されます。Lambda のコントロールプレーンに保存されるすべての顧客データは、不正な開示や改ざんから保護するために設計された AWS KMS を使用して、保存時に暗号化されます。
データプレーンは、Lambda 関数の呼び出しをトリガーする Lambda の Invoke API です。Lambda 関数が呼び出されると、データプレーンは AWS Lambda ワーカー (または単に Amazon EC2
Lambda 実行環境
各呼び出しは、Lambda の Invoke サービスによって、リクエストを処理できるワーカー上の実行環境にルーティングされます。お客様やその他のユーザーは、実行環境とのインバウンドネットワーク通信またはイングレスネットワーク通信をデータプレーン経由以外で直接開始することはできません。これにより、実行環境への通信が確実に認証および承認されます。
実行環境は特定の関数バージョン向けに予約されており、関数バージョン、関数、または AWS アカウント間で再利用することはできません。つまり、2 つの異なるバージョンを持つ関数には、少なくとも 2 つの一意の実行環境が生成されることになります。
各実行環境は、一度に 1 つの同時呼び出しに対してのみ使用できます。パフォーマンス上の理由から、同じ関数バージョンの複数の呼び出し間で再利用できます。さまざまな要因 (呼び出し速度、関数設定など) により、特定の関数バージョンに対して複数の実行環境が存在する場合もあります。このアプローチを採用すると、Lambda は関数のバージョンレベルを分離することができます。
Lambda は現在、関数バージョンの実行環境内での呼び出しを分離していません。つまり、ある呼び出しにより、次の呼び出し (/tmp に書き込まれたファイルやメモリ内のデータなど) に影響を与える可能性のある状態が残される場合があります。ある呼び出しにより、別の呼び出しに影響を与えることを避けるには、Lambda では追加の個別の関数を作成することをお勧めします。たとえば、エラーが発生する可能性が高い複雑な解析操作向けに個別の関数を作成したり、セキュリティに関する操作を実行しない関数を再利用したりすることができます。Lambda では現在、お客様が作成できる関数の数に制限はありません。制限の詳細については、「Lambda のクォータ」のページを参照してください。
実行環境は Lambda によって継続的にモニタリングおよび管理されていますが、次のようなさまざまな理由で作成または破棄される可能性があります。
-
新しい呼び出しが到着しても、適切な実行環境が存在しない場合
-
内部ランタイムまたはワーカーソフトウェアのデプロイがあった場合
-
プロビジョニングされた同時実行数の設定が新しく公開された場合
-
実行環境またはワーカーのリース時間がライフタイムの上限に近づいているか、ライフタイムの上限を超えている場合
-
その他の内部ワークロード再分散プロセス
関数設定にプロビジョニングされた同時実行数を設定すると、関数バージョンに存在する事前プロビジョニングされた実行環境の数を管理できます。この設定を行うと、Lambda は設定された数の実行環境を作成、管理し、その存在を常に確認します。これにより、規模を問わず、サーバーレスアプリケーションスタートアップ時のパフォーマンスを確実により詳細に制御できます。
呼び出しに応じて Lambda によって作成または管理される実行環境の数を確実に制御する方法は、プロビジョニングされた同時実行数を設定する以外にはありません。
実行ロール
それぞれの Lambda 関数には実行ロールを設定する必要があります。実行ロールとは、関数に関するコントロールプレーンおよびデータプレーンのオペレーションを実行する際に Lambda サービスが引き受ける IAM ロールです。Lambda サービスはこのロールを引き受け、一時的なセキュリティ認証情報をフェッチします。この認証情報は、関数の呼び出し中に環境変数として使用できます。Lambda サービスは、パフォーマンス上の理由で、この認証情報をキャッシュし、同じ実行ロールを使用する異なる実行環境で再利用する場合があります。
最小特権の原則を確実に遵守するため、Lambda では、各関数が固有のロールを持ち、必要最小限のアクセス権限のセットで設定を行うことをお勧めします。
Lambda サービスは、VPC 関数用の Elastic Network Interface (ENI) の作成と設定、Amazon CloudWatch Application Insights
このトピックの詳細については、「AWS Lambda 実行ロール」のドキュメントページを参照してください。
Lambda MicroVM とワーカー
Lambda は、AWS Lambda ワーカーと呼ばれる Amazon EC2 インスタンスのフリートに実行環境を作成します。ワーカーとはベアメタル
責任共有モデルの一環として、ワーカーのセキュリティ設定、コントロール、パッチ適用レベルを維持する責任は Lambda が担います。Lambda チームは、Amazon Inspector
図 3 – AWS Lambda ワーカーの分離モデル
ワーカーの最大リース有効期間は 14 時間です。ワーカーのリース有効期間の終わりに近づくと、それ以降は呼び出しのルーティングが行われず、MVM は正常終了され、基盤となるワーカーインスタンスは終了します。Lambda は、フリートのライフサイクルアクティビティを継続的にモニタリングし、アラームを発します。
ワーカーへのすべてのデータプレーン通信は、ガロア/カウンターモードによる高度暗号化標準 (AES-GCM) を使用して暗号化されます。ワーカーは、Lambda のサービスアカウントで Lambda が管理する、ネットワーク分離された Amazon VPC でホストされているため、データプレーンオペレーション以外の手段ではワーカーを直接操作することはできません。
ワーカーが新しい実行環境を作成する必要がある場合、ワーカーにはお客様の関数アーティファクトにアクセスするための期限付きの権限が付与されます。これらのアーティファクトは、Lambda の実行環境とワーカー向けに最適化されています。ZIP 形式を使用してアップロードされた関数コードは一度最適化され、AWS が管理するキーと AES-GCM を使用して暗号化された形式で保存されます。
コンテナイメージ形式を使用して Lambda にアップロードされた関数も最適化されます。コンテナイメージは、まず元のソースからダウンロードされ、個別のチャンクに最適化された後、AES-CTR
