The Serverless Singularity Has Arrived

従来、アプリケーションを構築するには、ECS インスタンスを購入し、オープンソースのソフトウェアシステムを構築し、さらにそれを運用保守する必要がありました。トラフィックの増減がある中で、そのプロセス全体は非常に複雑かつ煩雑でした。

サーバーレスサービスを利用することで、これらの課題が簡素化されました。セミマネージドからフルマネージドまで、すべてのサービスは API ベースで、無制限のキャパシティは完全に柔軟であり、組み立てて使用でき、生産性は大きく変化しました。同時に、ソフトウェア開発モデルのアップグレードを推進し、組立式研究開発が主流となります。

Alibaba Cloud のサーバーレスに関する全体的な知見に基づき、アリババの研究員であり、Alibaba Cloud のインテリジェントクラウドネイティブアプリケーションプラットフォームのゼネラルマネージャーである丁宇（書桐）が、エンタープライズアプリケーションアーキテクチャの進化とサーバーレスの台頭がもたらす業界の変化について詳しく解説しました。

過去 10 年間、クラウド移行は確実なトレンドとなっています。

クラウド移行期において、企業はスムーズなクラウド移行の実現に注力していたため、クラウドベンダーはクラウドホスティングをコア戦略として位置づけていました。クラウドの主な形態はリソースベースのサービスであり、仮想マシンの形で企業に大規模なコンピューティング能力を提供していました。

開発者にとって、仮想マシンの機能と使い方は IDC の物理サーバーと何ら変わりがなく、既存のアプリケーションと技術スタックを変更せずにスムーズにクラウド移行できました。クラウドホスティングの戦略は、クラウド移行期における企業のコアニーズを満たし、成功を収めました。

クラウドに移行する企業が増え、多くの企業システムが最初からクラウド上で構築されるようになると、企業のコアな関心事は、クラウドの機能をどのように活用して製品を迅速に市場に投入し、ビジネスの成功を達成するかに変化しました。

これにより、次の段階のクラウド開発の主な目標は、自社の強みを活かして大規模かつ複雑なアプリケーションの開発と運用保守の課題を解決することに変化しました。しかし、コンピューティング能力の形態が依然としてサーバーなどのリベースの形態である場合、利用のハードルは依然として高いままです。コンピューティング能力とビジネスの距離が遠く、企業はコンピューティング能力を有効活用するために包括的なインフラストラクチャを必要とします。

コンピューティング能力を電気のように手軽にするには、クラウドコンピューティングに新しい形態が必要です。

クラウドサービスの役割は大きく変化します。単にリソースを提供するだけでなく、企業がアプリケーションを構築するための新しいプラットフォームとなる必要があります。マシンの運用保守のような低付加価値の反復作業を最小限に抑え、ビジネス革新に集中できるよう支援することが求められます。

これからの 10 年間は、クラウドが自らの能力を進化させ、企業がクラウドを有効活用できるよう支援する段階です。クラウドベンダーの中核となる能力はサーバーレスクラウドサービスです。

なぜサーバーレスを選ぶのか

サーバーレスサービスはフルマネージド

クラウドベンダーは、ストレージコンピューティング分離、ハードウェアとソフトウェアの共同最適化などの基盤技術を通じて、サービスのリソース効率とパフォーマンスを大規模に向上させることができます。Alibaba Cloud のストレージサービスを例に取ると、2018 年から RDMA 技術が大規模に採用され、Solar-RDMA プロトコルや HPCC フロー制御、エンドネットワーク統合技術が開発されました。

ネットワークとストレージの協調設計により、FPGA のハードウェアアクセラレーションによる圧縮アルゴリズムと組み合わせ、安定したマイクロ秒レベルの読み書き性能を実現しています。企業はサービス API を呼び出すだけで、クラウドベンダーの各分野における専門知識を活用し、技術の恩恵を受けることができます。

サーバーレスサービスは適応型の弾力スケーラビリティを備え、企業アプリケーションが予測不能なビジネス負荷や急激な負荷変動によりスムーズに対応できるようにします。

