How to use a plug-in to solve the problem of serverless grayscale publishing

サーバーレスグレースケールリリース

サーバーレスとは

サーバーレスは、その名の通り、サーバーを意識する必要がないコンピューティングの新しい提供方式です。「すぐに使えて、完全な機能を備え、即座に稼働できる」状態を提供します。ユーザーはコードを実行するためのサーバーを事前にプロビジョニングしたり管理したりする必要がなく、各ベンダのサーバーレスプラットフォームにコードをデプロイするだけです。同時に、従量課金、高い柔軟性、低い運保守コスト、イベント駆動、コスト削減と効率向上といったサーバーレスのメリットを享受できます。

サーバーレスグレースケールリリースとは

グレースケールリリースはカナリアデプロイメントとも呼ばれます。かつて鉱夫たちは坑内に入る前にカナリアを先に連れて行きました。坑内でカナリアが酸欠や有毒ガス中毒で死ななければ、鉱夫たちは坑内に入って作業しました。つまり、カナリアが鉱夫たちの命を守っていたと言えます。

同様に、ソフトウェア開発のプロセスにもカナリア、すなわちグレースケールリリースがあります。開発者は新機能をまず一部のユーザーに公開し、そのユーザー間で新機能がスムーズに動作し、フィードバックが良好であれば、全ユーザーに新機能を開放します。カナリアリリースは、一度にすべてをリリースするのではなく、段階的に正式リリースへ移行していくプロセスです。

では、サーバーレスプラットフォームにデプロイした関数のグレースケールリリースはどのように行うのでしょうか。

以下では、Alibaba Cloud FC を例にご紹介します。

グレースケールリリースには 1 つのプロセスと 2 つの方法があります。

1 つのプロセス

サーバーレスグレースケールリリースは、エイリアスを設定することで実現します。エイリアスでは、グレースケールバージョンとメインバージョンのトラフィック比率を設定できます。関数を呼び出す際、設定したエイリアスを使用することで、トラフィックを対応するバージョンに比率に応じて送信できます。

グレースケールリリースの設定プロセスは以下の通りです。

・サービス内で新バージョンをリリースする。

・エイリアスを作成または更新し、新バージョンと安定バージョンを関連付けます。新バージョンがグレースケールバージョンとなります。

・トリガーをエイリアスに関連付ける。

・カスタムドメインをエイリアスに関連付ける。関数の呼び出し時にエイリアスを使用すると、トラフィックは設定された比率に応じて新バージョンと安定バージョンに送信されます。

2 つの従来の方法

Alibaba Cloud コンソール Web インターフェイス：

バージョンのリリース

エイリアスの作成

トリガーの関連付け

カスタムドメインの関連付け

Serverless Devs CLI の使用：

バージョンのリリース

s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"

エイリアスの作成とグレースケールの設定

s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20

トリガーの関連付け

コンソールでの設定が必要

カスタムドメインの関連付け

コンソールでの設定が必要

コンソールまたは Serverless Devs を使用したグレースケールリリースの各ステップは、ユーザー自身が操作を行う必要があり、さまざまな設定によりミスが発生しやすいことがわかります。これらの課題に加えて、グレースケールリリース戦略を便利に利用できないという問題もあります。

一般的なグレースケールリリース戦略は 5 つあります。

1. CanaryStep：段階的リリース。最初に指定した割合のトラフィックをグレースケールに振り分け、指定した時間間隔後に残りのトラフィックをグレースケールに振り分けます。

2. LinearStep：バッチリリース。各バッチで固定のトラフィックを振り分け、指定した時間間隔後に次のバッチを開始します。

3. CanaryPlans：カスタムグレースケールバッチ。各バッチのグレースケールトラフィックと間隔時間を設定し、指定した間隔後に設定されたトラフィックでグレースケールを実行します。

4. CanaryWeight：手動グレースケール。任意の時点でグレースケールバージョンの重みを直接設定します。

5. FullWeight：フルリリース。特定のバージョンにすべてのトラフィックを振り分けます。

これらのグレースケール戦略のうち、最初の 3 つは間隔時間の設定が必要です。しかし、コンソールや Serverless Devs ツールでは間隔時間を自動設定できないため、ユーザーはアラームなどの方法で次のグレースケールプロセスを手動で実行する必要があり、非常に不便です。そこで、関数のグレースケールリリースをワンクリックで支援するプラグイン FC-Canary をご紹介します。

