Enterprises use Serverless to expand business systems

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

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


前回の説明でも、本日多くの皆様がお集まりになり、サーバーレスについて学ぶ機会を持っていただけたことを確認しました。
サーバーレスイベント駆動エコシステム、非同期システム、サーバーレスワークフローの開発責任者として、本日の共有が皆様にサーバーレスの技術的原理と、サーバーレスが企業のコスト削減と効率化の目標達成にどのように役立つかを理解していただけることを願っています。
同時に、企業がコンテナ化からサーバーレスへの移行段階にある際に、技術アップグレード、アーキテクチャ変革、コスト削減と効率化のためにサーバーレスをどのように適用するかに関するベストプラクティスのガイダンスも紹介します。
最後に、実際の生産環境で使用されているサーバーレス顧客事例を紹介し、サーバーレスが実際の生産プロセスでどのように活用され、ビジネス上の課題を解決しているかを理解していただきます。


企業テクノロジーアップグレードの核心的な推進力と課題

企業テクノロジーアップグレードの核心的な推進力

まず、企業の生産プロセスにおけるテクノロジーアップグレードの 3 つの核心的な推進要因を理解しましょう。


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


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


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


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

「サーバーレスの過去と現在」という記事は、サーバーレスがなぜ生まれたのか、そしてそれが解決しようとする核心的な問題は何かを理解するための良い伏線を提供しています。
企業開発の核心的な目標に戻ると、ビジネスロジックをより迅速に実装し、環境構築やシステム連携にかかる開発時間を短縮し、ビジネス開発により多くの時間を集中させることです。
開発完了後、開発したビジネスコードをデプロイしてサービスを提供する稼働環境が必要であり、稼働中に関わる関連保守作業、すなわち一般的に運用保守と呼ばれるものも含みます。
この全体のプロセス（一般的に DevOps と呼ばれるもの）において、開発、運用保守に携わる皆様が直面する課題は、明確に実感されていると思います。
まとめると、企業の開発効率の問題です。
開発効率に加えて、企業にとって非常に重要なもう 1 つの要素は開発コストの問題です。
ここでは、企業研究開発における IT コストのみを議論します。
理想的なモデルは、実際にビジネス価値を生み出す計算に対してのみ支払うことです。
しかし通常、実際にビジネス価値を生み出す計算は、ビジネスリクエストのライフサイクルと一致しています。
実際のビジネスリクエストが到着する前、またはリクエスト間隔中であっても、保持しているコンピューティングリソースに対して支払い続ける必要があります。
これらの時間帯のコンピューティングリソースはビジネスにとってアイドル状態であるにもかかわらずです。
これも、サーバーレスがリクエスト単位の課金を実現し、顧客のコスト削減を図りたいと考える需要です。
リクエスト単位の課金をよりよく理解していただくために、K8s や ECS の課金モデルを紹介します。
K8s を購入すると、それらに対して支払いが発生します。
Pod を作成すると、クラスターがリソースを割り当てます。
リクエストトラフィックが到来していない時でも、Pod リソースに対して支払い続ける必要があります。
サーバーレスでは、コードを提供してプラットフォームにデプロイした状態、つまりコードパッケージとコンテナイメージがサーバーレスプラットフォームにデプロイされた状態では、ウォームアップ中、実行中、またはスタンバイ状態にある可能性があります。
しかし、実際のビジネスリクエストが到来する前の期間、または 2 つのリクエスト呼び出しの間隔中には、コンピューティングコストは発生しません。


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

