How can enterprises use Serverless to rapidly expand business systems?

技術アップグレードからコスト削減と効率化まで

皆様、こんにちは。本日の Serverless のトピックを皆様と共有できることを大変嬉しく思います。

前回の解説では、多くの方々が本日の会場にお越しいただき、Serverless について学ぶ機会を持っていただいたことを確認しました。Serverless イベント駆動エコシステム、非同期システム、Serverless ワークフローの研究開発ディレクターとして、本日の共有が皆様に Serverless の背後にある技術原理と、Serverless がどのように企業の成本削減と効率化の目標達成を支援するかを理解するお役に立てれば幸いです。

同時に、企業がコンテナ化から Serverless への移行段階にある際に、Serverless を活用した技術アップグレード、アーキテクチャ変革、コスト削減と効率化を実現するためのベストプラクティスガイダンスも共有します。最後に、実際の運用環境で使用されている Serverless の顧客事例を紹介し、運用プロセスでの Serverless の活用方法とビジネス上の課題解決への理解を深めていただきます。

企業技術アップグレードのコア駆動力と課題

企業技術アップグレードのコア駆動力

まず、企業の運用プロセスにおける技術アップグレードの 3 つのコア駆動力を理解しましょう：

・1 つ目は、急速なビジネス成長と IT ケイパビリティ不足の矛盾による駆動力です。新興ビジネスが到来した際、ビジネスの不確実性により、事前にビジネスを予測・計画し、IT レベルでの基盤準備を行うことは困難です。企業は非常に短い期間で急速なビジネス成長を支える IT ケイパビリティを備える必要があります。

・2 つ目は、研究開発による効率向上です。研究開発の効率は技術的な手段で向上させることができ、または人員の最適化を通じて目的を達成することもできます。

・3 つ目は、企業 IT コスト最適化の需要です。比較的初期の開発段階でも、安定的なビジネス成長段階でも、企業の存続や収支均衡を実現するためには、コストを重視し、コスト削減の需要に駆動されて技術アップグレードを求めます。

企業アプリケーション開発の課題

「Serverless の過去と現在」という記事は、Serverless がなぜ生まれたのか、どのようなコア課題を解決しようとしているのかを理解するための良い伏線を提供します。企業開発のコア目標に戻ると、ビジネスロジックをより迅速に実装し、環境構築とシステム連携に費やす開発時間を削減し、ビジネス開発により多くの時間を集中させることです。

開発完了後、開発したビジネスコードをデプロイしてサービスを提供する実行環境が必要であり、実行プロセスに伴う関連メンテナンス作業、すなわち運用保守も含まれます。このプロセス全体（一般的に DevOps と呼ばれるもの）において、開発と運用保守に携わるすべての方が明確に感じている課題、すなわち企業の研究開発効率の問題が存在します。

研究開発効率に加えて、企業にとって非常に重要なもう一つの要素は研究開発コストの問題です。ここでは、企業研究開発における IT コストのみを議論します。理想的なモデルは、実際にビジネス価値を生み出すコンピューティングに対してのみ課金することです。しかし通常、実際にビジネス価値を生み出すコンピューティングはビジネスリクエストのライフサイクルと一致しており、実際のビジネスリクエストが到来する前やリクエストの合間にも、保持しているコンピューティングリソースに対して課金し続ける必要があります。これらの時間帯においてビジネスにとってコンピューティングリソースはアイドル状態ですが、これこそ Serverless がリクエスト単位の課金を実現し、顧客のコスト削減を図りたいと考えている需要です。

リクエスト単位の課金をより良く理解するために、K8s または ECS の課金モデルを例に挙げます。K8s を購入すると、それに対して課金する必要があります。Pod を作成すると、クラスターからリソースが割り当てられます。リクエストトラフィックが到来していない時でも、Pod リソースに対して課金し続ける必要があります。

Serverless では、コードを提供してプラットフォーム上にデプロイします。コードパッケージとコンテナイメージは Serverless プラットフォーム上にデプロイされており、ウォームアップ中、実行中、またはスタンバイ状態にある場合があります。しかし、実際のリクエストが到来する前の期間や、2 つのリクエスト呼び出しの合間には、コンピューティングコストは発生しません。

企業業務システム研究開発の課題

企業にとって、通常アプリケーションと呼ぶものは、単純なプログラムではなく、企業全体のビジネスケーパビリティを担う情報システムです。