典型的な業務システムは、アプリケーション層、アクセス層、リソース層に分けられます。リソースベースのクラウドサービスはリソース層の柔軟性のみを提供するため、企業はアクセス層とアプリケーション層の柔軟性も実現し、ビジネスのフルリンク弾力性を達成する必要があります。

1) アーキテクチャ設計段階

各コンポーネントの依存関係に基づき、弾力的スケーリングと流量制限・デグレーデーションの策を定めます。リレーショナルデータベースのように柔軟性の低いサービスについては、一般的に向こう 3 年間のデータベースの書き込み・読み取り規模を予測し、データベース分割やテーブル分割を行う必要があります。

2) リソースプランニング段階

各コンポーネントのスケーリングの難易度、スケーリングの速度、ビジネス負荷の変化の速さなどの要素を考慮し、冗長リソースを通じて対応する柔軟性を実現します。アクセス層のリソースはシステム全体に占める割合が低く、冗長リソースを維持するコストも高くなく、容易に拡張できます。アプリケーション層のリソースプランニングは最も難易度が高いです。アプリケーション層は最もリソース消費が大きく、通常、冗長リソースで負荷ピークに対応することは許可されません。さらに、アプリケーション層のスケーリングは上流および下流の連携を伴い、複雑性が非常に高くなります。また、アプリケーション層の各サービスのトラフィック規模は異なるため、明確に整理し、ホットリンクの冗長リソースプランニングに重点を置く必要があります。

3) オンライン運用段階

完全な可観測性を通じて、リンクのトラフィックを定量化し、ホットスポットを検出し、動的にスケーリングを実行し、ホットリンクのトラフィックを再定量し、クローズドループで動的スケーリングを継続するかどうかを判断します。さらに、完全かつタイムリーなモニタリングとアラームも非常に重要です。異なるコンポーネントに対して異なるホットフローのしきい値を設定し、ホットフローが検出された後、関連するコンポーネントの開発・運用担当者にタイムリーに通知し、事前に定めた策に従って処理する必要があります。

リソース層の弾力性のみでビジネス全体のレジリエンスを構築する複雑性は非常に高いことがわかります。サーバーレスサービスの適応型の弾力スケーラビリティの目標は、複雑性を簡素化し、企業がより容易にビジネスの柔軟性を実現できるようにすることです。

まず、クラウドベンダーは多数のミドルウェア、データベース、ビッグデータなどの BaaS ベースのサービスをサーバーレス化します。データベースを例に取ると、NoSQL のような柔軟性の高いデータベースサービスを提供するだけでなく、従来のリレーショナルデータベースもサーバーレス化します。

次に、サーバーレスコンピューティングサービスは通常、100 ミリ秒から秒レベルのインスタンス起動速度を持ち、毎秒数千から数万のインスタンスを起動し、高度に自動化された弾力スケーラビリティを備えています。サーバーレス BaaS サービスと組み合わせることで、フルリンクのビジネス柔軟性を実現します。

最後に、サーバーレスサービスは通常、流量制限とデグレーデーションの機能を備えており、企業リソースを制御可能にし、システム全体の障害連鎖問題に容易に対処できるようにします。

リソースを効率的に活用する方法は、企業が共通して直面する課題です。業界のデータセンターの統計によると、企業の全体的な平均リソース使用率は高くなく、一般的に 15% 未満です。リソース使用率を改善するために、企業は一般的に以下の課題に直面しています。

・各事業部門のリソース使用は相互に独立しており、リソースプーリングや統一スケジューリングが行われていません。

・パフォーマンス、ピーク負荷、将来のビジネス成長への備えなどの要素を考慮し、事業部門はより多くのリソースを申請する傾向があり、通常、実際の使用量の 3〜5 倍です。

