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

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

[三木泉，＠IT]

【完訳】CNCF Serverless Whitepaper v1.0　連載バックナンバー

　本連載では、サーバレスコンピューティング（以下、サーバレス）を解説したCloud Native Computing Foundation（CNCF）のServerless Working Groupによるホワイトペーパー、CNCF Serverless Whitepaper v1.0」を完訳してお届けしている。

　連載第4回は、サーバレスアーキテクチャとはどのようなものかを、技術的に解説した部分を掲載する（翻訳・構成：三木泉）。

サーバレス処理モデルの詳細を見る

　このセクションでは、サーバレスフレームワークにおける現在の関数の使用法を要約し、一般的なサーバレス関数要件、ライフサイクル、呼び出しタイプ、必要とされる抽象化について示します。サーバレス関数の仕様を定義することで、関数を一度コーディングすると、異なるサーバレスフレームワークで使用できるようにすることを目指します。このセクションでは、関数の構成とAPIについて正確な定義は行いません。

　FaaSソリューションは、一般的に、次の図に示すような幾つかの中核要素を備えます。

• イベントソース：1つまたは複数の関数インスタンスにイベントをトリガまたはストリームする
• 関数インスタンス：単一の関数／マイクロサービス。要求に応じて拡張可能
• FaaSコントローラー：関数インスタンスとそのソースのデプロイ、制御、監視を行う
• プラットフォームサービス：FaaSソリューションで使用される一般的なクラスタサービスまたはクラウドサービス（BaaSとも呼ばれる）

　まず、サーバレス環境における関数のライフサイクルを見てみましょう。

関数のライフサイクル

　以下のセクションでは、関数のライフサイクルのさまざまな側面、およびサーバレスのフレームワーク／ランタイムがそれらを管理する典型的な方法について説明します。

関数デプロイメントパイプライン

　関数のライフサイクルは、コードを記述し、仕様とメタデータ（「関数の定義」を参照）を提供することから始まります。「ビルダー」エンティティがこのコードと仕様を取り込み、コンパイルしてアーティファクト（コードバイナリ、パッケージ、またはコンテナイメージ）を作成します。次にアーティファクトは、イベントトラフィックやインスタンスの負荷に基づいて関数インスタンス数のスケーリングを担当するコントローラエンティティによって、クラスタに展開されます。

関数のオペレーション

　サーバレスフレームワークでは、関数のライフサイクルを定義して制御するために、次のアクションとメソッドを使用できます。

• 作成（Create）：仕様とコードを含む新しい関数を作成する
• パブリッシュ（Publish）：クラスタにデプロイできる新しいバージョンの関数を作成する
• （あるバージョンの）エイリアス／ラベルの更新（Update Alias/Label）：バージョンエイリアスの更新
• 実行／呼び出し（Execute/Invoke）：イベントソースを通じずに特定のバージョンを呼び出す
• イベントソースの関連付け（Event Source association）：特定のバージョンの関数をイベントソースに接続する
• ゲット（Get）：関数のメタデータと仕様を返す
• 更新（Update）：関数の最新バージョンを変更する
• 削除（Delete）：関数を削除する。特定のバージョンまたは全てのバージョンを削除できる
• リスト：関数とそのメタデータのリストを表示する
• 統計取得（Get Stats）：関数の実行時の使用状況に関する統計を返す
• ログ取得（Get Logs）：関数によって生成されたログを返す

　関数を作成するときに、その一環としてメタデータ（「関数の仕様」の部分で説明します）を提供すると、コンパイルされ、場合によってはパブリッシュされます。関数は後で起動、無効、有効にすることができます。関数をデプロイするには、次のユースケースをサポートできる必要があります。

• イベントストリーミング：このユースケースでは、常にキュー内にイベントが存在する可能性があるが、処理は明示的なリクエストによって一時停止／再開する必要がある
• ウォームスタートアップ：いかなる時点でも最小限のインスタンスは起動している。関数は既にデプロイされ、イベントを処理する準備ができているため、受け取った "最初の"イベントではウォームスタートする（対照的に、コールドスタートでは「受信」イベントによる最初の呼び出しでデプロイされる）

　ユーザーは関数をパブリッシュできます。これによって新しいバージョン（最新バージョンのコピー）が作成され、パブリッシュされたバージョンはタグ付け／ラベル付けされているか、エイリアスを持っています。下記を参照してください。

　ユーザーは、デバッグおよび開発プロセスのために、直接（イベントソースまたはAPIゲートウェイをバイパスして）関数を実行／起動できます。ユーザーは、バージョン、同期／非同期操作、冗長性レベルなどの起動パラメータを指定できます。