業務システムを構築する際、通常はいくつかの段階を経ます。まず技術アーキテクチャの選択です。多くの企業システムはゼロから構築されるのではなく、継続的なビジネスの蓄積の中で反復的に進化します。しかし、新しい業務システムに直面した際、また再構築が必要な既存の業務システムに対して、どのようなアーキテクチャとオープンソースフレームワークを選択するかを考える必要があります。アーキテクチャのスケーラビリティ、フレームワークの保守性、コミュニティの成熟度、技術習得のハードル、そしてその後のビジネス開発人材の採用を考慮する必要があります。

セルフビルドシステム、特にインターネット環境では、分散システムがもたらす運用保守の負担と安定性の課題が開発チームを圧迫し、技術統合が困難になることで、企業の分散業務システムのセルフビルドに大きな課題をもたらします。

分散システム開発の課題

典型的な分散システムの主要コンポーネントでは、負荷分散、フロー制御、リソーススケジューリング、システムの可観測性、システムの安定性、高可用性要件、サービスガバナンスに関する一連の課題を考慮する必要があります。継続的な研究開発投資と運用保守の負担が、自主研究開発の主な課題となっています。

Serverless 関数コンピューティングによる技術アップグレードからコスト削減と効率化の実現

これらの需要と課題に直面し、Serverless 技術がプロダクトレベルでどのようにこれらの需要と課題に対応し解決するかを議論する前に、Serverless の本来の意図は何であったかを振り返りましょう。クラウドコンピューティングの最先端技術分野として、Serverless は当初から「高い弾力性、サーバーレス運用保守、使った分だけ課金」の実現を目指していました。この目標の観点から、Serverless は技術アップグレードの観点から我々が直面するコストと効率の課題を解決するために始まりました。すなわち「正しい道を歩めば、遠くまで行けないことはない」ということです。

関数コンピューティングのコア目標

「使った分だけ課金、サーバーレス運用保守、高い柔軟性」。この 3 つの概念は、顧客視点と技術用語の間で良いバランスを見出しています。Serverless 技術を担当する研究開発人員であれ、企業の技術アップグレードを担当する意思決定者であれ、Serverless が実現したい価値を直接理解できます。この 3 つの概念を中心に、2 つのコア目標を達成する必要があります。効率向上目標とコスト最適化目標です。

従量課金はよりビジネス視点からの考え方です。リクエストに基づく課金であることは理解しやすいでしょう。サーバーレス運用保守は、運用保守または研究開発の観点から、サーバーの調達に余計な時間を費やしたくないということです。運用保守の面では、リソースの弾力的なスケーリングやヘルスチェックなど一連の運用保守作業が含まれます。これら 2 つを実現するには、基盤となるプロダクトケーパビリティが必要です。最もシンプルなものは高い弾力性であり、必要な時にリソースを利用し、不要な時にリソースをリリースできるということです。これによってのみ、従量課金のロジックを支えることができます。

実際のビジネス価値に対するリクエスト課金により、ユーザーのコストを削減し、柔軟性による顧客リソースの保持コスト削減を実現します。実際、リソース確保の労力が小さいほど、保持時間が短くなり、実際のコンピューティング時間に近づくことで、コスト削減が実現します。効率目標は、まずシンプルな方法で開発される必要があります。複雑であれば、研究開発人員が受け入れることは難しく、効率向上の役割も果たせません。さらに、シンプルな開発を基盤として、迅速なデプロイにより研究開発人員がリリースとスケーリングに費やす時間を削減することで、コストと効率の目標が達成されます。

関数コンピューティングのプログラミングモデルによる [アプリケーション開発] の簡素化

Serverless の基本目標を理解した上で、関数コンピューティングがどのようにこの 2 つの目標を達成するかを議論する必要があります。まず、関数コンピューティングのプログラミングモデルから達成できる目標を評価する必要があります。関数コンピューティングはイベント駆動型のフルマネージドコンピューティングサービスです。

関数コンピューティングを使用すると、ユーザーはサーバーなどのインフラストラクチャを購入・管理する必要がなく、コードを記述してアップロードするだけで済みます。関数コンピューティングがコンピューティングリソースを準備し、柔軟かつ信頼性の高いタスク実行を行い、ログクエリ、パフォーマンスモニタリング、アラームなどの機能を提供します。

