使用量が250%増加し、このレポートによりサーバーレスが再び注目を集める

[[406964]]

この記事は、Datadog の最新の Serverless レポートの解釈です。誰でも議論のためにメッセージを残していただけます。

あらゆる新しいテクノロジーには、その出現と進化の過程で支持者と懐疑論者が存在します。サーバーレスの利点は、顧客がインフラストラクチャへの投資から可能な限り解放され、自社のビジネスに集中して、テクノロジーによってより多くの商業的価値を生み出すことができることです。同時に、顧客は使用量に応じて料金を支払うだけでよく、コンピューティング リソースを常駐させる必要はありません。

「Datadog の AWS 顧客の半数が Lambda を使用しており、AWS コンテナ顧客の 80% が Lambda を使用しています。」

はい、このデータは昨年 Datadog が発表した調査レポートから得たもので、海外市場におけるサーバーレスの導入進捗状況を客観的に反映しています。 1 年後、Datadog は 2 番目の Serverless 調査レポートを発表しました。海外におけるサーバーレスの最新動向を見てみましょう。これは、サーバーレス構築にすでに投資している、またはまだ傍観している意思決定者やユーザーにとって参考になるかもしれません。

観点

ポイント1: Lambda呼び出しは2年前より3.5倍頻繁になり、実行時間は1日あたり最大900時間になりました。

サーバーレスの使用の深さをどのように定義するのでしょうか?

2019 年以降、Lambda を使用している企業では使用量が大幅に増加しています。平均すると、2021 年初頭までに、これらの企業は 2 年前と比べて 1 日あたり 3.5 倍多くの関数を呼び出していました。さらに、同じ Lambda ユーザー グループでは、関数は企業ごとに 1 日平均 900 時間実行されていました。

通常のクラウド サーバーは、サーバーのレンタル構成とレンタル期間に基づいて課金されます。レンタル構成は、vCPU とメモリに基づいて価格設定されます。

関数 Compute は異なります。使用中の通話回数と機能実行時間に基づいて課金されます。したがって、呼び出し回数と関数の実行時間は、顧客が Serverless をどの程度使用しているかを示す指標となります。レポートでは 1 日あたりの呼び出しの絶対数に関する情報は提供されませんが、1 日あたり 900 時間の実行時間のデータに基づいて、顧客の Serverless 消費量の区間推定を行うことができます。

Alibaba Cloud Function Compute の課金基準に基づいて、プリペイド モデルを使用して計算します。

1 GB の計算能力のインスタンスを 1 秒間実行するコストは 0.00003167 元です。メモリ仕様を1GB、1日あたり900時間稼働とすると、推定消費量は102.6元、年間消費量は37,000元となります。ストレージ、ネットワーク、セキュリティ、データベースなどの他のクラウド製品の消費と組み合わせると、それはすでに中規模企業のクラウド支出になります。さらに、関数を呼び出すコストは通常​​それほど高くなく、特に AI モデリングに関連する Python などの関数アプリケーションの場合はその傾向が顕著です。 Alibaba Cloud Function Compute を 1 日あたり 100 万回呼び出すコストは 13.3 元です。

ポイント2: Lambda の平均実行時間は 60 ミリ秒で、1 年前の半分に短縮されました。

イベント駆動型アーキテクチャでは、実行時間は重要な生産要素である

関数実行時間は、FaaS 分野における新しい概念です。 FaaS はイベント駆動型アーキテクチャであるため、コンピューティング リソースは関数アプリケーションを実行するために呼び出され、実際にトリガーされたときにのみ課金されます。関数アプリケーションの実行時間が長くなるほど、料金が高くなります。通常のクラウドサーバーは、関数コンピューティングとは異なり、サーバーをレンタルすることで課金されます。通常のクラウド サーバーも自動エラスティック スケーリング機能を提供しますが、イベント駆動型アーキテクチャではないため、スケーリング ルールが制限されます。さらに、通常のクラウド サーバーは秒単位で課金されますが、Lambda や Alibaba Cloud Function Compute などの業界の FaaS 製品はすでにミリ秒単位の課金をサポートしています。課金の粒度が細かくなるほど、コンピューティング コストを最適化する余地が大きくなります。

