5.2. 自動スケーリング

Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング (autoscaling) を提供します。たとえば、アプリケーションがトラフィックを受信せず、scale-to-zero が有効にされている場合、Knative Serving はアプリケーションをゼロレプリカにスケールダウンします。scale-to-zero が無効になっている場合、アプリケーションはクラスターのアプリケーションに設定された最小のレプリカ数にスケールダウンされます。アプリケーションへのトラフィックが増加したら、要求を満たすようにレプリカをスケールアップすることもできます。

Knative サービスの自動スケーリング設定は、クラスター管理者によって設定されるグローバル設定とすることも、個別サービスに設定されるリビジョンごとの設定とすることもできます。OpenShift Container Platform Web コンソールを使用して、サービスの YAML ファイルを変更するか、または Knative (kn) CLI を使用して、サービスのリビジョンごとの設定を変更できます。

注記

サービスに設定した制限またはターゲットは、アプリケーションの単一インスタンスに対して測定されます。たとえば、target アノテーションを 50 に設定することにより、各リビジョンが一度に 50 の要求を処理できるようアプリケーションをスケーリングするように Autoscaler が設定されます。

5.2.1. スケーリング限度

スケーリング限度は、任意の時点でアプリケーションに対応できる最小および最大のレプリカ数を決定します。アプリケーションのスケーリング限度を設定して、コールドスタートを防止したり、コンピューティングコストを制御したりできます。

5.2.1.1. スケーリング下限

アプリケーションにサービスを提供できるレプリカの最小数は、最小 min-scale のアノテーションによって決定されます。ゼロへのスケーリングが有効になっていない場合、min-Scale 値のデフォルトは 1 になります。

次の条件が満たされた場合、min-scale 値はデフォルトで 0 レプリカになります。

  • mi-scale の注釈が設定されていません
  • ゼロへのスケーリングが有効にされている
  • KPA クラスが使用されている

min-scale アノテーションを使用したサービス仕様の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

5.2.1.1.1. Knative CLI を使用した最小スケール注釈の設定

minScale アノテーションを設定するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが提供されます。kn service コマンドを --scale-min フラグと共に使用して、サービスの --min-scale 値を作成または変更できます。

前提条件

  • Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。

手順

  • --scale-min フラグを使用して、サービスのレプリカの最小数を設定します。 

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    コマンドの例

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2

5.2.1.2. スケーリング上限

アプリケーションにサービスを提供できるレプリカの最大数は、max-scale アノテーションによって決定されます。max-scale アノテーションが設定されていない場合、作成されるレプリカの数に上限はありません。

max-scale アノテーションを使用したサービス仕様の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

5.2.1.2.1. Knative CLI を使用した最大スケール注釈の設定

Knative (kn) CLI を使用して max-scale のアノテーションを設定すると、YAML ファイルを直接変更する場合に比べ、ユーザーインターフェイスがより合理的で直感的です。--scale-max フラグを指定して knservice コマンドを使用すると、kn service の max-scale 値を作成または変更できます。

前提条件

  • Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。

手順

  • --scale-max フラグを使用して、サービスのレプリカの最大数を設定します。 

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    コマンドの例

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10

5.2.2. 並行処理性

並行処理性は、特定の時点でアプリケーションの各レプリカが処理できる同時リクエストの数を決定します。並行処理性は、ソフトリミットまたはハードリミットのいずれかとして設定できます。

  • ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。

  • ハードリミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。

    重要

    ハードリミット設定の使用は、アプリケーションに明確なユースケースがある場合にのみ推奨されます。ハードリミットを低い値に指定すると、アプリケーションのスループットとレイテンシーに悪影響を与える可能性があり、コールドスタートが発生する可能性があります。

ソフトターゲットとハードリミットを追加することは、Autoscaler は同時リクエストのソフトターゲット数を目標とするが、リクエストの最大数にハードリミット値のハードリミットを課すことを意味します。

ハードリミットの値がソフトリミットの値より小さい場合、実際に処理できる数よりも多くのリクエストを目標にする必要がないため、ソフトリミットの値が低減されます。

5.2.2.1. ソフト並行処理ターゲットの設定

ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。autoscaling.knative.dev/target アノテーションを仕様に設定するか、または正しいフラグを指定して kn service コマンドを使用して、Knative サービスにソフト並行処理ターゲットを指定できます。

手順

  • オプション:Service カスタムリソースの仕様で Knative サービスに autoscaling.knative.dev/target アノテーションを設定します。

    サービス仕様の例

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

  • オプション:kn service コマンドを使用して --concurrency-target フラグを指定します。 

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    並行処理のターゲットを 50 リクエストに設定したサービスを作成するコマンドの例

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

5.2.2.2. ハード並行処理リミットの設定

ハード並行処理リミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。containerConcurrency 仕様を変更するか、または正しいフラグを指定して kn service コマンドを使用して、Knative サービスにハード並行処理リミットを指定できます。

手順

  • オプション:Service カスタムリソースの仕様で Knative サービスに containerConcurrency 仕様を設定します。

    サービス仕様の例

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

    デフォルト値は 0 です。これは、サービスの 1 つのレプリカに一度に流れることができる同時リクエストの数に制限がないことを意味します。

    0 より大きい値は、サービスの 1 つのレプリカに一度に流れることができるリクエストの正確な数を指定します。この例では、50 リクエストのハード並行処理リミットを有効にします。

  • オプション:kn service コマンドを使用して --concurrency-limit フラグを指定します。 

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    並行処理のリミットを 50 リクエストに設定したサービスを作成するコマンドの例

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

5.2.2.3. 並行処理ターゲットの使用率

この値は、Autoscaler が実際に目標とする並行処理リミットのパーセンテージを指定します。これは、レプリカが実行する ホット度 を指定することとも呼ばれます。これにより、Autoscaler は定義されたハードリミットに達する前にスケールアップできるようになります。

たとえば、containerConcurrency 値が 10 に設定され、target-utilization-percentage 値が 70% に設定されている場合、既存のすべてのレプリカの同時リクエストの平均数が 7 に達すると、オートスケーラーは新しいレプリカを作成します。7 から 10 の番号が付けられたリクエストは引き続き既存のレプリカに送信されますが、containerConcurrency 値に達した後、必要になることを見越して追加のレプリカが開始されます。

target-utilization-percentage アノテーションを使用して設定されたサービスの例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...