How Serverless Helps Enterprises Expand Their Business Systems

１、エンタープライズアプリケーションと業務システム開発の課題

従来のエンタープライズアプリケーション開発プロセスには多くの課題があります。たとえば、ビジネスロジックレベルでは、プロジェクト開発、デプロイメント、構築、保守があり、サーバー利用レベルでは、リソース見積もり、サーバー設定、サーバーセキュリティ管理、サーバー運用保守などがあります。

また、運用保守とコストの観点からも、従来のアプリケーションは効率とコストの二重の課題に直面しています。たとえば、継続的な稼働はエネルギーの損失をもたらし、長期スタンバイ状態も企業にとってコスト損失の原因となります。

企業が開発するアプリケーションは、企業の業務システムを担うことが多くあります。アーキテクチャの選択においては、市場には多くの技術プロダクトやアーキテクチャの概念が存在し、ビジネスの迅速なイノベーションを実現するために適切な新技術を選定する必要があります。次に、分散システム技術は複雑であり、導入にあたっては高い学習コストと運用保守コストが必要です。たとえば、マイクロサービスを統合する際のフロー管理や、基盤の弾力性のあるリソース制御の方法などは、ビジネスに大きな課題をもたらします。最後に、技術ポートフォリオの統合度が不十分であり、全体的な計画と統合的なエンドツーエンドソリューションが不足しています。

多種多様なリソースを購入することも、業務システム構築の効率に影響します。リソース、ネットワーク、トラフィックガバナンス、アーキテクチャ設計、リソース運用保守、可観測性、ランタイム適応、多言語対応、タスクスケジューリングなどが、研究開発効率の障壁となります。

Serverless は、技術アップグレードからコスト削減と効率向上まで、企業を支援できます。

では、Serverless とは何か、何をするものか、そして何ができるのかを見ていきましょう。

Serverless には三つのコアコンセプトがあります。従量課金（コストレベル）、サーバーレス運用保守（DevOps レベル）、そして高い柔軟性（インフラレベル）です。

初期段階では、Serverless は主に高い柔軟性によって業界の探求をリードしてきました。現在では、エンタープライズの業務システムが抱える課題を真に解決するために、Serverless を本格的に導入すべき段階にあります。

Serverless は分割型プログラミングを推進し、ビジネスコードのみに注目することで、全体的な構造がよりアジャイルになります。プラットフォームが優れた実行環境を構築しているため、開発者はコード開発に集中するだけで素早く成果を得られ、開発者の効率が大幅に向上します。

Serverless を通じて、中規模の業務システムを分単位で実装でき、オンラインでの POC も迅速に完了できます。100 ミリ秒の極めて柔軟なスケーリングにより、オンラインビジネスがあらゆる種類の突発的トラフィックに対応でき、リソースのプロビジョニング能力も非常に優れています。Function Compute のコールドスタートの問題は避けられませんが、継続的なイテレーションを通じてこの問題の解決に取り組んでいます。また、リソース使用率は 100% に達し、リクエストごとの課金で、1 ミリ秒のコンピューティング粒度により、実際に消費したリソースに対してのみ支払えばよい仕組みです。



さらに、Function Compute を基盤とした自社業務システムの構築においても、広範なレベルでは依然としてプラットフォームベースの運用保守が必要であり、運用保守の免除は Function Compute レベルに限られます。

Serverless のコスト削減効果は、トラフィックの潮汐が明確なシナリオで発揮され、明確なピークと谷がないビジネスシナリオでは、十分なコスト削減効果を得るまでに長い時間が必要です。

２、Serverless 体系の標準装備された細粒度化機能

フラッシュセールやオンラインライブ配信アクティビティの特徴の一つは、トラフィックが不確実であることです。そのため、基盤層にはリソースを柔軟にプロビジョニングする能力が不可欠であり、これはビジネス起動の柔軟性とは異なる次元のものです。コード起動は主にレイテンシレベルに現れ、リソースの柔軟性は主に QPS レベルに現れます。

コードの実行には、コードのダウンロード、コンテナ起動、ランタイム初期化、関数初期化、関数実行など、いくつかの段階を経る必要があります。Function Compute の最適化により、100 ミリ秒での起動を実現しました。

システム側では、リソースの再作成を回避し、同一テナントまたは関数内でのリソース再利用を可能にするため、インスタンスリソースのプーリングとインスタンス同時実行数の予測を実現し、メモリミラーリングによる汎用テンプレートを迅速に提供しています。ネットワーク面では、ユーザー VPC との接続に対応するため、プラグアンドプレイの VPC 最適化ソリューションを提供し、ネットワーク機能を関数の実行中インスタンスに迅速に組み込めるようにしています。最後に、関数実行時のプロファイリング機能とアクセラレーション機能の結果は、後続の処理にフィードバックされます。

