主要なクラウドプロバイダーは引き続きサーバーレスの採用を積極推進

過去 1 年間で、Azure と Google Cloud 上でシステムを稼働する組織のサーバーレス採用率はそれぞれ 6% と 7% 増加し、AWS の増加率は 3% でした。AWS の顧客の 70% 以上、Google Cloud の顧客の 60% が現在 1つ以上のサーバーレスソリューションを利用しており、Azure は 49% で僅かに劣っています。

今年のレポートでは、2 つの新しいサーバーレスプラットフォーム、Azure Container Apps と AWS CloudFront Functions をデータに含めました。FaaS ソリューションは引き続きサーバーレス全体の人気を牽引している一方で、クラウドプロバイダーは顧客のニーズをより満たすためにサーバーレスツールのスイートを拡張していることがわかります。クラウドプロバイダーが既存のソリューションを改善し、サーバーレスコンテナやサーバーレスエッジコンピューティングなど、より新しい広範なサービスを提供するにつれて、より多くの企業がこれらのツールを利用して顧客に価値を提供できるようになっています。

注: この実証の目的のため、サーバーレスを採用している組織は以下のテクノロジーの少なくとも 1 つを使用しています。

• AWS: AWS Lambda、AWS App Runner、ECS Fargate、EKS Fargate、AWS CloudFront Functions
• Azure: Azure Functions、Azure Container Apps、Azure Container Instances
• Google Cloud: Google Cloud Functions、Google App Engine-Flex、Google Cloud Run

フルマネージド型コンテナベースのサーバーレス導入では Google Cloud がリード

Datadog の 2022 年の報告では、AWS Lambda、Google Cloud Functions、Azure Functions など、ランタイムが管理された従来型の関数に比べて、各企業はコンテナとしてパッケージ化された関数や、フルマネージド型のコンテナベースアプリケーションプラットフォームといったサーバーレス技術の利用を拡大していることが示されています。

この傾向は、主要な 3 つのクラウドすべてで続いています。特に Google Cloud では、サーバーレスを採用する組織の 66% がコンテナベースのサーバーレスワークロード (Cloud Run や第 2 世代の Cloud Functions など) を利用しています。

2019 年の Cloud Run のローンチ以来、Google Cloud はこのカテゴリーでリードしてきましたが、今年はコンテナ化された Lambda 関数と AWS App Runner を搭載したフルマネージド型のコンテナワークロードを実行しているサーバーレス組織が増加し、AWS のシェアが 26% に増加しました。この数値は昨年の約 20% から上昇し、Azure は 22% で僅かに劣っています。当初は割合が少なかったとはいえ、2022 年 5 月の Azure Container Apps のリリースにより、Azure のコンテナベースのワークロード採用率は前年比 76% と著しい伸びを見せています。

コンテナベースのサーバーレスコンピューティングプラットフォームの人気が高まっている一因は、サーバーレスの導入と移行を簡素化できるためだとされています。例えば、組織は既存のコンテナイメージをクラウドプロバイダーがホストするレジストリにアップロードし、それらのコンテナをマイクロサービスとしてシームレスにデプロイすることができます。また、サーバーレスコンテナ製品は、サーバーレス関数と比較して、幅広い言語と大規模なアプリケーションサイズをサポートしており、ワークロードの移行をさらに促進しています。

新興サーバーレスプラットフォームの主要カテゴリーはフロントエンド開発

今日のサーバーレスコンピューティング界においては、AWS、Google Cloud、Azure といった主要なクラウドプロバイダーの他にも、多くのプレーヤーが存在しています。例えば、Vercel、Netlify、Cloudflare、Fastly などの最新のフロントエンド開発およびコンテンツデリバリネットワーク (CDN) プラットフォームは、コアプラットフォームと緊密に統合されたサーバーレスコンピューティング機能を開発者に提供しています。主要なクラウドでサーバーレスワークロードをモニタリングしている全組織の 7% は、これらの新興クラウドプラットフォームの少なくとも 1 つを使用してワークロードを実行しています。このうち 62% が Vercel や Netlify のようなフロントエンド開発プラットフォームを利用しており、39% が Cloudflare や Fastly のようなエッジコンピューティング製品を利用しています。

