2020.02.13 2022.10.28

研究論文「Serverless Computing: Economic and Architectural Impact」によって検証されたサーバーレスの長所

kuni

最近、AWS Lambdaに関する学術論文「Serverless Computing: Economic and Architectural Impact」を読みました。この論文は、AWS Lambdaをテーマにした最初の学術的研究の1つであり、ロンドンのITコンサルタント会社パートナーのGojko Adzic氏と、インペリアル・カレッジ・ロンドンの主任研究員であるRobert Chatley氏によって2017年に発表されたものです。

この論文は、サーバーレス・コンピューティングの経済的な影響・効果に関して非常に示唆に富んでいるため、その重要なポイントを紹介していきます。現時点で論文の発表当時（2017年）と取り巻く技術や背景が変わっている部分はありますが、サーバーレスの効果に関する本質は変わっていません。

なお、サーバーレスを基本からおさえたい方は、ぜひ以下のコラムをご一読ください。

・なぜサーバーレスが注目されているのか？ゼロから学ぶサーバーレスアーキテクチャ（FaaS）入門

論文では、Gojko Adzic氏が立ち上げたマインドマップサービス「MindMup」と、ソーシャル・ネットワークのYublの2つのサービスを対象に、AWS Lambdaベースのサーバーレス・アーキテクチャへの移行が、両社のビジネスにどのような影響を与えたかをまとめています。

Contents

サーバーレスによってホスティング費用の99.8%〜99.95%を削減
なぜサーバーレスでは大きなコスト削減が可能なのか？
MindMupとYublのケースでの実際の効果を検証
1. ケース1. MindMup社
2. ケース2. Yubl社
サーバーレス・コンピューティングがもたらす機会
1. 1. モジュールの分離・独立化
2. 2. システムの安価なバージョンニングを可能に
サーバーレス・コンピューティングの制約
1. 処理の遅延の発生
2. ベンダーロックイン
結論：サーバーレスのビジネス価値とは？
MMMのサーバーレスへの取り組み

サーバーレスによってホスティング費用の99.8%〜99.95%を削減

以下の通り、5分毎に200ミリ秒の処理を行った際のホスティング費用が、従来のクライアント・サーバモデルと、サーバーレスとでどう変わるかを比較しました。

For example, if a service task takes 200 milliseconds to execute, but needs to run only every five minutes, a traditional client/server architecture would require dedicating a service instance to it, and ensuring that a fail-over service instance is available just in case the primary crashes.

結果としては、512MBのメモリのEC2（仮想サーバー）のコストは、1時間あたり0.0059ドルでした。このマシンを2台実行すると、0.0118ドルかかりました。（プライマリおよびフェイルオーバー）

一方で、512MBのLambdaインスタンス（サーバーレス）の1時間あたりのコストは0.000020016ドルで、99.8％以上のコスト削減になりました。

Lambdaは低メモリインスタンスを提供するため、メモリが少なくて良い場合は仮想サーバーと比べてさらにコストが下がります。128MBのLambdaインスタンスの場合、コストは1時間あたり0.000004992ドルになり、99.95％以上のコスト削減になりました。

なお、実サービスで求められるシステムの可用性を考慮して、仮想サーバーに関しては、フェイルオーバーのコストも含めていますが、サーバーレスではプラットフォーム自体が可用性を備えています。この点もコストの違いに繋がっています。

なぜサーバーレスでは大きなコスト削減が可能なのか？

サーバーレスでは、顧客毎ではなくプラットフォーム全体でコンピューター資源の最適化が実施されている点が、利用者のコスト削減にも大きな影響を与えていると考えられます。

また、論文ではアクセスモデルの違いについても触れられています。

サーバーレスの近年のプラットフォームでは、分散型の認証を行うことができるため、接続元のクライアントがストレージなどのバックエンドに対して直接アクセスを行います。従来のクライアント・サーバーモデルで見られるような、専用サーバーでアプリケーションとサービスを保護し、ブローカーとして機能するような「ゲートキーパー」は存在しません。