企業にとって、一般的にアプリケーションと呼ぶものは、単純な意味でのプログラムではなく、企業全体のビジネス能力を担う情報システムです。
業務システムを構築する際、通常、システムアーキテクチャの選択などいくつかの段階を経ます。
1 つ目は技術アーキテクチャの選択です。
多くの企業システムはゼロから構築されるのではなく、絶え間ないビジネスの蓄積の中で反復的に進化していきます。
しかし、新しい業務システムに直面した時、および再構築が必要な既存の業務システムに対して、どのようなアーキテクチャとオープンソースフレームワークを選択するかを決める必要があります。
アーキテクチャのスケーラビリティ、フレームワークの保守性、コミュニティの成熟度、技術習得のしきい値、そしてその後のビジネス開発人材の採用を考慮する必要があります。
自社構築システム、特にインターネット環境では、分散システムがもたらす運用保守の負担と安定性の課題が開発チームを圧倒し、技術統合が困難になり、企業の自社構築分散業務システムに大きな課題をもたらします。


分散システム開発の課題

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


サーバーレス関数コンピューティングによる技術アップグレードとコスト削減・効率化

これらすべての需要と課題に直面して、サーバーレステクノロジーが製品レベルでこれらの需要と問題にどのように対応し解決するかを議論する前に、サーバーレスの本来の意図は何だったかを振り返りましょう。
クラウドコンピューティングの最先端技術分野として、サーバーレスは当初から「高い伸縮性、サーバー不要の運用保守、必要に応じた課金」の実現を目指しています。
この目標の観点から、サーバーレスは技術アップグレードの観点から私たちが直面するコストと効率の問題を解決するために始まったと言えます。
「正しい道を歩めば、遠くまで行き過ぎることはない」という格言の通りです。


関数コンピューティングの核心的な目標

「必要な分だけ課金、サーバー運用保守不要、高い伸縮性」。
これら 3 つの概念は、顧客視点と技術用語の間で良いバランスを見出しています。
サーバーレス技術を担当する開発者も、企業の技術アップグレードを担当する意思決定者も、サーバーレスが実現したい価値を直接理解できます。
これら 3 つの概念を中心に、2 つの核心的な目標を達成する必要があります。
効率向上目標とコスト最適化目標です。
従量課金は、よりビジネス視点に立ったものです。
リクエストに基づく課金であることは理解しやすいでしょう。
サーバー運用保守不要は、運用保守または開発の観点から、サーバー購入により多くの時間を費やしたくないことを意味します。
運用保守の面では、リソースの弾性拡張やヘルスチェックなど、一連の運用保守作業が含まれます。
この 2 つを実現するには、基本的な製品能力が必要です。
最もシンプルなのは高い伸縮性で、必要な時にリソースを使い、不要な時にリソースを回収できることです。
そうして初めて、従量課金のロジックを支えられます。
実際のビジネス価値を持つリクエストに対して課金することでユーザーコストを削減し、柔軟性による顧客リソースの保持コスト削減を実現します。
実際、リソース保持の労力が小さいほど、保持時間も短くなり、実際のコンピューティング時間に近づくことで、コスト削減が実現します。
効率目標は、まずシンプルな方法で開発できることが前提です。
複雑であれば、開発者が受け入れるのが難しく、効率向上の効果を発揮できません。
さらに、シンプルな開発を基盤として、迅速なデプロイにより開発者がリリースやスケーリングに関与する時間を短縮します。
これがいわゆるコストと効率の目標です。


関数コンピューティングのプログラミングモードで [アプリケーション開発] をよりシンプルに

サーバーレスの基本的な目標を理解した上で、Function Compute がどのようにしてこれら 2 つの目標を達成するかを議論する必要があります。
まず、Function Compute のプログラミングモードから達成できる目標を評価する必要があります。
Function Compute はイベント駆動型のフルマネージドコンピューティングサービスです。
Function Compute を使用すると、ユーザーはサーバーなどのインフラストラクチャを購入・管理する必要がなく、コードを記述してアップロードするだけです。
Function Compute がコンピューティングリソースを準備し、柔軟かつ信頼性の高いタスク実行、ログクエリ、パフォーマンスモニタリング、アラートなどの機能を提供します。
関数粒度で独立した関数単位を開発し、迅速にデバッグ、デプロイ、リリースできるため、リソース購入と環境構築の運用保守を大幅に節約できます。
同時に、Function Compute はイベント駆動モデルです。
イベント駆動とは、ユーザーがサービス間のデータ転送の問題に注意を払う必要がないことを意味し、これによりコーディングに関わる多くのサービスアクセスリンクロジックを省略できます。
「イベント駆動」+「関数粒度開発」+「サーバー運用保守不要」といった多次元の特徴により、Function Compute はビジネスロジック開発の基盤ロジックにより集中でき、真の技術アップグレードと開発効率の向上を実現します。