・コアではないアプリケーションの断片化されたリソース消費が大量のリソース浪費につながっています。高可用性の要件を満たすため、多くのコアではないアプリケーションが少なくとも 2〜3 台のサーバーを必要としますが、これらのアプリケーションは低頻度で呼び出されるロングテール型が多く、サービス停止後もサーバーの解放を忘れることでリソース浪費が発生します。Alibaba Group では、コアではないアプリケーションのリソース消費がコアアプリケーションを上回っています。

・異なる性質のアプリケーション間で共有リソースがなく、ピーク負荷平準化が行われておらず、クラスター全体の平均リソース使用率が高くない状態です。

コンテナ化はリソース使用率を改善する効果的な手段ですが、実装は比較的複雑です。Alibaba Group は、フルスタックのコンテナ化、統一スケジューリング、オフライン混在デプロイメントを通じて、リソースの全体的な使用率を向上させています。これには、コンテナのパフォーマンス最適化、テナント分離、基盤サーバーのコンピューティング能力正規化、カスタマイズされた統一スケジューリングとオフライン混在デプロイメントなどが含まれます。

サーバーレスの目標は、企業がよりシンプルな方法でリソース使用率を改善し、コストを削減できるようにすることです。

Function Compute を例に取ると、企業はアイドル状態のリソースに対して課金されるのではなく、実際に使用したリソースに対してのみ課金されます。これは、大量のテスト環境、プレリリース環境、本番環境、および多くのコアではないアプリケーションの断片化されたリソース使用シナリオにおいて、サーバーレスを使用後のリソース使用率が非常に高くなることを意味します。

パフォーマンス面では、一部のリソースを事前予約する必要がありますが、Function Compute のアイドルリソースコストはサーバーよりも低くなります。Function Compute にはマルチ AZ のディザスタトレランス機能が組み込まれており、企業はディザスタトレランス用の冗長リソースを準備する必要がありません。Function Compute は 100 ミリ秒レベルの弾力的スケーリング速度と豊富なスケーリングルールをサポートしており、企業はピーク負荷用にリソースを予約する必要がありません。

クラウドサービスがサーバーレスの形態に進化すると、企業の利用ハードルが大幅に下がり、サーバーレスはコンピューティング能力を電気のように手軽にします。

開発モデルのアップグレードを推進する

アプリケーションアーキテクチャと開発モデルの進化は、主に企業のビジネス成長要求によって推進されています。企業は常に、ビジネス規模と複雑性の増大に対応し、製品をより速く市場に投入し、ビジネス革新の速度を加速するために、より俊敏であることを求めており、これには大規模かつ複雑なソフトウェアの迅速なイテレーションを支援する技術が必要です。

従来のエンタープライズレベルのアプリケーションアーキテクチャは通常モノリシックです。すべてのモジュールが結合され、同時にリリースされます。このモノリシックアーキテクチャは初期段階では管理しやすいですが、ビジネスの発展に伴い、大きな複雑性を生み出します。この密結合アーキテクチャは、開発、テスト、運用保守の各段階で多くのコンフリクトを引き起こし、イテレーション全体のスピードを低下させます。

たとえば、アプリケーション全体の開発ではすべてのモジュールが統一された言語とフレームワークの技術スタックを採用する必要があります。基本ライブラリが複数のモジュールで共有されている場合、1 つのモジュールが新バージョンにアップグレードしたい場合、他のモジュールが新バージョンを必要としていなくても、すべてのモジュールを同時にアップグレードするように説得する必要があります。すべてのモジュールのリリースサイクルが強制的に同期され、1 つのモジュールの問題がアプリケーション全体のリリースに影響を与えます。

あるモジュールのオンライン問題を迅速に修正することも非常に困難です。進行中の他のモジュールの変更とマージし、コンフリクトを解決し、アプリケーション全体を再リリースし、すべてのテストを実行してからでないとオンラインに再リリースできません。モノリシックアプリケーションアーキテクチャはソフトウェア開発効率の要件を満たせなくなり、マイクロサービスを中心としたインターネット分散アーキテクチャに取って代わられました。

