サーバーレスクラウド開発の高度なアプリケーションを紹介する記事

以前、アプリケーションにクラウド関数を作成し、そのクラウド関数を Express と統合し、クラウドデータベースと連携して追加、削除、変更、クエリのインターフェースを作成しました。ただし、この開発方法は Serverless を使用する最良の方法ではありません。

私たちのコードでは、バックエンドアプリケーション全体のすべてのビジネス機能が 1 つの関数に記述されています。これを行う利点は、管理が容易になることです。結局のところ、1 つのアプリケーションの下には 1 つのクラウド機能しかありません。ただし、単一のクラウド関数の同時実行には制限があります。並列関数インスタンスの数はクラウドベンダーによって決定されます。制限を超えると、イベントキューは、新しい関数インスタンスを生成する前に、他の関数インスタンスの実行が完了するまで待機する必要があります。

サーバーレスは弾力的にスケーラブルではないのかと疑問に思う人もいるかもしれません。業務処理のニーズに応じてリソースが自動的に割り当てられると言われています。関数に同時実行制限があるのはなぜですか?

これを理解するには、FaaS がどのように機能するかを理解する必要があります。

FaaSの仕組み

FaaS プラットフォームでは、デフォルトでは関数は実行されず、リソースは割り当てられず、関数コードも FaaS に保存されません。 FaaS はトリガーイベントを受信した場合にのみ関数を開始して実行します。以前は、関数コードを実行するために HTTP トリガーを使用しました。関数実行プロセス全体は、実際には次の 4 つの段階に分けられます。

コードのダウンロード: FaaS プラットフォーム自体はコードを保存しません。代わりに、コードをオブジェクトストレージに配置します。関数を実行する必要があるときは、関数コードがオブジェクトストレージからダウンロードされ、解凍されます。したがって、FaaS プラットフォームでは通常、コードパッケージのサイズが制限され、通常は 50 MB を超えることはできません。

コンテナを起動します。コードがダウンロードされた後、FaaS は関数構成に基づいて対応するコンテナを起動します。 FaaS はリソースの分離にコンテナを使用します。

オペレーティング環境を初期化します。コードの依存関係を分析し、ユーザー初期化ロジックを実行し、エントリ関数の外部でコードを初期化するなどします。

コードの実行: エントリ関数を呼び出してコードを実行します。

関数が初めて実行されるときは、4 つの完全なステップが実行されます。最初の 3 つのプロセスは総称して「コールドスタート」と呼ばれ、最後のステップは「ホットスタート」と呼ばれます。

コールドスタートプロセス全体には、最大で数百ミリ秒かかる場合があります。関数の実行が終了した後、実行環境は一定期間保持されます。保持時間は、クラウドベンダーによって異なりますが、数分から数十分の範囲になります。この期間中に関数を再度実行する必要がある場合、FaaS プラットフォームは最後に実行された環境を使用します。これは「実行コンテキストの再利用」であり、「インスタンスの再利用」とも呼ばれます。関数の起動プロセスは「ホットスタート」とも呼ばれます。「ホットスタート」にかかる時間は、すべて機能の起動にかかる時間です。一定時間リクエストがない場合、関数実行環境は次のイベントが到着するまで解放され、その後再びコールドスタートから初期化されます。

次のクラウド関数を検討してください。

クラウド関数が初めて呼び出されたとき、関数の戻り値は 1 であり、これは予想どおりです。

しかし、このクラウド関数を継続的に呼び出すと、戻り値が 2 から増加したり、1 になったりすることがあります。これはインスタンスの再利用の結果です。

ホットスタート時は関数を実行するNode.jsプロセスが再利用され、プロセスのコンテキストが保持されるため、変数 i がインクリメントされます。
コールドスタートの場合、Node.js プロセスは新しく、コードは最初から完全に実行され、1 が返されます。

以下は関数のリクエスト図です。「リクエスト 1」と「リクエスト 3」はコールドスタート、「リクエスト 2」はホットスタートです。

関数が実行されると、実行環境は破棄されます。最初の関数実行時にはパフォーマンスが低下しますが、リソースの利用効率は大幅に向上します。環境は初期化され、コードを実行する必要がある場合にのみハードウェアリソースが消費されます。また、アプリケーションに多数のリクエストがある場合、ほとんどの場合、関数の実行はホットスタートになる可能性があります。

関数のライフサイクルから、関数が 1 分ごとに実行される場合、関数はほぼ常にホットスタートされ、つまり以前の実行コンテキストが再利用されることがわかります。実行コンテキストには、関数のコンテナ環境とエントリ関数の外部のコードが含まれます。