Vercel Functions や Netlify Functions のようなプラットフォームを活用することで、フロントエンド開発者はクラウドからアプリケーション全体を簡単に作成・実行できます。これにより、フルスタックプロジェクトや開発をより多くの人が利用できるようになります。一方、Cloudflare Workers や Fastly Compute@Edge のような分散型エッジプラットフォームは、開発者が既存の CDN プロバイダーと緊密に統合された形で、エンドユーザーに近いサーバーレスアプリケーションを構築することを可能にします。

Cloudflare や Vercel などのプラットフォームは、フロントエンド開発とフルスタック開発のためのエッジコンピューティングを取り入れるよう進化してきました。例えば、Cloudflare は Workers を利用してフルスタックアプリケーションを構築できるよう、Pages やその他のツールを提供しています。また、Vercel でアプリをデプロイする際、開発者は同社のエッジネットワークを利用することができます。全体として、主要なクラウドプロバイダー以外の CDN とフロントエンド開発プラットフォームの進化は、組織が高いパフォーマンスのエンドユーザーエクスペリエンスを提供するための代替オプションを採用していることを示唆しています。

Node.js と Python は依然として AWS Lambda 関数の主要言語

Python と Node.js は、AWS Lambda 開発者の間で今でも最もよく使われている言語であり、実際には、Lambda データセットにおける呼び出しの半分以上が、Python または Node.js で書かれた関数によって行われています。Lambda が最も早くサポートした 2 つの言語のうちの 1 つであることに加え、どちらの言語も Lambda のための堅牢なツールと大規模な開発者コミュニティを提供しています。そのため、組織がサーバーレスシステムを初めて導入する際には、Python と Node.js を利用する傾向があります。

Datadog の調査によれば、Java は Lambda 言語の中で 3 番目に人気で、カスタムランタイムと Go がほんの少し後れて続いています。これらの合計は、当社の顧客による Lambda 呼び出し全体の約 4 分の 1 を占めています。Java が 3 番目に人気のある Lambda 言語である理由は、大企業が Java で書かれた既存のワークロードやアプリケーションを Lambda に移行していることが増えているからだと考えられます。

さらに、カスタムランタイムは最も急成長している関数であり、Lambda 関数の呼び出し割合は前年比で 50% 以上増加しています。カスタムランタイムの人気が高まっているのは、サーバーレスコンテナに対する関心が高まっているからでしょう。サーバーレスコンテナは、PHP や Rust など、Lambda がネイティブにサポートしていない言語で関数を記述することを可能にし、サーバーレスの機能を拡張します。

Java での AWS Lambda 関数のコールドスタート時間は、Python や Node.js の 2 倍

コールドスタートとは、サーバーレスのコンピューティングプラットフォームがリクエストに対応するために新しい実行環境を作成しなければならない状況を指し、これは今日のサーバーレス開発者が直面している主要な懸念点のひとつです。Lambda におけるコールドスタートの影響は、関数がどのランタイムで書かれるかによって異なります。例えば、Node.js と Python の関数はコールドスタート時間が最も短く、Java の関数は最も長くなります。Java の平均コールドスタート時間は、Python のそれと比較してほぼ 3 倍であり、これは Java 仮想マシン (JVM) と Java の実行に必要なライブラリのロードに時間がかかるためだと考えられます。

Datadog の調査では、Lambda 関数に割り当てられるメモリ量がランタイムによって異なることも明らかになっています。これは、Lambda 関数に割り当てられるメモリを増やすと、その関数に割り当てられる CPU の量も増え、コールドスタート時間を短縮できるためだと考えられます。Python や Node.js など、コールドスタート時間がすでに最も短いランタイムは、一般的に Java よりも割り当てられるメモリが少ないのが特徴です。AWS は、プロビジョニング済みの同時実行、プロアクティブな初期化、Lambda SnapStart など、開発者がコールドスタートに対処し、サーバーレス関数のパフォーマンスの影響を軽減するためのさまざまなツールを開発しています。

ARM での AWS Lambda 利用が過去 1 年で倍増

