[発表] Lambda 関数が VPC 環境で改善されます

本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。

元の投稿からの更新情報：

• 2019年11月28日（PST）：  次のリージョンに対して、元の投稿に記載されている改善を完全に展開しました：中東（バーレーン）。
• 2019年11月25日（PST）：次のリージョン、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中央）、EU（ロンドン）、EU（ストックホルム）、およびアジア太平洋（香港）に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。
• 2019年11月6日（PST）：次のリージョン、米国西部（北カリフォルニア）、EU（アイルランド）、EU（パリ）、アジア太平洋（ムンバイ）、アジア太平洋（ソウル）、アジア太平洋（シンガポール）、アジア太平洋（シドニー）、南アメリカ（サンパウロ）に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。
• 2019年9月27日（PST）：米国東部（オハイオ）、欧州（フランクフルト）、およびアジア太平洋（東京）の地域へ完全に展開しました。これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。
• 既知の問題（2019年10月4日（PST）に更新）： HashiCorp Terraformを使用している場合、サブネット、セキュリティグループ、VPCなどのVPCリソースは、この新しいモデルでのENIの動作方法の変更により破棄に失敗する可能性があります。この問題を解決するための手順と、詳細についてはこちらをご覧ください。

2019年9月3日（PST）の元の投稿：

AWS Lambda 関数が Amazon VPC ネットワークでどのように機能するかが大幅に改善されたことをお知らせします。 2019年9月3日（PST）のローンチ機能により、関数の起動パフォーマンスが劇的に改善され、Elastic Network Interface がより効率的に使用されるようになります。 これらの改善は、すべての既存および新しい VPC 接続の関数に追加費用なしで展開されています。 ロールアウトは 2019年9月3日（PST）から始まり、すべてのリージョンで今後数か月にわたって徐々に展開されます。

Lambda は2016年2月に初めて VPC をサポートし、AWS Direct Connect リンクを使用して VPC またはオンプレミスシステムのリソースにアクセスできるようになりました。 それ以来、お客様が VPC 接続を広く使用して、さまざまなサービスにアクセスしているのを見てきました。

• Amazon RDS などのリレーショナルデータベース
• Redis 用 Amazon ElastiCache または Amazon Elasticsearch Service などのデータストア
• Amazon EC2 または Amazon ECS で実行されているその他のサービス

2019年9月3日（PST）のリリース機能により、LambdaとVPC 間のこの接続性が強化されます。

AWS Lambda がこれまで Amazon VPC と統合していた方法について

これまでの統合方法は、Lambda を使用したネットワークの仕組みの基本を理解するのに役立ちます。2019年9月3日（PST）現在、Lambda のすべてのコンピューティングインフラストラクチャは、サービスが所有する VPC 内で実行されます。

呼び出し元から任意の実行モデル（同期、非同期、またはポーリングベース）で Lambda 関数を呼び出す場合、Lambda API を介して実行されます。関数が実行される実行環境への直接的なネットワークアクセスはありません。

VPC の選択が関数に設定されていない場合、他の AWS サービス、API の HTTPS エンドポイント、またはインターネット上の AWS の外部のサービスとエンドポイントなど、パブリックインターネットで利用可能なものにはアクセスできます。ただし、関数はユーザーが所有する VPC 内のプライベートリソースに接続できません。

ユーザーが所有する VPC（カスタマー VPC）に接続するように Lambda 関数を設定すると、カスタマー VPC 内に Elastic Network Interfaces（ENI）が作成され、クロスアカウント接続が行われます。これらのENI は、Lambda 関数からプライベートリソースへのネットワークアクセスを許可します。これらの Lambda 関数は引き続き Lambda サービスの VPC 内で実行され、カスタマー VPC を介したネットワーク経由のリソースのみに現在アクセスできます。関数のすべての呼び出しは引き続き Lambda API から行われ、これまでと同様に実行環境に直接ネットワークアクセスすることはできません。アタッチされた ENI はユーザーアカウント内に存在し、そのリージョンのアカウントに存在する制限にカウントされます。

このモデルでは、多くの課題に直面する恐れがありました。新しい ENI を作成してアタッチするのにかかる時間は、より長いコールドスタートを引き起こす恐れがあります。これは基本的にはコードを呼び出す前に新しい実行環境を起動するのにかかる時間です。関数の実行環境がスケールしてリクエストの増加に対応するにつれて、より多くの ENI が作成され、Lambda インフラストラクチャにアタッチされます。関数設定や同時実行性は、実際に作成およびアタッチされる ENI 数の因数となり、実行環境間で共有されます。

関数用に作成されたすべてのネットワークインターフェースは、VPC サブネットに関連付けられ、IP アドレスを消費します。 ネットワークインターフェイスのアカウントレベルの上限に対してカウントされます。

関数がスケールするにつれて、いくつかの問題に注意する必要があります。

• サブネット内の IP アドレス空間の管理
• アカウントレベルのネットワークインターフェイスの制限に達すること
• 新規ネットワークインターフェイス作成の API レート制限に達する可能性

何が変更されるか

