サーバレスアーキテクチャを詳しく知る：【完訳】CNCF Serverless Whitepaper v1.0（4）（4/4 ページ）

本連載では、サーバレスコンピューティングの概要とユースケース、コンテナオーケストレーションやPaaSとの使い分け方などを解説した、Cloud Native Computing Foundationのホワイトペーパーを完訳してお届けしている。第4回は、サーバレスアーキテクチャとはどのようなものかを、技術的に解説した部分を掲載する。

[三木泉，＠IT]

関数のコンテキスト

　関数が呼び出されると、フレームワークは、複数の関数呼び出しにまたがって適用されるプラットフォームリソースまたは一般プロパティへのアクセスを提供することができます。これにより、呼び出しごとに、全ての静的データをイベントに配置したり、関数がプラットフォームサービスを初期化したりする必要がなくなります。

　コンテキストは、入力プロパティや環境変数、グローバル変数の組み合わせとして提供されます。幾つかの実装では、3つ全てを組み合わせます。

コンテキストの例：

• 関数名、バージョン、ARN
• メモリ制限
• リクエストID
• クラウドリージョン
• 環境変数
• セキュリティキー／トークン
• ランタイム／Binパス
• ログ
• データバインディング

　実装によっては、ログオブジェクトを初期化します（AWSのグローバル変数またはAzureのコンテキストの一部など）。これには、プラットフォームに組み込まれた機能を使用して、関数の実行を追跡できるログオブジェクトを使用します。従来のロギングに加えて、将来の実装では、カウンタの使用状況／監視機能やトレース機能をプラットフォームコンテキストの一部として抽象化し、関数の使いやすさをさらに向上させることになるでしょう。

　データバインディングは関数コンテキストの一部です。プラットフォームはユーザーによる構成に基づいて外部データリソースへの接続を開始し、こうした接続は複数の関数呼び出しにわたって再利用される可能性があります。

関数の出力

　関数が終了すると、次のようになります。

• 呼び出し元に値を返す（例えば、HTTPリクエスト／レスポンスの例）
• 結果をワークフローの次の実行段階に渡す
• 出力をログに書き込む

　返されたエラー値または終了コードによって、関数が成功したか失敗したかを知る確実な方法があるはずです。

　関数出力は構造化されてもよく（例えばHTTPレスポンスオブジェクト）、または非構造化されてもよい（例えば出力文字列）ことになります。

サーバレス関数のワークフロー

　サーバーレスドメインでは、ユースケースは次のいずれかのカテゴリに分類されます。

1. 単一のイベントが単一の機能をトリガする
2. 単一のイベントや複数イベントの組み合わせが、1つの関数をトリガする
3. 1つのイベントによって、複数の関数をトリガする
4. 関数の結果は、別の関数のトリガとなる可能性がある
5. N個のイベントがm個の関数をトリガする。すなわち、イベントと関数がインタリーブされたワークフロー。例えばevent 1がfunction 1をトリガし、function 1の完了とevent 2とevent 3がfunction2をトリガし、さらにfunction 2の結果に応じてfunction 3かfunction 4への分岐がトリガされる

　ユーザーは、サーバレスのユースケースまたはワークフローを指定する方法が必要です。例えば、1つのユースケースは、写真がクラウドストレージにアップロード（写真ストレージイベントが発生）された際に、この写真を対象とした顔認識を行う場合があります。別のIoTユースケースは、動き検知イベントが受信されたときに「モーション分析を行う」ことができ、分析関数の結果に応じて「家のアラームと警察への呼び出しをトリガする」か、単に「動きの検知された画像を家の所有者に送信する」といったことができます。詳細は、ユースケースのセクションを参照してください。

　AWSは、ユーザーがワークフローを指定するための「ステップ関数」プリミティブ（ステートマシンベースのプリミティブ）を提供しますが、ステップ関数はワークフロー内のどのイベントがどの関数をトリガするかに関する指定を許可しません。 https://aws.amazon.com/step-functions/を参照してください。

　次の図は、イベントと関数を含むユーザーのワークフローの例です。このような関数グラフを使用することで、ユーザーはイベントと関数の相互作用、およびワークフロー内の関数間で情報をどのように渡すことができるかを簡単に指定できます。

　関数グラフの状態には、次のものがあります。

• イベントステート：この状態では、イベントソースからのイベントを待ってから、関数実行をトリガするか、複数の関数を順番に実行するか、並列または分岐で実行する
• オペレーション／タスクステート：この状態では、イベントを待つことなく、1つ以上の関数を順番にまたは並列に実行する
• スイッチ／選択ステート：この状態は、複数の他の状態への遷移を可能にする（例えば、前の関数結果が、異なる次の状態への分岐／遷移をトリガする）
• 終了／停止ステート：この状態では、ワークフローを終了し、失敗／成功を示す
• パスステート：この状態は、2つの状態の間にイベントデータを注入する
• 遅延／待機ステート：この状態では、指定した期間または指定した日時まで、ワークフローの実行を遅延する

　状態情報および関連情報は、障害からの回復を考慮し、永続ストレージに保存する必要があります。幾つかのユースケースでは、ユーザーはある状態からの情報を次の状態に渡したい場合があります。この情報は、関数実行結果の一部、あるいはイベントトリガに関連する入力データの一部かもしれません。状態間で渡す必要がある情報をフィルタリングするために、各状態で情報フィルタを定義する必要があります。

　ここでは、サーバレスアーキテクチャの基本的な構成に始まり、サーバレスフレームワークに求められるさまざまな要件を紹介している。抽象度が高い点はサーバレスの重要な特色だが、構築したいアプリケーションの種類によっては、複雑な機能が必要とされる場合もある。抽象度と自由度のバランスは、それぞれのフレームワークにおける重要なテーマの1つとなる。（三木）

　連載第5回（最終回）は、サーバレスに関する現時点でのレコメンデーション、そして今後の展開およびCNCFの活動に関する部分を掲載する。