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

関数コード

　関数コードや依存関係、バイナリは、S3オブジェクトバケットやGitリポジトリなどの外部リポジトリに存在することも、ユーザーが直接提供することもできます。 コードが外部リポジトリにある場合、ユーザーはパスと認証情報を指定する必要があります。

　サーバレスフレームワークはまた、ユーザーが（例えば、Web hookを使用して）コードリポジトリにおける変更を見て、コミット時に自動で関数イメージ／バイナリを構築できるようにすることも可能です。

　関数は外部のライブラリやバイナリと依存関係にある場合があります。こうした依存関係については、ビルドプロセスを記述する方法（Dockerfile、Zipなど）を含め、ユーザーが提供する必要があります。

　さらに、関数はOCIイメージのようなバイナリパッケージを介して、フレームワークに提供することもできます。

関数の定義

　サーバレス関数の定義には、次の仕様とメタデータが含まれている場合があります。関数の定義はバージョン固有です。

• 一意のID
• 名
• 説明
• ラベル（またはタグ）
• バージョンID（またはバージョンエイリアス）
• バージョン作成日時
• （関数定義の）最終変更日時
• 関数ハンドラ
• ランタイム言語
• コード＋依存関係またはコードパスと認証情報
• 環境変数
• 実行におけるロールと秘密情報
• リソース（必要なCPU、メモリ）
• 実行タイムアウト
• ログの失敗（デッドレターキュー）
• ネットワークポリシー／VPC
• データバインディング

メタデータの詳細

　関数フレームワークは、関数のために以下のメタデータを扱うことができます。

• バージョン：各関数バージョンには固有の識別子が必要。さらに、バージョンには1つ以上のエイリアス（「最新」、「本番」、「ベータ」など）を使用してラベルを付けることができる。 APIゲートウェイおよびイベントソースは、トラフィック／イベントを特定の関数バージョンにルーティングする
• 環境変数：ユーザーは、実行時に関数に与えられる環境変数を指定することができる。環境変数は、秘密情報や暗号化されたコンテンツから取得することも、プラットフォーム変数（例えば、Kubernetes EnvVar定義など）から取得することもできる。環境変数を使用すると、開発者はコードを修正したり、関数を再構築したりせずに、関数の振る舞いとパラメータを制御できる。これにより、開発エクスペリエンスは向上し、関数の再利用が可能になる
• 実行ロール：関数は、プラットフォームリソースへのアクセスを許可および監査する特定のユーザーまたはロールIDで実行する必要がある
• リソース：関数によって使用されるメモリやCPUなど、必要な、あるいは最大のハードウェアリソースを定義する
• タイムアウト：プラットフォームによって停止されるまでに、関数呼び出しを実行できる最大時間を指定する
• 失敗ログ（Dead Letter Queue）：失敗した関数の実行リストを適切な詳細情報と共に格納するキューあるいはストリームへのパス
• ネットワークポリシー：（外部サービス／リソースと通信するための）関数に割り当てられたネットワークドメインとポリシー
• 実行セマンティクス：関数の実行方法を指定（例えば「最低1回」「最高1回」「イベントごとに1回」）

データバインディング

　幾つかのサーバレスフレームワークでは、関数が使用する入出力データリソースをユーザーが指定できるため、開発者にとってのシンプルさ、パフォーマンス（実行間のデータ接続が保持される、データをプリフェッチできるなど）、セキュリティ（データソースの資格情報はコードではなくコンテキストの一部となる）が向上します。

　バインドされたデータは、ファイル、オブジェクト、レコード、メッセージなどの形をとることができます。関数の仕様はデータバインディング定義の配列を含むことがあり、それぞれがデータリソース、クレデンシャルおよび使用パラメータを指定します。データバインディングはイベントデータを参照することができます（例：DBキーはイベント「ユーザー名」フィールドから取得します）。詳しくはhttps://docs.microsoft.com/azure/azure-functions/functions-triggers-bindingsをご覧ください。

関数への入力

　関数への入力は、イベントデータおよびメタデータを含み、コンテキストオブジェクトを含むことができる。

イベントデータとメタデータ

　イベントの詳細を関数ハンドラに渡す必要があります。イベントによってさまざまなメタデータを持っている可能性があります。従って、関数がイベントのタイプを判別し、全イベント共通、およびイベント固有のメタデータを簡単にパースできるようにすることが望まれます。

　イベントクラスを実装から切り離すことが望ましい場合があります。例えば、ストリーミングストレージがKafkaまたはKinesisであるかどうかに関わらず、メッセージストリームを処理する関数が同じように動作できるようになります。どちらの場合も、メッセージボディとイベントメタデータを受信し、メッセージは異なるフレームワーク間でルーティングされます。

　イベントには単一のレコード（例えばリクエスト／レスポンスモデル）が含まれている場合と、複数のレコードまたはマイクロバッチ（ストリーミングモードなど）を受け入れる場合があります。

　FaaSソリューションで使用される一般的なイベントデータとメタデータの例は、次の通りです。

• イベントクラス／種類
• バージョン
• イベントID
• イベントソース／オリジン
• ソースアイデンティティ
• コンテンツタイプ
• メッセージ本文
• タイムスタンプ

イベントやレコードに固有のメタデータの例：

• HTTP：パス、メソッド、ヘッダ、クエリ引数
• メッセージキュー：トピック、ヘッダ
• レコードストリーム：テーブル、キー、オペレーション、修正時刻、古いフィールド、新しいフィールド

イベントソース構造の例：

• http://docs.aws.amazon.com/lambda/latest/dg/eventsources.html
• https://docs.microsoft.com/azure/azure-functions/functions-triggers-bindings
• https://cloud.google.com/functions/docs/concepts/events-triggers

　いくつかの実装では、イベント情報を関数に渡すためのメカニズムとしてJSONに焦点を当てています。これは、高速処理を行う関数（例えば、ストリーム処理）や低消費電力デバイス（IoT）において、シリアル化／非シリアル化の大きな負荷につながる可能性があります。こうした場合には、ネイティブな開発言語の構造や、追加のシリアル化メカニズムを考慮することに価値があるかもしれません。