そのため、従来のクライアント・サーバーモデルでは「処理」と「ストレージ」のコストが発生していたのに対し、サーバーレスでは「処理」が不要になり「ストレージ」のコストだけで済むことになります。この点が大きなコスト差の原因だと説明されています。

なお、無数の接続デバイスから連続的にデータ送信を行う「Internet of things(IoT)」でサーバーレスが採用される理由の1つも、このような分散型認証モデルを用いたバックエンドシステムへの直接接続が、コスト優位性を持っているためではないかと考えられます。

MindMupとYublのケースでの実際の効果を検証

MindMupとYublの2つのケースについて、サーバーレスを採用したことで実際にどのような課題を解決できたのかを見ていきます。

ケース1. MindMup社

MindMupでは、2016年のHerokuからAWS Lambdaへの移行の際に、定型的なコードを大幅に削減しつつ、システムのコア機能であるマインドマップ図の変換処理も改善することができました。Herokuでは、ファイルの変換処理に関して、メッセージキュー接続、タスクの再試行処理、ロギングと監視などの処理をすべて独自に実装していたものの、AWS Lambdaに移行したことで、コアのファイル変換以外の処理を廃止することができました。アプリケーションの開発者がビジネスロジックに集中できるようになり、新機能の実装にかける時間の確保できるようになったとのことです。

数値的な結果は、以下の説明の通りです。

Comparing the usage loads between February 2016 (before the transition to Lambda) and February 2017 (after the transition was fully completed) [1], the number of active users of MindMup increased by slightly more than 50%, but the hosting costs dropped slightly less than 50%, resulting in savings of about 66%, despite a number of new services being added during that year.

Lambdaへの移行中、アクティブユーザ数は50%以上増加したにも関わらず、ホスティングコストは50%弱減少し、新サービスを追加したものの最終的には66%のコスト節約を実現できました。

ケース2. Yubl社

ソーシャルネットワークのYublは、スマートフォンアプリのバックエンドを仮想サーバーに構築していました。可用性を考慮して、バックエンドは複数のデータセンター（アベイラビリティーゾーン）に配備されていました。

一般的にSNSでは、インフルエンサーや広告主がキャンペーンを行うとトラフィックが急増することがあります。Yublは、この対策として常にシステムに余裕を持たせ、オートスケールも採用していましたが、スケールアップには平均15分の時間を要していたそうです。

そこでYublは、コストを効率化・最小化しつつ、素早いデプロイを可能にするため、バックエンドをLambdaに移行しました。結果は以下の通り、非常にインパクトの大きいものでした。

To provide continuity during the migration, the team had to continue to run the EC2 instances until everything was moved over to Lambda, but this $5000 per month bill was for much smaller instances than they had been running previously, so their estimate is that moving to Lambda gave an operational cost reduction of greater than 95% for a comparable amount of compute.
(中略)
Delegating responsibility for a lot of infrastructural concerns to the platform meant that they could spend more of their time developing new business features. Where previously deployments were risky and required careful planning, after moving to Lambda and working with smaller units they were fast and low effort, with the option to instantly roll back if things went wrong.

Lambdaに移行して同じ計算量を処理した場合、月額5000ドルかかっていたEC2インスタンスのコストは、95%以上削減されると推測されました。

また、インフラの多くの懸念をプラットフォーム側に委譲することで、より多くの時間をビジネスに必要な新機能の開発に費やすことができるようになりました。障害時の即座のロールバックや、安全で素早いデプロイもできるようになりました。

サーバーレス・コンピューティングがもたらす機会

論文は、サーバーレスによって以下の2つの機会がもたらされるとしています。

1. モジュールの分離・独立化

仮想マシンやPaaS（Google App EngineやHeroku）では、実行するタスクを一つのアプリケーションに紐付けますが、コンピュータリソースを共有しているため、タスクが相互干渉してしまうデメリットが存在します。とはいえ、全てのタスクを個別のアプリケーションやサーバーで実行させると、コストの増加に直結してしまいます。

サーバーレスでは、利用したリソース量とコストが比例するため、コスト削減のためにリソースを共有するという方向には進みません。また、プラットフォームがセキュリティや可用性を担保するため、各タスクが独自に処理を行う実装をすることで、他のタスクへの影響や依存を無くすことができます。