　ユーザーは、関数の統計（起動回数、平均稼働時間、平均遅延、失敗、再試行など）を取得したい場合があります。統計値は現在のメトリック値または時系列値として（例えばPrometheus、あるいはAWS Cloud Watchなどではクラウド事業者に）保存されます。

　ユーザーは関数のログデータを取得したい場合があります。重大度や時間範囲、コンテンツによってフィルタリングされることもあります。ログデータは関数ごとに得られ、関数の作成や削除、明示的なエラー、警告、デバッグメッセージ、（オプションとしては）関数のStdoutやStderrなどのイベントが含まれます。起動ごとに1つのログエントリを作るか、（関数実行フローを簡単に追跡できるように）ログエントリを特定の起動に関連付ける方法が望まれます。

関数のバージョン管理とエイリアス

　関数には複数のバージョンがあり得ます。ベータ／本番、A / Bテストなど、さまざまなレベルのコードを実行できます。バージョン管理を使用する場合、関数バージョンはデフォルトでは「最新」であり、「最新」バージョンでは更新や改変があり得ます。そのような変更のたびに、新たなビルドプロセスがトリガされる可能性があります。

　ユーザーがバージョンをフリーズしたい場合は、パブリッシュ・オペレーションを実行します。これにより、イベントソースを構成するタグまたはエイリアス（「beta（ベータ）」「production（本番）」など）を伴った新しいバージョンを作成し、イベントまたはAPIコールを特定の関数バージョンにルーティングできます。最新でない関数バージョンは不変（そのコードと関数仕様の全てまたは一部）であり、一度パブリッシュされると変更することはできません。関数は 「非公開」にすることはできません。代わりに削除する必要があります。

　今日の実装では、関数の分岐やフォーク（古いバージョンのコードの更新）は実装と利用を複雑にしてしまうため、ほとんどの場合許されていませんが、将来的にはこれが求められるかもしれません。

　同じ関数に複数のバージョンがある場合、ユーザーは、どの関数バージョンを動かしたいか、および異なるバージョン間でイベントのトラフィックをどのように分割するかを指定しなければなりません（例えば、ユーザーはイベントトラフィックの90％を安定版に、10％をベータ版あるいは「カナリアアップデート」にルーティングすると指定可能）。これは、正確なバージョンを指定するか、またはバージョンエイリアスを指定することによって行えます。バージョンエイリアスは、通常関数バージョンを参照します。

　ユーザーが関数を作成または更新すると、変更の性質に応じて新しいビルドとデプロイメントが実行されます。

イベントソースと関数の関連付け

　関数は、イベントソースによってトリガされたイベントの結果として呼び出されます。関数とイベントソースはn対mの関係です。単一のイベントソースを使用して複数の関数を呼び出すことができます。また、単一の関数が複数のイベントソースによってトリガされることがあります。イベントソースは、特定バージョンの関数または関数のエイリアスにマッピングできます。後者は、関数を変更する手段として使え、イベントの関連付けを変更する必要なく新しいバージョンをデプロイできます。イベントソースでは、同じ関数の異なるバージョンそれぞれに対するトラフィックの割り当て量を定義することもできます。

　関数を作成した後、またはその後の時点で、そのイベントの結果として関数呼び出しをトリガするイベントソースを関連付ける必要があります。これには、次のような一連のアクションとメソッドが必要です。

• イベントソースの関連付けを作成する
• イベントソースの関連付けを更新する
• イベントソースの関連付けを一覧表示する

イベントソース

　イベントソースの種類には、次のものがあります。

• イベントやメッセージングサービス（RabbitMQ、MQTT、SES、SNS、Google Pub/Subなど）
• ストレージサービス（Amazon S3、Dynamo DB、Kinesis、Cognito、Google Cloud Storage、Azure Blob、igurazio V3IO＜オブジェクト／ストリーム／DB＞など）
• エンドポイントサービス（IoT、HTTPゲートウェイ、モバイルデバイス、Alexa、Google Cloud Endpointsなど）
• 設定リポジトリ（Git、CodeCommit）
• 開発言語固有のSDKを使用するユーザーアプリケーション
• スケジュールされたイベント――一定間隔で関数を呼び出せる

　イベントごとに提供されるデータは、イベントソースによって異なりますが、イベント構造は、イベントソースに応じて情報をカプセル化する機能を持つ一般的なものでなければなりません（詳しくは、「イベントデータとメタデータの詳細」の項を参照）。