サーバレスの現状 the State of Serverless | Datadog

2021 年 5 月更新 この調査は、2020 年 2 月に公開された本記事の初稿に基づくものです。

サーバーレスは、クラウドを積極活用するスタートアップ企業から大企業まで、あらゆる規模の組織で支持を集めています。サーバーレスシステムを使用することで、チームはアイデアをより早く市場に投入することができます。インフラストラクチャーの管理に時間を取られることもなく、しかも使用した分だけの料金を支払えばよいという点もメリットです。本レポートでは、数千の企業で実行されている数百万もの機能を調査し、サーバーレスが実務でどのように使用されているかを調査しました。

短時間で実行されるタスクからユーザー向けのアプリケーションまで、サーバーレスは幅広いユースケースを強力にサポートします。最も成熟し、広く利用されている FaaS (function-as-a-service) 製品といえば AWS Lambda ですが、Azure Functions や Google Cloud Functions の採用も目覚ましく増加しています。現在、サーバーレスのエコシステムは FaaS の域を超え、開発者がより速く、より動的なアプリケーションを構築するのに役立つ数多くのサービスを含むまでに成長しています。Amazon CloudFront ユーザーの 4 分の 1 はサーバーレスエッジコンピューティングを採用しており、企業は AWS Step Functions を活用して、さまざまな分散コンポーネントのアプリケーションロジックを管理しています。

それでは、サーバーレスの導入に関するより詳しいインサイトと傾向を以下にてご覧ください。


Trend Number 1

Lambda 関数の呼び出し回数が 2 年前の 3.5 倍に増加

AWS Lambda はインフラストラクチャーに捉われない拡張性の高いアプリケーションを構築できることが特徴で、開発者のイノベーションを加速させます。今日、チームは単にサーバーレスを実験的に使うだけではなく、ソフトウェアスタックに欠かせない要素として採用しています。実際、当社の調査によると、2019 年以降に Lambda を使い始めた企業ではその使用量が大幅に増加しており、2021 年初頭には 1 日あたりの関数の起動回数が 2 年前に比べて平均 3.5 倍にまで増加しました。さらに、Lambda ユーザーの同じコホート内では、各組織における関数は平均して 1 日に合計 900 時間稼働していました。

“Datadog’s 2021 The State of Serverless report highlights developers accelerating their adoption of serverless architectures to address new, more advanced business challenges. We’re excited to see organizations benefit from the agility, elasticity, and cost efficiency of adopting serverless technologies like AWS Lambda, and are here to support this growing, diverse developer community.”

—Ajay Nair, GM of Lambda Experience, Amazon Web Services

Trend Number 2

Azure Functions と Google Cloud Functions の勢いが加速

AWS Lambda を火付け役として勢いを増したサーバーレス・ムーブメントですが、Lambda が唯一の選択肢ではありません。Azure Functions と Google Cloud Functions も、それぞれのクラウドプラットフォームにおける採用を加速させています。過去 1 年間で、Azure Functions を利用している組織の割合は 20% から36% に上昇しました。また、Google Cloud に至っては、約 4 分の 1 の組織が現在 Cloud Functions を使用しています。Cloud Functions は 3 つの FaaS のうち最後に登場したサービスですが、Google Cloudにとってサーバーレスは新しい概念ではありません。Google Cloud プラットフォームは 2008 年に最初の完全なサーバーレスコンピューティングサービスである Google App Engine を導入しています。しかし現在では、Google の新しいサーバーレスサービスである Cloud Functions と Cloud Run に勢いが移ってきていると言えます。

“使用しているフレームワーク、言語、クラウドを問わず、サーバーレスはビルドとイテレーションのスムーズな実行に役立ちます。2 年前、Next.js はサーバーレス関数のファーストクラスのサポートを開始し、動的なサーバーサイドレンダリング (SSR) や API ルートを実現しました。それ以来、Vercel ユーザーの間でサーバーレスの導入が驚くほど進み、起動回数は月に 2 億 6,200 万回から月に 74 億回 (28 倍) という驚異の成長を遂げました。”

—Guillermo Rauch、Vercel CEO 兼 Next.js 共同創設者

Trend Number 3

1 年前と比べて、Lambda 起動時間の大幅短縮を実現

