Serverless Function Computing Helps Enterprises Reduce Costs and Improve Efficiency

背景

クラウドコンピューティングの PaaS 分野におけるインフラストラクチャの一つとして、Message Queuing Service（以下、Message Service）は、高い同時実行性、ピークシェービングとオフピーク処理の特徴により、開発者からますます注目を集めています。Message Service は、上流のメッセージプロデューサーサービスからのリクエストを受け付け、下流のコンシューマーサービスに接続します。消費に関して、2 つの課題があります。

1. Message Service から下流のコンシューマーサービスへ、低コスト、高スループット、低レイテンシでメッセージデータを伝達するにはどうすればよいですか？

2. 運用保守が不要で、オンデマンドで柔軟にスケールできるメッセージ消費サービスをどうすれば迅速に構築できますか？

ここでは、Alibaba Cloud のサーバーレスコンピューティングサービスと Message Service を組み合わせて、このようなシステムを構築する方法を紹介します。

用語の説明

Function Compute

Alibaba Cloud の Function Compute は、イベント駆動型のフルホスト型サーバーレスコンピューティングサービスです。Function Compute を利用することで、サーバーなどのインフラストラクチャを管理する必要がなく、コードを記述してアップロードするだけで済みます。Function Compute がコンピューティングリソースを確保し、コードを弾力的かつ信頼性の高い方法で実行します。プロダクトの詳細については、公式ドキュメント [1] をご参照ください。

Connector

Connector は大量のデータのインポートとエクスポートを実現します。たとえば、ApsaraMQ for Kafka のトピックから stdout へデータをエクスポートしたり、ローカルファイルのデータを RocketMQ にインポートしたりできます。Connector は、異なるシステム間のデータレプリケーションと転送の複雑さを簡素化します。本稿で取り上げる Message Service とコンピューティングサービスの接続も Connector に依存しています。

EventBridge

イベントバスは Connector のプロダクトサービスであり、Alibaba Cloud サービス、カスタムアプリケーション、SaaS アプリケーションなどの標準化された一元アクセスをサポートし、標準化されたプロトコルを使用してこれらのアプリケーション間でイベントをルーティングできます。疎結合な分散型イベント駆動型アーキテクチャを簡単に構築できます。プロダクトの詳細については、公式ドキュメント [2] をご参照ください。

アーキテクチャの進化

従来のデータ消費アーキテクチャを左図に示します。

1) データソースが生成したデータをメッセージシステムに書き込む。

2) 開発者が Message Service の提供する OpenAPI Explorer / SDK またはプロキシサービスクライアントを利用して、Message Service からデータを読み取る。

3) メッセージデータ処理のビジネスロジック（すなわちメッセージ消費）に従って、メッセージ消費のビジネス結果をターゲットサービスに書き込む。このアーキテクチャでは、開発者が以下の課題に直面します。

1. Message Service からどうすれば同時に安全にデータを読み取れますか？

2. データ消費能力が生産能力に追いつかない場合、どうすれば消費スループットを迅速に向上させられますか？

3. ターゲットサービスのリソースがボトルネックになった場合、どうすれば迅速にスケールアウトできますか？トラフィックのピークが過ぎた後、アイドルマシンコストをどう処理しますか？

4. リアルタイムかつ順序通りの消費をどう保証しますか？

5. フォールトトレランス、キャッシュ、デグレード、流量制限などの高可用性対策をどう実現しますか？

6. リンクの状況や異常をどうモニタリングしますか？

1

上記のような細かく複雑な課題の中には、必ず痛点に直面するものがあると思います。これらの課題を同時に解決するため、Alibaba Cloud は Connector Service（上記右図参照）を開発し、Message Service とサーバーレスコンピューティングサービス間のデータリンクを接続しました。上流の Message Service インスタンスと下流のコンシューマーオペレーターを宣言するだけで、ワンクリックでオンラインデプロイできます。Connector は、豊富なストリームコンピューティングフレームワークのデータ処理とモニタリング機能も備えており、以下にまとめます。

Transform：UDF 方式でカスタムデータクレンジングロジックを定義でき、JsonPath 構文によるシンプルなデータ抽出もサポート。

1. Filter：不要なメッセージの後続処理を削減。プレフィックスマッチング、数値マッチング、IP アドレスマッチングなど、多様なフィルターマッチングルールを提供。

Window：メッセージ数と時間間隔に基づいてメッセージを集約・プッシュするウィンドウ機能を提供。メッセージ処理のスループットを向上させ、処理コストを削減。

Real Time：Message Service からのメッセージプルからターゲットサービスへのプッシュまでの遅延はミリ秒レベル。

カスタム同時消費機能：同時かつ安全にメッセージを消費し、スループットを向上。

エラスティックコンピューティングリソース：下流のコンピューティングサービスが負荷に応じて自動的にスケーリングし、サーバーリソースの水位を気にする必要がない。

