MMMブログ

"Serverless Computing: Economic and Architectural Impact" からサーバーレスがビジネスにもたらす影響・効果を考える

サーバーレスがどのような効果をビジネスにもたらすか?

Neuri Consultingのパートナーで、商用マインドマップサービスを提供する「MindMup」の共同創設者であるGojko Adzic氏と、インペリアル・カレッジ・ロンドンの主任研究員であるRobert Chatley氏によって2017年に発表された、AWS Lambdaに関する最初の学術論文の一つである 『Serverless Computing: Economic and Architectural Impact』 を読み。

現時点で発表当時(2017年)と取り巻く技術・背景が異なる部分はあるにせよ、サーバーレス・コンピューティングの適用によってもたらされる、経済的な影響・効果に関して、非常に示唆に富んでおり、重要なポイントを取り上げて、その効果を見ていきます。

本ブログの参考文献: Serverless Computing: Economic and Architectural Impact ,(参照:2020-02-11)

なお「そもそも、サーバーレスって何?」という方は、株式会社MMMコーポレートサイトに掲載されているコラム なぜサーバーレスが注目されているのか? をご一読ください。

2つのケース・スタディのサーバーレス移行によるビジネス影響を調査

論文では、MindMupと、SNSサービスを手掛けていたYublの2社をケース・スタディとしており、両社はアプリケーションをAWS Lambdaベースのサーバーレス・アーキテクチャへ移行したことによって、ホスティング費用が66% ~ 95%削減された結果 を踏まえ。

サーバーレス・アーキテクチャへの転換が、両社のビジネスにどのような影響を与えたのか?をまとめた内容となっています。

仮想サーバー比較で99.8%〜99.95%のホスティング費用削減の例

論文では若干極端な例が取り上げられていましたが。

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.

処理に200ミリ秒かかり、かつ5分毎ごとに実行するタスクがある例では、従来のクライアント/サーバ・アーキテクチャ前提の仮想サーバー環境と比較し、AWS Lambdaを用いたサーバーレスでは、 99.8%〜99.95%のホスティング費用削減 が記載されています。

重要なポイントは、単一の仮想サーバーでのコスト比較ではなく、実サービスで求められるシステムの可用性を考慮し、フェイルオーバーインスタンスも含めている箇所であり、AWS Lambdaにおいては、サービス可用性がプラットフォームによって担保されている。 という点もコスト差につながっています。

サーバレス・コンピューティングでは、顧客毎のような粒度ではなく、クラウド・プラットフォーム全体で、大規模な仮想コンテナ環境として、コンピューター資源の最適化が実施されており、このような、大規模、かつコンテナライゼーションによって、より効率的なコンピューター資源の利用が可能となり、利用者のコスト削減にも大きな影響を与えています。

旧来型のクライアント・サーバーモデルとの大きな違い

This is a major change from the traditional client/server model, where direct access from clients to back-end resources, such as storage, is a major security risk.

サーバーレス・コンピューティングでは、接続元のクライアントが、ストレージなどのシステムバックエンドに対し、直接アクセスを行うモデルを採用している点が、従来のクライアント・サーバーモデルとの大きな違いとしています。

本論文では、そのアクセスモデルの違いをAWSの認証機構を用いて、クライアント単位で詳細な権限モデルやセキュリティ保護の実装が行える点を紹介した上で。

The platform’s requirement for distributed request-level authorization causes us to remove components from our design, which would traditionally be required to perform the role of a gatekeeper, but here only make our system more complex and costly to operate.

分散型の認証を実装している昨今の新しいプラットフォームでは、従来のクライアントサーバーモデルで見られる、専用サーバーを使用し、アプリケーションとサービスを保護し、ブローカーとして機能するような「ゲートキーパー」は不要であり、これらはシステムを複雑化し、結果的に運用コストを増大させるものだと定義しています。

このアクセスモデルの違いにより、従来型のクライアント/サーバーモデルでは「処理」と「ストレージ」の両コストが発生するのに対し、サーバーレスのアプローチでは、Lambdaを使用し セキュリティを保持して、クライアントがイベントストアに直接続でき、処理コストが削減できる と結論づけています。

論文例に挙がっていたモバイル機器での分析や、無数の接続デバイスから連続的にデータ送信を行うケースが多い「Internet of things(IoT)」でもサーバーレス・アーキテクチャが採用される一つの要因として、この「分散型認証モデルを用いたバックエンドシステムへの直接接続のコスト優位性」があるのではないでしょうか。

MindMup、Yublでの実際の効果と検証

2つのケース・スタディで抱えていた課題と、解決へのアプローチ、結果を見ていきましょう。

ケース1. MindMup社

