4.2. 自動スケーリング
4.2.1. 自動スケーリング
Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング (autoscaling) を提供します。たとえば、アプリケーションがトラフィックを受信せず、scale-to-zero が有効にされている場合、Knative Serving はアプリケーションをゼロレプリカにスケールダウンします。scale-to-zero が無効になっている場合、アプリケーションはクラスターのアプリケーションに設定された最小のレプリカ数にスケールダウンされます。アプリケーションへのトラフィックが増加したら、要求を満たすようにレプリカをスケールアップすることもできます。
Knative サービスの自動スケーリング設定は、クラスター管理者によって設定されるグローバル設定とすることも、個別サービスに設定されるリビジョンごとの設定とすることもできます。
OpenShift Container Platform Web コンソールを使用して、サービスの YAML ファイルを変更するか、または Knative (kn
) CLI を使用して、サービスのリビジョンごとの設定を変更できます。
サービスに設定した制限またはターゲットは、アプリケーションの単一インスタンスに対して測定されます。たとえば、target
アノテーションを 50
に設定することにより、各リビジョンが一度に 50 の要求を処理できるようアプリケーションをスケーリングするように Autoscaler が設定されます。
4.2.2. スケーリング限度
スケーリング限度は、任意の時点でアプリケーションに対応できる最小および最大のレプリカ数を決定します。アプリケーションのスケーリング限度を設定して、コールドスタートを防止したり、コンピューティングコストを制御したりできます。
4.2.2.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" ...
4.2.2.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
4.2.2.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" ...
4.2.2.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
4.2.3. 並行処理性
並行処理性は、特定の時点でアプリケーションの各レプリカが処理できる同時リクエストの数を決定します。並行処理性は、ソフトリミットまたはハードリミットのいずれかとして設定できます。
- ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。
ハードリミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。
重要ハードリミット設定の使用は、アプリケーションに明確なユースケースがある場合にのみ推奨されます。ハードリミットを低い値に指定すると、アプリケーションのスループットとレイテンシーに悪影響を与える可能性があり、コールドスタートが発生する可能性があります。
ソフトターゲットとハードリミットを追加することは、Autoscaler は同時リクエストのソフトターゲット数を目標とするが、リクエストの最大数にハードリミット値のハードリミットを課すことを意味します。
ハードリミットの値がソフトリミットの値より小さい場合、実際に処理できる数よりも多くのリクエストを目標にする必要がないため、ソフトリミットの値が低減されます。
4.2.3.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
4.2.3.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
4.2.3.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" ...
4.2.4. Scale-to-zero
Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング (autoscaling) を提供します。
4.2.4.1. scale-to-zero の有効化
enable-scale-to-zero
仕様を使用して、クラスター上のアプリケーションの scale-to-zero をグローバルに有効または無効にすることができます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者パーミッションがある。
- デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。
手順
KnativeServing
カスタムリソース (CR) のenable-scale-to-zero
仕様を変更します。KnativeServing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: enable-scale-to-zero: "false" 1
- 1
enable-scale-to-zero
仕様は、true
またはfalse
のいずれかです。true に設定すると、scale-to-zero が有効にされます。false に設定すると、アプリケーションは設定された スケーリング下限 にスケールダウンされます。デフォルト値は"true"
です。
4.2.4.2. scale-to-zero 猶予期間の設定
Knative Serving は、アプリケーションの Pod をゼロにスケールダウンします。scale-to-zero-grace-period
仕様を使用して、アプリケーションの最後のレプリカが削除される前に Knative が scale-to-zero 機構が配置されるのを待機する上限時間を定義できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者パーミッションがある。
- デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。
手順
KnativeServing
カスタムリソース CR のscale-to-zero-grace-period
仕様を変更します。KnativeServing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: scale-to-zero-grace-period: "30s" 1
- 1
- 猶予期間 (秒単位)。デフォルト値は 30 秒です。