Past and present life of Serverless

クラウドコンピューティングからサーバーレスアーキテクチャへ

こんにちは、Alibaba Cloud Serverless プロダクトマネージャーの Liu Yu です。皆様と一緒に、サーバーレスアーキテクチャの過去と現在を探っていきましょう。

クラウドコンピューティングからクラウドネイティブ、そしてサーバーレスアーキテクチャへ、技術の急速な発展には一定の法則があります。では、なぜサーバーレスアーキテクチャが生まれたのでしょうか。

クラウドコンピューティングの誕生

1946 年に世界初の汎用コンピュータ ENIAC が誕生して以来、コンピュータ科学技術の発展は止まることなく前進し続けています。近年では目まぐるしい変化があり、絶えずブレークスルーとイノベーションを続ける人工知能の分野、5G がさらなる機会をもたらす IoT の分野、そしてますます身近な存在となっているクラウドコンピューティングの分野があります。

図には 3 つのキーワードが見えます。2003 年から 2006 年にかけて、Google は 3 つの重要な論文を発表しました。これらの論文は、HDFS (分散ファイルシステム)、MapReduce (並列計算)、HBase (分散データベース) の技術基盤と将来の可能性を示し、クラウドコンピューティングの発展方向を正式に確立しました。これら 3 つの論文、あるいはこれら 3 つの技術について、「これらがあったからこそ、クラウドコンピューティングが正式に幕を開けた」と語る人もいます。

クラウドコンピューティングの発展は急速で誰もが認めるところです。しかし、クラウドコンピューティングの進展に伴い、もう一つの用語が生まれ、急速にトレンドの中心を占め、より広く注目されるようになりました。それがクラウドネイティブです。

クラウドコンピューティングとクラウドネイティブのテキスト構成構造を分析すると、クラウドネイティブは cloud と computing の間に native が加わったものと見ることができます。つまり、クラウドコンピューティングの急速な発展は、技術の進化であれ概念のアップグレードであれ、最終的によく知られたクラウドネイティブを生み出したと言えます。

クラウドコンピューティングとは何でしょうか。実は、クラウドコンピューティングの萌芽的概念は 1961 年に既に誕生していました。MIT の 100 周年記念式典で、1971 年のチューリング賞受賞者である John McCarthy が初めてある概念を提唱しました。この概念は後に、クラウドコンピューティングの「最初にして先進的な」夢想モデルとして語られるようになりました。将来、コンピュータは公共リソースとなり、生活の中の水道、電気、ガスのように誰もが利用できるようになるというものです。1996 年に「クラウドコンピューティング」という用語が正式に提唱されました。2009 年には、カリフォルニア大学バークレー校 (UC Berkeley) が論文でクラウドコンピューティングについてより詳細な説明を発表しました。その中で、クラウドコンピューティングは実現すべき長年の夢であり、インフラストラクチャとしてのコンピューティングという古くからの構想に新たな名前が付いたものであり、急速に商業的な現実になりつつあると述べられています。同時に、この論文ではクラウドコンピューティングを明確に定義しています。クラウドコンピューティングはインターネット上のアプリケーションサービスと、それらのサービスを提供するデータセンターのソフトウェアおよびハードウェア施設を含むというものです。

クラウドネイティブの台頭

現在、クラウドネイティブ技術も急速に発展しています。では、クラウドネイティブとは何でしょうか。「真のクラウドネイティブとは何か」という記事では、非常に明確な説明がなされています。クラウドから生まれ、クラウド上で成長し、クラウドに由来するソフトウェア、ハードウェア、アーキテクチャこそが真のクラウドネイティブであり、クラウドから生まれた技術がクラウドネイティブ技術です。つまり、クラウドに生まれ、クラウドで育ち、クラウドから生まれたものがクラウドネイティブなのです。

クラウドネイティブには何が含まれるでしょうか。クラウドネイティブという 3 文字と結びついた馴染みのある技術はすべてクラウドネイティブ関連技術です。たとえば、データベースならクラウドネイティブデータベース、ネットワークならクラウドネイティブネットワークなどです。CNCF Landscape には、クラウドネイティブファウンデーションによるクラウドネイティブプロダクトのディメンションが示されており、データベース、ストリーム、メッセージ、コンテナイメージ、サービスメッシュ、ゲートウェイ、K8S、そしてもちろん非常に注目されている用語である Serverless が含まれています。

サーバーレスアーキテクチャの登場

