Explain the six application scenarios of Serverless architecture

ガイドリーディング

サーバーレスアーキテクチャは、今後のクラウドコンピューティング分野で重要な技術アーキテクチャとなり、より多くのビジネスで採用されていくでしょう。サーバーレスアーキテクチャはどのようなシナリオで優れたパフォーマンスを発揮し、どのようなシナリオでは不向きなのか、さらに詳しく調べてみましょう。あるいは、どのようなシナリオがサーバーレスアーキテクチャに適しているのでしょうか。

サーバーレスアーキテクチャの適用シーン

サーバーレスアーキテクチャの適用シーンは、通常その特徴によって決まり、サポートされるトリガーが具体的なシーンを決定します。図 1-1 に示すように、CNCF サーバーレスホワイトペーパー v1.0 では、サーバーレスアーキテクチャについて以下のユーザーシナリオが記述されています。

・非同期コンカレント処理。コンポーネントを独立してデプロイおよびスケールできます。

・突発的または予測不可能なサービス利用。

・短期間のステートレスアプリケーションで、コールドスタート時間に敏感でないシナリオ。

・迅速な開発と反復が求められるビジネス。

図 1-1 CNCF サーバーレスホワイトペーパー v1.0 に記述されたサーバーレスアーキテクチャに適したユーザーシナリオ

CNCF は、サーバーレスアーキテクチャの特徴に基づく 4 つの適用可能なユーザーシナリオに加え、一般的なトリガーと組み合わせた具体例も提供しています。

・データベースの変更 (挿入、更新、トリガー、削除) に応じたロジックの実行。

・IoT センサーの入力メッセージ (MQTT メッセージなど) の解析。

・ストリーム処理の実行 (動的データの分析または変更)。

・短時間で大量の処理を必要とする単発のデータ抽出、変換、保存 (ETL)。

・チャットボットインターフェイスを通じたコグニティブコンピューティング (非同期) の提供。

・CRON タスクやバッチ処理など、短期間実行されるタスクのスケジューリング。

・機械学習および AI モデル。・CI/CD パイプラインによるビルド作業向けのオンデマンドリソース提供。

CNCF サーバーレスホワイトペーパー v1.0 は、サーバーレスアーキテクチャの特徴に基づき、サーバーレスに適したシナリオやビジネスを理論的に解説しています。クラウドベンダーは、各自のビジネス視点からサーバーレスアーキテクチャの典型的なアプリケーションシナリオを説明しています。

一般的に、Object Storage Service がサーバーレス関連プロダクトのトリガーとして使用される場合、代表的なアプリケーションシナリオには動画処理やデータ ETL 処理などが含まれます。API Gateway は、ユーザーが外部リンクや関連機能にアクセスするケースが多く見られます。API Gateway がサーバーレス関連プロダクトのトリガーとして機能する際の典型的なアプリケーションシナリオは、アプリのバックエンド、Web サイトのバックエンド、WeChat ミニプログラムなどを含むバックエンドサービスです。

一部のスマートスピーカーも関連インターフェイスを公開しており、API Gateway 経由でクラウドファンクションをトリガーして対応するサービスを取得できます。Object Storage Service トリガーや API Gateway トリガーの他にも、よく使用されるトリガーにはメッセージキュートリガー、ApsaraMQ for Kafka トリガー、ログトリガーなどがあります。

1. Web アプリケーションまたはモバイルアプリケーションのバックエンド

サーバーレスアーキテクチャをクラウドベンダーが提供する他のクラウドプロダクトと組み合わせることで、開発者は柔軟でスケーラブルなモバイルアプリケーションや Web アプリケーションを構築し、リッチなサーバーレスバックエンドを簡単に実現できます。これらのプログラムは複数のデータセンターで利用可能です。図 1-2 に Web アプリケーションバックエンド処理の例を示します。

図 1-2 Web アプリケーションバックエンド処理の例

2. リアルタイムファイル・データ処理

動画アプリケーションや SNS アプリケーションなどのシナリオでは、ユーザーがアップロードする画像、音声、動画の総量と頻度が高く、処理システムに高いリアルタイム性と同時実行性が求められます。この場合、複数の関数を使用してユーザーがアップロードした画像の圧縮やフォーマット変換などの処理を行い、さまざまなシナリオのニーズに対応できます。図 1-3 にリアルタイムファイル処理の例を示します。

図 1-3 リアルタイムファイル処理の例

サーバーレスアーキテクチャがサポートする豊富なイベントソース、イベントトリガーメカニズム、コード、シンプルな構成を通じて、リアルタイムでデータを処理できます。たとえば、オブジェクトストレージの圧縮パッケージの解凍、ログやデータベースのデータクリーニング、Message Service (MNS) メッセージのカスタム消費などです。図 1-4 にリアルタイムデータ処理の例を示します。

図 1-4 リアルタイムデータ処理の例

3. オフラインデータ処理