関数コンピューティングのプログラミングモードで [アプリケーション稼働コスト] をより低く

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


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

クラウド開発者であれ、ビジネスのアップグレードを図る企業顧客であれ、サーバーレスの「従量課金、サーバー運用保守不要、高い伸縮性」という 3 つの概念はほぼ広く知られるようになりました。
しかし、サーバーレスで具体的に何ができ、どのように活用するかは、依然として私たちの周辺で最もよく聞かれる声です。
サーバーレスの研究開発初期段階では、技術チームは通常、柔軟性とコールドスタート高速化にさらに注力し、柔軟性を通じて製品の技術競争力を際立たせ、市場での製品のリーディングポジションを確立し、これらの能力に依存してサーバーレスの高い伸縮性という技術目標を実装することで、開発者や企業顧客をサーバーレスの利用に引き付けようとします。
この段階では、技術的な影響力に依存してサーバーレスを探求する方向性がより強くなります。
サーバーレスの理解が深まり、柔軟性が向上するにつれて、本質的な変更なしに顧客が生産環境でサーバーレスを使用する必要がある際に、柔軟性以外の価値についてより多く考えるようになります。
この時、弾性カバレッジはもはやコンピューティングリソースに限定されず、ネットワーク、ストレージ、その他の関連リソースも含まれます。
柔軟性はシステムの基本機能として、製品のあらゆる面に浸透します。
システム的な視点から、サーバーレスで何ができるか、顧客に何をもたらせるか、そしてカスタマイズが必要な部分にビジネスを集中させる方法をより多く考慮する必要があります。
サーバーレスで何ができ、どのように実現するかを答える前に、まずサーバーレスで何ができ、どのようなすぐに使える機能を提供できるかを理解しましょう。


関数コンピューティング ― クラウド製品のコネクタ

コンピューティングプラットフォームとして、サーバーレス Function Compute（FC）は孤立した島ではありません。
クラウドコンピューティングエコシステム全体の他の製品と連携して分散クラウド開発環境を形成することで初めて、関数コンピューティングの価値を最大化し、企業顧客がこれに基づく業務システム構築のニーズを満たせます。
連携の最大の価値は、クラウド製品の背後にあるサービスの接続問題を解決することです。
これは Function Compute のイベント駆動アーキテクチャの基盤でもあります。
イベント駆動の価値は、隠れた呼び出しロジックをより直感的な方法でユーザーに理解させることにあります。
これらの呼び出しはユーザーのビジネスロジックに反映される必要はありません。
接続はシステム間の依存関係も意味します。
この依存関係は最終的に結合度を通じて反映されます。
結合度は関数従属性の強さを示すものではなく、ソフトウェアアーキテクチャの実装レベルでより反映され、実装の結果です。
これはソフトウェアアーキテクチャ分野で強調される「高凝集、低結合」の実装要件でもあります。
イベント駆動はイベント駆動方式でこの実装要件を満たします。
このアーキテクチャに基づき、ソフトウェアの内部実装は、以前の典型的なモノリシックアプリケーションや従来のマイクロサービス実装とは異なり、複数のサービス依存クライアントを自社のビジネスシステムに統合することに大きく依存する必要がなくなります。
クラウドベースの開発環境では、クラウド製品が担うサービスは比較的凝集度が高く、クラウドネイティブアーキテクチャで重要な役割を果たします。
クラウド製品間のイベント通知メカニズムは、顧客が複数のクラウド製品を活用して独自のクラウドネイティブ業務システムをより良く構築するのに役立ちます。
そうでなければ、クラウド製品間のイベント監視は非常に複雑でコストがかかります。
製品接続によってもたらされる開発効率に加えて、ユーザーがイベントをサブスクライブして処理ロジックを提供する際、顧客は処理不要なイベントリクエストを潜在的にフィルタリングしています。
イベント駆動は、各イベントリクエストが実際には効果的な駆動力であることを意味します。
現在、Function Compute は API Gateway、メッセージミドルウェア MQ、Object Storage Service（OSS）、Tablestore、Simple Log Service（SLS）、CDN、ビッグデータ DataHub、クラウド関数など、複数のクラウド製品との統合により完全なイベントエコシステムを構築しています。
同時に、EventBridge を通じて Alibaba Cloud 全体のクラウド製品の運用保守イベント（ログ監査、クラウドモニタリング、製品運用保守）にもアクセスし、顧客が Function Compute と多くのクラウド製品を活用して、イベント駆動アーキテクチャに基づくクラウドネイティブ業務システムを構築できるよう支援しています。


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

