アプリケーション・スケーリングの構成
IBM Cloud® Code Engineでは、アプリケーションの実行中のインスタンスの数が着信ワークロードに基づいて自動的に増減する (ゼロになる) ため、アプリケーションのスケーリングについて考える必要はありません。 自動スケーリングでは、使用されないリソースのための料金は支払いません。
Code Engine は、システム内の要求の数をモニターし、着信要求の負荷 (アプリケーションへの HTTP 接続を含む) に合わせてアプリケーション・インスタンスを増減します。 これらの HTTP 接続は、プロジェクトの外部からの要求、プロジェクト内で実行されている他のワークロードからの要求、またはサブスクライブしている可能性があるイベント・プロデューサーからの要求となり得ます。これらのプロデューサーがどこにあるかは関係ありません。Code Engineは、アプリケーション・インスタンスを自動的に複製し、すべてのインスタンス間で要求のロード・バランシングを行うようにネットワーク・インフラストラクチャーを構成します。
スケーリングの仕組み
Code Engine は、システム内での要求数をモニターし、アプリケーションの並行性設定の制約の範囲内で、アプリケーション・インスタンスをスケーリングします。
Code Engine コンソールからアプリケーションのスケーリングを監視するには、特定のアプリケーション・ページにナビゲートします。 アプリケーションの実行中、実行中インスタンスの数は、指定したインスタンス最大数に基づいて 1
以上になります。 アプリケーションが処理する要求の数が、構成されているターゲット並行性より少ない場合、アプリケーションは、実行中のインスタンスの数を、構成されているインスタンスの最小数まで拡張します。
最小インスタンス数が 0
(デフォルト値) に設定されている場合、アプリケーションはゼロにスケールダウンし、アプリのインスタンス数は 0
インスタンスを反映します。 アプリケーションがスケールダウンされ、要求がアプリケーションにルーティングされると、 Code Engine はアプリケーションをスケールアップし、新しく作成されたアプリケーション・インスタンスに要求をルーティングします。
アプリケーションが完全にスケールダウンできるようにするには、アプリケーション・コードで SIGTERM シグナルを処理する必要があります。 Code Engine が自動的にスケールダウンすると、SIGTERM シグナルがアプリケーションに送信されます。 アプリケーションが SIGTERM シグナルを処理しない場合、アプリケーション・インスタンスは、要求タイムアウト値 (デフォルト値は 300 秒) によって構成された時間、 Terminating
状況のままになります。
要求タイムアウトの期間が経過すると、 Code Engine は SIGKILL シグナルを送信して、 Terminating
状況のアプリ・インスタンスを強制的に停止します。
スケーリングの境界
スケーリング境界を構成するには、 Code Engine がアプリケーションの実行中インスタンスの数を自動スケーリングするインスタンスの最小数と最大数の値の範囲を設定します。 この範囲は、アプリケーションを作成または更新するときに構成します。
-
インスタンスの最小数-要求が処理されない場合でも常に実行されているアプリのインスタンスの最小数。
0
(デフォルト) に設定した場合、アプリケーションにトラフィックが到達していないときに、Code Engineはすべてのインスタンスを削除します。 アプリケーションの実行中のインスタンスを常に保持するには、この値を0
より大きい値に設定します。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでインスタンスの最小数の値を設定します。 CLI で、app create
およびapp update
コマンドに--min-scale
オプションを指定します。 -
インスタンスの最大数-アプリケーションに対して実行できるインスタンスの最大数。 自動スケーリングは、この制限まで行われます。 この値を
0
に設定すると、アプリケーションは必要に応じてスケーリングされ、アプリのスケーリングは、アプリのプロジェクトのリソース割り当て量ごとのインスタンスによってのみ制限されます。 Code Engine の制限と割り当て量を参照してください。 コンソールから Code Engine を使用してアプリケーションを作成または更新する場合は、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでインスタンスの最大数の値を設定します。 CLI で、app create
およびapp update
コマンドに--max-scale
オプションを指定します。 このオプションのデフォルト値は10
です。
アプリケーションをイベント・プロデューサーに接続する場合、スケーリングの境界を設定するときに、それらのプロデューサーからのイベントの頻度とボリュームを考慮に入れてください。 例えば、同時に多数のイベントを受信することが予想され、各イベントの処理に数分かかる可能性がある場合は、各イベントを迅速に処理できる場合よりも大きな最大スケール値が必要になることがあります。 設定する値が小さすぎると、イベントの受信で遅延が生じたり、リソースが処理されて解放されるのを待っている間にタイムアウトになってイベントがドロップされたりする可能性があります。
並行性およびタイミングの自動スケーリング設定
以下の構成設定を使用して、アプリケーションのスケーリングを制御します。
-
並行性-この値は、アプリの各インスタンスが一度に処理できる要求の数を示します。 例えば、通貨値 100 は、コードが同時に 100 個の同時要求を処理できることを意味します。 この値は「ハード・リミット」です。つまり、Code Engine は、並行性設定で指定された要求数を超える数の要求が、アプリケーションのインスタンスに到達することを一切許可しません。 したがって、コードが単一スレッドであり、一度に 1 つの要求しか処理できない場合は、並行性を
1
に設定することを検討してください。 指定された数の要求がアプリケーションの実行中のすべてのインスタンスに送信されると、 Code Engine は、追加の要求に備えてインスタンスの数を増やします。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションで最大並行性の値を設定します。 CLI を使用する場合は、--concurrency
コマンドおよびapp create
コマンドでapp update
オプションを指定します。 -
ターゲットの並行性-この値は、ロードされたシステムで必要な、インスタンスごとの「ソフト制限」または要求数として機能します。 例えば、
concurrency
を100
として指定し、target concurrency
を70
として指定した場合、 Code Engine はインスタンスごとの要求数を 70 に制限しようとします。 このオプションを指定しても、インスタンスごとの要求が 70 を超えないことは保証されません。トラフィックが増加する可能性が高いためです。 しかし、70 から 100 までの緩衝域を置くことで、システムは、1 インスタンスあたりの負荷が 70 以下に戻るように新規インスタンスを作成することができます。target concurrency
が指定されていない場合、デフォルトはconcurrency
の値です。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでターゲットの並行性の値を設定します。 CLI で、app create
およびapp update
コマンドに--concurrency-target
オプションを指定します。 -
要求タイムアウト-アプリケーションが要求に応答しなければならない時間 (秒単位)。それ以外の場合は失敗します。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションで要求タイムアウト値を設定します。 CLI で、
app create
およびapp update
コマンドに--request-timeout
オプションを指定します。 -
スケールダウン遅延-アプリケーションがスケールダウンするまでに、並行性が低下した状態で経過する必要がある時間 (秒単位)。 アプリケーションへの着信要求のパターンが分かっている場合は、デフォルトの
0
より大きい値を指定して、アプリケーションのスケールダウンを遅らせることができます。 このオプションに高い値を使用すると、同時に実行されるアプリケーション・インスタンスの平均数が増加する可能性があり、追加コストが発生します。 スケール・ダウン遅延が0
に設定されている場合でも、システムは、アプリケーションがインスタンス数をスケールダウンする前に短時間待機します。これにより、要求の並行性の低下が十分に安定し、スケールダウンが保証されます。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでスケールダウン遅延値を設定します。 CLI で、app create
およびapp update
コマンドに--scale-down-delay
オプションを指定します。
例えば、インスタンスの最大数の値が 10
に設定され、並行性が 100
に設定されている場合、アプリケーションは、要求の潜在的なキューイングが発生する前に、1000 個の並行要求を処理できます。 同時に 1000 を超える要求が予期される場合は、アプリのインスタンスの最大数の値を増やすことを検討してください。
Code Engine の動作について詳しくは、「 IBM Cloud Code Engine: Optimizing Application Scaling, Latency, and Throughput」、および「 Tuning IBM Cloud Code Engine Scale-Down Delay to Reduce Application Response Times」を参照してください。
インスタンスの最小数をインスタンスの最大数と等しい値に設定すると、スケーリングは行われず、ターゲットの通貨とスケールダウン遅延の値は適用されません。 ただし、並行性の値は引き続き有効です。
自動スケーリングのシナリオ例
以下の自動スケーリング設定を使用して構成されたアプリケーションがあるとします。
- インスタンスの最小数 = 4
- インスタンスの最大数 = 20
- 並行性 = 2
これらの設定を使用すると、アプリは同時に 2 つの同時要求を処理できます。 トラフィックがない場合、アプリケーションは自動的に 4 つのインスタンスにスケールダウンします。 4 つのインスタンスが処理できるのは、4 * 2 (通貨) = 8 個の要求のみです。 アプリケーションの CPU とメモリーの設定が十分であることを前提として、20 個のインスタンスが 20 * 2 (通貨) = 40 個の要求を処理できるように、アプリケーションは最大 20 個のインスタンスまで拡張できます。
アプリケーションが、ログイン・ページをロードするためにアプリケーションへの 6 回の呼び出しを必要とする静的 Web アプリケーションであるとします。 10 人のユーザーが同時にアプリケーション・ログイン・ページにログインするとします (10 * 6 = 60 回の呼び出し)。 アプリケーションで処理できる要求が 40 個を超える呼び出しが 60 個あるため、アプリケーションのユーザーは、呼び出しがキューに入れられるにつれて速度が低下する可能性があります。
アプリへのトラフィックが 1 分ほどないと、 Code Engine は自動的にスケールダウンを開始します。 アプリケーションがスケールダウンすると、一部のインスタンスが Terminating
状況に設定されます。 Code Engine は SIGTERM シグナルをアプリケーションに送信します。コードはこのシグナルを処理してシャットダウンする必要があります。 アプリケーションがこのシグナルを処理しない場合、アプリケーション・インスタンスは、要求タイムアウト値
(デフォルト値は 300 秒) によって構成された時間、 Terminating
状況のままになります。 要求タイムアウトの期間が経過すると、 Code Engine は SIGKILL シグナルを送信して、 Terminating
状況のアプリ・インスタンスを強制的に停止します。
8 つのアクティブ・インスタンスがあり、12 個のインスタンスがある場合、 Terminating
状況のまま 300 秒 (5 分) になります。 これらの 12 個のインスタンスは、要求を受信しません。 8 * 2 (通貨) = 16 を超える要求が着信した場合、 Code Engine は新規インスタンスをスケールアップします。
この例では、この静的コンテンツの 2
の並行性の値は低くなっています。 アプリに設定する自動スケーリング値を決定する必要があります。これは、割り当てられた CPU およびメモリー・リソースでアプリの実装が処理できる内容によって異なります。
待ち時間とスループットの最適化
アプリケーションの待ち時間とスループットを最適化するには、いくつかの一般的なモデルの長所と短所、およびコンテナー並行性を構成するためのベスト・プラクティスを理解してください。
並行性の設定を使用して、アプリケーションの作成時または更新時にインスタンスごとに同時に処理できる要求の最大数を指定します。 Code Engineコンソールで、「ランタイム」セクションに並行性の値を設定します。 CLI では、**app create
コマンドまたはapp update
**コマンドで--concurrency
オプション (別名 --cn
)
を使用します。
モデル | 良い点 | 悪い点 |
---|---|---|
単一並行性、--cn=1 |
アプリケーションがメモリー集中または CPU 集中のワークロードを処理するときには、単一並行性構成を選択します。一度に 1 つの要求だけがアプリケーション・インスタンスに入るので、その要求は、インスタンスに対して構成された CPU とメモリーの全体量を使用できるためです。 | この単一並行性モデルを使用するアプリケーションは迅速にスケールアウトします。 このスケールアウトにより、追加の待ち時間とスループットの低下が生じる可能性があります。新しいアプリケーション・インスタンスを作成することは既存のものを再使用するよりもコストがかかるからです。 複数の要求を同時に処理できる場合、アプリケーションにとって待ち時間が大きな問題となるのであれば、このモデルを選択しないでください。 |
高並行性、--cn=100 (デフォルト) 以上 |
アプリケーションが、CPU 集中でもメモリー集中でもないのでリソースを待機できる、大量の HTTP 要求または応答のワークロードを処理する場合は、この構成を選択します。 この並行性構成は、リモート・データベースに対する作成、取得、更新、および削除の各操作でデータの読み取りおよび書き込みを行う API バックエンドに対して選択できます。 一部の要求は入出力で待機しますが、その他の要求は全体的な待ち時間やスループットに影響を与えることなく処理されます。 | この設定は、複数の並行要求が CPU、メモリー、または入出力を求めて競合する場合には最適ではありません。リソースを求める競合は実行を遅らせ、待ち時間とスループットに悪影響を与えることがあるためです。 |
最適並行性、--cn=N |
単一の要求がアプリケーションに適した時間内に応答を得るために必要なリソースの量が判明している場合に、最適並行性構成を選択します。 アプリケーションが自然言語翻訳アプリケーションであり、言語変換の機械学習モデルが 32 GB であり、要求ごとに 0.7 vCPU に関する単一の翻訳計算が必要な場合に、この構成を選択できます。 インスタンスあたり 9 の vCPU と 32 GB のメモリーの構成を選択できます。 最適なコンテナー並行性は約 13 (9 vCPU/0.7 vCPU ) です。 |
アプリケーションのリソース要件を知らない場合には、最適並行性構成を選択しないでください。 正しくないコンテナー並行性を設定すると、過度に積極的または過度に消極的なスケーリングが生じることがあります。これにより、アプリケーションの待ち時間、エラー率、およびコストが影響を受けます。 詳しくは、アプリケーション・コンテナーの並行性の判別を参照してください。 |
無限並行性、--cn=0 (無効) |
無効 | 無限並行性構成は Code Engine ではサポートされていません。 無限並行性構成は、可能な限り多くの要求を単一のアプリケーション・インスタンスに転送します。これにより、追加のアプリケーション・インスタンスのスケーリングが遅延することがあります。 |
アプリケーション・コンテナーの並行性の判別
最適なコンテナー並行性の値は、許容可能な要求の待ち時間で、アプリケーションが処理できる並行要求数の最大値によって決まります。
コンテナー並行性は、アプリケーションの成功率、待ち時間、およびスループットに直接影響を与えます。 コンテナー並行性の値が大きすぎてアプリケーションが処理できない場合、待ち時間とスループットが悪影響を受け、 502
および 503
のエラー応答が表示される可能性があります。
コンテナー並行性の値がアプリケーションにとって低すぎる場合、システムはアプリケーションをより迅速にスケールアウトして、要求を多数のアプリケーション・インスタンス間に配分します。これにより、追加のコストと待ち時間が発生します。 負荷が急増するとき、並行性の値が低いと、システムの内部バッファーがあふれて、一時的な 502
応答が生じることもあります。
アプリケーションのコンテナー並行性構成を判別するには、要求と待ち時間を検討します。
-
アプリケーションを作成し、その並行性を
1000
(max) に設定し、min-scale
とmax-scale
の両方を1
に設定します。ibmcloud ce application create --name APPNAME --image APPIMAGE --min-scale=1 --max-scale=1 --concurrency=1000
-
まず、複数の要求を高いレートで送信します。
502
エラーが発生する場合、結果が成功率 100% となるまでレートを低くします。 -
ステップ 2 の出力の要求待ち時間を見つけます。 要求待ち時間が許容されない場合は、要求待ち時間が許容できるようになるまで、要求率をさらに低くしてください。 要求所要時間も重要であることに注意してください。要求の計算に
2
秒かかる場合と100
ミリ秒かかる場合とでは違いがあるからです。許容可能な要求レートと待ち時間は、アプリケーション特性とスケーリング構成によって異なります。 例えば、アプリケーション内の計算に約 100 ミリ秒かかり、並行性設定が 10 の場合、1 つのアプリケーション・インスタンスは 1 秒あたり約 100 の要求を処理することができ、待ち時間は約 100 ミリ秒となります (ネットワーク待ち時間は無視します)。
-
アプリケーションのコンテナー並行性の値を計算するには、ステップ 2 からレート (
req/s
) を取り出して、ステップ 3 の待ち時間 (秒数) で除算します:CC = RATE/LATENCY
。 例えば、レートが秒あたり80
の要求で、待ち時間が2
秒の場合、結果として並行性は concurrency =80 req/s / 2 s = 40
となります。 -
アプリケーションを更新して、コンテナー並行性を直前のステップで取得した値に設定します。ワークロードを再実行して、成功率と待ち時間が許容可能かどうかを確認します。
-
コンテナー並行性の値を拡大しながら成功率と待ち時間を観察して、アプリケーションでの実験を行います。
-
最適なコンテナー並行性の値でアプリケーションを更新し、
min-Scale
境界とmax-scale
境界を削除して、アプリケーションが自動的にスケーリングできるようにします。
CLI を使用したアプリのスケーリング方法の監視
CLI を使用して、アプリの実行中インスタンスの数を確認できます。
-
app create
コマンドを使用してアプリケーションを作成します。ibmcloud ce application create --name myapp --image icr.io/codeengine/helloworld
-
アプリケーションを呼び出します。
app create
コマンドの出力からアプリの URL を入手するか、ibmcloud ce app get --name myapp --output url
を実行することができます。curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
-
application get
コマンドを実行して、アプリケーションの状況を表示します。Running instances
の値を見つけます。 この例では、アプリの実行中インスタンスは1
つです。 以下に例を示します。ibmcloud ce application get --name myapp
出力例
[...] OK Name: myapp [...] URL: https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud Cluster Local URL: http://myapp.4svg40kna19.svc.cluster.local Console URL: https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration Status Summary: Application deployed successfully Environment Variables: Type Name Value Literal CE_API_BASE_URL https://api.us-south.codeengine.cloud.ibm.com Literal CE_APP myapp Literal CE_DOMAIN us-south.codeengine.appdomain.cloud Literal CE_PROJECT_ID abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f Literal CE_REGION us-south Literal CE_SUBDOMAIN abcdabcdab Image: icr.io/codeengine/helloworld Resource Allocation: CPU: 1 Ephemeral Storage: 400M Memory: 4G Revisions: myapp-ds8fn-1: Age: 6m25s Traffic: 100% Image: icr.io/codeengine/helloworld (pinned to fe0446) Running Instances: 1 Runtime: Concurrency: 100 Maximum Scale: 10 Minimum Scale: 0 Timeout: 300 Conditions: Type OK Age Reason ConfigurationsReady true 6m10s Ready true 5m56s RoutesReady true 5m56s Events: Type Reason Age Source Messages Normal Created 6m28s service-controller Created Configuration "myapp" Normal Created 6m28s service-controller Created Route "myapp" Instances: Name Revision Running Status Restarts Age myapp-ds8fn-1-deployment-79bdd76749-khtmw myapp-ds8fn-1 2/2 Running 0 32s
アプリがゼロにスケーリングされるまで数分かかることがあるため、しばらくお待ちください。
-
application get
コマンドを再実行し、Running instances
の値がゼロにスケーリングされていることを確認します。 アプリケーションが処理する要求の数が、構成されているターゲット並行性より少ない場合、アプリケーションは、実行中のインスタンスの数を、構成されているインスタンスの最小数まで拡張します。 このシナリオでは、実行中のインスタンスの数は自動的にゼロになります。--min-scale
オプションが0
(デフォルト値) に設定されている場合、実行中のインスタンスの数は自動的にゼロになります。アプリがゼロにスケーリングされるまで数分かかることがあるため、しばらくお待ちください。
ibmcloud ce application get -n myapp
出力例
OK Name: myapp [...] URL: https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud Cluster Local URL: http://myapp.4svg40kna19.svc.cluster.local Console URL: https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration Image: icr.io/codeengine/helloworld Resource Allocation: CPU: 1 Ephemeral Storage: 400M Memory: 4G Revisions: myapp-ds8fn-1: Age: 12m Traffic: 100% Image: icr.io/codeengine/helloworld (pinned to 548d5c) Running Instances: 0 Runtime: Concurrency: 100 Maximum Scale: 10 Minimum Scale: 0 Timeout: 300 Conditions: Type OK Age Reason ConfigurationsReady true 3m7s Ready true 2m54s RoutesReady true 2m54s Events: Type Reason Age Source Messages Normal Created 3m21s service-controller Created Configuration "myapp" Normal Created 3m20s service-controller Created Route "myapp"
-
ゼロからスケーリングするためにアプリケーションを再度呼び出します。
curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
-
application get
コマンドを再実行し、Running instances
の値がゼロからスケール・アップされていることを確認します。 以下に例を示します。ibmcloud ce application get -n myapp
出力例
OK Name: myapp [...] URL: https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud Cluster Local URL: http://myapp.4svg40kna19.svc.cluster.local Console URL: https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration Status Summary: Application deployed successfully Environment Variables: Type Name Value Literal CE_API_BASE_URL https://api.us-south.codeengine.cloud.ibm.com Literal CE_APP myapp Literal CE_DOMAIN us-south.codeengine.appdomain.cloud Literal CE_PROJECT_ID abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f Literal CE_REGION us-south Literal CE_SUBDOMAIN abcdabcdab Image: icr.io/codeengine/helloworld Resource Allocation: CPU: 1 Ephemeral Storage: 400M Memory: 4G Revisions: myapp-00001: Age: 42s Latest: true Traffic: 100% Image: icr.io/codeengine/helloworld (pinned to 1cee99) Running Instances: 1 Runtime: Concurrency: 100 Maximum Scale: 10 Minimum Scale: 0 Scale Down Delay: 0 Timeout: 300 Conditions: Type OK Age Reason ConfigurationsReady true 25s Ready true 12s RoutesReady true 12s Events: Type Reason Age Source Messages Normal Created 44s service-controller Created Configuration "myapp" Normal Created 43s service-controller Created Route "myapp" Instances: Name Revision Running Status Restarts Age myapp-00001-deployment-d59b87654-xkqh7 myapp-00001 3/3 Running 0 43s
アプリの最小インスタンス数と最大インスタンス数の設定
アプリ・インスタンス数の最小値と最大値を更新することにより、アプリの実行インスタンス数を変更できます。
アプリケーションのインスタンスの最小数のデフォルト値は、 0
です。 アプリがトラフィックを受信しない場合は、 0
にスケーリングされ、実行中のアプリのインスタンスはありません。 この状況では、アプリケーションが再びトラフィックを受信すると、応答が遅くなる可能性がありますが、アプリケーションはスケール・アップされます。 この動作を変更するには、コンソールまたは CLI でアプリケーションを更新し、最小スケールを 1
に設定します。
アプリのインスタンスの最大数のデフォルト値は 0
です。これにより、アプリを必要に応じてスケーリングできます。 詳しくは、 境界のスケーリング を参照してください。
コンソールからの自動スケーリング範囲の変更
Code Engine がコンソールからアプリの実行中インスタンスの数を自動スケーリングする範囲を変更するには、以下の手順を実行します。
- アプリにナビゲートします。
- 「構成」 タブを選択します。
- 「リソース」&「スケーリング」 タブを選択します。
- アプリの最小インスタンス数と最大インスタンス数を設定します。
- (オプション) アプリを自動スケーリングするための要求の並行性とタイミングの設定を確認して設定します。
- 「デプロイ」 をクリックして変更を保存し、アプリ・リビジョンをデプロイします。
アプリケーションを更新すると、アプリによって新しいリビジョンが作成され、トラフィックがそのインスタンスにルーティングされます。
CLI を使用した自動スケーリング範囲の変更
CLI を使用して、 Code Engine がアプリの実行インスタンス数を自動スケーリングする範囲を変更するには、 --min-scale
オプションと --max-scale
オプションを、アプリに必要なインスタンス数に設定して application update
コマンドを実行します。 オプションで、アプリケーションの要求の並行性とタイミングの設定を行うことができます。 これらのオプションには、 --concurrency
、 --concurrency-target
、 --request-timeout
、および --scale-down-delay
があります。 これらの自動スケーリング値の設定について詳しくは、 境界のスケーリング、および
並行性とタイミングの自動スケーリング設定 を参照してください。
アプリケーションを更新すると、アプリによって新しいリビジョンが作成され、トラフィックがそのインスタンスにルーティングされます。