各ビジネスのリクエスト処理が効果的であってこそ、全体のビジネス効率向上に反映されます。Serverless はイベント駆動型として、API ゲートウェイ、Kafka、ログなど、さまざまなデータタイプのクラウドプロダクトとシステムを接続する必要があります。データソースとの連携が確立されれば、イベント駆動方式でプロダクトに蓄積されたデータを処理し、Function Compute 内でシステムのビジネス目標を達成できます。

データプロダクトに加えて、開発運用保守を担当するお客様は、ECS の稼働状況、クラウドモニタリングの問題、VPC 作成など、運用保守関連のイベントに関心を持ち、これらの運用保守イベントを活用して他のクラウドプロダクトの SDK を能動的に呼び出し、関連リソースを作成することも求めています。

Alibaba Cloud のクラウドプロダクトは EventBridge を通じて Function Compute に接続でき、イベントベースの運用保守を実行できます。

エンタープライズ業務システムで最も一般的なメッセージミドルウェアは、システムデカップリングプロダクトです。ビジネスメッセージのコンシューマー側の実装は非常に簡単であり、Function Compute を使用して消費する目的は、プラットフォームのサービス性を活かしつつ、バックエンドのビジネスメッセージ処理におけるリソース弾力性を実現することです。メッセージがない場合、Function Compute のリソースは回収され、課金も発生しません。

Function Compute 全体でステートレスなメッセージ消費機能を実現しており、これはリアクティブパターンに似ています。ステートフルな部分はプラットフォームのトリガー機能が提供し、ステートレスなビジネス関連またはユーザー定義の部分は関数として実装されるため、ビジネスのカスタマイズ性とリソースのレスポンシブ性の両方が保証されます。

一般的なアプリケーションゲートウェイでは、通常サーバーを購入し、コードを記述し、スレッドプールを構築する必要があります。これらのプロセスでは多くの課題を解決する必要があります。何台のマシンを購入すべきか、各マシンのランタイムでのスレッドプールの同時実行数はいくつにすべきかといった問題です。

Function Compute のシナリオでは、非同期タスクで処理されるリクエストを非同期サービスに送信でき、このサービスを通じてリクエストが並列にスケジューリングされます。関数は容量無制限のスレッドプールモデルと同様に機能し、マネージド型で信頼性の高いリクエスト処理を提供し、at-least-once の実行を保証できます。関数の柔軟な設定によりフロー制御が可能であり、各フェーズの実行状況の確認や実行中のタスクのキャンセルなど、実行管理機能も提供されます。

実行完了後、サービス結果が提供されます。追加の関数を実装する必要はなく、結果を次の関数やメッセージキューに配信できるため、関連性のない疎結合なプロダクトが結果をさらに処理できます。

Serverless は、すぐに使えるシステムの可観測性を提供し、リクエスト実行のレスポンスタイム、CPU 使用率、メモリ使用量、および呼び出しチェーンの各フェーズの所要時間を確認できます。

３、エンタープライズが Serverless を活用して業務システムを迅速に拡張する方法

エンタープライズは業務システムを拡張する過程で、全業務を Serverless に移行する必要があるかどうかという問題に直面します。比較的シンプルな業務システムであれば完全移行は可能です。長年蓄積された大規模な業務システムの場合は、一部の機能を Serverless に移行するためにシステムの分割が必要です。後者の場合、疎結合な方法でリクエストを Function Compute にオフロードするにはどうすればよいでしょうか。

まず、HTTP RESTful 経由で関数にアクセスできます（イベント関数は現在サポートされておらず、今後 URL アクセスをサポートする予定です）。さらに、OSS やメッセージキューへの配信、DB トリガーによる疎結合なデカップリングで、ダウンストリームの業務システムを起動できます。

業務システムには実行コンテキストも必要です。Function Compute の仕様に従ったプログラミング規約を記述できます。また、イメージやカスタムランタイムを通じて、既存のイメージを Function Compute 上で実行する方法も提供されています（コンテナ変換が必要）。実行コンテキストは同じままで、基盤のコンピューティングリソースが Function Compute に移行されます。

システムの分割には、以下の原則を推奨します。

第一に、タスククラスの処理を行うビジネスロジックを分割し、Function Compute に移行します。SDK、HTTP、タイミングトリガー、イベント駆動の送信方法を使用してタスクを Function Compute で実行させることで、Function Compute の従量課金と開発の利便性を活用でき、既存の業務システムへの影響を最小限に抑えられます。

第二に、MQ のビジネスメッセージ処理ロジックを分割し、イベント駆動のビジネスメッセージ処理を使用します。

第三に、ファイル関連のビジネスロジックを分割し、OSS のイベント駆動方式で迅速に処理します。生成物を OSS に保存すれば、追加システムの開発なしにプロセス全体を完結できます。

