Design and optimization of in constant query

従来、アプリケーションを構築するには、ECS インスタンスを購入し、オープンソースソフトウェアシステムを構築し、さらにそのメンテナンスを行う必要がありました。トラフィックの増減があるため、そのプロセス全体は非常に複雑で手間のかかるものでした。

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

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

この 10 年間、クラウド移行は確定的なトレンドとなっています。

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

開発者にとって、仮想マシンの機能と使い方は IDC の物理サーバーと変わりなく、既存のアプリケーションと技術スタックを変更することなくスムーズにクラウド移行できます。Cloud Hosting の戦略は、クラウド移行段階における企業のコアニーズに的確に応えたため、成功を収めました。

ますます多くの企業がクラウドに移行し、多くの企業システムが初日からクラウド上に構築されるようになるにつれ、企業のコアな注目点は、クラウドの能力をより効果的に活用していかに迅速に製品を市場に投入し、ビジネスの成功を達成するかに変化しました。

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

コンピューティング能力を電力のように普及させるには、クラウドコンピューティングに新たな形態が必要です。

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

次の 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 レベルの大量データを扱い、99.999999999% のデータ信頼性と 99.95% の可用性を保証し、多様化された階層的なデータストレージと処理能力を提供しています。

Alibaba Cloud Message Queuing RocketMQ は数億規模のピークメッセージを処理する試練を経てきました。これらのクラウドサービスは、柔軟性と信頼性の面で、企業がオープンソースソフトウェアを基に構築したシステムに比べて明らかな優位性を持っています。

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

プロバイダーがストレージ、コンピューティング、ミドルウェア、ビッグデータなどの分野でより多くのサーバーレスサービスを投入し、これらのサービスがイベント駆動型で密接に統合されるにつれ、クラウドは徐々にアプリケーション構築と運用のスーパープラットフォームへと進化し、アプリケーション研究開発モデルも組み立て型研究開発へとアップグレードされました。

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

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

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

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

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

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

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

2. ビジネス機能が密結合されており、ビジネスの反復要求についていけません。ローンチ戦略は流動的で、各リリースが大きな影響を与えます。

3. 負荷に明らかなピークとオフピークがあり、インスタンスが常駐しているため、リソース使用率が低くなっています。

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

サーバーレスは運用管理不要のため、ビジネスロジックの開発のみが必要であり、クライアント担当者が完全にリリースでき、チーム間の連携問題を回避できます。プラットフォームに組み込まれたアプリケーションのスムーズなリリース機能により、クライアント担当者は安心して迅速な反復とリリースを行えます。

配信戦略などのバックエンドサービスも関数単位に切り離され、ルールフィルタリング関数、疲労リマインダー関数、コンテンツアセンブリ関数などが含まれます。独立したバックエンドサービスとして開発と反復を行い、各リリースの影響を小さく抑え、影響範囲を制御します。

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

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

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

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

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

サーバーレスは 2012 年に提唱されて以来、2022 年の現在、IT 開発の主流となり、クラウドサービスプロバイダーのコア能力の主流となっています。

私たちは、サーバーレスシンギュラリティが到来したと考えています。いわゆるシンギュラリティとは、安定的な発展から高速な発展への転換点であり、業界が全面的に爆発し始めることを示しています。そして、私たちもこの変化を目撃する技術者の一世代となるのです。