関数粒度で独立した関数ユニットを開発し、迅速なデバッグ、迅速なデプロイとリリースを実現することで、リソース調達と環境構築の運用保守を大幅に節約できます。同時に関数コンピューティングはイベント駆動モデルです。イベント駆動とは、ユーザーがサービスプロダクト間のデータ転送の問題に注意を払う必要がないことを意味し、コーディングにおける多くのサービスアクセスリンクロジックを省くことができます。「イベント駆動」+「関数粒度開発」+「サーバーレス運用保守」という多次元の特徴により、関数コンピューティングはビジネスロジック開発の基盤ロジックにより集中することを支援し、真の技術アップグレードと研究開発効率の向上を実現します。

関数コンピューティングのプログラミングモデルによる [アプリケーション実行コスト] の削減

開発モードによる研究開発効率の向上に加えて、関数コンピューティングがどのように顧客のコスト削減を支援する基盤ロジックを実装するかを見ていきましょう。ユーザーのリクエストに基づき、ユーザートラフィックに応じたモデルで課金することが最も理想的な状態です。しかし、リクエストに応じた課金には大きな技術的課題があります。関数コンピューティングのインスタンス起動がユーザーの RT 要件以下である必要があり、コールドスタート性能が特に重要になります。この時、高い弾力性が Serverless の従量課金とビジネスコスト削減の基盤技術サポートとなります。関数コンピューティングは「高い弾力性」+「使った分だけ課金」のモデルを通じて、Serverless 関数コンピューティングが真の基盤コスト削減ロジックを実現するのを支援します。

関数コンピューティングのすぐに使えるアトミック機能

クラウド開発者であれ、ビジネスのアップグレードを目指す企業顧客であれ、Serverless の「使った分だけ課金、サーバーレス運用保守、高い柔軟性」という 3 つの概念はほぼ浸透しています。しかし、Serverless が具体的に何をどのようにできるかは、依然として最も多く聞かれる声です。

Serverless の研究開発初期段階では、技術チームは通常、弾力性とコールドスタート高速化に重点を置き、弾力性を通じてプロダクトの技術競争力を高め、市場でのプロダクトのリーディングポジションを確立し、これらのケーパビリティに依存して Serverless の高い弾力性の技術目標を実装することで、開発者と企業顧客を引き付けようとします。この段階では、技術的な影響力に依存して Serverless を探求する方向性がより強くなります。

Serverless の理解が深まり、弾力性が向上するにつれて、本番環境で本質的な変更なしに使用する必要がある際に、弾力性以外の Serverless の価値についてより深く考えるようになります。この時点で、弾力性の範囲はコンピューティングリソースだけでなく、ネットワーク、ストレージなどの関連リソースも含まれます。システムの基本ケーパビリティとして、弾力性はプロダクトのあらゆる側面に浸透し、Serverless が何をどこまでできるのか、顧客に何をもたらせるのか、そしてカスタマイズが必要な部分にどう集中できるのかを、システム的な視点からより多く考慮する必要があります。

Serverless が何をどうできるかに答える前に、まず Serverless が具体的にどのような機能を持ち、どのようなすぐに使えるケーパビリティを提供できるかを理解しましょう。

関数コンピューティング -- クラウドプロダクトのコネクタ

コンピューティングプラットフォームとして、Serverless 関数コンピューティング (FC) は孤立した存在ではありません。クラウドコンピューティングエコシステム全体の他のプロダクトと連携して分散型クラウド開発環境を形成して初めて、関数コンピューティングの価値を最大化し、企業顧客がこれに基づく業務システム構築の需要を満たすことができます。

連携の最大の価値は、クラウドプロダクト背後のサービスの接続問題を解決することです。これは Serverless 関数コンピューティングのイベント駆動アーキテクチャの基盤でもあります。イベント駆動の価値は、より直感的な方法で隠れた呼び出しロジックを理解できるようにすることです。これらの呼び出しはユーザーのビジネスロジックに反映される必要はありません。接続はシステム間の依存関係も意味します。この依存関係は最終的に結合度を通じて反映されます。結合度は機能的依存関係の強さを直接示すものではなく、ソフトウェアアーキテクチャの実装レベルに反映されるものであり、実装の結果です。これはソフトウェアアーキテクチャ分野で強調される「高凝集・低結合」の実装要件でもあります。