1つ目のMindMup社では、2016年にHerokuからAWS Lambdaに移行した後、まず、定型化されたコード(ボイラープレートコード)の大幅な削減が効果として挙げられており、システムのコア機能であるマインドマップ図の変換処理を通じて、HerokuとAWS Lambdaを比較しています。

Herokuでは、各ファイル変換処理はそれぞれ、メッセージキュー接続・切断と再接続、何らかの要因で失敗したタスクの再試行処理、ロギングと監視を全て独自に実装していたそうですが、AWS Lambdaに移行したことで、コアであるファイル変換以外の部分を廃止でき アプリケーション開発者がインフラではなく、ビジネスロジックに集中でき、削減された工数によって、新機能の実装に必要な時間の確保が可能 となったとのことです。

結果的にMindMup社のケースでは。

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.

AWS Lambdaへの移行によって アクティブユーザ数は50%以上増加したにも関わらず、ホスティングコストは50%弱減少。 そして、その年に多くの新サービスを追加しましたが、 最終的には66%の節約を実現したとのことです。

ケース2. Yubl社

2016年4月にSNSを展開していたYubl社は、Node.jsベースのバックエンドサービスをスマートフォンアプリに提供しており、各サービスは仮想サーバーで実行され、サービスの可用性を考慮し、複数の物理的に異なるデーターセンター(アベイラビリティーゾーン)に配備されていました。

SNSにおけるパターンとして、影響力のあるインフルエンサーや広告主がキャンペーンを実施したタイミングで、トラフィックが70倍に急増する可能性があり、Yubl社は、常時かなり余裕をもたせたシステムとしつつ、オートスケールを採用していましたが、スケールアップ時には平均で15分程度の時間を要していたそうです。

そこで課題解決に向け、経営陣と新スタッフによって、Yubl社は。

  • コスト効率が良い
  • インフラ維持コストを最小限に抑える
  • すばやく、頻繁に、独立して、ダウンタイムなしでデプロイを可能に

これらを新たな目標に掲げ、リニューアルを進めた結果。

That was compared to approximately $5000 per month for EC2 instances. 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.

バックエンドをLambdaに移行、多くの新機能を実装しても、サービスの月額使用料は200ドル以下となり、EC2の旧環境と同等の処理能力を保持しながらも、95%以上のコスト削減が推定されたとのことです。

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に移行後は、リリースの粒度を小さくできることで、問題が発生した場合に即座にロールバックでき、旧環境と比較して、デプロイが安全で、素早く、コストの少ないものになったと定義しています。

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

本論文ではサーバーレス・コンピューティングにより、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. システムの安価なバージョンニングを可能に

もう一つの「機会」としてAWS Lambdaの課金モデルと、Lambdaが有するバージョニング機構によって、開発者が顧客が利用するアプリケーションに対してバージョン管理が可能になるという点を取り上げています。

オンプレミス(自社保有)、サーバーホスティングやアプリケーションホスティングでは、複数のアプリケーションバージョンを同時に導入した場合、そのバージョン分だけ運用コストが比例して加算するため、ほとんどの企業では、A/Bテストなどより安価に実現可能な、フロントエンド領域のユーザーテストを適用していますが。

With AWS Lambda, there is no additional cost to operating multiple versions. For example, the cost for 10,000 requests going to a single version is the same as the cost of two groups of 5,000 requests each going to two different versions.

Lambdaでは、複数のバージョン運用の追加コストがかからず、例として単一バージョンに送信される1万個のリクエストと、異なるバージョンに送信される5,000個の要求コストは同一であると論文内で定義しています。

これらコスト的な制約を取り除くことによって、より実験的な攻めの事業運営が可能となり、開発者側でA/Bテストや段階的な機能リリースなどのテクニックを安価に使用できる機会が生み出されます。

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

本論文では、サーバーレス・コンピューティングの弱みと制約についても触れています。

Service Level Agreement(サービス提供レベルの確約)

No strong service-level agreements AWS Lambda is a relatively new service, so Amazon is not yet offering any uptime or operational service level agreements.

AWS LambdaにおけるアップタイムやSLA(Service Level Agreement)に関して言及がありましたが。

2018年10月に AWS Lambda がサービスレベルアグリーメント (SLA) を発表 されています。

よって、こちらの制約に関しては、論文執筆時点と比較して、可用性の観点からもAWS Lambdaを適用できる範囲は広がっています。

処理遅延の可能性

AWS Lambdaは、動作の仕様として、自動的に有効なインスタンス数を増減するため、場合によっては新しいリクエストを受け付けたタイミングで、処理に必要なインスタンスを作成する可能性があります。

このプロセスについては、開発者での制御できず、実行するアプリケーションの言語にも依存しますが、新インスタンスを生成時、約1秒〜10秒の時間を要する可能性があります。