非同期デカップリングとピーククリッピングの特徴により、メッセージ製品はインターネット分散アーキテクチャに不可欠な要素となっています。
サーバーレス Function Compute は独自のアプリケーションシナリオを持っています。
メッセージ製品の生態系統合のために、Function Compute はアーキテクチャレベルで特別に構築されています。
EventBridge 製品が提供する EventStreaming チャネル能力に基づいて、汎用メッセージ消費サービスである Poller Service を構築し、このアーキテクチャに基づいて、ユーザーに RocketMQ、Kafka、RabbitMQ、MNS などのメッセージタイプトリガー機能を提供しています。
消費のロジックをサービス化し、プラットフォームとビジネスロジックを分離し、消費ロジックと処理ロジックを分離します。
従来のアーキテクチャのメッセージプルモデルをサーバーレスのイベント駆動プッシュモデルに変換し、Function Compute によるメッセージ処理の計算ロジックをサポートして、サーバーレスなメッセージ処理を実現します。
このアーキテクチャに基づき、顧客のメッセージクライアント統合接続問題を解決し、メッセージ処理ロジックの実装を簡素化し、ピークとトラフのあるビジネスモデルに対してリソースの動的拡張とユーザーコストの削減を実現します。


関数コンピューティング ― すぐに使える非同期タスク処理機能