第四に、軽量データ処理のビジネスロジックを分割し、Serverless ETL 機能を使用して、OSS、Elasticsearch、RDS などのダウンストリームシステムに配信します。

４、エンタープライズが Serverless 体系を使用する際の課題分析

エンタープライズの移行とアップグレードには、主に三つの推進力があります。ビジネス推進によるアーキテクチャのアップグレード、効率推進による技術のアップグレード、コスト削減推進による技術革新です。

移行の過程で、エンタープライズは以下の課題に直面します。

第一に、移行と変換が困難であり、Function Compute のプログラミング仕様とランタイム要件への適応が必要です。

第二に、関数の最大実行時間制限があり、既存ビジネスの移行に不利です。

第三に、Function Compute のリクエストモデルは従来のアプリケーションと大きく異なり、同時実行の概念が理解しにくい点です。Function Compute は、1 リクエスト 1 インスタンスと、単一インスタンスでの複数リクエスト同時処理という二つの方式を提供しています。

第四に、計算インスタンスはユーザーに対して透過的であり、エラー処理とトラブルシューティングが困難です。

第五に、課金モデルが複雑で理解しにくく、コストが制御可能かどうか懸念されます。

第六に、コールドスタートです。現在のリンク遅延は 3〜5 ミリ秒です。

５、顧客シナリオのケース共有

ケース 1：分众传媒（Focus Media）の広告効果識別

Focus Media は画像認識処理システムを開発しました。ポスター変更後、スタッフは写真を撮影して APP 経由でバックグラウンドサーバーにアップロードします。週末は変更のピークであり、ピーク時のトラフィックは平常時の 10 倍以上になります。

ケース 2：IoT モニタリング映像の送信ソリューション

コンシューマーエレクトロニクス業界の IoT モニタリング映像を OSS に送信します。Function Compute を通じて OSS 上のファイル内容のインターセプトなどの処理を迅速に行い、処理結果を業務システムと連携させる必要があります。1 日あたりの平均呼び出し量は QPS 8 万以上に達します。

ケース 3：Weibo の大量画像処理

Weibo の大量画像処理では、主に Function Compute を使用して画像を高速処理し、ミリ秒レベルの弾性スケーリングとイベント駆動モデルを組み合わせて画像処理を実現しています。

ケース 4：ライブストリーミングのコンテンツレビュー

インタラクティブエンターテインメント業界のライブストリーミングでは、オンラインビデオとビデオインタラクションのリアルタイムおよびセグメント化されたセキュリティ監査または認証を達成する必要があり、Function Compute で実現できます。

ケース 5：クライアントデータストリーム処理の分析

ゲーム業界のデータ生成後、Kafka にレポートされたメッセージを Kafka の ETL 機能で処理する必要があります。

ケース 6：カードゲームのバトル計算

カードゲームのシナリオでは、各バトル後にのみ計算が発生し、Serverless の使用に非常に適しています。

ケース 7：ゲーム配信チャネルのパッケージング

ゲーム配信チャネルのパッケージングシナリオは、イベント駆動で実装されています。

ケース 8：Internet of Vehicles プラットフォーム

Internet of Vehicles プラットフォームは、端末からデータを収集した後、Kafka または RabbitMQ に転送して処理します。

Q&A

Q：GPU コンテナのコールドスタート時間はどのくらいですか

A：コンテナの起動時間は、GPU 内の参照モデルサイズに依存します。たとえば、3 GB のカスタマイズイメージでキャッシュアクセラレーションを使用した場合、約 2 秒です。10 MB 以上のファイルが含まれている場合は、10〜30 秒かかる可能性があります。

Q：サービスを Function Compute に移行した後、Arthas ツールで動作を確認できますか

A：現在、Arthas はサポートされていません。Java は動的注入機能が比較的強力なため、Arthas のサポート実装は容易です。しかし Function Compute はマルチ言語対応であるため、Java やマイクロサービスシナリオに特化した監視・診断機能の提供は困難です。今後、Web シナリオ対応で Arthas サポートが実装される可能性があります。

Q：マイクロサービスシナリオを直接 Function Compute に移行するのは適切ですか

A：推奨されません。Lambda アーキテクチャでは、通常ゲートウェイとメソッドロールの組み合わせの方が適しています。高速 Web 対応の HTTP 関数、URL、カスタムドメインを提供しており、これらは比較的ロングテールなため Function Compute に適しています。高頻度リクエストの場合、直接処理には不向きです。まずゲートウェイの能力を設定し、同時にメソッド呼び出し（メソッド呼び出しには偏りがあり、高頻度のメソッドもあれば低頻度のメソッドもあります）と連携して、完全なサービス能力を提供する必要があります。

同時実行の面では、単一インスタンスで複数のリクエストを処理することで、コールドスタートの平均起動時間を短縮できます。大部分のリクエストが 1 つのインスタンス上で処理されるためです。