データ構造から、ますます多くの AWS 顧客が公式のコスト最適化のベストプラクティスに従って関数の実行時間を短縮し、それによってコンピューティングコストをさらに最適化し、サーバーレスのコスト上の利点を最大化していることがわかります。

下の図では、関数実行時間曲線の末尾が非常に長くなっており、Lambda が短期ジョブをサポートするだけでなく、コンピューティング集約型のユースケースもサポートしていることがわかります。本レポートでは、Lambda がどのようなコンピューティング集約型のビジネス シナリオで使用されているかは示していませんが、国内のクラウド ベンダーが推進している事例から判断すると、音声やビデオの処理、AI モデリングなどのアプリケーションが中心です。

視点3：AWS Lambdaに加え、Azure FunctionやGoogle Cloud Functionも急成長中

百の学派の繁栄は、業界が成熟するための必然的な段階である

AWS Lambda は最も古い FaaS 製品であり、その後に Azure と Google が FaaS 製品を開始しました。彼らの成長率は、業界全体の成熟から恩恵を受ける可能性があります。 1 年前、Azure 顧客のうち Azure Function を使用していたのはわずか 20% でした。 1年後、この数字は36%に増加し、Googleのクラウド顧客の25%がすでにCloud Functionを使用しています。

このセクションでは、報告書は Vercel の事例を引用しています。

Vercel は、サーバーやドメイン名を購入したり、Nginx をインストールして構成したり、Web サイト ファイルをアップロードしたり、DNS 解決項目を追加したり、Web 証明書を構成したりすることなく、Web サイトやアプリを迅速に展開できる、非常に実用的な Web サイト管理およびホスティング ツールです。最も重要なことは、個人使用の場合、永久に無料であることです。

Vercel は、密結合されていないアプリケーションをホストします。言うまでもなく、Vercel のビジネス モデルは、サーバーレス テクノロジーのコスト上の利点を最大限に活用して、無料の個人ユーザーがもたらすサーバー コストを最小限に抑え、サーバー側のレンダリング、API ルーティングなどのリクエストを機能アプリケーションを通じて処理します。過去 1 年間で、Vercel のサーバー呼び出しは月間 2 億 6,200 万回から 74 億回へと 28 倍に増加しました。

ポイント 4: AWS Step Functions は Lambda の最適なパートナーです。平均して、各ワークフローには 4 つの機能が含まれており、その数は月ごとに増加しています。

機能アプリケーションのオーケストレーションは機能アプリケーションの境界を広げます

通常、完全なビジネス ロジックは単一の関数アプリケーションでは完了できません。複数の機能アプリケーションが必要であり、エラスティック コンピューティングやバッチ コンピューティングなどのコンピューティング ユニットも含まれます。このとき、ワークフロー オーケストレーション機能により、さまざまなコンピューティング タスクを順番、分岐、並列などの方法で分散オーケストレーションできるため、面倒なビジネス スプライシングによるコード作業を簡素化できるほか、ビジネス プロセス全体の各実行リンクの状態を視覚的に監視できるため、一石二鳥となります。 AWS Step Functions はそのような機能を提供します。

レポートによると、各 Step Functions ワークフローには平均 4 つの Lambda 関数が含まれており、この数は月ごとに増加しています。これは、ますます複雑化するビジネス ロジックを処理するためにワークフローを使用する顧客が増えていることを示しています。そのうち、実行時間が 1 分未満のワークフローが 40% を占めていますが、実行時間が 1 時間以上、さらには 1 日以上かかるワークフローもいくつかあります。これらの長期実行ワークフローは主に AI モデリングに基づいています。

このセクションでは、マーケティング メール プッシュ サービスなどの B2B トランザクションの分野で構造化メッセージ送信サービスを提供する Stedi 社の事例を紹介します。このタイプのビジネス シナリオには、イベント トリガーの特性があり、短時間で多数のターゲット メールボックスを呼び出す必要があります。サーバーレス + ワークフローは、コストと開発・運用効率の面での最適化に対する顧客の要求に十分に応えることができます。