下の図は典型的な非同期タスク処理システムの基本モデルを示しています。
API を通じてタスクの送信、スケジューリング、実行を行い、最終的に実行結果を配信します。
従来のタスク処理フレームワークでは、タスクスケジューリング、負荷分散、フロー制御戦略の機能は通常、サービスゲートウェイに基づいて構築されます。
これは分散システムの構築において最も基本的でありながら最も核心的で、最も複雑な部分であり、最も多くの人的投資を必要とします。
バックエンド実装は通常、プロセス粒度のメモリキューとランタイムレベルのスレッドプールモデルに基づいて、具体的なタスクのディスパッチと実行を完了します。
スレッドプールは通常、選択したプログラミング言語のランタイムと密接に関連しており、システムアーキテクチャはプログラミング開発言語に強く依存します。
サーバーレス非同期タスク処理システムのフローは次の通りです。
ユーザーが API を通じてタスクを配信し、リクエストがサーバーレスサービスゲートウェイに到着した後、非同期リクエストキューに格納されます。
Async Service がこれらのリクエストの引き継ぎを開始し、リクエストスケジューリングによりバックエンドリソースを取得します。
これらのリクエストは具体的なバックエンドリソースに割り当てられて実行されます。
このアーキテクチャ図において、Async Service は従来のアーキテクチャでのリクエストディスパッチャー、負荷分散、フロー制御戦略、リソーススケジューリングの実装を担当します。
この時、関数クラスターは抽象化された分散スレッドプールモデルに相当します。
Function Compute モデルでは、インスタンス間は相互に分離されており、リソースは水平方向のスケーリング能力を持ちます。
関数コンピューティングにより全体的なリソースプール容量が計算されるため、従来のアプリケーションアーキテクチャでの単一マシンリソース制限によるスレッドプール容量問題とリソーススケジューリングのボトルネック問題を回避できます。
同時に、タスク実行環境は全体の業務システムランタイムに制限されません。
これがサーバーレス非同期タスクシステムの従来のタスクシステムに対する優位性です。
サーバーレスタスク処理システムのアーキテクチャから見ると、その処理ロジックは非常にシンプルです。
分散システムが依存する機能のほとんどは、Async Service システムロールによって透過的に実装されています。
ユーザーにとっては、タスク処理ロジックの多くは関数プログラミングを通じて提供されます。
全体のアーキテクチャは言語ベースのランタイムスレッドプールへの依存を回避し、Function Compute クラスター全体が「無制限」容量の「スレッドプール」を提供します。
サービスモードを通じて、ユーザーはリクエストを提出するだけであり、その他の並行処理、フロー制御、バックログ処理はすべてサーバーレスプラットフォームが完了します。
もちろん、実際の実行プロセスでは、ビジネス特性に基づいて非同期タスク処理の同時実行数、エラーリトライ戦略、結果配信を設定する必要があります。


関数コンピューティング ― すぐに使える観測機能

関数が多くのすぐに使える機能を提供した後、顧客が最も緊急に必要としているのは、これらのすぐに使える機能の観測です。
顧客の開発・デバッグ、ビジネスロジック最適化、システム安定性、計量・課金などのニーズに対応して、ユーザーが関心を持つ指標や運用状態をどのように明らかにするか。
すぐに使える観測機能のサポートを提供する必要があります。
特に顧客がサーバーレスを使用し始める初期の移行段階では、システムのブラックボックス情報を顧客に明示し、製品課金の透明性を向上させることが非常に必要です。
現在のすぐに使える観測機能により、タスク処理の全体プロセスと消費したコンピューティングリソースを明確に確認できます。


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

次に、実際の業務システムにおいて、企業は Function Compute が提供するアトミック機能を活用して自社の業務システムをどのように迅速に拡張できるかに焦点を当てます。
サーバーレスが企業の業務システム拡張とアーキテクチャアップグレードを実現するための信頼できる依存先として真に機能するようにします。


企業システムの迅速な Function Compute 統合アトミック機能

冒頭で、業務システムの All on Serverless を推進し、企業全体の業務システムをサーバーレス上で稼働させたいと述べました。
しかし現実的には、この目標はこの段階ではまだ非常に挑戦的です。
私たちはまだ比較的初期の移行段階にあります。
ベストプラクティスの提案を提供し、企業が既存のシステム基盤の上に、サーバーレスシステムが提供するアトミック機能を活用してコスト削減と効率化の目標を達成し、サーバーレス技術を自社の業務システムに導入し、サーバーレスの継続的な使用を通じてサーバーレスがもたらすビジネス価値を体験できるよう支援したいと考えています。
このような機能を既存システムとどのように迅速に統合するか。
Function Compute は SDK、HTTP URL、多様なイベント駆動型アクセス方法を提供し、Function Compute の VPC 機能を活用して、Function Compute と顧客の既存システムのネットワーク空間を接続できます。
同時に、ビジネスサポートの面では、関数は公式標準ランタイム、ユーザーがカスタマイズしたランタイムサポート、コンテナエコシステムと統合したコンテナイメージデプロイメントモードを含む多次元のランタイム機能を提供し、顧客の業務システムをサーバーレスプラットフォーム上で稼働させるためのしきい値を最小化します。
コンテナエコシステムと比較して、Function Compute は非常に顕著なイメージウォームアップ加速機能を提供し、顧客の業務システムを迅速に起動して外部サービスを提供できるように支援します。