多くの場合、サーバーレスアーキテクチャは一種の接着剤と呼ばれます。他の多くのクラウドネイティブプロダクトとユーザーのビジネスを結びつけると同時に、非常に魅力的な技術的メリットを提供します。そのため、多くのプロジェクトやビジネスに採用されています。では、サーバーレスアーキテクチャとは何でしょうか。

Serverless の構造を見ると、伝えたい意図が容易にわかります。Server はサーバーを指し、Less は少なくするという意味です。つまり、サーバーレスアーキテクチャが伝える意図は、より専門的なことをより専門的な人に任せ、開発者がサーバーなどの基盤関連コンテンツに割く関心を減らし、より価値のあるビジネスロジックにより多くのエネルギーを注ぐことです。

2009 年、UC Berkeley はクラウドコンピューティングに関する論文を発表しました。その論文で UC Berkeley はクラウドコンピューティングを明確に定義し、サービスの可用性、データセキュリティ、監査可能性など、クラウドコンピューティングが直面する 10 の困難と課題を提示するとともに、クラウドコンピューティングが次の 10 年を牽引すると断言しました。

2019 年、ちょうど 10 年後に UC Berkeley は再び論文を発表しました。この論文では、複数の観点からサーバーレスアーキテクチャについて説明しています。たとえば、構造の観点から Serverless は FaaS と BaaS の組み合わせであることを肯定し、特徴の観点からサーバーレスアーキテクチャとみなされるプロダクトやサービスは従量課金モデルと弾力スケーラビリティの特徴を備えるべきだと指摘しました。また、Serverless がクラウド時代のデフォルトのコンピューティングパラダイムとなり、Serverful コンピューティングを置き換えるだろうと大胆に述べており、これはサーバークライアントモデルの終焉も意味します。

IaaS から PaaS、そして Serverless へ、クラウドコンピューティングの発展方向はますます明確になり、サーバーレス化のトレンドも一層顕著になっています。

この時点でクラウドネイティブについて話していてもサーバーレスアーキテクチャについて話していても、クラウドという概念は絶えずアップグレードされており、クラウド技術も継続的に進化しています。これらの変化はすべて、効率性の向上、セキュリティの向上、コスト削減、そして生産性の向上のためなのです。

サーバーレスアーキテクチャとは何か

サーバーレスアーキテクチャには明確な定義はありませんが、Serverless は FaaS と BaaS の組み合わせであるという見方が多くの人に受け入れられています。いわゆる FaaS は Function as a Service、BaaS は Backend as a Service です。両者が一体となってサーバーレスアーキテクチャの不可欠な一部となり、開発者にコスト削減と効率化の技術的メリットを提供します。

確かに、CNCF クラウドネイティブファウンデーションは Serverless ホワイトペーパーで、Serverless は FaaS と BaaS の組み合わせであると認めています。UC Berkeley も論文でこの見方を肯定する一方で、特徴の観点から、サーバーレスアーキテクチャとみなされるプロダクトやサービスには従量課金モデルと弾力的スケーリングの特徴も備わっている必要があると指摘しています。ただし、これは 2019 年時点での「記述」に過ぎません。

現在までに、サーバーレスアーキテクチャは「自己更新と進化」を遂げました。ICT Academy が発表した Serverless ホワイトペーパーでは、サーバーレスアーキテクチャのコンピューティングプラットフォームに関数ディメンションとアプリケーションディメンションの 2 つの形態が含まれると明確に指摘されています。時の経過とともに、Alibaba Cloud はいち早くサーバーレスアプリケーションエンジン (SAE) というアプリケーション指向のプラットフォームを業界に導入しました。つまり、これはサーバーレスアプリケーションのベストプラクティスと言えます。

ここまでで、サーバーレスアーキテクチャの構成は明確になりました。

・構造の観点から、Serverless はコンピューティングプラットフォームと BaaS プロダクトの組み合わせです。コンピューティングプラットフォームにはイベント駆動型の関数コンピューティングと、サーバーレスアプリケーションのベストプラクティスである Serverless App Engine (SAE) が含まれます。BaaS レイヤーには API 管理、CDN、オブジェクトストレージ、データベースなどのクラウドサービスが含まれます。

・特徴の観点から、UC Berkeley が述べたように、サーバーレスアーキテクチャとみなされるプロダクトやサービスには従量課金モデルと弾力スケーラビリティが必要です。

サーバーレスアーキテクチャと従来のアーキテクチャの違い

クラウド時代の新たなコンピューティングパラダイムとして、サーバーレスアーキテクチャは本質的に分散アーキテクチャに属します。その動作原理は従来のアーキテクチャと若干異なりますが、天地を覆すような変化ではありません。

