AWSは、 Lambda関数をVirtual Private Cloud（VPC）内のリソースに接続する方法を変更すると発表した。この変更 — 関数の実行毎にネットワークインターフェースを生成するのではなく、事前に生成されたネットワークインターフェースを使用する — によって、サーバレス関数の"コールドスタート"の主要要因が排除される。
この変更は、IOpipeのAustin Huminski氏が"VPCを多用する企業間におけるサーバーレス導入の変曲点"と呼ぶものだろうか？事実として、AWS Lambdaのユーザは2016年以降、VPC内で動作するサーバやサービスに接続することが可能だった。AWS Lambdaのコンピューティングインフラストラクチャは、そのすべてがAWSが所有するVPCで実行されるため、カスタマVPCへの接続は従来、エラスティックネットワークインターフェイスを介して行われてきた。ここで使用するエラスティックネットワークインターフェイスは、各実行環境のカスタマVPC内に生成されるものだった。Lambda関数のコードは、これらのネットワークインターフェイスが生成され、接続が確立されるまでは実行できなかったのだ。AWSがこの図で示したように、関数がスケールアップするにつれて、より多くの実行環境が、より多くのネットワークインターフェイスを必要とするようになっていた。
今回発表されたAWS Lambdaのアップデートによって、 AWSのブログ記事に説明されているように、接続アーキテクチャがより単純なものになる。
本日より、関数をVPCに接続する方法を変更します。 ネットワークロードバランサとNATゲートウェイが使用するネットワーク機能の仮想化プラットフォームであるAWS Hyperplaneは、AWS PrivateLinkなどのサービスにおいてVPC間接続をサポートしてきました。今回の更新では、Lambda関数からカスタマVPCへのNAT機能の提供に、このHyperplaneを活用しています。
AWSのこのイメージに示されているように、カスタマVPCサブネットへのネットワークインターフェイスは、AWS Lambda実行環境間で共有されるようになる。
AWSによると、共有ネットワークインターフェイスのワンタイムセットアップは、完了まで90秒程度を必要とする。しかし、ネットワークインターフェースが生成されるのは、Lamda関数が最初に生成された時か、あるいはVPC設定がアップデートされた時であるため、コールドスタート時の接続関連のレイテンシはゼロに近づくことになる。同じことが関数のスケーリングにも当てはまり、新しい実行環境毎に新たなネットワークインターフェースを用意する必要はなくなるのだ。AmazonのChris Munns氏は先頃、このVPCネットワーキング変更がデプロイされた後に、遅延が顕著に低下することを表したグラフをツイートした。
余談だが、"コールドスタート"の質問は、多くのワークロードにおいてサーバーレス機能が適さない理由として、しばしば持ち上がっている。関数が呼び出されてからコードが実際に実行されるまでの遅延の要因は何だろう？AmazonのTim Bray氏は、コールドスタートの遅延は多くの場所から生じている、と指摘する。
関数を起動するのに要する時間は、関数を最後に起動したのがどれだけ最近かに依存しています。比較的最近に実行した場合は、おそらくホストにロードされて実行準備ができているので、イベントを適切な場所にルーティングするだけです。そうでない場合は、空いているホストを見つけて、ストレージ内の関数を見つけて引き出し、インストールした上で起動する必要があります。
関数が"起動"されると、次には言語固有の初期化があり、コードのコンパイルやVMの起動などが必要となる場合もある、とBray氏は言う。その上で、状態のロードや依存サービスへの接続など、関数が実行するさまざまな処理が存在するのだ。いずれにしても、コールドスタート時間をプログラム言語毎に比較したこの比較資料を見る限り、AWSは、コールドスタート時間の削減に向けて、Lambdaのチューニングを着実に前進させているようだ。
当然ではあるが、VPCを実行せずにAWS Lambdaを使用することも可能で、そうしているユーザもある。Lambda関数はデフォルトで、多数のAWSサービスを含む、公開インターネット上で利用可能な任意のサービスにアクセスすることができるのだ。しかしながら、最近のAWSは、従来のワークロードの多くをVPCに移行するよう、ユーザに働きかけている。Amazon EC2仮想マシンは、デフォルトではVPC内で実行される。リレーショナルデータベースサービスのAmazon RDS、データウェアハウスのRedshift 、Paas的環境であるElastic Beanstalkも同様だ。IOpipeのHuminski氏は、VPCモデルはクラウドを採用する企業には馴染みがあるので、AWS Lambdaのような最新のランタイムにも適しているようだ、と述べている。
プライベートデータセンタから移行している、あるいはハイブリッドインフラストラクチャを運用している企業や組織にとっては、VPCは難しいものではないでしょう。ITでは一般的な、有刺鉄線で守られた従来型の独立したサーバ環境のような外見、匂い、味を持っているからです。
...
今回の変更によって、Lambda関数をVPCに接続しやすくなりますが、VPCの側では、基本的なアーキテクチャは変わっていません。
この機能は段階的に世界展開されており、 数週間以内に展開が完了する見込みである。AWSは、今回の変更を説明するためにドキュメントを更新して、機能のアップグレードに関連する費用発生のないことを公開している。AWSによると、VPC外部のエンドポイントへの接続にIAMのアクセス許可設定とNATゲートウェイが必要であることなど、VPC接続の多くの面は従来と同じである。