クラウドプラットフォームは、現在の負荷に基づいてクラウド機能インスタンスの数を自動的に制御し、リクエストを均等に分散します。複数の連続したリクエストは、同じインスタンスによって処理される場合とされない場合があります。これは上記のコードで確認できる内容です。 i の値は非常に制限がなく、パターンはまったくありません。したがって、クラウド関数を作成するときは、クラウド関数がステートレスかつべき等であること、つまり、現在のクラウド関数の実行が、前のクラウド関数の実行中に実行環境に残っていた情報に依存しないことを確認する必要があります。

Todo の例に戻りましょう。すべてのビジネスロジックをクラウド関数に配置するため、処理できる同時実行の量が大幅に制限されます。同時実行性が一定のレベルに達すると、それ以上の関数インスタンスは作成できなくなり、サーバーリソースを割り当てることもできなくなります。より良い方法は、ビジネスロジックを分割することです。 1 つのクラウド関数は、独立したビジネスロジックプロセスに対応します。これはミニプログラムのクラウド開発に反映されています。私たちに提供されるデフォルトのミニプログラムクラウド開発テンプレートは、ミニプログラムアプリケーションが各クラウド機能を処理する方法です。

そして、機能や業務が増えていくと必然的に機能も増え、開発工程におけるコード管理が特に重要になってきます。 Tencent が公式に提供している cloudbase-framework ツールがその方法を提供します。先ほど使用した CloudBase CLI コマンドラインツールは、cloudbase-framework の外部インターフェースツールです。つまり、使用するコマンドラインは、実際には cloudbase-framework によって提供される関数を呼び出します。

アプリケーションを作成するための tcb new、http トリガーを作成するための tcb application deployment、http トリガーを作成するための tcb service create、コードを段階的に更新するための tcb fn code update xxx function name など、それらのいくつかは以前にすでに使用しています。

コードのデプロイに関連するこれらのコマンドに加えて、フレームワークはクラウドプラットフォームリソースをワンストップで管理する機能も提供します。

CloudBaseフレームワークの使用

次に、サーバーレス開発モデルに従って Todo ケースをリファクタリングします。 Tencent Cloud Development CloudBase では、さまざまな開発テンプレートが作成されています。 tcb new コマンドを使用すると確認できます。アプリケーションテンプレートを選択するときは、Vue アプリケーションを選択して、Vue クラウド開発プロジェクトを作成します。

プロジェクトが作成されると、プロジェクトパスの下に cloudfunctions ディレクトリがあることがわかります。ここにクラウド関数が保存されます。 1 つの機能はフォルダーです。

では、これらの機能をどのように管理すればよいのでしょうか?プロジェクトのルートパスには、アプリケーションフレームワーク全体の構成ファイルである cloudbaserc.json ファイルがあります。この構成ファイルを使用して、プロジェクトアプリケーションを管理できます。したがって、始める前に、まずこの構成ファイル内の各構成項目の意味を理解する必要があります。

バージョンフィールド: CLI 0.9.1 以降では、動的変数機能をサポートする新しいバージョン 2.0 構成ファイルが導入されています。

新しい機能を有効にするには、cloudbaserc.json で "version": "2.0" を宣言します。新しいバージョンの構成ファイルは JSON 形式のみをサポートします。動的変数機能を使用すると、cloudbaserc.json 構成ファイル内の動的変数を使用して、環境変数やその他のデータソースから動的データを取得できます。 {{}} で囲まれた値は動的変数として定義され、データソース内の値を参照できます。

envId フィールド: アプリケーション ID

$schema : 設定テンプレートの説明

地域: アプリケーションが配置されている地域

フレームワーク: 設定ファイルの主な設定項目

フレームワークフィールド: name属性はアプリケーション名です

framework.plugins : ここでアプリケーションを管理します。

フレームワークはプラグインメカニズムをサポートし、さまざまなアプリケーションフレームワークやクラウドリソース用のプラグインを提供します。アプリケーションが依存するプラグインは、plugins パラメータの下で構成されます。フレームワークは、プラグインの構成に従ってアプリケーションを管理し、アプリケーションのビルド、デプロイメント、開発、デバッグなどのプロセスを処理します。アプリケーションは複数のプラグインを使用し、異なるカスタムプロパティ名を使用してそれらを管理できます。

公式プラグインは多数あり、https://docs.cloudbase.net/framework/plugins/ で確認できます。