ポイント5: AWS CloudFront の顧客の4分の1が Lambda @Edge を使用している

エッジはサーバーレスの新たな市場になりつつある

Lambda@Edge は、アプリケーション ユーザーの近くでコードを実行し、パフォーマンスを向上させ、レイテンシーを削減できる Amazon CloudFront の機能です。 Lambda@Edge を使用すると、顧客は世界中の複数の場所でインフラストラクチャをプロビジョニングまたは管理する必要がなくなります。使用したコンピューティング時間に対してのみ料金が発生し、コードが実行されていないときは料金は発生しません。

これは、エッジ シナリオでクラウドからコンピューティング パワーを呼び出すことなく、ネットワークがサーバーレス コンピューティング パワーを顧客に提供するのと同じであり、ビデオ監視やインテリジェント分析、ビジネスの監視と分析、IoT シナリオのその他のタスクなど、遅延の影響を受けやすいエッジ ビジネスの顧客エクスペリエンスが向上します。

レポートによると、Amazon CloudFront の顧客の 4 分の 1 が Lambda@Edge を使用しており、これらの顧客の 67% は関数の実行時間が 20 ミリ秒未満であり、これらのアプリケーションがレイテンシーに非常に敏感であることがわかります。このようなエッジ ビジネスの需要が高まれば高まるほど、エッジでのサーバーレスの可能性は高まります。

ポイント6: 顧客機能予約インスタンスの半数以上はリソース使用率が80%未満

コールドスタートはイベント駆動型アーキテクチャの必然的な命題である

特に Java/.Net プログラミング フレームワークでは、Java がユーザー コードを実行する前に仮想マシン (JVM) を初期化し、多数のクラスをメモリにロードする必要があるため、アプリケーションの起動が遅くなります。業界では、機能予約インスタンスの提供や、オンデマンド読み込みとより効率的なストレージおよびアルゴリズムによるコンテナイメージのプル速度の向上など、コールドスタートを最適化するための多くのアイデアが提供されており、それによってコールドスタート速度が最適化されています。

本質的に、関数予約インスタンスはコールド スタートを回避するための迅速かつ効果的な方法ですが、コールド スタートの問題を根本的に解決するものではありません。予約するリソースが多ければ多いほど、無駄が増え、サーバーレスが推奨するオンデマンドの使用に反することになります。そのため、今年のレポートでは、機能予約インスタンスの顧客の使用状況に細心の注意を払っています。

レポートによると、関数予約インスタンスを使用する顧客の 57% が、予約インスタンス内のリソースの 80% 未満しか使用していません。そのうち、30% 以上の顧客はリソースの 40% 未満しか使用していません。顧客の 40% 以上は使用率が 80% ～ 100% であるため、これらの顧客は依然としてコールド スタートの問題に遭遇するはずです。したがって、ビジネス向けにリザーブドインスタンス設計を継続的に最適化することは、依然としてメーカーと顧客が共に取り組まなければならない命題であり、関連するベストプラクティスは大きな指針となるでしょう。興味のある方は、Alibaba Cloud Function Compute のベストプラクティスをご覧ください。

視点7: オープンソースのサーバーレスフレームワークは関数アプリケーションをデプロイする主な方法です

アプリケーションが詳細になるほど、展開が難しくなります。

サーバーレス アーキテクチャでは、いくつかの関数アプリケーションを手動でデプロイすることはそれほど複雑ではないかもしれません。しかし、アプリケーションが数十または数百に拡張されると、アプリケーションの展開の難しさは倍増します。現時点では、いくつかのデプロイメント ツールを使用すると、デプロイメントの効率が向上します。 Kubernetes は、コンテナ化されたアプリケーションを自動的にデプロイ、スケーリング、管理するために使用されるのと同様に、コンテナを管理するプロセスにおいて不可欠なツールとなっています。