イベント駆動は、イベント駆動方式でこの実装要件を満たします。このアーキテクチャに基づき、ソフトウェアの内部実装は以前の典型的なモノリシックアプリケーションや従来のマイクロサービス実装とは異なり、複数のサービス依存クライアントを独自のビジネスシステムに統合することに大きく依存する必要がなくなります。

クラウドベースの開発環境では、クラウドプロダクトが担うサービスは比較的凝集度が高く、クラウドネイティブアーキテクチャで重要な役割を果たします。クラウドプロダクト間のイベント通知メカニズムは、顧客が複数のクラウドプロダクトに基づく独自のクラウドネイティブ業務システムをより良く構築するのに役立ちます。そうでなければ、クラウドプロダクト間の連携は非常に複雑でコストのかかる作業となります。プロダクト接続による開発効率の向上に加えて、ユーザーがイベントを購読して処理ロジックを提供する際、顧客は処理不要なイベントリクエストを既にフィルタリングしており、イベント駆動は各イベントリクエストが実際に効果的な駆動力となることを意味します。

現在、関数コンピューティングは複数のクラウドプロダクトとの統合により完全なイベントエコシステムを構築しています。これには API Gateway、メッセージミドルウェア MQ、Object Storage Service (OSS)、Tablestore、Simple Log Service (SLS)、CDN、ビッグデータ DataHub、クラウド関数呼び出しなどが含まれます。同時に、EventBridge を通じて Alibaba Cloud のクラウドプロダクト全体の運用保守イベント (ログ監査、クラウドモニタリング、プロダクト運用保守) にもアクセスし、顧客が関数コンピューティングと多数のクラウドプロダクトを組み合わせて、イベント駆動アーキテクチャに基づくクラウドネイティブ業務システムを形成できるよう支援します。

関数コンピューティング -- 効率的なメッセージエコシステムのイベント駆動モデル

非同期デカップリングとピーククリッピングの特性を持つメッセージプロダクトは、インターネット分散アーキテクチャに不可欠な要素となっています。Serverless 関数コンピューティングには独自のアプリケーションシナリオがあります。メッセージプロダクトのエコシステム統合のために、関数コンピューティングはアーキテクチャレベルで特別に構築されています。EventBridge プロダクトが提供する EventStreaming チャネルケーパビリティに基づき、汎用メッセージ消費サービスである Poller Service を構築し、このアーキテクチャに基づいて、RocketMQ、ApsaraMQ for Kafka、RabbitMQ、Message Service (MNS) などのメッセージタイプトリガーケーパビリティをユーザーに提供します。

消費ロジックとプラットフォームロジックを分離し、消費ロジックと処理ロジックを分離します。従来のアーキテクチャのメッセージプルモデルを Serverless のイベント駆動プッシュモデルに変換し、関数コンピューティングがメッセージ処理のコンピューティングロジックを担えるようにすることで、サーバーレスなメッセージ処理を実現します。このアーキテクチャに基づき、顧客のメッセージクライアント統合接続問題を解決し、メッセージ処理ロジックの実装を簡素化し、ピークとトラフのある業務モデルに対してリソースを動的に拡張してユーザーコストを削減できます。

関数コンピューティング -- すぐに使える非同期タスク処理ケーパビリティ

以下の図は典型的な非同期タスク処理システムの基本モデルを示しています。API を通じてタスクの送信、スケジューリング、実行を行い、最終的に実行結果を配信します。

従来のタスク処理フレームワークでは、タスクスケジューリング、負荷分散、フロー制御戦略のケーパビリティは通常サービスゲートウェイ上に構築され、これは分散システム構築において最も基本的でありながら最もコアで、最も複雑な部分であり、最も多くの人的投資を必要とします。バックエンドの実装は通常、プロセス単位のメモリキューとランタイムレベルのスレッドプールモデルに基づいて、具体的なタスクのディスパッチと実行を完了します。スレッドプールは通常、選択したプログラミング言語のランタイムと密接に関連しており、システムアーキテクチャはプログラミング開発言語に大きく依存します。

Serverless 非同期タスク処理システムのプロセスは以下の通りです。ユーザーが API を通じてタスクを分散し、リクエストが Serverless サービスゲートウェイに到着した後、非同期リクエストキューに保存されます。Async Service がこれらのリクエストの引き継ぎを開始し、リクエストスケジューリングによりバックエンドリソースを取得します。これらのリクエストは特定のバックエンドリソースに割り当てられて実行されます。

