「サーバーレス( Serverless )」はバズワードかもしれませんが、その定義は明確になりつつあります。AWS Lambda はリリースされてからまだ 5 年も経っていませんが、AWS でインフラストラクチャを構築している企業の半数近くで採用されています。このレポートでは、何千もの企業のサーバーレスの使用状況を調査し、サーバーレスが実際にどのように（そしてどのくらい）使用されているかを明らかにします。
サーバーレス環境では、サーバー、データベース、キュー、さらにはコンテナなどのインフラストラクチャコンポーネントをプロビジョニングおよび管理する必要がないため、チームは運用に関する負荷を最小限に抑えて、コードの開発に注力できます。このレポートでは、パブリッククラウドと同じ従量課金制モデルを提供する FaaS（ファンクションアズアサービス）として知られるサーバーレスサブセットを中心に取り上げますが、インフラストラクチャコンポーネントではなく「関数（ファンクション）」のレベルで現状を紹介していきます。関数とは、ユーザーリクエストまたはその他のイベントによって呼び出され、ビジネスロジックの一部を実行するコードです。
このレポートでは、最初に、2020 年現在で、Datadog や他のユーザーベースにおいて最も成熟し広く採用されているサーバーレスプラットフォームである AWS Lambda に中心に説明します。このレポートでは、今後、Google Cloud Platform や Microsoft Azure など、他のプロバイダーのサーバーレスサービスについても調査する可能性があります。
AWS ユーザーの半分が Lambda を採用
2020 年初頭において、Lambda はすでにニッチなテクノロジーとは呼べなくなっています。Amazon Web Services を使用している Datadog のお客様のほぼ半数が Lambda を採用しています（Lambda の採用と AWS の使用状況の定義方法については、以下の「調査方法」のセクションを参照してください）。この採用率と環境の規模別の Lambda 使用状況の内訳（次のデータで説明）をご覧いただくと、クラウドネイティブのアーリーアダプターだけが Lambda を採用しているわけではなく、ニッチなユースケースではなくなっていることが分かります。それどころか、サーバーレス関数は、現在、AWS でインフラストラクチャを構築しているさまざまな企業で広く使用されています。
大規模な環境で、採用が進む Lambda
驚くべきことに、Lambda の普及はスタートアップ企業や小規模企業が推進しているわけではないことです。むしろ、企業のインフラストラクチャ環境が主にサーバー、コンテナー、サーバーレス関数のいずれであっても、Lambda の採用と企業のインフラストラクチャ環境の規模の間には明確な相関関係があります（これらの規模の違いの詳細については、下記の「調査方法」のセクションをご覧ください）。最大規模のインフラストラクチャフットプリントがある企業の 4 分の 3 以上が Lambda を採用しています。
多くのコンテナユーザーが Lambda を利用
Lambdaは、AWS でコンテナを実行している企業の間で特に人気があることが分かっています。2020 年 1 月の時点で、コンテナを実行している AWS の組織の約 80% が Lambda を採用しています。サーバーレス関数とコンテナは 2 つのまったく異なる環境ですが、インフラストラクチャを抽象化し、運用に関する懸念を取り除き容易にするなど、同じような理由から採用される傾向があります。Lambda とコンテナインフラストラクチャが直接関連するユースケースもいくつかありますが（例：Lambda 関数を使用して Amazon Elastic Container Service タスクをトリガーする場合など）、多くの組織はさまざまなニーズに対応するために、Lambda とコンテナを個別に実行しています。たとえば、アプリケーションの多くの部分をコンテナクラスタで実行する一方で、短期間に集中して処理されるタスク（支払処理など）をサーバーレス関数にオフロードしているケースがあります。
Amazon SQS および DynamoDB と相性の良い Lambda
Lambda ユーザーは、関数をインフラストラクチャおよびアプリケーションコンポーネントと連携させるときに、さまざまなテクノロジーを選択できます。関数がトリガーされると、多くの場合、関数は生成したデータをメッセージキューに送信します。メッセージキューは、そのデータを他の Lambda 関数、サーバーベースアプリケーション、またはクラウドサービスに転送します。メッセージキューは、サーバーレスの「従量課金制」モデルを組織が採用するのに役立ちます。サーバーレス関数の場合、関数が別の関数を呼び出して応答を待機する無駄な時間を生じさせることなく（また、請求対象となる呼び出し時間を浪費せず）、メッセージキューを介して非同期で呼び出しを行うことができます。また、関数はエフェメラル（短命）でステートレスであるため、多くの場合、別々の永続的なデータストアに対して読み取りまたは書き込みを行います。
Lambda 関数と同じリクエストで呼び出しまたはクエリされるサービスの中で最も多いのが Amazon DynamoDB です。キーバリューストアやドキュメントストアは、低レイテンシが保証されるクラウド型の自動スケーリングデータストアであるため、Lambda 関数との相性に非常に優れます。Lambda のユースケースにおけるデータストアで次に人気のある選択肢は、SQL データベース（Amazon RDS インスタンスまたはセルフマネージドデータベース）および Amazon S3 です。Amazon Simple Queue Service（SQS）が、Lambda リクエストのメッセージキューとして最も利用されており、次に Amazon Kinesis と Amazon Simple Notification Service（SNS）が続きます。SQS は、論理的にはサーバーレスアーキテクチャに適合しています。セットアップとスケーリングが簡単であり、コストが比較的安く、Lambda との緊密な統合が可能です。
Lambda ユーザーの間で最も人気の高いNode.js と Python
Lambda ユーザーが利用できる言語とフレームワークの中で、Python および JavaScript（Node.js プラットフォームを利用）が、明らかに最も多く利用されています。現在のすべての Lambda 環境の 47% が Python を実行しており、さらに 39% が Node.js アプリケーションを実行しています。Python 3 と Python 2（2020 年 1 月にサポート終了）の利用比率は 2 対 1 になっています。
Python および Node.js の Lambda ランタイムの人気は、アプリケーション開発の最近のトレンドと Lambda サービス自体の進化を反映しています。AWS は、2015 年に Java と Python のサポートを追加する前に、Node.js を最初にサポートするランタイムとして、2014 年にプレビュー版の Lambda をリリースしました。C#（.NET Core 経由）、Go、Ruby のサポートは、2018 年に追加されました。
Lambda 関数の実行時間の中央値は 800 ミリ秒
Lambda 関数の実行時間の中央値は約 800ミリ秒です。これは、すべての呼び出しの平均値ですが、実行時間は広く分布しています。Lambda 関数の 4 分の 1 の平均実行時間は 3 秒を超えており、12% は 10 秒以上かかります。サーバーレスのレイテンシはアプリのパフォーマンスだけでなくクラウドにかかる費用にも影響することから、Lambda 関数の実行時間が長くなる場合には注意が必要です。Lambda の料金体系は、「ギガバイト秒」単位のコンピュート時間に基づきます。これは、使用する関数に割り当てられるメモリ（詳細は以下を参照）に、呼び出しの実行時間を掛けて計算されます。
関数の実行時間の分布を拡大すると、関数の約 5 分の 1 が 100 ミリ秒以内に実行され、約 3 分の 1 が 450 ミリ秒以内に実行されています。
半数の Lambda 関数に最小のメモリが割り当てられている
前述のように、Lambda 呼び出しのコストは、実行時間と関数のメモリの積で計算されます。そのため、Lambda を実行している企業は、関数に割り当てられるメモリを制限する利点があります（この設定は構成が可能であるため、関数の実行時間よりも制御が容易です）。実際、47% の関数は、128 MB の最小メモリ設定で実行するように構成されています。一方で、ユーザーが各関数に最大で 3,008 MB を割り当てることができる場合でも、割り当てられるメモリが 512 MB を超えている関数は 14% に留まっています。
定義されたタイムアウトの 3 分の 2 は 1 分未満
各 Lambda 関数では、1 秒から 15 分までの範囲でタイムアウトする時間を構成できます。これは、Lambda 関数を呼び出して実行することが許可される最長期間となります。ほとんどの関数では、短いタイムアウトが使用されており、構成されたタイムアウト値の 3 分の 2 は 60 秒以下です（関数が作成されるときのデフォルトのタイムアウトは 3 秒です）。
関数の処理がハングするとクラウドのコストを浪費する恐れがあり、Lambda アプリケーションアーキテクチャでは高速な応答が必要となることが多いため、短いタイムアウト値を設定することが推奨されます。Lambda 関数のための REST インターフェイスを提供するために一般的に使用される Amazon API Gateway の最大タイムアウト設定は 29 秒です。そのため、Lambda が正常に処理を完了した場合でも、応答に 29 秒以上かかる API Gateway から呼び出されている Lambda 関数はエラーになります。これらの考慮事項にもかかわらず、多くの関数が、許容される最大のタイムアウト設定（現在の 900 秒の制限と以前の 300 秒の制限（2018 年 10 月まで有効）の両方）を使用するように構成されています。
同時実行制限が定義されている関数は 4％ のみ
デフォルトでは、Lambda のお客様は、特定のリージョンですべての関数を 1,000 回同時に実行するように制限されています。ユーザーは各関数について同時実行の制限を設定できます。これにより、特定の関数について、同時実行プール全体の一部を効果的に予約できます。この関数で同時実行回数の制限が超過すると、実行回数が調整されます。
ほとんどの組織が、同時実行の制限のオプションを認識しているにもかかわらず、現在、同時実行回数の制限が構成されているのはすべての関数で 4.2% のみになっています。実際、Lambda を実行している企業の 88.6% が、自社の環境で少なくとも 1 つの関数について、同時実行制限を利用しています。同時実行制限が定義されている関数は、調整される可能性がはるかに高くなります。5 日間の評価したところ、同時実行制限が構成されている関数の 8.3% が少なくとも 1 回調整されました。これに対し、関数別ではなくリージョン別の制限によってのみ制限された関数はわずか 0.3% でした。
サーバレスのご案内に登録
リサーチ｜ご案内｜製品アップデート情報
調査方法
調査対象
このレポートは、Datadog の顧客ベースにある数千社の使用状況データをまとめたものです。ただし、Datadog の顧客にはさまざまな企業規模と業界範囲が含まれますが、いくつかの共通の特徴があります。まず、ソフトウェアインフラストラクチャとアプリケーションのパフォーマンスについて意識が高い傾向にあります。また、通常よりも、クラウドプラットフォームやクラウドサービスを採用する傾向が高くなっています。この記事のすべての結果は、グローバル市場を網羅し大規模であるものの不完全なサンプルである Datadog の顧客ベースのデータを利用しているため、統計的に偏りが生じています。
Lambda の採用
このレポートでは、ある月に少なくとも 5 つの異なる Lambda 関数を実行した場合に、企業が Lambda を採用していると見なしています。S3 や CloudWatch ログなどのデータを Datadog に送信するDatadog Forwarder 関数は、関数のカウントから除外されています。
AWS の使用状況
ある月に少なくとも 5 つの異なる Lambda 関数または 5 つの異なる EC2 インスタンスを実行した場合、企業が AWS を使用していると見なしています。Datadog では、このような定義の下で、EC2 インスタンスのみを実行している、サーバーレス関数を排他的に実行している、または両方を組み合わせて実行している企業で構成される AWS のユーザーベースを管理しています。
環境の規模
企業のインフラストラクチャ環境の相対的な規模を推定するために、サーバーレス関数、コンテナ、物理サーバー、クラウドインスタンス、およびその他のインフラストラクチャサービスについての企業の使用状況を調査しています。カテゴリ間の境界（「中規模」や「大規模」など）は必然的に人為的に設定されていますが、各カテゴリ間の傾向は明確にしています。