論文では、以下の通り、サーバーレスが「より小さく、分離されたモジュールを開発する機会をもたらす」としています。

Without strong economic and operational incentives for bundling, serverless platforms open up an opportunity for application developers to create smaller, better isolated modules, that can more easily be maintained and replaced.

コンピューターリソース共用時に、利用料の観点や運用上のメリットが見出だせなければ、サーバーレス・プラットフォームは、開発者にとって、より保守しやすく、より疎結合で、交換が容易な、分離されたモジュールを作成する「良い機会」をもたらすと定義しています。

2. システムの安価なバージョンニングを可能に

もう一つの機会は、Lambdaのバージョニング機能です。

従来、アプリケーションの複数のバージョンが同時に存在すると、そのバージョンの数に比例して運用コストが増加しました。

ところがLambdaでは、複数のバージョン管理に対して、追加コストは発生しません。1つのバージョンに10,000件のリクエストを行ったときのコストと、2つのバージョンに5,000件ずつリクエストしたときのコストは、同一になります。

この特長によって、例えばA/Bテストや段階的な機能リリースなど、実験的なサービス提供をより安価に行うことができるようになります。

サーバーレス・コンピューティングの制約

検証を通じて、サーバーレスが持つ制約も明らかになりました。

処理の遅延の発生

AWS Lambdaは、有効なインスタンス数が自動的に増減されるため、リクエストを受け付けたタイミングで必要なインスタンスを新しく作成する場合があります。このプロセスは、開発者が制御できない仕様になっています。

論文でも以下のように触れられています。

This means that very infrequently used services might experience constant high latency.

Even for frequently used services, clients might experience some additional latency during usage spikes when many new instances get created.

記載の通り、使用頻度が低いサービスでは大きな遅延が発生する可能性があります。使用頻度が高いサービスであっても、新しいインスタンスが多数作成された場合は遅延が発生する可能性があるとしています。

言語にもよりますが、インスタンスの作成には1秒〜10秒の時間を要することがあります。

なお、AWSはこの問題を解決する努力をしてきており、2019年にリリースされたProvisioned Concurrency for Lambda Functionsという機能を利用すれば対処できるケースも出てきました。

ベンダーロックイン

サーバーレスでは、認証や構成管理から、バックエンドストレージやスケーリング、そして監視に至るまで、あらゆる機能をプラットフォームが提供しています。コード自体はプラットフォームに依存しないものの、そのコードを通じて実現するサービスはプラットフォームに大きく依存する形となります。

この点について、本論文では以下のように触れています。

Serverless architectures provide incentives to let client applications connect directly to storage resources and queues, so client code becomes more tightly coupled to other platform services. In practice, this means that moving a serverless application from one cloud provider to another would require a significant rewrite.

この通り、コードがプラットフォームと密結合されるため、プラットフォームを乗り換える際には大幅のコードの書き換えが必要になります。

結論：サーバーレスのビジネス価値とは？

MindMupとYublの2つのケースを用いてサーバーレスの検証を行った結果、短時間で大量のリクエストを捌くような高スループットが求められる場合や、処理遅延（レイテンシー）がサービス提供上の大きな問題とならない場合に、サーバーレスを利用することで「ホスティング費用を大幅に削減し、新機能の提供に要する時間を短縮できる」という結論が得られました。

サーバーレスでは、処理を実行していない時間は課金されないため「アイドルコストの削減」が可能となります。論文の最初の例で挙げられていたように、仮想サーバーと比較して99.8%〜99.95%という劇的なホスティング費用の削減についても、このアイドル時間の課金の有無が大きく影響しています。

また、運用の効率化もコスト削減に寄与します。適切なスキルセットや経験のあるチームであれば、従来のオンプレミス環境や仮想サーバーと比較して、システム運用に必要な運用コストがはるかに小さくなります。

加えて、目に見えるコスト削減以上に大きな価値をもたらすのが、ビジネス俊敏性の向上、つまり「製品や新機能を市場に投入するまでの時間が短い」という点です。俊敏性の向上は、企業にとって大きな競争優位性に繋がるはずです。