Alibaba Cloud Service Mesh:リクエストベースの Pod 自動スケーリングの有効化

前提条件

• ASM 上の Knative を使用してデプロイされた Knative サービスが必要です。詳細については、「ASM 上の Knative を使用したサーバーレスアプリケーションのデプロイ」をご参照ください。

KPA の仕組み

Knative Serving は、各 Pod に Queue Proxy コンテナを注入します。Queue Proxy は処理中のリクエストをトラッキングし、同時実行数メトリックを KPA にレポートします。KPA はこれらのメトリックに基づき、必要な Pod 数を計算し、基盤となる Deployment をスケーリングします。

Panic window = Stable window x panic-window-percentage

                                                    |
                                Panic Target--->  +--| 20
                                                  |  |
                                                  | <------Panic Window (6s)
                                                  |  |
     Stable Target--->  +-------------------------|--| 10
CONCURRENCY             |                         |  |
                        |                      <-----------Stable Window (60s)
                        |                         |  |
--------------------------+-------------------------+--+ 0
120                       60                           0
                       TIME (seconds)

KPA のグローバル構成

KPA は、config-autoscaler ConfigMap を通じて knative-serving 名前空間内で構成します。現在の構成を確認するには、次のコマンドを実行します。

kubectl -n knative-serving get cm config-autoscaler -o yaml

ConfigMap の構造は以下のとおりです。

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  _example:
    container-concurrency-target-default: "100"   # Pod あたりのソフト同時実行ターゲット
    container-concurrency-target-percentage: "0.7" # スケーリングトリガーの利用率係数
    enable-scale-to-zero: "true"                   # Pod 数をゼロまでスケーリングすることを許可
    max-scale-up-rate: "1000"                      # 評価サイクルごとの最大スケールアップ倍率
    max-scale-down-rate: "2"                       # 評価サイクルごとの最大スケールダウン倍率
    panic-window-percentage: "10"                  # 安定ウィンドウに対するパニックウィンドウの割合（%）
    panic-threshold-percentage: "200"              # パニックモードをトリガーする同時実行数の割合（%）
    scale-to-zero-grace-period: "30s"              # 最後の Pod がゼロにスケーリングされる前に実行される最大時間
    scale-to-zero-pod-retention-period: "0s"       # ゼロへのスケーリング決定後、最後の Pod がアクティブなまま維持される最小時間
    stable-window: "60s"                           # 安定モードでの平均化に使用する時間ウィンドウ
    target-burst-capacity: "200"                   # トラフィックバースト用に予約される追加容量
    requests-per-second-target-default: "200"      # RPS メトリック使用時のデフォルト RPS ターゲット

_example 配下の値はデフォルト値です。パラメーターを変更するには、_example から該当項目をコピーし、data フィールドに記述してください。

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

同時実行ターゲットに基づくスケーリング

この例では、同時実行ターゲットを 10 に設定して autoscale-go アプリケーションをデプロイし、負荷テストを実行して、KPA が需要に応じて Pod をスケーリングすることを検証します。

1. 同時実行ターゲットを 10 に設定した autoscale-go.yaml という名前のファイルを作成します。

       apiVersion: serving.knative.dev/v1
       kind: Service
       metadata:
         name: autoscale-go
         namespace: default
       spec:
         template:
           metadata:
             labels:
               app: autoscale-go
             annotations:
               autoscaling.knative.dev/target: "10"   # 平均同時実行数が 10 x 0.7 = 7 を超えるとスケーリング
           spec:
             containers:
               - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

2. アプリケーションをデプロイします。

       kubectl apply -f autoscale-go.yaml

3. ゲートウェイの IP アドレスを取得します。ASM コンソールにログインし、対象の ASM インスタンス名をクリックして、[ASM ゲートウェイ] ＞ [Ingress ゲートウェイ] の順に選択します。Ingress ゲートウェイページで、[サービスアドレス] セクションの IP アドレスを確認します。

4. 30 秒間、50 の同時リクエストで負荷テストを実行します。前のステップで取得した IP アドレスに置き換えて <gateway-ip> を使用します。ゲートウェイアドレスの取得方法については、「ASM 上の Knative を使用したサーバーレスアプリケーションのデプロイ」の「ステップ 3：ゲートウェイアドレスの照会」をご参照ください。負荷テストツールの詳細については、hey をご参照ください。

       hey -z 30s -c 50 \
         -host "autoscale-go.default.example.com" \
         "http://<gateway-ip>?sleep=100&prime=10000&bloat=5"

5. 結果を検証します。KPA はアプリケーションを約 7 個の Pod にスケーリングします。同時実行ターゲットが 10、デフォルトの利用率係数が 70% の場合、KPA は Pod あたりの平均同時実行数が 7（10 × 0.7）を超えると Pod の追加を開始します。この先読みスケーリングにより、リクエスト量が増加しても同時実行ターゲットが超過しないようになります。

   

定義済みの範囲内でのスケーリング

この例では、Pod 数を 1 ～ 3 の範囲に制限するスケール範囲を設定して、同じ autoscale-go アプリケーションをデプロイします。

1. 同時実行ターゲットを 10、minScale を 1、maxScale を 3 に設定した autoscale-go.yaml という名前のファイルを作成します。

       apiVersion: serving.knative.dev/v1
       kind: Service
       metadata:
         name: autoscale-go
         namespace: default
       spec:
         template:
           metadata:
             labels:
               app: autoscale-go
             annotations:
               autoscaling.knative.dev/target: "10"      # Pod あたりの同時実行ターゲット
               autoscaling.knative.dev/minScale: "1"      # 常に少なくとも 1 つの Pod を実行
               autoscaling.knative.dev/maxScale: "3"      # Pod 数を 3 個を超えないように制限
           spec:
             containers:
               - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

2. アプリケーションをデプロイします。

       kubectl apply -f autoscale-go.yaml

3. ゲートウェイの IP アドレスを取得します。ASM コンソールにログインし、対象の ASM インスタンス名をクリックして、[ASM ゲートウェイ] ＞ [Ingress ゲートウェイ] の順に選択します。Ingress ゲートウェイページで、[サービスアドレス] セクションの IP アドレスを確認します。

4. 30 秒間、50 の同時リクエストで負荷テストを実行します。前のステップで取得した IP アドレスに置き換えて <gateway-ip> を使用します。ゲートウェイアドレスの取得方法については、「ASM 上の Knative を使用したサーバーレスアプリケーションのデプロイ」の「ステップ 3：ゲートウェイアドレスの照会」をご参照ください。負荷テストツールの詳細については、hey をご参照ください。

       hey -z 30s -c 50 \
         -host "autoscale-go.default.example.com" \
         "http://<gateway-ip>?sleep=100&prime=10000&bloat=5"

5. 結果を検証します。負荷テスト中に KPA はアプリケーションを最大 3 個の Pod にスケーリングします。トラフィックが停止すると、minScale で指定されたとおり、1 個の Pod が実行されたままになります。スケール範囲により、過剰プロビジョニングを防ぎながら、コールドスタートを解消できます。

   

次のステップ

• ASM ゲートウェイを使用して Knative サービスに HTTPS でアクセス：暗号化通信により Knative サービスのエンドポイントを保護します。

• ASM 上の Knative を使用して Knative サービスのトラフィック分割によるカナリアリリースを実行：トラフィック分割により新しいバージョンを段階的にロールアウトします。

• Knative での HPA の使用：リクエスト同時実行数ではなく CPU 使用率に基づいてスケーリングします。