Serverless Devs プラグイン FC-Canary を使ったグレースケールリリース

上記の課題を解決するために、Serverless Devs 用のプラグイン FC-Canary が登場しました。このプラグインは、Serverless Devs ツールと FC コンポーネントを通じて関数のグレースケールリリース機能を実現し、複雑なパラメータ設定、開発者の手動作業の必要性、利用可能なリリース戦略の不足といった課題を効果的に解決します。

（Content configuration and precautions - partial screenshots）

参考：https://github.com/devsapp/fc-canary

FC-Canary の特長

1. FC-Canary は非常にシンプルな設定に対応

ユーザーは s.yaml に最小 5 行のコードを追加するだけで、グレースケールリリースを開始できます。

2. FC-Canary の設定ガイダンスはシンプルで明確

3. FC-Canary は複数のグレースケール戦略に対応

段階的リリース：最初に指定した割合のトラフィックをグレースケールに振り分け、指定した時間間隔後に残りのトラフィックをグレースケールに振り分けます。

この場合、トラフィックの変化は：新バージョンに 20%、10 分後に新バージョンに 100%

手動グレースケール：任意の時点でグレースケールバージョンの重みを直接設定します。

この場合、トラフィックの 10% が新バージョンに、90% が安定バージョンに振り分けられます。

カスタムグレースケール：配列形式でグレースケールの変化を設定します。

この場合、トラフィックの変化は：新バージョンに 10% →（5 分後）新バージョンに 30% →（10 分後）新バージョンに 100%

バッチリリース：グレースケールの割合を段階的に累積し、最終的に 100% のトラフィックが新バージョンに到達します。

トラフィックの変化：新バージョンに 40% →（10 分後）新バージョンに 80% →（10 分後）新バージョンに 100%

フルリリース：100% のトラフィックを新バージョンに振り分けます。

FC-Canary プラグインは 5 つのグレースケール戦略に対応しています。ユーザーは必要な戦略を選択し、シンプルな設定を行うだけで、ワンクリックでのグレースケールリリースを体験できます。

4. FC-Canary のグレースケールステージのプロンプトが明確

プラグインは各マイルストーンをログ形式で表示し、開発者に十分な安心感を提供します。

5. FC-Canary は DingTalk グループボットのリマインダに対応

DingTalk ボットを設定すると、グループ内で関連するリマインダを受け取れます。

FC-Canary のベストプラクティス

FC-Canary プラグインを使用して、Node.js 12 の関数をグレースケールリリースします。

コードリポジトリ：https://github.com/devsapp/fc-canary/tree/main/example/singleFunc-http

初期化設定

コード設定

YAML 設定

canaryWeight 戦略を採用します。グレースケールリリース後、トラフィックの 50% が新バージョンに、50% が旧バージョンに振り分けられます。

初回リリース

リリースの実行

ターミナルで s deploy --use-local を入力します。

結果の確認

コマンドラインのログ出力で確認できます。

初回リリースのため、プロジェクトに履歴バージョンが存在しないため、グレースケールリリース戦略が設定されていても、FC-Canary プラグインはフルリリースを実行します。つまり、トラフィックはすべてバージョン 1 に送信されます。

コードを修正して 2 回目のリリース

2 回目のリリースの前に、コードを修正してエラをスローするようにします。

リリースの実行

ターミナルで s deploy --use-local を入力します。

結果

コマンドラインの出力ログで確認できます。

2 回目のリリースでは、グレースケールリリース戦略が適用されます。つまり、トラフィックの 50% がバージョン 1 に、50% がバージョン 2 に送信されます。

テスト

ログに出力されたドメインを取得し、そのドメインに 100 回アクセスしてから、コンソールのモニタリングダッシュボードを確認します。

関数が合計 100 回呼び出され、エラのある関数が 49 回、正常な関数が 100 - 49 = 51 回実行されたことがわかります。正常な関数とエラのある関数は、それぞれ呼び出し総数の約 50% を占めています。

分析：関数バージョン 1 が正常な関数で、関数バージョン 2 がエラのある関数です。グレースケール設定はバージョン 1 に 50%、バージョン 2 に 50% であるため、呼び出しプロセスでエラのある関数と正常な関数はそれぞれ約 50% を占めるはずです。図の結果は仮定と一致しており、グレースケール戦略が正常に機能していることを証明しています。

まとめ：コンソールを使用したグレースケールリリースと比較して、FC-Canary プラグインを使用することで、バージョンの手動作成、エイリアスのリリース、トリガーの関連付け、カスタムドメインの管理といった手間を省くことができ、非常に便利に利用できます。

