1. サーバーレスとは何ですか?
1. サーバーレステクノロジーの概要
サーバーレス(サーバーレス アーキテクチャ)とは、ステートレス コンピューティング コンテナーで実行される開発者によって実装されるサーバー側ロジックを指します。イベントによってトリガーされ、サードパーティによって完全に管理されます。そのビジネス レベルの状態は開発者によって使用されます。ストレージリソースが記録されています。
サーバーレスにより、開発者はサーバー (物理マシン、仮想マシン、コンテナなど) を直接扱う必要がなくなります。ホストが存在しないことの利点は、サーバーのメンテナンスに関するユーザーの運用オーバーヘッドが大幅に軽減され、サーバーのアップグレードを心配する必要がないこと、またホストが存在しないということは、アプリケーションで監視する必要があるメトリクスが異なることを意味します。これは、使用されている基盤となるサービスのほとんどが、CPU、メモリ、ディスク サイズなどの従来のメトリクスを公開しなくなったためです。これにより、アーキテクチャの基礎となる動作の詳細に特別な注意を払う必要がなくなりました。
AWS クラウド アーキテクチャ戦略担当バイスプレジデントの Adrian Cockcroft 氏は、かつてサーバーレスを定義する簡単な方法を示しました。「PaaS が 20 ミリ秒以内にインスタンスを効果的に起動し、0.5 秒実行できる場合、それはサーバーレスと呼ばれます。」そして、「A Berkeley View on Serverless Computing」の論文の説明では、「Serverless = FaaS + BaaS」となります。
上記のサーバーレス アーキテクチャの技術ロジック図を参照すると、サーバーレス アーキテクチャがサードパーティ サービス (サービスとしてのバックエンド、または「BaaS」とも呼ばれる) または一時コンテナーで実行されるカスタム コード (サービスとしての機能) に大きく依存していることがわかります。したがって、FaaSと BaaS は、サーバーレスの 2 つの特定の実装と見なすことができます。関数は、サーバーレス アーキテクチャにおける抽象言語ランタイムの最小単位です。この「従量制」アーキテクチャでは、関数を実行するために必要な CPU や RAM、その他のリソースの量ではなく、関数の実行にかかる時間が重要であり、料金を支払うのはその関数の実行時間だけです。それらの関数が実行される時間を計測します。
以下は、サーバーレスの利点と現在のいくつかの欠点の簡単な分析です。
サーバーレスアーキテクチャの利点は次のとおりです。
- 開発速度の向上：IaaSやPaaSと比較して、サーバーレス技術に基づくFaaSプラットフォームは、従来のアプリケーションを実行するプロセスで顧客のビジネスコードのロジック部分を抽象化して抽出します（ユーザー関数コード+ BaaSのパターンを形成）。開発者は、クラウド プラットフォームの標準開発機能セットによれば、開発者は最下位層でどのようなフレームワークが使用されているかを気にする必要がなく、ビジネス ロジックを開発するだけでよく、インスタンスがいくつ実行されているか、どこで実行されているかなどはわかりません。これにより、開発者はビジネス コードに重点を置くことができます。
- 組み込みの自動デプロイメント: サーバーレス アーキテクチャは通常、プラットフォーム上で提供される API やさまざまなツールを通じて組み込みの自動デプロイメントを実装します。通常、これらのツールはソース コード リポジトリへの変更をリッスンし、コードが更新されると自動的に運用環境にデプロイされます。デプロイ中に、ツールはコードを 1 つ以上の関数にパッケージ化し、FaaS プラットフォームにアップロードし、リクエストに応じて適切な URL とイベント トリガーを使用して構成します。このようにして、各リクエストは対応する関数の実行をトリガーし、コードのリアルタイムのデプロイメントを実現します。
- リソースのオーバーヘッドを削減する:関数がリクエストされていない場合、関数インスタンスは 0 です。リクエストがあると、クラウド プラットフォームはトラフィックを運ぶインスタンスをすぐに起動します。さらに重要なことは、従来のサービスはインスタンスの仕様に従って請求されるのに対し、関数はリクエストに応じて請求できる、つまり呼び出しごとに 1 回支払うということです。
サーバーレスアーキテクチャのいくつかの欠点:
- 状態管理:自由なスケーリングを実現するには、ステートレスであることが必須です。ステートフル サービスの場合、サーバーレスを使用すると柔軟性が失われます。ステートフル サービスはストレージと対話する必要があるため、必然的にレイテンシーと複雑さが増加します。
- コンピューティング環境は高度に標準化されており、サーバーレス コンピューティング アプリケーションが実行される基盤となるサーバーとオペレーティング環境はユーザーに対して透過的であり、ユーザーが選択したり最適化したりすることはできません。サーバーレス コンピューティング プログラムが実行される環境は高度に標準化されており、特定のオペレーティング環境、特定のサーバー バージョン、さらには特定のハードウェア リソースに依存する依存関係によっては、互換性を確保することが困難です。
- ローカル テスト: 現時点では、サーバーレス アーキテクチャを使用した開発プロセスには、成熟したデバッグ ツールと開発ツールがまだ不足しています。
- コールドスタート時間
2. サーバーレスの主要技術
(1) イベントドリブン
サーバーレスの「実行時のみコンピューティング」機能は、サーバーレスが「厳密な」イベント駆動型コンピューティングであることを意味します。イベント駆動型プログラミング設計 この設計モデルは、対話型プログラム (対話型プログラム) の場合に考案されました。これは、システムのプログラミング モデルが大幅に変更されたことも意味します。デスクトップ プログラムや Web フロントエンド アプリケーションなどの GUI プログラムを作成するとき、ボタン、リンク、その他のコンポーネントに対するユーザーの操作をリッスンして、対応する処理ロジックを開始します。これは、ユーザーが使用しているときにのみユーザーの動作に応答するサーバーレスに似ています。
(2) コンテナ技術
コンテナ テクノロジーは通常、サーバーレス アーキテクチャの Docker を通じて実装されます。クラウド サービス プロバイダーは、各関数のコードを別個の Docker コンテナーにパッケージ化します。コンテナー内では、他の関数やアプリケーションの動作に影響を与えることなく、分離された環境でコードを実行できるようにすることができます。
リクエストが到着すると、クラウド サービス プロバイダーはコンテナ内の関数を実行し、完了するとコンテナを破棄します。これにより、各関数の実行時間が短くなり、多くのリソースが消費されなくなり、リソースの無駄が回避されます。
サーバーレス アーキテクチャでは、コンテナー テクノロジーを使用することで、分離された環境で機能を確実に実行でき、増大する需要に合わせて迅速に拡張できます。同時に、コンテナー テクノロジは、関数のアクセス許可を制限して、アクセスすべきではないデータへの関数のアクセスを防ぐことができるため、アプリケーションのセキュリティも向上します。
3. 一般的な技術アーキテクチャとの比較
(1) 従来のアーキテクチャ - VS - サーバーレス
従来の Java Web アプリケーションの技術アーキテクチャは、次の図に示すとおりです。
このようなアーキテクチャでは、フロントエンドを非常に軽量にすることができ、アプリケーション ロジックは不要で、ユーザー インターフェイスのレンダリングと HTTP を介したバックエンドへのリクエストの送信のみを担当し、すべてのデータ操作はバックエンドによって実行されます。 Java プログラム。このようなアーキテクチャは開発が比較的簡単ですが、保守は非常に複雑です。フロントエンド開発とバックエンド開発の両方で、データベースの保守とアプリケーションの更新とアップグレードに非常に専門的な人材、環境構成、および特別な人材が必要です。
サーバーレス アーキテクチャでは、セッション状態をサーバー側のコードに保存する必要がなくなり、セッション状態を NoSQL に直接保存します。これにより、アプリケーションがステートレスになり、柔軟な拡張が可能になります。フロントエンドは BaaS を直接使用してバックエンドのコーディング要件を削減でき、このアーキテクチャは本質的にアプリケーション開発の人件費を削減し、インフラストラクチャを維持するリスクを軽減し、クラウド機能を利用して拡張と迅速な反復を促進します。
（2）MicroService -VS- サーバーレス
マイクロサービス (MicroService) は、ソフトウェア アーキテクチャの分野でもう 1 つの注目のトピックです。マイクロサービスが、単一の責任と機能に焦点を当てた小さな機能ブロックに基づいており、モジュール化を使用して複雑な大規模アプリケーションを結合する場合、サーバーレス アーキテクチャはより「コードの断片化」を実現できるとさらに考えることができます。これを Function as a Services (FaaS) と呼びます。いわゆる「関数」(Function)は、マイクロサービスよりも小さなプログラム単位を提供します。たとえば、マイクロサービスは、顧客に対してすべての CRUD 操作を実行するために必要なコードを表すことができますが、FaaS の「関数」は、顧客が実行するすべての操作 (作成、読み取り、更新、削除) を表すことができます。「アカウント作成」イベントがトリガーされると、対応する「関数」が AWS Lambda 関数を通じて実行されます。このレベルの意味から、サーバーレス アーキテクチャを FaaS の概念と単純に同一視することができます。
サーバーレスは本質的にマイクロサービス アーキテクチャを補完するものです。サーバーレス アプリケーションには独自のゲートウェイ、データベース、インターフェイスがあり、好みの言語 (サービス プロバイダーによって制限される) を使用してサービスを開発することもできます。言い換えれば、この状況ではサーバーレスが完璧なマイクロサービス インスタンスになる可能性があります。
（3）サーバーフルクラウド -VS- サーバーレスクラウド
従来のクラウド プラットフォームとサーバーレス プラットフォームの 3 つの主な違いは次のとおりです。
- ** コンピューティングとストレージの分離。**ストレージとコンピューティングは個別にスケールされ、プロビジョニングされ、個別に価格設定されます。通常、ストレージは別のクラウド サービスによって提供され、計算はステートレスです。
- ** リソース割り当てを管理せずにコードを実行します。**ユーザーはリソースを要求する代わりにコードを提供し、クラウドはそのコードを実行するためのリソースを自動的に提供します。
- 割り当てられたリソースではなく、使用されたリソースに比例して支払います。請求は、基本的なクラウド プラットフォームの特定の要素 (割り当てられた VM のサイズや数など) ではなく、実行に関連する特定の要素 (実行時間など) に基づいて実行されます。
従来のクラウド プラットフォームとサーバーレス プラットフォームのその他の技術的詳細の比較 (AWS を例に挙げます):
4. サーバーレス業界のエンジニアリング実践
- AWS Lambda: AWS Lambda クラウド コンピューティング サービスの概要_AWS Lambda の使い方 - AWS クラウド サービス(amazon.com)
- Alibaba Cloud ファンクション コンピューティング プラットフォーム:ファンクション コンピューティング FC_Serverless Computing_Serverless_Containers およびミドルウェア - Alibaba Cloud (aliyun.com)
- オープンソースのFaaSプラットフォーム
- 等
二、FaaS
1、IaaS -> CaaS -> PaaS -> FaaS
-
IaaS (サービスとしてのインフラストラクチャ): サービスとしてのインフラストラクチャ。インフラストラクチャ（コンピューティング、ストレージ、ネットワークなど）をサービスとして提供することを指し、ユーザーはこれをベースに独自のアプリケーション環境を構築できます。
-
CaaS (サービスとしてのコンテナー): サービスとしてのコンテナー。これはコンテナー技術をユーザーに提供することを指し、ユーザーはコンテナーを通じて独自のアプリケーションを実行できます。
-
PaaS (サービスとしてのプラットフォーム): サービスとしてのプラットフォーム。開発プラットフォームとアプリケーション管理ツールの提供を指し、ユーザーはアプリケーションの開発と運用のみに注意すればよく、基盤となるインフラストラクチャには注意を払う必要はありません。
-
サーバーレス: サーバーレス アーキテクチャ。これは、アプリケーションを実行するためにサーバー リソースを明示的に管理および構成する必要がなく、基本的な管理とメンテナンスはすべてプラットフォーム プロバイダーの責任であることを意味します。ユーザーは自分のコードをアップロードし、コードが自動的に実行されるのを待つだけで済みます。サーバーレス = FaaS + BaaS。BaaS (サービスとしてのバックエンド)
-
FaaS (Function as a Service) Function as a Service:クラウド コンピューティング サービスとして、開発者はアプリケーション全体ではなく、個々の機能をクラウド プロバイダーに展開できます。クラウド プロバイダーは、リクエストが到着すると関数を自動的に実行し、リクエストが完了すると関数を破棄します。そして「FaaS」で最も重要な「F」、つまり機能はどのように定義されているのか？OpenFaaS プロジェクトの開始者である Alex による CloudFunction の次の定義を参照できます。
2. FaaSのキーテクノロジー
FaaS で直面する必要があるいくつかの主要な技術的ソリューションについて簡単に説明しましょう。
(1) 柔軟なスケーリング (オーケストレーションベースとしての K8s)
自動スケーリングは関数コンピューティングのコスト最適化の重要な部分であり、自動スケーリングの主なターゲットは関数インスタンスです (一部の FaaS アーキテクチャには、一緒に開始される MQ トリガー インスタンスも含まれています)。エラスティック スケーリングの主なプロセスには、インジケーターのセンシング (エラスティック スケーリングのトリガー) -> スケーリング ポリシー計算のスケジューリング -> 最終的なスケーリングの有効化が含まれます。上記の手順は k8s HPA と非常に似ていますが、関数の特性に合わせて実装メカニズムが変更されています。このようにして、k8s の現在の機能も FaaS の柔軟なスケーリング要件を効果的に満たすことができるため、オープンソース コミュニティにおけるサーバーレス/FaaS 製品は、基本的に k8s./FaaS 製品開発に基づいて実装されます。
以下は、k8s に基づくオープン ソース プロジェクト OpenFaaS のアーキテクチャ図です。
Elastic scalingに関しては、Kubernetes の HPA に加えて、コミュニティにはイベント駆動型アーキテクチャの Elastic Framework KEDA と KPA (Knative 実装) があります。KEDA が解決する中心的な問題は、イベント駆動型アーキテクチャ (イベント トリガー スケーリング) の下での柔軟なスケーリングと、0 -> 1、1 -> 0 のインスタンスの問題です。KEDA は Kubernetes Metrics Server として機能し、ユーザーは次のことを行うことができます。専用の Kubernetes カスタム リソース定義を使用して自動スケーリング ルールを定義します。
KEDA はクラウドとエッジで実行でき、Kubernetes コンポーネント (水平ポッド オートスケーラーなど) とネイティブに統合でき、外部依存関係がありません。、KEDA の全体的な構造は次のとおりです。
(2) 関数ランタイムと関数ロード機構
FaaS ランタイムは、関数実行用のリソースとセキュリティで分離された言語ランタイム環境を提供し、呼び出しイベント、コンテキスト情報、および応答情報を関数に配信する必要があります。関数ランタイムには、多言語アクセスをサポートするための統一インターフェイス仕様と、関数インスタンスのライフサイクルを維持するための専用の監視および管理コンポーネント (関数インスタンスで開始されるエージェントと同様) が必要です。業界で成熟した FaaS プラットフォームである AWS の Lambda を例に
とるその関数ランタイム アーキテクチャは次の図に示すものと似ています。右側の点線のボックスは、RuntimeAgent (つまり、関数を処理する API エンドポイント) 呼び出しプロセス中の関数プロセスを監視および管理し、実行データを収集して関数インスタンス外のHostAgent (Lambda Service)にアップロードして分析および記録する;プロセスには、ユーザーの業務を実行する関数プロセスが含まれますFaaS プラットフォームによって提供されるロジックとランタイム環境。
Lambda は、ランタイムおよびランタイム APIを通じて複数の言語をサポートします。ランタイム API とランタイムは API 仕様を通じて呼び出され、ユーザー関数は初期化、ロード、呼び出しなどの操作を完了するためにランタイムの特定のインターフェイス関数を実装するだけで済みます。さらに、ランタイムは、Lambda と関数の間で呼び出しイベント、コンテキスト情報、応答を渡すための言語固有の環境を提供します。ユーザーは、Lambda プラットフォームが提供するランタイムを使用することも、独自のランタイムを構築することもできます。主要なプログラミング言語の各バージョンには、python3.10 や nodejs18.x など、一意のランタイム識別子を持つ
個別のランタイムがあります。新しいメジャー言語バージョンを使用するように関数を構成するには、ランタイム識別子を変更する必要があります。AWS Lambda はメジャーリリース間の下位互換性を保証できないため、これはお客様の裁量による操作となります。
コンテナ イメージとして定義された関数の場合、コンテナ イメージの作成時にランタイムとLinux ディストリビューションを選択できます。ランタイムを変更するには、関数の構成を更新し、新しいコンテナー イメージを作成する必要があります。ランタイムは Amazon Linux ディストリビューションとペアになっています。基礎となる実行環境には、関数コードからアクセスできる追加のライブラリと環境変数が用意されています。
k8s クラスターでは、実行環境関数インスタンス全体が特定のクラスター内のポッドとして実行され、他の k8s コンポーネントまたはユーザー定義コンポーネントと対話できます。
上記のことから、Lambda はユーザー関数を均一にパッケージ化して実行時にミラーリングすることで関数の読み込みを実装していることがわかりますが、ここでは展開しませんが、ユーザー関数のコードの読み込みはディレクトリのマウントやメモリの共有によって実装することもできます。
(3) コールドスタート
コールドスタートとは、スケジュール設定から起動、サービスの提供が可能になるまでのユーザー関数インスタンスの準備フェーズを指します。従来の k8s クラスターでユーザー関数と関数ランタイムを含むミラー コンテナーを起動する手順を見てみましょう。
- スケジューリング関数のリソースを適用するには、kube-scheduler が需要と既存のリソースの計算に基づいてスケジューリング ノードを指定します。
- 指定されたノードの kubelet プロセスは、ポッドがノードにディスパッチされたことを検出し、コンテナー ランタイムを呼び出すときにレジストリからイメージをプルします。
- 低レベルのコンテナーが実行されているときにコンテナーをプルアップし、k8s エンドポイントを登録してヘルスチェックを実行します (1 秒ごと)
- ヘルスチェックに合格し、コンテナーがクラスター内で正常に初期化されます。
- (コンテナ内: 関数ランタイム、関数インスタンス、RuntimeAgent など、初期化と関数登録が完了)
イメージのプル時間は制御不能で、数秒から数十秒、場合によっては数分にも及びます。関数コードがイメージに含まれる場合、関数イメージの不均一性と多数の関数ミラーリングの存在により、再利用するのは難しい。次に、kubelet によるコンテナの作成には通常数秒かかりますが、コンテナ起動後はコンテナ内の関数プロセスの起動時間 (実行環境の起動や依存関係の準備など) にも時間がかかります。
要約すると、関数のコールド スタートの遅延は FaaS の重要な問題であり、現在、業界ではコールド スタートの最適化のために次の方法があります。
-
イメージプルの遅延については、イメージコード分離の方法を採用できます。イメージ自体が階層化されているため、関数ランタイム、RuntimeAgent、その他の環境に依存するレイヤーからユーザー関数コードを分離し、ノードがその部分を進めます。変更されないコンテンツの部分 時間を節約するために事前にプルしてください。
-
コンテナの起動、関数ランタイム、RuntimeAgentなどのコンテナ内の環境、コンテナ起動後のコンポーネント起動による時間ロスを考慮すると、関数インスタンスを予熱する、つまりコールド状態を維持することで遅延を短縮できます。start resource pool。FaaS プラットフォームは、コールド スタート リソース プールを形成するために、ビジネス関数を含まない基本コンテナのバッチを事前に維持できます。コールド スタート プロセスの後、それはユーザー関数インスタンスにバインドされ、プルスルーできます。 **共有ストレージボリューム** または直接オンライン コードを取得するなどしてユーザー関数インスタンスをロードし、サービスの提供を開始します。コールド スタート プールの容量、拡張、縮小は、FaaS プラットフォームによって均一に監視および管理されます。(または、より軽量で効率的なコンテナ ランタイムを使用します。1 つは Firecracker などの KVM ベースの軽量仮想化テクノロジであり、もう 1 つは Wasm です。AWS の Lambda 基盤テクノロジは Firecracker を使用しており、そのコールド スタート時間はミリ秒レベルです)
-
ヘルスチェックに関して、OpenFaaS は、K8s ヘルスチェックの前に RuntimeAgent (watchdog) を使用して外部トラフィックを事前に受け入れて処理することで遅延を削減しようとしていますが、この方法には多くの問題があり、現時点では推奨されていません。
-
コンテナ内でのユーザ業務関数プロセスインスタンスの起動に時間がかかる場合は、OpenFaaSでキャッシュ関数インスタンスを保持したまま、コンテナ内でリクエストごとにプロセスをフォークする方法を参考にしてください。
さらに、一般的な FaaS では、フロー レートが 0 の場合、関数インスタンスのトラフィックを 0 に減らす必要があります (K8s ネイティブ HPA では一時的にこれを行うことはできませんが、KEDA では行うことができます)。ただし、一部の FaaS プラットフォームではこれに関する制限が強制されていません。 OpenFaaS オープン ソース バージョンは、デフォルトで関数インスタンスを実行して初期トラフィックを伝送します。また、他の一部のプラットフォームでは、初期化が長すぎる問題を回避するためにコールド スタート リソース プールを維持する方法が採用されています。
(4) 関数の呼び出し・トリガー方法
-
Web 関数アーキテクチャに基づいています。その本質は、HTTP 経由で関数を呼び出すことです。ここでの核心は、関数インスタンスのランタイム環境が Web フレームワークと Web サーバーを提供する必要があり、リクエストがランタイムに入った後にユーザー関数が呼び出されるということです。各関数は、デフォルトで HTTP トリガーを構成し、固定の独立したドメイン名を割り当てます。ドメイン名が要求される限り、HTTP トリガー関数として実行できます。関数は、対応するインターフェイスを実装している限り、要求を処理できます。 、最後に FaaS プラットフォームによって提供される API ゲートウェイを介して、関数インスタンス インターフェイスのリクエストを一元的に処理します。
-
イベント駆動型アーキテクチャ: コミュニティ製品とパブリック クラウド製品の両方にトリガーの概念があります。いわゆるトリガーは実際にはイベント ソースであり、イベント ソースは統合サイドカー コンテナーで受信して HTTP で関数を呼び出すことも、各関数のランタイムで直接受信して関数を呼び出すこともできます。
-
メッセージ キュー MQ に基づく: MQ の消費は、ビジネス シナリオにおける一般的なビジネス タイプです。オフライン データ計算であっても、オンライン リアルタイム メッセージであっても、MQ は、ビジネスを非同期に処理し分離するためのミドルウェアとして選択されます。したがって、MQ メッセージ キューは、 FaaSプラットフォーム全体の最大の交通入口として使用されます。
-
ユーザー定義のトリガー方法:たとえば、OpenFaaS の Connector と呼ばれるコンポーネントを使用すると、開発者は関数のトリガー方法をカスタマイズできます。
(5) その他
以下は私が個人的にまとめた FaaS に関する技術的なポイントであり、あまり完全ではない可能性があり、参考程度に留めてください。
3. クラウドネイティブのFaaSフレームワーク
(1) オープンファンクション
OpenFunction は、最新のクラウドネイティブFaaS (Function as a Service) フレームワークであり、Knative、Tekton、Shipwright、Dapr、KEDA などを含む多くの優れたオープンソース テクノロジー スタックを導入しています。可能性は無限です。
- Shipwright を使用すると、ユーザーは関数構築プロセス中にイメージ構築ツールを自由に選択および切り替えることができ、それらを抽象化して統一 API を提供します。
- Knative は、強力な自動スケーリング機能を備えた優れた同期関数ランタイムを提供します。
- KEDA は、より多くの種類の指標に基づいて自動的にスケーリングでき、より柔軟です。
- Dapr は、さまざまなアプリケーションの一般的な機能を抽象化し、分散アプリケーション開発の作業負荷を軽減します。
(2) OpenFaaS
OpenFaaS は、長期にわたって開発された FaaS オープン ソース プロジェクトであり、GitHub で注目を集めており、CloudFunction の実行時のリクエストの処理モードについてさらに調査が行われています。この記事の 3 番目のセクションでは、FaaS 実践の導入に焦点を当てます。
(3) Knative：ホーム - Knative
Knative は、コンテナ化されたアプリケーションの開発、デプロイ、管理のプロセスを簡素化し、高速化するように設計されたオープンソースの Kubernetes ベースのプラットフォームです。開発者が最新のクラウドネイティブ アプリケーションを Kubernetes クラスターにデプロイし、サーバーレス アーキテクチャ (サーバーレス) と自動化されたコンテナ オーケストレーションを実装するのに役立つ一連のビルディング ブロックとツールを提供します。
3. FaaS の実践 - OpenFaaS
1。概要
(1) とは何ですか
OpenFaaS は、ユーザーが独自の機能をデプロイして実行できるオープンソースの FaaS フレームワークです。OpenFaaS は、基盤となるテクノロジーとして Docker コンテナを使用し、任意のクラウド環境またはプライベート クラウド上で実行できます。OpenFaaS プロジェクトは、Kubernetes クラスターやスタンドアロン仮想マシンなどの低レベルのインフラストラクチャを、サーバーレス機能を管理するための高レベルのプラットフォームに変えることを目的としています。
(2) 何をしましたか
- 関数呼び出し: WatchDog は、 Cloud Function を呼び出して監視するための OpenFaaS の主要な実装であり、関数とマイクロサービスを実行するためのリバース プロキシとして機能します。これは、独立して使用することも、OpenFaaS コンテナーの EntryPoint として使用することもでき、関数コンテナーで「 Init Process 」として開始することもできます。Golang で実装された組み込み HttpServer があり、同時リクエスト、タイムアウト、ヘルス チェックなどの機能を提供します。開発者はさまざまな環境変数をロードすることで機能をカスタマイズできます。
- 自動スケーリング: OpenFaaS は、独自に設計された AutoScaler を使用して、機能を自動的にスケーリングします。
- コールド スタート: OpenFaaS はアーキテクチャ設計に重点を置いています。OpenFaaS はコールド スタート プールを維持せず、オンデマンドでビジネス コードをロードします。読み取り専用のファイル システムを維持することを望んでいます。コンテナ キャリアは、予測可能性を得るために不変のユニットとして設計されています。ライフサイクルを確保し、最大限のセキュリティを実現します。したがって、トラフィックがない場合、OpenFaaS はデフォルトで関数インスタンスの数をゼロに削減しません。関数粒度のオプション構成としてのみ有効になります。コールド スタート データ トラフィック全体は、最小のインスタンスによって伝送されることが期待されます。新しいインスタンスに必要なリソースのスケジューリング、バイナリ プル、プロセスの起動、およびヘルス チェックにより、コールド スタートの膨大なオーバーヘッドが生成されます。
(3) 使用方法
OpenFaaSは Helm を通じてネイティブ K8 にデプロイされます
2. 主要な技術コンポーネント
OpenFaaSテクノロジーの概要図:
上図は OpenFaaS の抽象的なサービス プロセスであり、各ノードの簡単な紹介は次のとおりです。
ゲートウェイ:ユーザーリクエストと内部指示を受信するための HTTP ゲートウェイ。
NATSストリーミング:関数を非同期に実行するために使用されます。
Prometheus / AlertManager:サービス指標を収集し、操作をスケールするために使用されます。
faas -netes: K8S 用プロバイダー、Docker Swarm などの他のプロバイダーをカスタマイズできます。
Docker Registry:関数イメージをプルするためのリポジトリ。
（1）ウォッチドッグ
WatchDog は、Cloud Function の呼び出しと監視のための OpenFaaS の主要な実装です。最新の of-watchdog は、関数やマイクロサービスを実行するためのリバース プロキシとして機能します。スタンドアロンで使用することも、 OpenFaaS コンテナーのEntryPointとして使用することもでき、関数コンテナーで「 Init Process 」として開始することもできます。Golang で実装された組み込み HttpServer があり、同時リクエスト、タイムアウト、ヘルス チェックなどの機能を提供します。開発者はさまざまな環境変数をロードすることで機能をカスタマイズできます。OpenFaaS は、ClassicWatchdog と of-Watchdog という 2 つの Watchdog モードを開始しました。それぞれ以下の内容を紹介します。
- クラシック WatchDog 動作モード:
このモードでは、ウォッチドッグはポート8080でリッスンする軽量 HTTP サーバーを起動し、各受信リクエストは次のようになります。
- リクエストヘッダーとリクエストボディの読み取り
- 実際の関数を含む実行可能ファイルを fork または exec
- リクエストヘッダーとリクエストボディを関数プロセスの標準入力に書き込みます。
- 関数プロセスの終了（またはタイムアウト）を待ちます。
- 関数プロセスのstdoutとstderrを読み取ります。
- 未読のバイトを HTTP 応答で呼び出し元に送り返します。
上記のロジックは、従来のCommon Gateway Interface (CGI)に似ています。関数呼び出しごとに個別のプロセスを開始するのは効率が悪いように思える一方で、I/O 処理に標準入出力ストリームを使用するプログラム (CLI ツールを含む) を OpenFaaS 関数としてデプロイできるため、非常に便利です。 。
分離に関しては、関数と呼び出しを区別する必要があります。
- OpenFaaS のさまざまな機能は常にさまざまなコンテナーに分散されます
- スケーリング オプションに応じて、関数には 1 つ以上のコンテナーを含めることができます
- 同じ関数への独立した呼び出しが同じコンテナ内で終了する可能性がある
- 同じ関数の独立した呼び出しは、常に異なるプロセスを使用して行われます。
- リバース プロキシ ウォッチドッグ動作モード:
クラシックランタイムが CGI に似ている場合、このランタイム モードは後のFastCGIに似ています。ランタイムは、関数が呼び出されるたびに新しいプロセスを生成するのではなく、ウォッチドッグの背後で長時間実行される HTTP サーバーがあることを想定しています。これにより、本質的にウォッチドッグ コンポーネントがリバース プロキシに変わります。コンテナが起動すると、リバース プロキシ ウォッチドッグは、ポート8080でリッスンする軽量の HTTP サーバーも作成します。ただし、従来のウォッチドッグとは異なり、リバース プロキシウォッチドッグは関数のプロセスを 1 回作成するだけで、それを (長時間実行される) アップストリーム サーバーとして扱います。その後、関数呼び出しはそのアップストリームへの HTTP リクエストに変わります。
ただし、リバース プロキシモードは、クラシックモードを置き換えることを目的としたものではありません。クラシックモードの長所は、その関数が非常に簡単に記述できることです。これは、HTTP サーバーを使用しないコードの唯一のオプションでもあります。たとえば、Cobol、bash、PowerShell スクリプトなどで記述された関数です。
リバース プロキシランタイム モードを使用する場合:
- 関数は呼び出し間で状態を維持する必要があります。
- キャッシュ
- 永続的な接続 (例: 関数からデータベースへの接続を開いたままにする)
- ステートフル関数
- 関数ごとにプロセスを開始するとコストがかかり、呼び出しごとに遅延が発生する可能性があります
- (マイクロ)サービスを関数として実行したい
OpenFaaS 、 FaaS 、特に OpenFaaSの作成者であるAlex Ellis 氏によると、サーバー抽象化に依存せずにマイクロサービスを展開する簡素化された方法と見なすことができます。つまり、FaaS はサーバーレス アーキテクチャの標準的な例です。
したがって、関数は、リバース プロキシ アプローチを使用してマイクロサービスをデプロイする独自の方法と見なすことができます。便利、早くて簡単。ただし、ステートフル関数を使用する場合は、複数の呼び出しが同じプロセスで終了する可能性があるため、警告に注意してください。
- 1 つのプロセスで終了する同時呼び出しは、コード内で競合状態を引き起こす可能性があります (たとえば、ロックで保護されていないグローバル変数を持つ Go 関数)。
- 1 つのプロセスで終了する後続の呼び出しは、クロスコール データ漏洩につながる可能性があります (もちろん、従来のマイクロサービスと同様)。
- プロセスは呼び出し間で再利用されるため、コード内のメモリ リークは割り当て解除されません。
wathdog とリバース プロキシ ウォッチドッグの動作モードの比較:
（2）APIゲートウェイ
Openfaas ゲートウェイは、カスタム関数、組み込み UI、faas-cli 用の RESTful インターフェイスの外部ルーティングを提供し、API リクエストは Openfaas ゲートウェイによって処理および配布されます。
また、Openfaas ゲートウェイは Prometheus を統合して機能とサービスの監視機能を提供し、faas プロバイダー API を呼び出してコンテナーを管理することもできます。
Faas-provider は、Openfaas プロバイダーの Http REST API 標準に準拠する Go 言語で実装された SDK ツールセットです。
OpenFaaS API Gateway の主な役割:
- 関数に対する CRUD 操作
- プロキシ機能呼び出しサービス
- 関数コンテナのスケーリングを管理する
- コンテナキーの管理
- 丸太の排水
(3)FaaS-プロバイダーインターフェース/フェーズネット
参考文献: OpenFaaS におけるインターフェイスのパワー (alexellis.io)
（3）オートスケーリング
参考資料:自動スケーリング - OpenFaaS、OpenFaaS を使用してゼロにスケールし、再びゼロに戻す
(4) NATSベースの非同期関数呼び出し
次の 2 つの図は、PDF ファイル関数をアップロードするための同期/非同期呼び出しの呼び出しプロセスを簡単に示し、NATS を介して非同期関数呼び出しを実装する方法を示しています。
3. その他
(1) OpenFaaS開発者の視点
参考文献：