この制約について、本論文では。

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.

このようなLambda側の制御によって、使用頻度が非常に低いサービスでは、一定の高い処理遅延が発生する可能性、また、頻繁にリクエストが発生するサービスであっても、多くの新インスタンスの生成や使用率の急上昇時には、遅延を発生させる可能性があるとしています。

なお、こちらで指摘されている処理遅延については、その後Lambda側の改良が続けられ、2019年にリリースされた Provisioned Concurrency for Lambda Functions によって対処できるケースもあります。

処理実行時間の制約

Lambdaの処理実行が最大5分であるという制約により、適用できるケースが制限されてしまう言及がありますが。

こちらの実行時間における制約については、2018年に AWS Lambda で最長 15 分間実行に要する関数の取扱いが可能に なっており、また AWS Step Functions などのサービス連携フレームワークを用いることで対処可能なケースもあります。

ローカルマシン上での開発環境制約

開発者が開発・テスト目的で、シミュレートされたLambda関数をローカルマシンで実行する方法がなく。多くの場合、開発フローの変更が必要となり、ローカルマシンで統合テストは不可能という制約について言及がありますが。

これら制約に関しては docker-image など仮想コンテナを活用し、ローカルマシン上にLambda環境をシミュレーションする方法や、テストが必要なビジネス上の重要なロジックをLambdaに依存しない形で実装を進めていくという方式などで対処可能なケースもあります。

ベンダーロックイン

サーバーレスでは、認証・構成管理から、バックエンドストレージやスケーリング、そして監視に至るまで、あらゆる機能を・プラットフォームが提供しており、プログラムのコードそのものはLambdaに依存しないものの、サーバレスとしてサービスを立ち上げる際には、アプリケーションがプラットフォームに大きく依存する形となります。

この点について、本論文では。

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.

サーバレス・アーキテクチャーでは、クライアントが、ストレージ・リソースやバックエンドシステムに直接接続する形であるため、実装されるコードがサーバーレスを提供するプラットフォーム・サービスと緊密に結合される形となり、事実上サーバーレス・アプリケーションを、他のクラウド基盤に移行することは、大きなコード改修が必要と制約を定義しています。

結論

本論文では、2つのケース・スタディでの実際の効果の検証・影響を考察した結果。

  • 短時間で、大量リクエストを捌くような「高スループット」が求められるケース(99.999%の稼働が求められるミッション・クリティカルなケースは除く)
  • サーバーレス特有の処理遅延(レイテンシー)がサービス上の大きな問題とならない

これらに該当するワークロードに対しては。

The economics of hosting such tasks in a serverless environment make it a compelling way to reduce hosting costs significantly, and to speed up time tomarket for delivery of new features.

サーバーレスで稼働させる事により 『ホスティング・コストを大幅に削減し、新機能の提供に要する時間を短縮する』 と結論づけています。

サーバーレス適用時のビジネス価値のふりかえり

論文での2つのケース・スタディにおいて、具体的なエビデンスと共にサーバーレスによって得られた成果として

  1. コンピューターリソース課金額の大幅な削減(課金モデルの変化によるコスト削減)
  2. 新機能開発・市場投入時間の短縮(ビジネス俊敏性の向上)

が共通して挙げられます。

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

また、その他のコスト最適化として、運用面での効率化があり、適切なスキルセット・経験を有したチームであれば、システム運用に必要となる投資額は、オンプレミス環境や仮想サーバーベースの旧来のインフラと比較しても、はるかに少ないのは明白です。

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

これまで見てきたように、サーバーレスでは製品開発におけるスピードを大幅に高速化できますが、その為には、サーバーレス・プラットフォームの特性・制約を深く理解した上で、適切な設計とアプリケーション開発のスキル・経験を有したチームが不可欠です。

MMMでは、多くのお客様に対して、ご紹介してきたサーバーレスの「価値」を届けることができるよう、AWS Lambdaを使ったサーバーレスアーキテクチャの構築・運用に関して実績を積み、知見を高める努力を行っています。

サーバーレスアーキテクチャ(AWS Lambda)

また、MMMは、AWS Lambdaに関する高い知見や実績が評価され、2019年11月に、日本で2社目となる AWS サービスデリバリープログラム(AWS Service Delivery Program)の「AWS Lambda」の認定 も受けています。

サーバーレスに関する疑問や相談のある方は、どうぞお気軽に お問い合わせ くださいませ。

このエントリーをはてなブックマークに追加

お問い合わせ

見積もり依頼や詳しいご相談など、クラウド・AWSに関する困りごとをお気軽にご相談ください。
以下のお問い合わせ先から受け付けています。

お問合わせはこちら

※通常1営業日内にご回答いたします。