Knativa's traffic-based grayscale release and automatic elastic practice
1、Knative
Knative はトラフィックに基づく自動スケーリング機能を提供します。ピーク時にはアプリケーションのリクエスト量に応じてインスタンス数を自動的に拡張でき、リクエスト量が減少するとインスタンス数を自動的に縮小して、リソースコストの自動化された節約を実現します。さらに、Knative はトラフィックベースのグレーリリース機能も提供し、トラフィックのパーセンテージを段階的に新バージョンへ配分できます。
Knative のグレーリリースと自動弾性について説明する前に、まず ASK Knative におけるトラフィックリクエストの仕組みを確認しましょう。
前述の図に示すように、トラフィックリクエストの仕組みは全体として以下の部分に分かれます。
左側は Knative Service のバージョン情報で、トラフィックのパーセンテージを設定できます。以下はルーティング戦略で、Ingress コントローラーを通じて対応するルーティングルールが Alibaba Cloud SLB に設定されます。
右側は対応する Service のバージョン Revision で、Deployment リソースに対応します。トラフィックが SLB を通じて流入すると、対応する転送ルールに従ってバックエンドサーバーの Pod に直接転送されます。
トラフィックリクエストの仕組みに加え、前述の図には KPA や HPA などの弾性戦略も示されています。
2、サービスライフサイクル
Service は開発者が直接操作するリソースオブジェクトで、Route と Configuration の 2 つのリソースで構成されます。
前述の図に示すように、ユーザーは Configuration の情報を設定することで、対応するイメージ、コンテンツ、環境変数の情報を指定できます。
1. Configuration
Configuration の役割は以下の通りです。
コンテナの期待状態を管理する。
バージョンコントローラーと同様に、Configuration が更新されるたびに新しいバージョン (Revision) が作成されます。
前述の図に示すように、Knative Service と比較すると、Configuration はその設定情報とよく似ており、Configuration 内の設定はコンテナの期待されるリソース情報です。
2. Route
Route の役割は以下の通りです。
トラフィックの異なるバージョン (Revision) への分配を制御する。
パーセンテージに基づくトラフィック分配をサポートする。
前述の図に示すように、Route リソースには以下のトラフィック情報が含まれ、各バージョンに対応するバージョンとトラフィック比率を設定できます。
3. Revision
Configuration のスナップショット。
バージョン追跡とロールバック。
Knative Service のバージョン管理用リソースが Revision で、これは Configuration のスナップショットです。Configuration が更新されるたびに新しい Revision が作成され、Revision を通じてバージョン追跡、グレーリリース、ロールバックを実現できます。Revision リソースでは、設定されたイメージ情報を直接確認できます。
3、トラフィックベースのグレーリリース
前述の図に示すように、最初に V1 バージョンの Revision を作成し、新しいバージョンの変更がある場合、Service 内の Configuration を更新するだけで、対応する V2 バージョンが作成されます。次に Route を使用して V1 と V2 に異なるトラフィック比率を設定します。前述の図では V1 が 70%、V2 が 30% です。トラフィックは 7:3 の比率で 2 つのバージョンに分配されます。V2 バージョンの検証に問題がなければ、トラフィック比率を調整してグレーリリースを継続し、新バージョン V2 が 100% に達するまで進めます。
グレーリリース中に新バージョンに異常が見つかった場合は、トラフィック比率をいつでも調整してロールバックできます。たとえば、グレーリリースが 30% に達した時点で V2 バージョンに問題が発生した場合、比率を元に戻して元の V1 バージョンにトラフィックを 100% 設定することで、ロールバック操作を実現できます。
さらに、Route 内の Revision にタグを追加することもできます。タグを設定すると、Knative がその Revision 用の直接アクセス可能な URL を自動生成します。この URL を通じて、対応するトラフィックを現在のバージョンに直接転送でき、特定のバージョンのデバッグを実現できます。
4、自動弾性
Knative は豊富な弾性戦略を提供するだけでなく、ASK Knative は対応する弾性メカニズムも拡張しています。次に、以下の弾性戦略について説明します。
Knative Pod 自動スケーリング (KPA)。
Pod 水平自動スケーリング (HPA)。
タイミングベースの自動スケーリング戦略と HPA の組み合わせ。
イベントゲートウェイ (トラフィックリクエストに基づく正確な弾性)。
カスタムスケーリングプラグインの拡張。
1. 自動スケールイン・スケールアウト - KPA
前述の図に示すように、Route はトラフィックゲートウェイとして理解できます。Activator は Knative におけるゼロから 1 へのスケーリングを担います。リクエストトラフィックがない場合、Knative は対応するサービスを Activator Pod に待機させます。最初のトラフィックが入ると、まず Activator に届きます。トラフィックを受信した後、Activator は Autoscaler を通じて Pod をスケールアウトします。スケールアウト完了後、Activator はリクエストを対応する Pod に転送します。Pod が準備完了になると、Route を通じて対応するサービスが直接 Pod にリンクされ、Activator の役割は終了します。
1 から N へのスケーリングプロセスでは、各 Pod 内の kube-proxy コンテナを通じてリクエスト同時実行数の指標、つまりリクエストメトリックを収集できます。Autoscaler はこれらのリクエストメトリックに基づいて集計を行い、必要なスケールアウト量を計算し、トラフィックに基づく最終的なスケーリングを実現します。
2. 水平スケールイン・スケールアウト - HPA
K8s のネイティブな HPA をラップしたもので、Revision を通じて対応する指標と戦略を設定し、K8s のネイティブな HPA を使用して CPU とメモリの自動スケーリングをサポートします。
3. タイミング + HPA の融合
リソースウォームアップのために事前に容量を計画する。
CPU およびメモリと組み合わせる。
Knative の上で、タイミングベースの HPA との統合により、リソースウォームアップのための事前計画された容量を実現します。K8s を使用する際、HPA によるスケーリングでは指標のしきい値に達するまで待つ必要があるため、実際の緊急シナリオに対応できないことがあります。定期的なスケーリングタスクの場合、特定の時間帯にスケールアウトが必要な容量をスケジュール方式で事前に計画できます。
また、CPU およびメモリベースのスケーリングとも統合されます。たとえば、特定の時間帯に 10 Pod を設定していても、現在の CPU 計算に基づくしきい値が 20 Pod を示している場合、両者の最大値である 20 Pod でスケールアウトされます。これがサービスの安定性の最も基本的な保証です。
4. イベントゲートウェイ
リクエスト数に基づく自動弾性。
1 対 1 のタスク分散。
イベントゲートウェイはトラフィックリクエストに基づく正確な弾性を実現します。イベントが入力されると、まずイベントゲートウェイに届きます。現在の受信リクエスト数に基づいて Pod をスケールアウトします。スケールアウト完了後、タスクと Pod を 1 対 1 で転送するリクエストが発生します。一部の Pod は同時に 1 つのリクエストしか処理できないため、この状況に対応する必要があります。これがイベントゲートウェイが解決するシナリオです。
5. カスタムスケーリングプラグイン
カスタムスケーリングプラグインのカスタマイズには 2 つの重要なポイントがあります。
指標の収集。
Pod インスタンス数の調整。
指標はどこから取得するのでしょうか。Knative コミュニティが提供するトラフィックベースの KPA のように、そのメトリックは定期タスクを通じて各 Pod の queue-proxy コンテナからメトリックを取得します。これらの指標をコントローラーを通じて処理・集計し、スケールアウトが必要な Pod 数を計算します。
どのようにスケーリングを実行するのでしょうか。実際には、対応する Deployment の Pod 数を調整することで実現します。
指標の収集と Pod インスタンス数の調整を制御することで、カスタムスケーリングプラグインを簡単に実装できます。
Knative はトラフィックに基づく自動スケーリング機能を提供します。ピーク時にはアプリケーションのリクエスト量に応じてインスタンス数を自動的に拡張でき、リクエスト量が減少するとインスタンス数を自動的に縮小して、リソースコストの自動化された節約を実現します。さらに、Knative はトラフィックベースのグレーリリース機能も提供し、トラフィックのパーセンテージを段階的に新バージョンへ配分できます。
Knative のグレーリリースと自動弾性について説明する前に、まず ASK Knative におけるトラフィックリクエストの仕組みを確認しましょう。
前述の図に示すように、トラフィックリクエストの仕組みは全体として以下の部分に分かれます。
左側は Knative Service のバージョン情報で、トラフィックのパーセンテージを設定できます。以下はルーティング戦略で、Ingress コントローラーを通じて対応するルーティングルールが Alibaba Cloud SLB に設定されます。
右側は対応する Service のバージョン Revision で、Deployment リソースに対応します。トラフィックが SLB を通じて流入すると、対応する転送ルールに従ってバックエンドサーバーの Pod に直接転送されます。
トラフィックリクエストの仕組みに加え、前述の図には KPA や HPA などの弾性戦略も示されています。
2、サービスライフサイクル
Service は開発者が直接操作するリソースオブジェクトで、Route と Configuration の 2 つのリソースで構成されます。
前述の図に示すように、ユーザーは Configuration の情報を設定することで、対応するイメージ、コンテンツ、環境変数の情報を指定できます。
1. Configuration
Configuration の役割は以下の通りです。
コンテナの期待状態を管理する。
バージョンコントローラーと同様に、Configuration が更新されるたびに新しいバージョン (Revision) が作成されます。
前述の図に示すように、Knative Service と比較すると、Configuration はその設定情報とよく似ており、Configuration 内の設定はコンテナの期待されるリソース情報です。
2. Route
Route の役割は以下の通りです。
トラフィックの異なるバージョン (Revision) への分配を制御する。
パーセンテージに基づくトラフィック分配をサポートする。
前述の図に示すように、Route リソースには以下のトラフィック情報が含まれ、各バージョンに対応するバージョンとトラフィック比率を設定できます。
3. Revision
Configuration のスナップショット。
バージョン追跡とロールバック。
Knative Service のバージョン管理用リソースが Revision で、これは Configuration のスナップショットです。Configuration が更新されるたびに新しい Revision が作成され、Revision を通じてバージョン追跡、グレーリリース、ロールバックを実現できます。Revision リソースでは、設定されたイメージ情報を直接確認できます。
3、トラフィックベースのグレーリリース
前述の図に示すように、最初に V1 バージョンの Revision を作成し、新しいバージョンの変更がある場合、Service 内の Configuration を更新するだけで、対応する V2 バージョンが作成されます。次に Route を使用して V1 と V2 に異なるトラフィック比率を設定します。前述の図では V1 が 70%、V2 が 30% です。トラフィックは 7:3 の比率で 2 つのバージョンに分配されます。V2 バージョンの検証に問題がなければ、トラフィック比率を調整してグレーリリースを継続し、新バージョン V2 が 100% に達するまで進めます。
グレーリリース中に新バージョンに異常が見つかった場合は、トラフィック比率をいつでも調整してロールバックできます。たとえば、グレーリリースが 30% に達した時点で V2 バージョンに問題が発生した場合、比率を元に戻して元の V1 バージョンにトラフィックを 100% 設定することで、ロールバック操作を実現できます。
さらに、Route 内の Revision にタグを追加することもできます。タグを設定すると、Knative がその Revision 用の直接アクセス可能な URL を自動生成します。この URL を通じて、対応するトラフィックを現在のバージョンに直接転送でき、特定のバージョンのデバッグを実現できます。
4、自動弾性
Knative は豊富な弾性戦略を提供するだけでなく、ASK Knative は対応する弾性メカニズムも拡張しています。次に、以下の弾性戦略について説明します。
Knative Pod 自動スケーリング (KPA)。
Pod 水平自動スケーリング (HPA)。
タイミングベースの自動スケーリング戦略と HPA の組み合わせ。
イベントゲートウェイ (トラフィックリクエストに基づく正確な弾性)。
カスタムスケーリングプラグインの拡張。
1. 自動スケールイン・スケールアウト - KPA
前述の図に示すように、Route はトラフィックゲートウェイとして理解できます。Activator は Knative におけるゼロから 1 へのスケーリングを担います。リクエストトラフィックがない場合、Knative は対応するサービスを Activator Pod に待機させます。最初のトラフィックが入ると、まず Activator に届きます。トラフィックを受信した後、Activator は Autoscaler を通じて Pod をスケールアウトします。スケールアウト完了後、Activator はリクエストを対応する Pod に転送します。Pod が準備完了になると、Route を通じて対応するサービスが直接 Pod にリンクされ、Activator の役割は終了します。
1 から N へのスケーリングプロセスでは、各 Pod 内の kube-proxy コンテナを通じてリクエスト同時実行数の指標、つまりリクエストメトリックを収集できます。Autoscaler はこれらのリクエストメトリックに基づいて集計を行い、必要なスケールアウト量を計算し、トラフィックに基づく最終的なスケーリングを実現します。
2. 水平スケールイン・スケールアウト - HPA
K8s のネイティブな HPA をラップしたもので、Revision を通じて対応する指標と戦略を設定し、K8s のネイティブな HPA を使用して CPU とメモリの自動スケーリングをサポートします。
3. タイミング + HPA の融合
リソースウォームアップのために事前に容量を計画する。
CPU およびメモリと組み合わせる。
Knative の上で、タイミングベースの HPA との統合により、リソースウォームアップのための事前計画された容量を実現します。K8s を使用する際、HPA によるスケーリングでは指標のしきい値に達するまで待つ必要があるため、実際の緊急シナリオに対応できないことがあります。定期的なスケーリングタスクの場合、特定の時間帯にスケールアウトが必要な容量をスケジュール方式で事前に計画できます。
また、CPU およびメモリベースのスケーリングとも統合されます。たとえば、特定の時間帯に 10 Pod を設定していても、現在の CPU 計算に基づくしきい値が 20 Pod を示している場合、両者の最大値である 20 Pod でスケールアウトされます。これがサービスの安定性の最も基本的な保証です。
4. イベントゲートウェイ
リクエスト数に基づく自動弾性。
1 対 1 のタスク分散。
イベントゲートウェイはトラフィックリクエストに基づく正確な弾性を実現します。イベントが入力されると、まずイベントゲートウェイに届きます。現在の受信リクエスト数に基づいて Pod をスケールアウトします。スケールアウト完了後、タスクと Pod を 1 対 1 で転送するリクエストが発生します。一部の Pod は同時に 1 つのリクエストしか処理できないため、この状況に対応する必要があります。これがイベントゲートウェイが解決するシナリオです。
5. カスタムスケーリングプラグイン
カスタムスケーリングプラグインのカスタマイズには 2 つの重要なポイントがあります。
指標の収集。
Pod インスタンス数の調整。
指標はどこから取得するのでしょうか。Knative コミュニティが提供するトラフィックベースの KPA のように、そのメトリックは定期タスクを通じて各 Pod の queue-proxy コンテナからメトリックを取得します。これらの指標をコントローラーを通じて処理・集計し、スケールアウトが必要な Pod 数を計算します。
どのようにスケーリングを実行するのでしょうか。実際には、対応する Deployment の Pod 数を調整することで実現します。
指標の収集と Pod インスタンス数の調整を制御することで、カスタムスケーリングプラグインを簡単に実装できます。
Related Articles
-
A detailed explanation of Hadoop core architecture HDFS
Knowledge Base Team
-
What Does IOT Mean
Knowledge Base Team
-
6 Optional Technologies for Data Storage
Knowledge Base Team
-
What Is Blockchain Technology
Knowledge Base Team
Explore More Special Offers
-
Short Message Service(SMS) & Mail Service
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00