タスク・ジョブクラスビジネス処理ロジックの分割

タスク・ジョブクラスビジネス処理ロジックの分割：一部のマイクロサービスアーキテクチャ業務システムでは、サーバーレス非同期タスク機能を利用してシステムのタスク処理要件を満たしています。
Function Compute は HTTP、SDK、タイミングトリガー、イベントトリガーなどの統合方法を提供し、ユーザーがリクエストを提出して関連タスクを実行できるようにしています。


MQ ビジネスメッセージ処理ロジックの分割

MQ ビジネスメッセージ処理ロジックの分割：企業の業務システムには、通常、メッセージミドルウェアで接続された多くのビジネスサブシステムがあります。
Function Compute はメッセージクラウド製品イベントトリガー機能を提供します。
メッセージキューを監視してアクティブにメッセージをプルして消費する従来のロジックをサーバーレストリガーに置き換え、メッセージ処理ロジックを Function Compute が担当します。
イベント駆動によりメッセージ消費とメッセージ処理をデカップリングし、イベント駆動が提供する信頼性の高い消費能力を利用して、サーバーレスなメッセージ処理ロジックを実現します。


ファイルクラス処理ビジネスロジックの分割

ファイルクラス処理ビジネスロジックの分割：一部のファイルおよび動画処理ビジネスでは、ファイルシステムと DB 間でデータが流れます。
Function Compute が提供する OSS トリガーと DB クラストリガー（OTS）を活用して、イベント駆動方式で関連データ処理ロジックを迅速に完了します。


データ処理クラスビジネスロジックの分割

データ処理クラスビジネスロジックの分割：データ処理クラスのビジネスロジックを、メッセージ製品が提供するサーバーレス ETL 能力を利用して処理し、Function Compute を活用してビジネスニーズに応じてソースエンドとターゲットエンドを迅速に拡張したいと考えています。


顧客シナリオ事例分析

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


アルゴリズムタスク

以下はアルゴリズム分野の典型的なビジネスシナリオアーキテクチャです。
アルゴリズムタスク、高性能コンピューティング、AI 関連推論タスク、広告画像認識、インテリジェント運用保守機能に関するものです。
通常、これらの部分は業務システムの中で比較的独立した部分に属します。
Function Compute を使用して推論用のアルゴリズムモデルを迅速にデプロイし、リクエストにより画像または推論に必要なパラメータ群を関数に参照します。
デカップリングロジックのレイヤーを導入したい場合は、MQ を使用し、MQ イベントでタスク実行をトリガーできます。
最終結果は OSS に送信され、生成されたファイルはイベント駆動によりさらに処理できます。


コンシューマーエレクトロニクス

コンシューマーエレクトロニクス分野では、顧客のサーバーレスソリューションで IoT 関連の動画転送を実現し、IoT から収集したデータをさらに分析し、最終的にクライアントがこれらの動画データを消費できるようにサポートしました。


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

以下は Weibo の画像アクセスと処理に関するサーバーレスシナリオケースです。
Function Compute を活用してコールドデータアクセスと個別化画像処理を実現しています。


教育業界

以下は教育業界向けサーバーレスソリューションです。
教育業界には明らかな現象があり、エンコーディング再放送、ライブ録画、ライブコンテンツ審査が共通の需要です。ライブ放送中は、フレームカットを通じてライブコンテンツの合法性を審査する必要があります。

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

以下はエンターテインメント業界向けサーバーレスソリューションで、映画コンテンツの動的フレームカット審査とスライストランスコーディングを目的としています。下の図は Pumpkin Movie の技術ソリューションで、Function Compute を活用してこのような機能を実現しています。

ゲーム業界

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