低レイテンシーを必要とする顧客向けのアプリケーションを動作させるために、Lambda の利用率はますます増加しています。2020 年には、Lambda の呼び出し時間の中央値は 60 ミリ秒で、前年の約半分に短縮されました。これは、Lambda のベストプラクティスに基づき、ワークロードに合わせて機能を設計する企業が増えたことで呼び出し時間が短縮されたためと考えられます。また、レイテンシー分布の末尾が長いことも見逃せません。これは、Lambda が短時間のジョブだけではなく、より計算量の多いユースケースにも対応していることを示唆しています。

Trend Number 4

Web アプリケーションからデータパイプラインまで、Step Functions があらゆる場面で活躍

AWS Step Functions は、開発者が複数の Lambda 関数や AWS サービスを組み込んだイベントドリブンなワークフローを構築することを可能にします。これらのワークフローの中で、Step Functionsはエラー処理、再試行、タイムアウト、その他のアプリケーションロジックを調整し、サーバーレスアプリケーションの拡張に伴う運用の複雑さを軽減します。当社の調査によると、Step Functions の平均的なワークフローには 4 つのLambdaファンクションが含まれており、この数は月を追うごとに増加しています。

Step Functions では「Standard」と「Express」という 2 種類のワークフローを利用することができます。ワークフローの 40% 以上が 1 分未満で実行されていることから、大量のイベント処理ワークロードをサポートするためにExpress ワークフローを使用している企業が多いと考えられます。しかし、多くのワークフローが短時間で実行される一方で、1 日以上かかるワークフローもあります。実際、最も長いステップファンクションのワークフローは 1 週間以上実行されます。Step Functions のワークフローには、例えば Amazon ECS や EC2 インスタンス上で動作するアクティビティワーカーを含めることができるため、Lambda 関数のタイムアウトである 15 分を超えて関数を実行することができます。このような理由で、Step Functions は Web リクエスト処理のようなレイテンシーが重要なタスクから、ビッグデータ処理のように複雑で長時間実行されるジョブまで膨大な数のユースケースをサポートすることができるのです。

“当社では、完全なサーバーレスアーキテクチャ全体で AWS Step Functions を採用しています。これにより、B2B 取引プラットフォームで大量のトランザクションを処理する信頼性の高いワークフローを設計・実行し、複雑な運用をよりシンプルにすることができます。”

—Zack Kanter、Stedi CEO

Trend Number 5

CloudFront ユーザーの 4 人に 1 人がサーバーレスエッジコンピューティングを導入

データ処理を確実に高速化できるエッジコンピューティングは、今かなりの旋風を巻き起こしています。現在、Amazon CloudFront を利用している企業の 4 分の 1 は、Lambda@Edge を活用して世界中のユーザーによりパーソナライズされた体験を提供しています。例えば、Lambda@Edge を通じてユーザーの特徴 (デバイスタイプなど) に基づいて画像を動的に変換したり、A/B テスト用に Web アプリケーションの異なるバージョンを生成したりすることができます。

Lambda@Edge は、CloudFront のエッジロケーションのネットワークを活用することで、オリジンサーバーの設定や管理の複雑さに悩まされることなく、エンドユーザーにより親しみやすい形で機能を実行することができます。当社のデータによると、Lambda@Edge の機能の 67% が 20 ミリ秒以下で実行されており、サーバーレスエッジコンピューティングは「最もレイテンシーが重要なアプリケーションでも、最小限のオーバーヘッドでサポートできる」という大きな可能性を秘めていることを示しています。この技術が成熟するにつれ、エンドユーザーの体験を向上させるために Lambda@Edge を利用する企業がさらに増えることを期待しています。

“Developers are increasingly moving parts of their applications to the edge. The ability to dynamically fetch and modify data from the CDN edge means you can deliver faster end-user experiences. Lambda@Edge made this possible in 2017, and now CloudFront Functions makes it simpler and more cost-effective for developers to run full JavaScript applications closer to their customers.”

—Farrah Campbell, Sr. Product Marketing Manager of Modern Applications,
Amazon Web Services

Trend Number 6

機能のほとんどで Provisioned Concurrency の過剰利用を確認