このアーキテクチャ図において、Async Service は従来のアーキテクチャにおけるリクエストディスパッチャー、負荷分散、フロー制御戦略、リソーススケジューリングの実装を担当します。この時、関数クラスターは抽象化された分散スレッドプールモデルに相当します。関数コンピューティングモデルでは、インスタンスは互いに分離されており、リソースは水平スケーリング能力を持ち、関数コンピューティングにより全体的なリソースプール容量を計算することで、従来のアプリケーションアーキテクチャにおける単一マシンのリソース制限によるスレッドプール容量問題とリソーススケジューリングのボトルネック問題を回避できます。同時に、タスク実行環境は業務システム全体のランタイムに制約されないため、これが Serverless 非同期タスクシステムが従来のタスクシステムに比べて優れている点です。

Serverless タスク処理システムのアーキテクチャの観点から見ると、その処理ロジックは非常にシンプルです。分散システムが依存するケーパビリティの大部分は Async Service のシステムロールにより透過的に実装されます。ユーザーにとっては、タスク処理ロジックの大部分は関数プログラミングを通じて提供されます。全体のアーキテクチャは言語ベースのランタイムスレッドプールへの依存を回避し、関数コンピューティングクラスター全体が「無制限」の容量を持つ「スレッドプール」を提供します。サービスモードを通じて、ユーザーはリクエストを送信するだけでよく、その他の並行処理、フロー制御、バックログ処理はすべて Serverless プラットフォームが完了します。もちろん、実際の実行プロセスでは、業務特性に基づいて非同期タスク処理の同時実行数、エラーリトライ戦略、結果配信を設定する必要があります。

関数コンピューティング -- すぐに使える観測ケーパビリティ

関数が多くのすぐに使えるケーパビリティを提供した後、顧客が最も必要としているのは、これらのすぐに使えるケーパビリティを観測することです。顧客の開発とデバッグ、ビジネスロジックの最適化、システムの安定性、課金などの需要に対して、ユーザーが気にする指標や運用状態をどのように明らかにするか。

すぐに使える観測ケーパビリティのサポートを提供する必要があります。特に顧客が Serverless を使い始める移行初期段階では、システムのブラックボックス情報を顧客に開示し、プロダクト課金の透明性を高めることが非常に重要です。現在のすぐに使える観測ケーパビリティにより、タスク処理の全プロセスと消費されたコンピューティングリソースを明確に把握できます。

企業はどのように FC を活用して業務システムを急速に拡張できるか

次に、実際の業務システムにおいて、企業は関数コンピューティングが提供するアトミックケーパビリティを活用してどのように独自の業務システムを急速に拡張できるか、Serverless が真に企業の業務システム拡張とアーキテクチャアップグレードの信頼できる基盤となる方法に焦点を当てて説明します。

企業システムによる関数コンピューティングの迅速な統合のアトミックケーパビリティ

冒頭で、業務システムの All on Serverless を推進し、企業の業務システム全体を Serverless 上で運用させたいと述べました。しかし現実的には、この目標はこの段階ではまだ課題が多いです。我々はまだ比較的初期の移行段階にあり、ベストプラクティスの提案を提供することで、企業が既存のシステム基盤の上で、Serverless システムが提供するアトミックケーパビリティを活用してコスト削減と効率化の目標を達成し、Serverless 技術を独自の業務システムに導入し、Serverless の継続的な使用を通じて Serverless がもたらすビジネス価値を体験できるよう支援したいと考えています。

既存システムとこのようなケーパビリティをどのように迅速に統合するか。関数コンピューティングは SDK、HTTP URL、および多様なイベント駆動型アクセス方法を提供し、関数コンピューティングの VPC ケーパビリティを活用して、関数コンピューティングと顧客の既存システムのネットワーク空間を接続できます。同時に、ビジネスサポートの面では、関数は多次元のランタイムケーパビリティを提供します。公式標準ランタイム、ユーザー定義カスタムランタイムのサポート、コンテナエコシステムと統合した顧客コンテナイメージデプロイモードを含み、顧客の業務システムが Serverless プラットフォーム上で運用されるためのハードルを最小限に抑えます。コンテナエコシステムと比較して、関数コンピューティングは非常に顕著なイメージウォームアップ高速化ケーパビリティを提供し、顧客の業務システムを迅速に起動して外部サービスを提供できるように支援します。