Serverless Devs のコンポーネントとプラグインの関係

コンポーネントとは

Serverless Devs Model v0.0.1 の説明によると、コンポーネントとは、Package Developer が開発・リリースした、Serverless Package Model の仕様に準拠するコードのことです。通常、このコードはアプリケーション内で参照され、Serverless Devs 開発ツールにロードされ、事前に定義されたルールに従って処理を実行します。たとえば、ユーザーのコードをサーバーレスプラットフォームにデプロイしたり、サーバーレスアプリケーションをビルド・パッケージしたり、サーバーレスアプリケーションをデバッグしたりします。

例：

Serverless Devs を使用して Alibaba Cloud Function Compute のリソースを管理する場合、YAML 設定ファイルで Alibaba Cloud FC コンポーネントを宣言し、FC コンポーネントの機能を利用できます。

FC コンポーネントは、Alibaba Cloud Function Compute リソースの管理機能を提供します。これには、サービス、関数、バージョン、エイリアスなどの管理機能が含まれます。

コンポーネントのアドレス：https://github.com/devsapp/fc

プラグインとは

プラグインはコンポーネントを補完するもので、コンポーネントの原子機能を提供します。

例：

FC コンポーネント deploy の関数デプロイ機能を使用して、デプロイ後にデプロイされた関数のグレースケールリリースを行う。

FC コンポーネント deploy の関数デプロイ機能を使用する際、デプロイ前に layer-fc プラグインを使用して、デプロイ時のコードアップロード時間を短縮できます。つまり、layer-fc により、関数がパブリック依存ライブラリ（リモート）内の依存関係を直接利用できるようになり、デプロイ時にこれらのリモート依存関係をアップロードする必要がなくなります。

コンポーネントとプラグインの関係

Serverless Devs Model において、コンポーネントは中核的な位置を占め、プラグインはそれを補完する役割です。つまり、プラグインの目的はコンポーネントの機能を強化し、オプションの原子機能を提供することです。

Serverless Devs はコンポーネントとプラグインのライフサイクルを管理します。Pre プラグインの場合、コンポーネントの実行前に実行されます。逆に、Post プラグインはコンポーネントの後に仕上げの処理を実行します。

コンポーネントは複数のプラグインを同時に利用できます。コンポーネントとプラグインの実行順序は以下の通りです。

プラグインは YAML の順序で実行されます。前のプラグインの実行結果は、次のプラグインの入力パラメータとなります。

最後の Pre プラグインの出力が、コンポーネントの入力パラメータとして使用されます。

コンポーネントの出力が、最初の Post プラグインの入力パラメータとして使用されます。

関連概念：

関数（Function）は、FC のスケジューリングと実行の基本単位であり、関数コードと関数設定で構成されます。FC の関数は必ずサービスに所属する必要があります。同一サービス配下のすべての関数は、サービス認可やログ設定などの共通設定を共有します。関数に関する操作の詳細は「関数の管理」を参照してください。関数計算はイベント関数と HTTP 関数の 2 つの関数タイプをサポートしています。それぞれの違いについては「関数の種類」を参照してください。

サービス（Service）はマイクロサービスに相当し（バージョンとエイリアスを持つ）、複数の関数をまとめて 1 つのサービス単位を構成できます。関数を作成する前に、まずサービスを作成する必要があります。同一サービス配下のすべての関数は、サービス認可やログ設定などの共通設定を共有します。

トリガー（Trigger）の役割は、関数の実行をトリガーすることです。関数計算はイベント駆動型の計算モデルを提供します。関数の実行は、関数計算コンソールや SDK からトリガーできるほか、他のイベントソースからもトリガーできます。指定した関数内にトリガーを作成できます。トリガーは一連のルールを記述し、イベントがそのルールに合致すると、イベントソースが関連付けられた関数をトリガーします。

カスタムドメイン（Custom Domain）は、関数計算で Web アプリケーションにドメインをバインドする機能です。

バージョン（Version）はサービスのスナップショットで、サービスの設定、関数コード、および関数設定を含みますが、トリガーは含まれません。バージョンがリリースされると、関数計算はサービスにスナップショットを生成し、自動的にバージョン番号を付与します。

エイリアス（Alias）はバージョンと組み合わせて、関数計算におけるソフトウェア開発ライフサイクルの継続的インテグレーションとリリースを実現します。