図に示すように、従来のアーキテクチャでは、開発者がアプリケーションを開発した後、仮想マシンサービスを購入し、動作環境を整備し、必要なソフトウェア (MySQL などのデータベースソフトウェア、NGINX などのサーバーソフトウェア) をインストールする必要があります。環境が整ったら、開発したビジネスコードをアップロードしてアプリケーションを起動します。この時点で、ユーザーはネットワークリクエストを通じて目的のアプリケーションに正常にアクセスできます。しかし、アプリケーションのリクエスト数が多すぎる場合や少なすぎる場合、開発者や運用担当者は実際のリクエスト数に基づいて関連リソースをスケールアウトまたはスケールインし、負荷分散リバースプロキシモジュールに対応する戦略を追加して、スケーリング操作がタイムリーに有効になるよう確保する必要があります。同時に、これらの操作中にオンラインユーザーに影響を与えないようにする必要があります。

サーバーレスアーキテクチャでは、アプリケーション公開の全プロセスと動作原理がある程度変化します。

開発者がビジネスコードの開発を完了した後、対応する FaaS プラットフォームにデプロイまたは更新するだけで済みます。その後、実際のビジネスニーズに基づいて関連トリガーを設定できます。たとえば、HTTP トリガーを設定して外部向け Web アプリケーションサービスを提供できます。この時点で、ユーザーはネットワークを通じて開発者が公開したアプリケーションにアクセスできます。このプロセスにおいて、開発者は仮想マシンの購入や運用管理などの関連操作に追加で注目する必要がなく、一部のソフトウェアのインストールやアプリケーションリソースのスケーリングにも追加で注目する必要がありません。開発者は自身のビジネスロジックにのみ注目すればよいのです。従来のアーキテクチャでインストール・設定が必要だったさまざまなサーバーソフトウェアは、クラウドベンダーが管理する設定項目に変わりました。同様に、従来のアーキテクチャでのリソースのスケーリングはサーバーの使用率に基づいて行う必要がありますが、これらはすべてクラウドベンダーに自動的に委ねられています。

従来の意味での弾力的スケーリングとは、プロジェクトの容量計画と実際のクラスター負荷の間に矛盾が生じたとき、すなわち既存のクラスターのリソースが負荷に耐えられないときに、クラスターのサイズを調整するか対応するリソースをさらに割り当てることでビジネスの安定性を確保することです。クラスター負荷が低い時期には、クラスターへのリソース割り当てを可能な限り削減してアイドルリソースの無駄を減らし、さらにコストを節約できます。しかし、サーバーレスアーキテクチャでは、弾力的スケーリングがさらに一般化されています。すなわち、ユーザー側でのプロジェクト自体の容量計画プロセスがなくなり、リソースの増減は完全にプラットフォームのスケジューリングによって決定されます。

UC Berkeley の記事では、サーバーレスアーキテクチャの特徴とメリットについて次のような表現があります。「コード実行のために手動でリソースを割り当てる必要はもうない。サービス稼働に必要なリソース (マシン数、帯域幅、ディスク容量など) を指定する必要はなく、コードを提供するだけで残りは Serverless プラットフォームが処理する。現在の実装段階では、プラットフォームがリソースを割り当てる際に、ユーザーがいくつかの戦略を提供する必要がある。たとえば、単一インスタンスの仕様や最大同時実行数、単一インスタンスの最大 CPU 使用率などである。理想的な状況では、学習アルゴリズムを使用して完全自動の適応割り当てを行う。」実際、ここで著者が述べる「完全自動適応割り当て」とは、サーバーレスアーキテクチャの弾力スケーラビリティを指しています。

サーバーレスアーキテクチャでの弾力スケーリングとは、サーバーレスアーキテクチャがビジネスのトラフィック変動に応じて自動的にリソースを割り当て・破棄し、安定性、高パフォーマンス、リソース使用率の向上を最大化できることを意味します。つまり、開発者がビジネスロジックの開発を完了し、ビジネスコードを Serverless プラットフォームにデプロイした後、プラットフォームは通常すぐにコンピューティングリソースを割り当てるのではなく、ビジネスコード、設定、その他の関連コンテンツを永続化します。トラフィックリクエストが到来すると、Serverless プラットフォームは実際のトラフィックと設定に基づいて自動的にインスタンスを起動します。逆の場合も同様で、場合によってはインスタンス数を 0 に減らすこともできます。つまり、プラットフォームが対応する関数にリソースを割り当てないのです。

サーバーレスアーキテクチャの中核的な技術的メリットである弾力スケーラビリティは、ある程度、リソース使用率の向上とグリーンコンピューティングへの移行プロセスを体現しています。

