前回の記事では、Serverless の内部動作について探りました。本質的には、Serverless は階層化スケジューリングと高速コールドスタートを活用し、イベント処理がないときはゼロまでスケールダウンできます。これは、人がいると点灯し、部屋が空になると自動的に消灯する音声起動型ライトに似ています。
基本を理解したところで、この印象的なテクノロジーの実用的な応用例について興味が湧くかもしれません。今日は、Serverless のユースケースを掘り下げていきます。ただし、その応用を理解するための前提条件として、コールドスタートと同様に重要な概念であるプロセスモデルを理解する必要があります。
サーバーレスのプロセスモデル
前回のセッションで Serverless のコールドスタートプロセスを振り返りましょう。クラウドプロバイダーがコンテナとランタイムの準備フェーズを管理し、私たちは関数の実行のみに集中できることを思い出してください。Serverless の領域では、関数の実行は「関数サービス」によって処理されます。関数トリガーが「イベント」の到着を知らせると、関数サービスは必要に応じて関数インスタンスを作成し、対応する関数を実行します。関数の実行が完了すると、そのインスタンスは終了し、Serverless アプリケーションはゼロまでスケールダウンして省電力モードに入ることができます。
では、関数実行後にインスタンスを終了せずに存続させ、次の関数呼び出しを待機させることは可能だろうか、と疑問に思うかもしれません。これにより、毎回のコールドスタートオーバーヘッドがなくなり、応答時間が短縮されます。
実際、Serverless はそのようなシナリオを想定しています。その結果、関数インスタンスを実行するプロセスの観点から、2つのモデルが存在します。
- 実行完了型 (Run-to-Completion): このモデルでは、関数インスタンスは準備ができると関数を実行し、すぐに終了します。これは Serverless の最も純粋な使い方です。
- 常駐プロセス型 (Persistent Process): こちらでは、関数インスタンスは準備後、関数完了時に終了せず、代わりに戻って次の関数呼び出しを辛抱強く待ちます。このモデルでも、所定の期間イベントがトリガーされなければ、クラウドプロバイダーは最終的に関数インスタンスを破棄することに注意してください。
データオーケストレーション
多くのエンジニアは、広く成功しているデザインパラダイムである MVC (Model-View-Controller) パターンに精通しています。しかし、フロントエンドの MVVM フレームワークの台頭により View 層が前方に押し出され、SPA (シングルページアプリケーション) が生まれました。一方、バックエンドの Control 層と Model 層は下降し、サービス指向のバックエンドアプリケーションが登場しました。
この変化により、フロントエンドとバックエンドの分離がより徹底されました。フロントエンド開発はモックデータインターフェースに依存して独立して進めることができ、バックエンドチームはデータインターフェースの開発に集中できます。しかし、この分離により、ネットワーク I/O の高いデータゲートウェイ層が導入されます。
非同期かつノンブロッキングな性質と、JavaScript がフロントエンドエンジニアにとって親和性が高いことから、Node.js は自然とデータゲートウェイ層の役割を担うようになりました。これにより、バックエンドのデータとインターフェースをオーケストレーションし、フロントエンドが消費しやすいデータ構造に適応させる Node.js の BFF (Backend For Frontend) 層が登場しました。
BFF 層は仲介役として機能し、フロントエンドとバックエンドを橋渡しします。未処理のデータ（しばしば生データやメタデータと呼ばれる）は、エンドユーザーにとっては事実上読み取れません。そのため、関連データを結合・処理し、価値を付加して意味のあるものにする必要があります。この結合と処理のプロセスをデータオーケストレーションと呼びます。
従来、BFF 層の Node.js アプリケーションの管理はリソース集約的であり、仮想マシンや PaaS プラットフォームが必要でした。しかし、BFF 層は主にステートレスなデータオーケストレーションを実行するため、実行完了型モデルを使用して Node.js アプリケーションを Serverless にシームレスに置き換えることができます。これが、ますます人気が高まっている SFF (Serverless For Frontend) という用語の本質です。
BFF から SFF への進化を理解したところで、新しいリクエストフローを追跡してみましょう。フロントエンドがデータリクエストを開始すると、関数トリガーが関数サービスを起動します。関数が起動し、バックエンドのメタデータインターフェースを呼び出し、返されたメタデータをフロントエンドが必要とする形式に処理し、最後に Serverless 関数は当然の休憩を取ることができます。
サービスオーケストレーション
サービスオーケストレーションはデータオーケストレーションと類似点がありますが、主な違いは、クラウドプロバイダーが提供するさまざまなサービスを結合・処理することに焦点を当てている点です。この概念は Serverless よりも前から存在しますが、従来の実装はサービスがサポートする SDK の言語バージョンによって制限されていました。通常、サービスをオーケストレーションするには YAML ファイルやコマンドラインインターフェースに頼っていました。これらのサービスや API を利用するには、好みのプログラミング言語で対応する SDK を見つけ、コードにロードし、シークレットキーを使用して SDK のメソッドを呼び出してオーケストレーションを行いました。データオーケストレーションと同様に、バックエンドの運用とデプロイのコストは大きく、SDK がない場合はプラットフォームのインターフェースやプロトコルに基づいて手動で実装する必要がありました。
Serverless は SDK 利用の境界を広げます。例えば、メールで確認コードを送信する必要がある Web サービスを考えてみましょう。これを、クラウドプロバイダーの SDK を使用してメールを送信する実行完了型の Serverless 関数で実現できます。同時に、常駐プロセス型の Serverless 関数がランダムな文字列の確認コードを生成して保存し、メール送信用の Serverless 関数をトリガーしてコードをユーザーの受信箱に配信します。確認時には、常駐プロセス型の Serverless 関数を再度呼び出してコードを検証できます。
Serverless の注目すべき利点の一つは、言語に依存しないことです。これにより、開発チームは単一の言語に縛られることなく、Java、PHP、Python、Node.js などの強みを活かして複雑なアプリケーションを協力して構築できます。
Serverless のサービスオーケストレーションのオープンな性質は、クラウドプロバイダーから大きな注目を集めています。これにより、言語に依存しないまま、多様で複雑なサービスオーケストレーションシナリオの作成が可能になり、さまざまなクラウドサービスのユースケースが大幅に拡大します。しかし、これは開発者に対して、選択したクラウドプロバイダーが提供する一連のサービスに精通することを要求します。
結論
- Serverless には2種類のプロセスモデルがあります：常駐プロセス型と使い捨て型です。常駐プロセス型は従来の MVC アーキテクチャに適応するために設計されており、自然に見えません。これから Serverless を始めるなら、Serverless の利点を最大限に活かせる使い捨て型をぜひお勧めします。
- 歴史を振り返ると、フロントエンドとバックエンドの分離によって発展した BFF を整理し、それを SFF に置き換えることができます。内部インターフェースのオーケストレーションであれ、外部データのオーケストレーションであれ、Serverless は大きな利点を発揮できます。
- データオーケストレーションからさらに進んで、Serverless とクラウドサービスプロバイダーの機能を活用してサービスオーケストレーションを実現し、より強力な複合サービスシナリオを作成し、研究開発の効率を向上させることができます。
Novita AI は、あなたの AI の野心を後押しするオールインワンのクラウドプラットフォームです。統合 API、サーバーレス、GPU インスタンス — 必要なコスト効率の高いツール。インフラを排除し、無料で始めて、AI ビジョンを現実にしましょう。
おすすめの読み物