2019年9月3日（PST）より展開される機能によって、関数が VPC に接続する方法が変更されます。 ネットワークロードバランサーと NAT ゲートウェイに使用される Network Function Virtualization プラットフォームである AWS Hyperplaneは、AWS PrivateLink などの製品の VPC 間接続をサポートしており、Hyperplane を活用して Lambda VPC からカスタマー VPC に NAT 機能を提供しています。

Hyperplane ENI は、Lambda サービスが制御する管理ネットワークリソースであり、複数の実行環境がアカウントの VPC 内のリソースに安全にアクセスできるようにします。 VPC のネットワークインターフェースを Lambda 実行環境に直接マッピングする以前のソリューションの代わりに、VPC のネットワークインターフェースは Hyperplane ENI にマッピングされ、関数はそれを使用して接続します。

Hyperplane は引き続き、VPC に存在するクロスアカウント接続ネットワークインターフェースを使用しますが、大幅に改善された方法となります。

• ネットワークインターフェースの作成は、Lambda 関数が作成されるか、VPC 設定が更新されるときに発生します。 関数が呼び出されると、実行環境は事前に作成されたネットワークインターフェイスを使用するだけで、そこへのネットワークトンネルをすばやく確立します。 これにより、コールドスタートでのネットワークインターフェイスの作成と接続にこれまで発生していた遅延が劇的に削減されます。
• ネットワークインターフェイスは実行環境全体で共有されるため、通常、関数ごとに必要なネットワークインターフェイスはほんの少数です。 アカウント内の関数にまたがるすべての一意のセキュリティグループ：サブネットの組み合わせには、個別のネットワークインターフェイスが必要です。 組み合わせがアカウント内の複数の関数で共有されている場合、関数間で同じネットワークインターフェイスを再利用します。
• 関数のスケーリングは、ネットワークインターフェースの数に直接関係しなくなり、Hyperplane ENI は、多数の同時関数実行をサポートするようにスケールできます

Hyperplane ENI は、アカウントのセキュリティグループとサブネットの組み合わせに関連付けられています。 同じセキュリティグループを共有する同じアカウントの関数：サブネットのペアは同じネットワークインターフェイスを使用します。 このように、複数の関数を利用する単一のアプリケーションが同じネットワークおよびセキュリティ構成を備えている場合、すでに存在するインターフェース構成の恩恵を享受できます。

この新しいモデルでも、以下の事柄には変更はありません。

• Lambda 関数には、カスタマー VPC 内の ENI 作成および削除に必要な IAM アクセス許可が引き続き必要です。
• これらのネットワークインターフェイスのサブネットとセキュリティグループの構成は引き続き、お客様が制御できます。 通常のネットワークセキュリティ制御を継続して適用し、VPC 設定のベストプラクティスに従うことができます。
• 関数に対してインターネットアクセスを提供するには、NAT デバイス（VPC NAT Gateway など）を使用したり、 VPC 外部のサービスに接続するには、VPC エンドポイントを使用する必要があります。
• 関数がVPC内部でアクセスできるリソースの種類については何も変わりません

前述のように、Hyperplane は、Lambda 関数が最初に作成されたとき、または VPC 設定が更新されたときに共有ネットワークインターフェイスを作成するようになり、関数のセットアップパフォーマンスとスケーラビリティが向上します。 この1回限りのセットアップは、完了するまでに最大 90 秒かかる場合があります。 共有ネットワークインターフェイスの作成中に Lambda 関数を呼び出すと、呼び出しは成功しますが、コールドスタート時間が長くなる場合があります。 セットアップが完了すると、Lambda 関数は呼び出し時にネットワークインターフェイスを作成する必要がなくなります。 アカウント内のLambda 関数が連続してアイドル状態になると、サービスは未使用の Hyperplane リソースを再利用するため、呼び出される頻度が非常に低い関数でもコールドスタート時間が長くなる可能性があります。

前に述べたように、この新しい機能を自分で有効にする必要はありません。また、関連する新しい費用もありません。 2019年9月3日（PST）から、今後数か月にわたってすべての AWS リージョンでこれを徐々に展開していきます。 特定のリージョンでの展開が完了した後、リージョンごとにこの投稿を更新します。

既存のVPCで構成された Lambda ワークロードがある場合、アプリケーションがすぐにスケールし、新しい呼び出しにすばやく応答することがわかります。 AWS X-Ray や APN Partners のような Lambda のモニタリングおよびプロファイリングツールを使用して、この変更を確認できます。

以下は、AWS X-Ray での改善前後のスクリーンショットになります。

１枚目の画像は、改善前に VPC 設定で起動された関数を示しており、呼び出し時にネットワークインターフェースを作成する完全なコールドスタートが確認できます。

この2枚目の画像では、同じ関数が実行されていますが、今回は新しい VPC ネットワーク性能を持つアカウントで実行されています。 これにより関数の起動時間に大きな違いが見られ、14.8 秒から 933ミリ秒に低下しています。

まとめ

AWS Lambda チームでは、「シンプルさ」を、お客様向けのサービスの構築においてどのように考えるかということを、中核となる理念と考えています。 Lambda を使用してサーバーレスアプリケーションを構築する際のエクスペリエンスを改善および簡素化する方法を常に求めています。 VPC との接続方法におけるこれらの変更により、Lambda 関数のパフォーマンスとスケーラビリティが向上し、サーバーレスアーキテクチャのフルパワーを活用できるようになります。