上記の図の弾力スケーリング部分で、左側は従来の仮想マシンアーキテクチャでのトラフィックとマシン負荷の図、右側はサーバーレスアーキテクチャの弾力モードでのトラフィックと負荷の図です。これら 2 つの図で、オレンジ色の部分はユーザー側が知覚するリソース負荷能力を表し、青い線はある日のウェブサイトのトラフィック推移を表しています。これら 2 つの図を比較すると、従来の仮想マシンアーキテクチャでは手動でリソースの増減を行う必要があり、変更の粒度はホストレベルであるため、実装は深刻な試練に直面することがわかります。粒度が粗すぎると、リソースの無駄とパフォーマンスの安定性の関係を効果的に均衡させることができません。

図の中で、青い線の上のオレンジ色の部分が無駄なリソースです。右側はサーバーレスアーキテクチャの弾力モードでのトラフィックと負荷の図です。この図では、負荷能力が常にトラフィックと一致していることが明確に見て取れます。つまり、左側の従来の仮想マシンアーキテクチャとは異なり、技術者の手動介入なしにトラフィックのピークと谷に対処する必要がありません。すべての弾力性 (スケールアウトとスケールインを含む) はクラウドベンダーによって提供されます。このモードがもたらすメリットは、一方では運用担当者のプレッシャーを軽減し、作業の複雑さを低減することです。他方では、ユーザーの知覚から、実際のリソース消費が必要なリソース消費と正の相関関係にあり、リソースの無駄を大幅に削減できることがわかります。これはある程度、グリーンコンピューティングの理念にも合致しています。

いわゆる従量課金モデルとは、使用した分だけ支払う課金方法です。従量課金により、ユーザーは事前に大量のリソースを購入する必要がなく、使用しながら支払うことができます。非 Serverless プロダクトやサービスでも、ある程度の従量課金機能を備えています。たとえば、仮想マシンなどのプロダクトにも従量課金のオプションがあります。しかし、サーバーレスアーキテクチャが従量課金を技術的メリットとして取り上げられる理由は、従量課金の粒度がより細かく、ユーザー側のリソース使用率がほぼ 100% に近いからです (実際にはリソース使用率が 100% に達するわけではなく、これはサーバーレスアーキテクチャ下でのリクエスト粒度におけるユーザー側の知覚のみを指します)。

ウェブサイトを例に取ると、昼間はリソース使用率が高く、夜間は比較的低くなります。しかし、サーバーなどのリソースを購入すると、実際にはその日のトラフィック量に関わらず、コストは継続的な支出プロセスとなります。従量課金モデルを採用しても、課金粒度が粗すぎてリソース使用率を最大化することができません。Forbes 誌の統計によると、商用およびエンタープライズデータセンターの典型的なサーバーは、平均最大処理能力の 5% から 15% の出力しか提供しておらず、これは従来のサーバーにおけるリソース使用率の低さと過剰な浪費を疑いなく証明しています。

サーバーレスアーキテクチャの登場により、ユーザーはサーバー、データベース、アプリケーション、さらにはロジックの管理をサービスプロバイダーに委託できるようになりました。このアプローチは、一方ではユーザー自身のメンテナンスの煩わしさを軽減し、他方ではユーザーが実際の関数の粒度に基づいてコストを支払うことを可能にします。サービスプロバイダーにとっては、より多くのアイドルリソースに追加処理を行うことができ、コストとグリーンコンピューティングの観点から非常に有利です。他方、サーバーレスアーキテクチャの従量課金モデルもリソース使用量に基づいて課金されますが、課金粒度がより細かくなっています。

・リクエスト数の観点：サーバーレスアーキテクチャの課金粒度はリクエストレベルであるのに対し、従来の仮想マシンなどのアーキテクチャの課金粒度はインスタンスレベルです (多くの場合、このインスタンスレベルでサポートされるリクエスト数は 1 よりもはるかに大きい)。

・課金時間の観点：サーバーレスアーキテクチャの課金時間は通常秒レベルです (現在、Alibaba Cloud はミリ秒または 100 ミリ秒の課金をサポートしています)。従来の仮想マシンアーキテクチャでは、課金時間の粒度は通常時間レベルです。