2021 年、AWS は ARM ベースの Graviton2 プロセッサでの Lambda 関数サポートを発表し、x86 ベースのプロセッサと比較して、より高速な実行時間と最大 34% のコスト削減を約束しました。Lambda を使用しているサーバーレス組織の中で、ARM を採用している組織の割合は過去 1 年間で倍増し、現在では 11% の組織が何らかの形で ARM を使用して Lambda 関数を呼び出しています。

ARM を採用したこれらの組織では、ARM 対応ランタイムを使う関数の 29% が ARM 上で実行されています。この採用傾向から、これらの組織は、提案されたパフォーマンスとコストの組み合わせによるメリットを享受している可能性が高いと推測されます。

しかし、これらの数字は、さらに多くの適格な関数が ARM に移行される機会がまだあることを示しています。AWS Lambda 関数の多くがまだ ARM に移行していない一因として、Graviton2 がまだすべての AWS リージョンで利用可能ではなく (最新情報はこちら)、Node、Python、Java、.NET、Ruby、カスタムランタイムのサブセットとしか互換性がないことが挙げられます。これらは普遍的に利用できるものではないため、サーバーレスフレームワークや自動化ツールは、まだデフォルトの設定としてこの技術を採用していません。

お客様との対話を基に考察すると、地域とランタイムの利用可能性が増加し、ARM がサーバーレスツールのデフォルト設定になるにつれて、サーバーレスの採用は拡大し続けることが予想されます。

Terraform は大規模組織の間で AWS Lambda のデプロイツールとして人気

Serverless Framework や Terraform のような Infrastructure as code (IaC) ツールは、開発者が手動で Lambda 関数やその他のリソースを大規模にデプロイし設定する課題を克服するのに役立ちます。AWS は IaC プラットフォームである CloudFormation 上に、フレームワークとして CDK、SAM、Chalice を提供しています。これらのツールによって、チームはインフラストラクチャーをより適切に定義し、サーバーレスリソースをプログラム的に管理することができます。当社の観察によれば、組織が成熟し拡大するにつれ、Lambda 関数のデプロイと管理に適した IaC ツールは、予測可能な方法で変化しています。

例えば、Serverless Framework は、Datadog の顧客の間で AWS Lambda 関数を管理する最も人気のある IaC ツールとなっています。アプリケーションとサーバーレスインフラストラクチャーを一緒にデプロイすることを容易にする、合理化されたワークフローを提供しています。これは、開発者コミュニティの強力なサポートとともに、新参者やサーバーレスに焦点を当てているチームにとって、魅力的なエントリーポイントとなっています。

それでも、組織のホスト数が増えるにつれて、AWS Lambda を管理するために Terraform を利用する傾向が見られます。これは Terraform の柔軟性、マルチクラウド対応、および DevOps チームによる幅広い採用と利用が、多様なクラウドインフラを運用する大規模な組織に支持されていることを示しています。

65% の組織が AWS Lambda 関数を VPC に接続

組織が既存のサービスの一部を Lambda に適応させたり置き換えたりする際には、すべてのサーバーレス関数がインフラ全体で統合されたままであることを確認することが重要です。これを実現するため、多くのチームは Lambda 関数を、広範なコンピューティングリソースとデータベースリソースを含む仮想プライベートクラウド (VPC) に直接接続しています。きめ細かなネットワークアクセス制御とセキュリティを提供するだけでなく、VPC は、大規模なアプリケーションのサーバーレスワークロードを、標準的なデプロイメントにおける Elastic Cloud Compute (EC2) や Relational Data Store (RDS) インスタンスなどの既存のインフラストラクチャーサービスに接続するために、組織にとってますます重要になっています。

過去 1 年間で、Lambda を利用している Datadog のお客様の 65% が、自社の AWS アカウント内の専用 VPC に接続された Lambda 関数を少なくとも 5 つデプロイしています。さらに、多くのお客様 (80%) が少なくとも 1 つの Lambda 関数を専用 VPC に接続しており、10% はすべての関数を独自の VPC で実行しています。

VPC に Lambda 関数を接続する際には、リスクとトレードオフを考慮する必要があります。AWS のデフォルトセキュア VPC を使用しないことで、お客様の組織は共同責任の枠組みの中で、より大きな責任を負う可能性があります。また、AWS は近年、ENI 接続のパフォーマンスを大幅に改善しましたが、VPC にはコールドスタートという追加の懸念点が存在します。