マイクロサービスアーキテクチャを採用すると、アプリケーションは独立したサービスで構成されます。これらのサービスは疎結合で、API 呼び出し、イベントトリガー、またはデータフローを通じてやり取りします。各サービスは特定の機能を担い、独立して開発、実行、公開されます。

マイクロサービスはモノリシックアーキテクチャの開発効率のボトルネックを解決しますが、アプリケーションインフラに対して非常に高い要求を突きつけます。

たとえば、独立して開発されたマイクロサービスが期待通りに連携できるようにするには、詳細な結合テストとエンドツーエンドテストが必要です。テスト環境でのアプリケーションデプロイ数は通常、本番環境の 10 倍です。アプリケーションインフラが独立したテスト環境を迅速に提供できない場合、大量のテスト時間が環境の安定性問題の解決に消費されます。

Alibaba Group の研究開発統計によると、1 人日の開発は通常 5〜7 人日のテストに対応しています。テスト環境は Alibaba Group の研究開発における最大の課題となっています。

マイクロサービスの疎結合は、データベースの利用、状態管理、問題診断、アプリケーションのデリバリーパイプラインにも大きな課題をもたらしています。業界ではマイクロサービスの複雑性と解決策について多くの議論がなされているため、ここでは繰り返しません。

マイクロサービスを中心としたインターネット分散アーキテクチャの実装は複雑であり、優れたツールとプラットフォームによるサポートが不可欠であるというのは業界の共通認識です。

マイクロサービスアーキテクチャに加え、企業はリアクティブアーキテクチャやイベント駆動型アーキテクチャなどのモデルも広く使用しています。これらのアーキテクチャは疎結合や俊敏な開発などのメリットをもたらしましたが、実装の複雑さもそれに応じて増大しました。

実際、業界ではアプリケーションの構築、オーケストレーション、運用、BaaS サービス、インフラ管理の各分野で豊富な製品とソリューションが提供されており、大規模なエコシステムが構築されています。しかし、これらのソフトウェアやサービスを統合し、柔軟で安定的かつ一体化させて、アプリケーションの開発イテレーションを加速することは容易ではありません。

クラウドを有効活用する段階において、クラウドの使命はこの複雑性を排除し、大規模かつ複雑なソフトウェア開発の質的飛躍を実現し、企業が技術の壁を打破できるよう支援することです。

各サーバーレスサービスは、当該分野におけるベンダーの能力を外部に提供したものです。サービス API を通じて機能を公開し、信頼性、柔軟性、パフォーマンスなどの能力指標を保証しています。そのため、これらは高品質なアプリケーション構築ブロックと言えます。

たとえば、Alibaba Cloud の OSS サービスは EB レベルの海量データを処理し、11 桁のデータ信頼性、99.95% の可用性、および多様な階層型データストレージと処理能力を保証しています。

Alibaba Cloud Message Queuing RocketMQ は、双十一等の超大规模トラフィックの洗礼を受けています。これらのクラウドサービスは、柔軟性と信頼性の面で、企業がオープンソースソフトウェアに基づいて構築したシステムと比べて明確な優位性を持っています。

クラウドベンダーだけでなく、多数のオープンソース商用製品もサーバーレスモデルを採用しています。Confluent Cloud、MongoDB Atlas、Snowflake、Databricks などが含まれます。

ストレージ、コンピューティング、ミドルウェア、ビッグデータなどの分野でサーバーレスサービスが増え続け、これらのサービスがイベント駆動型で緊密に連携されることで、クラウドはアプリケーションの構築と運用のためのスーパープラットフォームへと進化し、アプリケーション開発モデルも組立式研究開発へとアップグレードされました。

クラウドをアプリケーション構築の最適なプラットフォームに

Alibaba Cloud がますます包括的なサーバーレスプロダクトを提供するようになり、多くのクラウドプロダクトがモジュール化、API 化、サービス化されました。組み立てが可能で、アプリケーションをドラッグ＆ドロップで構築できます。