上記の図のボリューム部分は、ウェブサイトの 1 日のトラフィックグラフです。図の青い破線はある日のウェブサイトのトラフィック推移を示しています。「従来の仮想マシンアーキテクチャのトラフィックと費用の図」と「サーバーレスアーキテクチャの弾力モデルでの費用の図」を比較すると、左側の従来の仮想マシンアーキテクチャのトラフィックと費用の図では、ビジネスは通常本番環境に移行する前にリソース使用量の評価を行う必要があることがわかります。ウェブサイトのリソース使用量評価後、1 時間あたり最大 1,300 PV に耐えられるサーバーを購入するため、このサーバーが提供するコンピューティング能力の総量はオレンジ色の部分となり、費用も 1 日を通してオレンジ色の部分に対応するコンピューティング能力のコストとなります。しかし、実際に有効なリソース使用とコスト支出はトラフィック曲線より下の部分のみであり、トラフィック曲線より上のオレンジ色の部分はリソース損失と追加支出であることが明確に見て取れます。一方、右側のサーバーレスアーキテクチャの弾力モデルでの費用の図では、費用は基本的にトラフィックに比例しています。つまり、トラフィックが低いレベルのときは対応するリソース使用量が少なく、費用も比較的小さくなります。トラフィックが比較的高い値のときは、サーバーレスアーキテクチャの弾力スケーラビリティと従量課金機能により、リソース使用量と費用が正の相関で増加します。全体のプロセスを通して、左側の従来の仮想マシンアーキテクチャのトラフィックと費用の図に見られるような明らかなリソースの無駄や追加コスト支出が存在しないことが明確に見て取れます。

動画アプリケーション、ソーシャルアプリケーションなどのシナリオでは、ユーザーが画像、音声、動画を高頻度で大量にアップロードすることが多く、処理システムには高いリアルタイム性と同時実行性が求められます。たとえば、ユーザーがアップロードした画像に対して、複数の関数を使用して個別に処理を行えます。画像圧縮、フォーマット変換、コンテンツモデレーションなどが含まれ、異なるシナリオのニーズを満たします。たとえば：

さらに、Serverless はリアルタイムファイル処理、リアルタイムストリーム処理、機械学習、IoT バックエンド、モバイルアプリケーションバックエンド、Web アプリケーションなどのシナリオでも活躍できます。

世界をリードする Serverless プラットフォーム

Alibaba Cloud は国内でいち早く Serverless サービスを提供したメーカーの一つです。過去数年間、Alibaba Cloud は実践において顕著な成果を上げてきました。たとえば、Alibaba Cloud の Serverless プロダクト能力は 2021 年第 1 四半期の Forrester 評価で中国 1 位にランクされました。CNCF の 2020 年クラウドネイティブ調査レポートでは、Alibaba Cloud Serverless が中国最大の市場シェアを獲得しています。また、中国情報通信研究院の 2020 年中国クラウドネイティブユーザー調査レポートでも、Alibaba Cloud Serverless のユーザー数が中国 1 位となりました。

Alibaba Cloud Serverless のプロダクトとサービスが開発者に認められている理由は、安全なアーキテクチャと先導的な技術を基盤に、ユーザー中心の姿勢を堅持していることにあります。

Alibaba Cloud Serverless のプロダクトレイアウト

上記の図から、最下層がコンピューティングプラットフォームと BaaS プロダクトレイヤーであることがわかります。コンピューティングプロダクト部分には、イベント駆動型の関数コンピューティング FC と、サーバーレスアプリケーションのベストプラクティスである Serverless App Engine (SAE) があります。BaaS サービス連携部分には、サービス、データベース、ネットワーク、メッセージなど異なるレベルのプロダクトがあり、これらのプロダクトもクラウドからクラウドネイティブを経て Serverless へと進化しています。上位レイヤーには開発者向けツールとアプリケーションセンターがあり、フロントエンド統合、Web API、データベース処理、AI 推論など、開発者向けの一連の All On Serverless ソリューションとシナリオを提供しています。

Serverless をよりシンプルに：Serverless Devs

生態系レベルでは、Alibaba Cloud Serverless チームはベンダーロックインのないオープンソースツール Serverless Devs をリリースしました。Serverless Devs は Serverless をよりシンプルにするという姿勢を堅持し、Serverless アプリケーションの全ライフサイクルで役割を果たすことができます。Serverless Devs は、基盤仕様モデルにおいて中国情報通信研究院と共に Serverless ツールチェーンモデルをリリースすることを推進するだけでなく、ツールレベルでは CNCF Sandbox にプロジェクトを寄付し、CNCF Serverless Tools 分野で世界初の Sandbox プロジェクトとなりました。

まとめると、われわれはサーバーレスアーキテクチャの構築に真摯かつ専門的に取り組んでいます。感動的なプロダクト、優れたツール、責任ある仕事、実用的かつ革新的なコンテンツを目指しています。Alibaba Cloud サーバーレスアーキテクチャへのご注目ありがとうございます。