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

2020 年 2 月公開

「サーバーレス( Serverless )」はバズワードかもしれませんが、その定義は明確になりつつあります。AWS Lambda はリリースされてからまだ 5 年も経っていませんが、AWS でインフラストラクチャを構築している企業の半数近くで採用されています。このレポートでは、何千もの企業のサーバーレスの使用状況を調査し、サーバーレスが実際にどのように(そしてどのくらい)使用されているかを明らかにします。

サーバーレス環境では、サーバー、データベース、キュー、さらにはコンテナなどのインフラストラクチャコンポーネントをプロビジョニングおよび管理する必要がないため、チームは運用に関する負荷を最小限に抑えて、コードの開発に注力できます。このレポートでは、パブリッククラウドと同じ従量課金制モデルを提供する FaaS(ファンクションアズアサービス)として知られるサーバーレスサブセットを中心に取り上げますが、インフラストラクチャコンポーネントではなく「関数(ファンクション)」のレベルで現状を紹介していきます。関数とは、ユーザーリクエストまたはその他のイベントによって呼び出され、ビジネスロジックの一部を実行するコードです。

このレポートでは、最初に、2020 年現在で、Datadog や他のユーザーベースにおいて最も成熟し広く採用されているサーバーレスプラットフォームである AWS Lambda に中心に説明します。このレポートでは、今後、Google Cloud Platform や Microsoft Azure など、他のプロバイダーのサーバーレスサービスについても調査する可能性があります。

Trend Number 1

AWS ユーザーの半分が Lambda を採用

2020 年初頭において、Lambda はすでにニッチなテクノロジーとは呼べなくなっています。Amazon Web Services を使用している Datadog のお客様のほぼ半数が Lambda を採用しています(Lambda の採用と AWS の使用状況の定義方法については、以下の「調査方法」のセクションを参照してください)。この採用率と環境の規模別の Lambda 使用状況の内訳(次のデータで説明)をご覧いただくと、クラウドネイティブのアーリーアダプターだけが Lambda を採用しているわけではなく、ニッチなユースケースではなくなっていることが分かります。それどころか、サーバーレス関数は、現在、AWS でインフラストラクチャを構築しているさまざまな企業で広く使用されています。

state-of-serverless/FACT_1.png
Trend Number 2

大規模な環境で、採用が進む Lambda

驚くべきことに、Lambda の普及はスタートアップ企業や小規模企業が推進しているわけではないことです。むしろ、企業のインフラストラクチャ環境が主にサーバー、コンテナー、サーバーレス関数のいずれであっても、Lambda の採用と企業のインフラストラクチャ環境の規模の間には明確な相関関係があります(これらの規模の違いの詳細については、下記の「調査方法」のセクションをご覧ください)。最大規模のインフラストラクチャフットプリントがある企業の 4 分の 3 以上が Lambda を採用しています。

state-of-serverless/FACT_2.png

Trend Number 3

多くのコンテナユーザーが Lambda を利用

Lambdaは、AWS でコンテナを実行している企業の間で特に人気があることが分かっています。2020 年 1 月の時点で、コンテナを実行している AWS の組織の約 80% が Lambda を採用しています。サーバーレス関数とコンテナは 2 つのまったく異なる環境ですが、インフラストラクチャを抽象化し、運用に関する懸念を取り除き容易にするなど、同じような理由から採用される傾向があります。Lambda とコンテナインフラストラクチャが直接関連するユースケースもいくつかありますが(例:Lambda 関数を使用して Amazon Elastic Container Service タスクをトリガーする場合など)、多くの組織はさまざまなニーズに対応するために、Lambda とコンテナを個別に実行しています。たとえば、アプリケーションの多くの部分をコンテナクラスタで実行する一方で、短期間に集中して処理されるタスク(支払処理など)をサーバーレス関数にオフロードしているケースがあります。

state-of-serverless/FACT_3.png
Trend Number 4

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 との緊密な統合が可能です。

state-of-serverless/FACT_4.png
Trend Number 5
Trend Number 6

Lambda 関数の実行時間の中央値は 800 ミリ秒

Lambda 関数の実行時間の中央値は約 800ミリ秒です。これは、すべての呼び出しの平均値ですが、実行時間は広く分布しています。Lambda 関数の 4 分の 1 の平均実行時間は 3 秒を超えており、12% は 10 秒以上かかります。サーバーレスのレイテンシはアプリのパフォーマンスだけでなくクラウドにかかる費用にも影響することから、Lambda 関数の実行時間が長くなる場合には注意が必要です。Lambda の料金体系は、「ギガバイト秒」単位のコンピュート時間に基づきます。これは、使用する関数に割り当てられるメモリ(詳細は以下を参照)に、呼び出しの実行時間を掛けて計算されます。

state-of-serverless/FACT_6.png

関数の実行時間の分布を拡大すると、関数の約 5 分の 1 が 100 ミリ秒以内に実行され、約 3 分の 1 が 450 ミリ秒以内に実行されています。

Trend Number 7
Trend Number 8

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

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

serverless report banner x close