サーバーレスアーキテクチャでは、開発方法は組立式研究開発にアップグレードされ、プロセスオーケストレーション、イベント駆動型、さらには可視化を実現し、従来のソフトウェア開発方法を完全に刷新して、開発効率を大幅に向上させ、ビジネス上の課題に柔軟に対応します。権威ある機関の調査統計によると、組立式研究開発は従来のモデルと比べて開発効率を 50% 以上向上させることができます。

新興のインターネットスタートアップから大規模ソフトウェアを構築する伝統的な企業まで、サーバーレスアーキテクチャと組立式研究開発を活用できます。

Amap を例に取ると、そのローンチビジネスはユーザーの生活シーンと密接に関連しており、機能は変化に富んでいます。推奨される下流のビジネスカテゴリは急速に成長し、ビジネス戦略は可変です。さらに、ビジネス全体がユーザーの移動と密接に関連しており、明らかなピーク・オフピーク属性を持っています。

ビジネスの成長に伴い、ローンチプラットフォームの元のアーキテクチャはいくつかの明確な課題に直面しています。

1. クライアントの肥大化。カード処理、ナビゲーション計画、ページ表示などのロジックがすべて Web またはモバイルデバイス上に配置されており、クライアントのリリースが遅く、コードが肥大化しています。

2. ビジネス機能が密結合されており、ビジネスのイテレーション要件に追いつけません。ローンチ戦略は変化に富み、各リリースの影響が大きくなります。

3. 負荷に明らかなピークと谷があり、インスタンスが常駐し、リソース使用率が低くなります。

サーバーレスアーキテクチャはこれらの課題をうまく解決できます。まず、クライアントを軽量化し、エンド上のロジックの大部分を BFF 層 (Backends for Frontend) に移行します。

サーバーレスコンピューティングは運用保守が不要で、ビジネスロジックの開発だけで済み、クライアント担当者が完全にリリースできるため、チーム間のコラボレーション問題を回避できます。プラットフォームに組み込まれたアプリケーションのスムーズなリリース機能により、クライアント担当者は安心して迅速にイテレーションとリリースを行えます。

デプロイ戦略などのバックエンドサービスも関数にデカップリングされ、ルールフィルタリング関数、疲労リマインダー関数、コンテンツアセンブリ関数などが含まれます。独立したバックエンドサービスとして開発・イテレーションされるため、各リリースへの影響は小さく、影響範囲を制御できます。

ホットスポットロジックと上流・下流の依存関係を丁寧に整理することで、フルリンク弾力性とインターフェースレベルの流量制御機能を実現しました。弾力スケーリングは高速かつ安全で、リソース量は負荷のピークと谷に一致し、効率性が高くなります。

現在、サーバーレスアーキテクチャに基づく Amap のビジネスデプロイプラットフォームは本番トラフィックの 100% を処理し、ビジネス規模は 100 万 QPS に達し、デプロイ時間は数日から数時間に短縮され、全体コストは 38% 削減されました。

サーバーレスシンギュラリティの到来

クラウドコンピューティングの先駆者たちは、これからの 10 年間のクラウドコンピューティングのデフォルトのコンピューティングパラダイムはサーバーレスだと信じています。

2021 年に DataDog がリリースしたサーバーレス研究レポートのデータによると、クラウドベースのスタートアップから大企業までがサーバーレスに注目しており、サーバーレスエコシステムは FaaS を超えて数十のサービスを含むまでに拡大し、開発者がより迅速で動的なアプリケーションを構築するのに役立っています。

サーバーレスは 2012 年に提唱されてから 2022 年までの 10 年間で、今日の IT 開発の主流となり、クラウドサービスプロバイダーの能力の主流となりました。

サーバーレスシンギュラリティが到来したと確信しています。いわゆるシンギュラリティとは、安定期から高速成長期への転換点を指し、業界が全面的に爆発的に成長し始めることを示しています。そして、我々もこの変革を目の当たりにする技術者世代となるでしょう。