Lambda 関数を一定期間使用していなかった場合、呼び出し時にコールドスタートと呼ばれる短い実行遅延が発生します。しかし、ミリ秒レベルの応答時間を必要とするアプリケーションではコールドスタートは望ましくありません。そこで 2019 年末、AWS は Provisioned Concurrencyを導入し、実行環境を初期化してリクエストに応答できる状態に保つことで、Lambda ユーザー向けのコールドスタート対策を実施しました。

当社のデータによると、Lambda 関数に最適な量の Provisioned Concurrency を設定することは、ユーザーにとって既知の課題となっているようです。関数の半分以上が、設定された Provisioned Concurrency の 80% 未満しか使用していない一方で、割り当てのすべてを使用している関数は 40% 以上にのぼります。これは、依然としてコールドスタートが発生する可能性があり、さらに多くの同時実行を行うことでよりメリットが得られることを意味しています。アプリケーションのオートスケーリングを利用し、使用率に応じて Provisioned Concurrency を自動的にスケーリングすることでこれらの問題を回避することができます。

また、これらのランタイム特有の性質から、Provisioned Concurrency は Python や Node.js よりも起動時間が遅いJava や .NET Core 関数でよく使用されていることがわかっています。例えば、Java ではユーザーコードを実行する前に仮想マシン (JVM) を初期化し、さまざまなクラスをメモリにロードする必要があります。

Trend Number 7

Serverless Framework は、Lambda アプリケーションを AWS CloudFormation で展開するための優れた選択肢

サーバーレスアプリケーションの規模が大きくなると、Lambda 関数やその他のリソースの手動デプロイはたちまち複雑化します。AWS インフラストラクチャーやサードパーティのリソースを (スタックと呼ばれる) コレクションにプロビジョニングできる AWS CloudFormation は、AWS Cloud Development Kit (CDK)、AWS Serverless Application Model (SAM)、Serverless Framework などのフレームワークの基本的なデプロイメントメカニズムです。

中でもオープンソースの Serverless Frameworkは圧倒的に人気があり、現在、AWS CloudFormation でサーバーレスリソースを管理している組織の 90% 以上で使用されています。Serverless Framework 以外では、19% の組織が Vanilla CloudFormation、18% が AWS CDK、13% が AWS SAM を使用しています (注: 各組織で複数のデプロイメントツールを使用している可能性があるため、これらの値の合計は100%を超えています)。

サーバーレスアプリケーションで使用されている CloudFormation スタックの 65% には、 Lambda 関数が 1 つしか含まれていません。さらに、関数全体の過半数 (57%) は、CloudFormation でデプロイされていません。これは、多くの組織が、Infrastructure as Code によるサーバーレスワークフローの自動化と最適化の初期段階にあることを示唆しています。しかし、Kubernetes や Amazon Elastic Container Service (ECS) などのオーケストレーターが大規模なコンテナ群を管理するのに不可欠となったように、サーバーレスアプリケーションを大規模にデプロイする上で Infrastructure as Code ツールはより重要な役割を果たすようになると予想されます。

“開発者や企業がサーバーレス技術を活用してより高度なアプリケーションを構築する中で、サービスの構成、テスト、デプロイ、管理を確実に行うためのより強力なツールが必要とされています。これが、Serverless Framework や AWS CDK などオープンソースの Infrastructure as Code プロジェクトが生まれるきっかけとなりました。Serverless Framework だけでも、ダウンロード数は 2019 年の 1,200 万件から 2020 年には 2,500 万件に増加しており、開発者がサーバーレスでより多くのものを構築していく中で、これらのツールの採用と高度化が加速していくことが予想されます。”

—Jeremy Daly、Serverless Inc. サーバーレスクラウド ゼネラルマネージャー

Trend Number 8

Python は、特に大規模環境で最も人気のあるLambda ランタイム

2018 年以降、Lambda は Node.js、Python、Java、Go、.NET Core、Ruby の 6 種類のランタイムサポートを提供しています。しかし、Lambda ユーザーの間では Python と Node.js が引き続き優勢で、これらが関数の90% 近くを占めています。導入された Lambda の 58% が Python (前年比 11 ポイント増)、また 31% が Node.js を実行しています (前年比 8 ポイント減)。