レポートによると、80% 以上の顧客が Serverless Framework を使用して関数アプリケーションをデプロイおよび管理しています。レポートでは理由は示されていませんが、一般的に、これは Serverless Framework の使いやすさ、オープン性、コミュニティ特性と切り離せないものです。レポートでは、サーバーレス アプリケーションの大規模な展開において、コード展開ツールとしてのインフラストラクチャがより重要な役割を果たすようになると予測しています。 AWS が独自に開発した 3 つのデプロイメント ツール、Vanilla CloudFormation、AWS CDK、AWS SAM の使用率はそれぞれ 19%、18%、13% です。 （同じお客様が2つ以上のツールを同時にご利用になる場合もあり、合計すると使用率は100％を超えます）

中国に戻ると、Alibaba Cloud、Baidu Cloud、Huawei Cloud、Tencent Cloud はすべて独自のクローズドソースの展開ツールを提供しています。 Tencent Cloud は Serverless Framework と協力して Serverless Application Center を開発しました。 Alibaba Cloud は昨年、機能アプリケーションの展開、運用、保守、監視を提供するために Serverless Devs をオープンソース化しました。さらに、Node.js 開発フレームワークを提供する別の国内オープンソース プロジェクトである Midway も、すでに 4,000 以上のスターを獲得しています。 Serverlessに参加する開発者が増えることで、国内のオープンソースツールのエコシステムがさらに活発化していくと考えています。

ポイント8: Pythonは、特に大規模な環境で最も人気のあるLambdaランタイムです。

サーバーレスは、当然のことながら、多言語開発フレームワークをサポートします。では、どのタイプのプログラミング言語が最も人気があるのでしょうか?

レポートによると、ユーザーの 58% が Python を使用しており、Node.js が 31% のシェアを占め、Java、Go、.NET Core、Ruby のシェアは 10% 未満です。しかし、各メーカーの特性を考慮すると、Alibaba Cloud での Java シェアはより高くなる可能性があり、Azure では .NET の顧客が増えるでしょう。

興味深いことに、小規模な Lambda ランタイムでは、Node.js のシェアが Python よりも高くなっています。関数のサイズが大きくなるにつれて、Python の人気が高まります。企業組織では、次に示すように、Python は Node.js よりも 4 倍頻繁に使用されます。

雷娟氏は、Alibaba Cloud イントラネット上で、レポートのプログラミング言語部分の分析を共有しました。大企業はビッグデータ、AI などの面で Python をより多く使用しており、Lambda も大量に使用しているため、Python は Lambda の数において絶対的な優位性を持っています。 Node.js アプリケーションは、それほど大きなランタイム (マルチコア CPU と大容量メモリ) を必要とせず、通常は小さなインスタンスです。さらに、個々の Node.js 開発者は通常、小規模な Lambda 環境を選択することもあります。

また、各種プログラミング言語のバージョンの使用分布は、降順で、Python 3.x、Node.js 12、Node.js 10、Python 2.7、Java 8、Go 1.x、.NET Core 2.1、.NET Core 3.1 となっています。

要約する

全体的には、昨年と比較して、海外のサーバーレスユーザー数は急速に拡大しており、機能の実行時間は増加し、使用方法はより成熟し、開発者ツールはよりオープンになっています。中国では、サーバーレスは一部のオフライン タスクや低結合アプリケーションに限定されなくなりました。多くの企業顧客が、生産プロセスの中核部分に Serverless を適用しています。たとえば、Century Lianhua は、トランザクション システム、メンバーシップ システム、在庫システム、バックエンド システム、プロモーション モジュールなどのコア アプリケーションを機能コンピューティング上に展開し、顧客のインフラストラクチャへの投資を削減しました。 Xianyu は、関数間のコード再利用や関数依存関係の統一されたアップグレードなどの業界の問題を克服するために、従来の巨大アプリケーションのサーバーレス変換を実践し始めました。アプリケーションの変換には時間とウィンドウ期間が必要です。ますます多くの企業顧客が、業務の負担を軽減するためにサーバーレスを選択するようになると思います。