モニタリング＋ログ分析＋トラッキング：豊富なモニタリング指標とログ分析を提供し、開発者のシステム状態のモニタリングと障害特定を支援。

包括的な例外保護メカニズム：カスタムリトライ戦略＋フォールトトレラントメカニズム＋デッドレターキュー＋流量制限＋バックプレッシャー。

各機能の理解を深めるため、以下で各機能のメリットと適用シナリオを詳しく紹介します。

コスト削減と効率化の機能

Window

大規模データシナリオでは、1 リクエストあたり 1 メッセージの処理では、開発者のニーズに応えられなくなっています。Window の本質は、メッセージのバッチ処理能力を提供することです。Connector はプロダクトレベルで 2 つの設定可能なパラメーターを提供します。

• バッチプッシュの最大メッセージ数：1 回に集約する最大メッセージ数。バックログのメッセージ数が設定値に達した場合にのみ、メッセージが下流にプッシュされます。

•

• バッチプッシュ間隔：システムがバックログのメッセージを集約し、設定された間隔ごとに下流に送信します。0 秒に設定した場合、待ち時間なしで、受信次第すぐに配信されます。

これら 2 つのパラメーターの組み合わせにより、データ転送効率が大幅に向上し、データスループットが向上します。また、複数のユースケースに対応できます。たとえば：

• ストリーミングモードのリアルタイム消費：プッシュ間隔を 0 秒に設定し、最大プッシュ数を設定することで、上流からプルしたデータを下流のターゲットサービスにリアルタイムでプッシュできます。

• リクエストが疎で遅延に敏感でないシナリオで、メッセージを蓄積してバッチ処理したい場合。消費遅延は許容できるが、遅延時間を長くしたくない場合：バッチプッシュ数のパラメーターのみを設定すると、メッセージが長時間まばらで設定されたバッチ数に達せず、トラフィックの低い期間に過度に遅延する可能性があります。この場合、バッチプッシュ間隔パラメーターを導入することでこの問題を解決できます。

Transform

メッセージ消費にデータ処理は欠かせません。データ処理とは、元のデータを何らかのプロセスを通じてターゲットデータに変換することで、変換と呼ばれます。通常、元のデータは大きく完全な情報セットであり、ターゲットデータは構造化されたサブセットです。重要なのは、データクレンジングと抽出の機能をどう組み込むかです。この Connector は多様な変換機能を提供します。

• Template：元のデータとターゲットデータがいずれも構造化データで、データの抽出と組み立てルールがシンプルな場合、Template で変換を完了できます。Template は JsonPath データ抽出ルールもサポートしており、以下の図の通りです。

• UDF（User Definition Function）：元のデータ構造が複雑でデータ変換プロセスも複雑なシナリオでは、UDF を使用できます。UDF 方式では、関数のパラメーター入力プロトコルとパラメーターデータ構造のみが取り決められています。関数内でデータをどうクレンジングするか、返却するデータ構造はどうするかは、開発者が自由に実装できます。

まとめと展望

Serverless の Function Compute を基盤として、安全で信頼性の高いデータ消費システムを迅速に構築できます。システムのメリットを以下にまとめます。

• コスト削減

• Filter：無効なメッセージ処理と Function Compute の呼び出しを削減。

• Window：メッセージ蓄積とバッチ処理の機能を提供し、非リアルタイムで離散的なシナリオのメッセージをより良く処理でき、Function Compute の呼び出し回数も削減。

• 従量課金：コンピューティングリソースの従量課金機能により、ピーク時とオフピーク時のシナリオでピーク用にマシンを予約する無駄なオーバーヘッドを回避。

• 継続的な値下げ：Function Compute は 11 月に全リージョンの全課金項目を 12%〜47% 値下げし、メモリと CPU を細かく課金。

•

• 効率化

• 開発効率：Transform、UDF、Template、JsonPath などの機能がより多くのビジネスシナリオに対応し、追加開発を回避してシステムの迅速な構築を支援。今後もさらに多くのオペレーターが組み込まれ、オペレーターのオーケストレーションも可能になる予定。

• データ分析効率：数値取得、視覚分析などの機能を提供。シンプルなガイド付きインタラクションで、イベントベースのストリーミングクエリと分析を迅速に実現。

• 問題トラブルシューティング効率：イベントトラック、イベントマーケットなどの豊富な可観測性を提供し、ビジネス全体の状態のモニタリングと分析を支援。今後は、メトリック探索、運用保守モニタリング、障害特定などの多次元から機能を強化し、より包括的なシステムの可観測性を実現する予定。

• 運用保守効率：Serverless コンピューティングインスタンスのミリ秒単位の自動スケーリング機能により、リソース運用保守の負荷から完全に解放。

クラウドコンピューティングが全面的なサーバーレス化へと段階的に進む中、Message Service とサーバーレスコンピューティングの連携はより緊密になります。Connector の成熟化により、複雑なシステムの開発障居が下がり、エンドツーエンドのフルリンク深いクラウドアクセスを真に実現できます。