環境の規模別にランタイム使用率の内訳を調査したところ、興味深い傾向が明らかになりました。小規模な AWS 環境では Node.js が Python を上回っていますが、環境の規模が大きくなるにつれて Python の人気が上がっていたのです。最大規模の AWS 環境を持つ企業では、 Python が Node.js の 4 倍も使用されています。

2021 年 3 月時点での、バージョン別上位ランタイムは次の通りです。

  1. Python 3.x
  2. Node.js 12
  3. Node.js 10
  4. Python 2.7
  5. Java 8
  6. Go 1.x
  7. .NET Core 2.1
  8. .NET Core 3.1

Python で書かれた関数のうち、90% 以上が Python 3 を使用しており、バージョンでは Python 3.8 が最も人気です。Python 2.7 は 1 年前に比べて 25 ポイント減少しており、ユーザーの Python 3 への移行が進んでいます。また、AWS は 2021 年 5 月に Node.js 10 のサポートを終了する計画を発表しており、Node.js 12 だけでなく、新たにサポートが開始された Node.js 14 の利用も増えることが予想されます。Java に関しては 2019 年後半から Java 11 のサポートが始まったにも関わらず、Lambda ユーザーの間では Java 8 が Java 11 の 5 倍の人気を誇っています。

サーバレスのご案内に登録

リサーチ|ご案内|製品アップデート情報

serverless report banner x close

調査方法

調査人口

本レポートでは、Datadog の顧客ベースである数千の企業の使用データをまとめました。Datadog のお客様は、企業の規模や業界を問わず様々な分野で活躍されていますが、いくつかの共通した特徴があります。まず、これらのお客様はソフトウェアインフラストラクチャーとアプリケーションパフォーマンスに真剣に取り組んでいる傾向があります。また、一般のお客様よりも、クラウドプラットフォームやサービスの導入に傾倒しています。この記事に掲載されているすべての結果は当社の顧客ベースから得られたものであり、全世界の市場の大規模かつ不完全なサンプルであるため、データには偏りが存在します。

FaaS の採用

本レポートでは、ある月に 5 つ以上の異なる関数を実行した場合に、「AWS Lambda、Azure Functions、または Google Cloud Functions を採用済みの企業」であるとみなします。なお、S3 や CloudWatch のログなどのデータを Datadog に送信するDatadog Forwarder 関数は、関数の合計から除外しています。

クラウドプロバイダーの使用量

ある月に 5 つ以上のサーバーレス関数または 5 つ以上の仮想マシン (VM) を実行した企業を、「クラウドプロバイダー (AWS、Google Cloud、Microsoft Azureなど) を利用している企業」であるとみなします。このようにして、VM のみ、サーバーレス関数のみ、あるいは両方を混在させて実行している企業など、さまざまなタイプの組織からなるクラウドプロバイダーのユーザー基盤を把握することができます。

環境の規模

Datadog は企業のインフラ環境の相対的な規模を推定するために、サーバーレス関数、コンテナ、物理サーバー、クラウドインスタンス、その他のインフラストラクチャーサービスの利用状況を調査しています。カテゴリ間の境界 (中規模・大規模など) は必然的に人工的なものとなりますが、カテゴリ間の傾向は明確です。

実証 #1

長期的な Lambda の利用傾向を分析するために、2019年の開始時から Lambda を利用している組織に限定して調査を実施しました。このコホートの組織について、利用データをランダムにサンプリングし、2019 年から 2021 年初頭までの各四半期における関数ごとの 1 日の平均呼び出し回数を計算しました。そして、2019 年の第 1 四半期を基準とし、その指数を100 として以降の各四半期の値をこの基準指数で正規化することで、指数チャートをプロットしました。

実証 #6

各機能の Provisioned Concurrency の過不足を分析するために、2020 年にランダムにサンプリングされた日の平均利用率を計算し、それを分布としてグラフ化することで多様なワークロードの利用状況に関する代表的なデータを取得しました。

実証 #7

今回の調査は CloudFormation の使用のみを対象としているため、AWS コンソールを使って手動でデプロイした Lambda 関数や、Terraform のような別の Infrastructure as Code ツールでデプロイした Lambda 関数は除外しています。