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

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

[三木泉，＠IT]

関数の要件

　次のリストは、この技術の最新の状況を踏まえ、関数とサーバレスランタイムが満たす必要のある共通要件を示しています。

• 関数は、異なるイベントクラスの基礎となる実装から切り離されなければならない
• 関数は複数のイベントソースから呼び出されることがある
• 呼び出しメソッドごとに異なる関数を必要としない
• イベントソースは複数の関数を呼び出すことがある
• 関数には、複数の関数にまたがる呼び出しなどで、基底のプラットフォームサービスとの永続的なバインディングのメカニズムが必要になる場合がある。各関数は短命かもしれないが、ロギング、接続、外部データソースのマウントなどを関数の起動ごとに実行すると、ブートストラップが高価になる可能性がある
• それぞれの関数は、同じアプリケーション内で使用されている他の関数とは異なる開発言語で記述できる
• 関数ランタイムは、イベントのシリアル化／シリアル化解除のための負荷を、可能な限り最小化すべき（例えば、ネイティブな言語構造または効率的な符号化方式を使用）

　ワークフロー関連の要件は、次の通りです。

• 関数は、ワークフローの一部として呼び出すことができる。ここで、関数の結果は別の関数をトリガできる
• 機能は、単一のイベントあるいは一連のイベントの組み合わせによってトリガされ得る
• 1つのイベントは、シーケンシャルあるいは並行的に実行される複数の関数をトリガできる。また、イベントの組み合わせは、シーケンシャル／並行／分岐で実行されるm個の関数をトリガできる
• ワークフローの途中で、各種イベントや関数実行結果が受信される可能性があり、これが各種関数への分岐をトリガし得る
• 関数の結果の一部または全ては、別の関数への入力として渡す必要がある
• 関数は、関数間の呼び出しなどのため、基底のプラットフォームサービスとの永続的なバインドのメカニズムを必要とする可能性がある。そうしない限り、関数が短命となる可能性がある

関数の呼び出しタイプ

　関数は、次のようなユースケースに応じて、各種のイベントソースから呼び出すことができます。

1. 同期リクエスト（Req / Rep）、例えばHTTPリクエスト、gRPCコール
   • クライアントはリクエストを発行し、即時のリスポンスを待つ。これはブロッキングコール
2. 非同期メッセージキュー・リクエスト（Pub / Sub）。例えばRabbitMQ、AWS SNS、MQTT、電子メール、オブジェクト（S3）の変更、CRONジョブのようなスケジュールされたイベント
   • メッセージはエクスチェンジに対して発行され、サブスクライバーに配布される
   • 厳密なメッセージの順序はなし。一度だけ処理する
3. メッセージ／レコードのストリーム、例えばKafka、AWS Kinesis、AWS Dynamo DBストリーム、データベースCDC
   • メッセージ／レコードの順序付けられたセット（順次処理する必要がある）
   • 通常、ストリームは複数のパーティション／シャードに分割され、1シャードに対し1ワーカー（シャードコンシューマ）
   • ストリームは、メッセージ、データベースの更新（ジャーナル）、またはファイル（CSV、JSON、Parquetなど）から作成できる
   • イベントを関数ランタイムにプッシュすることも、関数ランタイムによってプルすることもできる
4. バッチジョブ、例えばETLジョブ、分散型ディープラーニング、HPCシミュレーション
   • ジョブはスケジューリングされ、または待ち行列に渡され、複数の関数インスタンスを並列に使用してランタイムで処理される。各関数インスタンスは、ワーキングセット（タスク）の1つまたは複数の部分を処理する
   • 全ての並列ワーカープロセスが全ての計算タスクを正常に完了すると、ジョブは完了する