タスク/ジョブ系業務処理ロジックの分割

タスク/ジョブ系業務処理ロジックの分割：一部のマイクロサービスアーキテクチャの業務システムでは、Serverless の非同期/非同期タスクのケーパビリティを活用して、システムのタスク処理需要を満たします。関数コンピューティングは HTTP、SDK、タイミング、イベントトリガーなどの統合方法を提供し、ユーザーがリクエストを送信して関連タスクを実行できるようにします。

MQ 業務メッセージ処理ロジックの分割

MQ 業務メッセージ処理ロジックの分割：企業の業務システムには通常、メッセージミドルウェアで接続された多くの業務サブシステムが存在します。関数コンピューティングはメッセージクラウドプロダクトのイベントトリガーケーパビリティを提供します。メッセージキューをリッスンしてアクティブにメッセージをプルして消費する従来のロジックを Serverless トリガーに置き換え、メッセージ処理ロジックは関数コンピューティングが担い、イベント駆動によりメッセージ消費とメッセージ処理をデカップリングし、イベント駆動が提供する信頼性の高い消費ケーパビリティを統一して、サーバーレスなメッセージ処理ロジックを実現します。

ファイル系処理業務ロジックの分割

ファイル系処理業務ロジックの分割：一部のファイルや動画処理業務では、ファイルシステムと DB の間でデータがやり取りされます。関数コンピューティングが提供する OSS トリガーと DB 系トリガー (OTS) を活用して、イベント駆動方式で関連データ処理ロジックを迅速に完了します。

データ処理系業務ロジックの分割

データ処理系業務ロジックの分割：データ処理系の一部の業務ロジックを、メッセージプロダクトが提供する Serverless ETL ケーパビリティを活用して処理し、関数コンピューティングによりビジネスニーズに応じてソース端とターゲット端を迅速に拡張することを期待します。

顧客シナリオ事例分析

次に、実際のユーザーの Serverless シナリオをいくつか紹介します。

アルゴリズムタスク

以下はアルゴリズム分野の典型的な業務シナリオアーキテクチャです。一部のアルゴリズムタスク、高性能コンピューティング、AI 関連推論タスク、広告画像認識、インテリジェント運用保守ケーパビリティを対象としています。

通常、これらの部分は業務システムの中で比較的独立した部分に属します。関数コンピューティングを使用して、推論用のアルゴリズムモデルを迅速にデプロイし、推論に必要な画像やパラメータ群をリクエスト単位で関数に渡します。デカップリング層を導入したい場合は、MQ を使用し、MQ イベントでタスク実行をトリガーできます。最終結果は Object Storage Service (OSS) に送信され、生成されたファイルをイベント駆動でさらに後続処理できます。

家電

家電分野では、顧客の Serverless ソリューションとして、IoT 関連の動画転送、IoT から収集したデータのさらなる分析、そしてクライアント側での動画データ消費をサポートしています。

相互エンターテインメント業界

以下は、画像の取り込みと処理を行う Weibo の Serverless シナリオ事例です。関数コンピューティングを使用して、コールドデータアクセスとカスタマイズされた画像処理を実現しています。

教育業界

以下は教育業界向けの Serverless ソリューションです。教育業界には明らかな特徴があり、エンコーディングによる再配信、ライブ録画、ライブコンテンツのレビューという共通の需要があります。ライブ配信中に、フレーム切り出しを通じてライブコンテンツの正当性をレビューする必要があります。

エンターテインメント業界

以下はエンターテインメント業界向けの Serverless ソリューションで、映画コンテンツの動的なフレーム切り出し監査とスライストランスコーディングを実現します。以下の図は Pumpkin Movie の技術ソリューションで、関数コンピューティングを使用してこのようなケーパビリティを実現しています。

ゲーム業界

以下はゲーム業界における関数コンピューティングの典型的なアプリケーション事例で、データ処理、バトル集計、ゲーム契約などのシナリオをカバーしています。ゲーム業界の複数のリーディング顧客は既にこのような Serverless ソリューションの組み合わせを使用して、独自の業務システムを実装しています。これらのシナリオは非常に特殊です。バトル集計を例に取ると、レプリカの実行タスク中にリアルタイムで継続的に計算する必要はありません。通常、レプリカが終了しそうな時や、レプリカの実行タスク中に戦闘が必要な時にのみ計算すればよく、これは典型的な Serverless アプリケーションシナリオです。