一般的に、ビッグデータを処理するには Hadoop や Spark などのビッグデータフレームワークと、データ処理用のクラスターを構築する必要があります。しかし、サーバーレス技術を使用すれば、取得したデータを Object Storage Service に継続的に保存し、Object Storage Service に設定した関連トリガーを介してデータ分割関数を起動し、関連データやタスクを分割してから処理関数を呼び出し、クラウドデータベースに格納するだけで済みます。

たとえば、証券会社では 12 時間ごとにその期間の取引を集計し、上位 5 件の取引を抽出しています。フラッシュセールサイトでは 1 日 1 回トランザクションフローログを処理して売り切れによるエラーを抽出し、商品の人気度とトレンドを正確に分析しています。Function Compute のほぼ無制限のスケーリング機能により、ユーザーは大規模なデータ計算を簡単に実行できます。

サーバーレスアーキテクチャを使用すると、ソースデータに対してマッパー関数とリデューサー関数を並列実行し、短時間で処理を完了できます。従来の方法と比較して、サーバーレスアーキテクチャを使用することでアイドルリソースを回避し、コストを削減できます。データ ETL 処理フローは図 1-5 のように簡素化できます。

図 1-5 データ ETL 処理の例

4. 人工知能

AI モデルのトレーニングが完了して外部に推論サービスを提供する際、サーバーレスアーキテクチャに基づいてデータモデルを関数にパッケージ化し、実際のユーザーからのリクエスト受信時にコードを実行します。従来の推論・予測と比較して、この方法の利点は、関数モジュール、バックエンドの GPU サーバー、その他の接続された機械学習サービスに従量課金で利用でき、自動スケーリングも可能なため、パフォーマンスを確保しながらサービスの安定性を維持できる点です。図 1-6 に機械学習 (AI 推論予測) 処理の例を示します。

図 1-6 機械学習 (AI 推論予測) 処理の例

5. モノのインターネット (IoT)

現在、多くのメーカーが独自のスマートスピーカー製品を発売しています。ユーザーがスマートスピーカーに話しかけると、スマートスピーカーはその音声をインターネット経由でバックエンドサービスに送信し、処理結果を取得してユーザーに返します。サーバーレスアーキテクチャを使用することで、メーカーは API Gateway、クラウドファンクション、データベース製品を組み合わせて、従来のサーバーや仮想マシンの代わりに利用できます。

一方では、サーバーレスアーキテクチャにより、リソースを使用した分だけ課金される従量課金を保証できます。つまり、ユーザーが使用したときにのみ関数部分が課金されます。他方では、ユーザー数が増加すると、サーバーレスアーキテクチャで実装されたスマートスピーカーシステムのバックエンドも自動スケールされ、ユーザー側サービスの安定性が保証されます。個々の関数のメンテナンスは単一の関数のメンテナンスと同等であり、メインプロセスに追加のリスクをもたらさず、より安全で安定的です。図 1-7 に IoT バックエンド処理の例を示します。

図 1-7 IoT バックエンド処理の例

6. 監視と自動運用保守

実際の運用では、Web サービスや API サービスの健全性を監視するスクリプトを実装することが多いです。これには可用性やレスポンス速度の確認が含まれます。従来の方法は、DNSPod モニタリング、Web サービスモニタリング、Alibaba Cloud モニタリングなどの監視プラットフォームを通じて監視とアラートを行うものです。

これらの監視プラットフォームの仕組みは、ユーザーが監視対象の Web サイトと期待されるレスポンス時間のしきい値を設定し、プラットフォームが各地域に配置したサーバーが定期的にリクエストを送信して、Web サイトやサービスの可用性を判断するというものです。ただし、これらのサーバーは多機能ではあるものの、必ずしもすべてのニーズに最適とは限りません。たとえば、ある Web サイトのステータスコードと各地域でのレイテンシを監視し、遅延のしきい値を設定して、ステータスが異常またはレイテンシが過大の場合にメールでアラートを発信するケースです。

現在、このようなカスタマイズされた要件に対して、ほとんどの監視プラットフォームは直接対応するのが難しいため、独自の Web サイトステータス監視ツールを開発することが特に重要になります。さらに、実際の運用保守の現場では、使用中のクラウドサービスに対する監視とアラートも必要です。たとえば、Hadoop や Spark を使用する場合はノードの健全性を監視し、Kubernetes を使用する場合は API Server や etcd などの指標を監視する必要があります。Kafka を使用する場合は、データのバックログや Topic、Consumer などの指標を監視する必要があります。

これらのサービスの監視には、単純な URL や特定の状態だけでは判断できないことが少なくありません。従来の運用保守では、別途マシンを用意して定期タスクを設定し、関連サービスを監視するのが一般的でした。サーバーレスアーキテクチャの重要な適用シーンの一つは、運用保守、監視、アラートです。定期トリガーと連携することで、一部リソースの健全性を監視し、感知できます。図 1-8 に Web サイト監視アラートの例を示します。