アプリケーション・スケーリングの構成
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では、--min-scaleオプションをapp createおよびapp updateコマンドで -
インスタンスの最大数-アプリケーションに対して実行できるインスタンスの最大数。 オートスケーリングはこの上限まで行われる。 この値を
0に設定すると、アプリケーションは必要に応じてスケーリングされ、アプリのスケーリングは、アプリのプロジェクトのリソースクォータあたりのインスタンスによってのみ制限されます。 Code Engine の制限と割り当て量を参照してください。 コンソールから Code Engine を使用してアプリケーションを作成または更新する場合は、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでインスタンスの最大数の値を設定します。 CLIでは、--max-scaleオプションをapp createおよびapp updateコマンドで このオプションのデフォルト値は10です。
アプリケーションをイベント・プロデューサーに接続する場合、スケーリングの境界を設定するときに、それらのプロデューサーからのイベントの頻度とボリュームを考慮に入れてください。 例えば、同時に多くのイベントを受信し、各イベントの処理に数分かかることが予想される場合、各イベントを迅速に処理できる場合よりも高い最大スケール値が必要になるかもしれない。 設定する値が小さすぎると、イベントの受信で遅延が生じたり、リソースが処理されて解放されるのを待っている間にタイムアウトになってイベントがドロップされたりする可能性があります。
並行性およびタイミングの自動スケーリング設定
アプリケーションのスケーリングを制御するには、以下の構成設定を使用します。
-
Concurrency - この値は、アプリの各インスタンスが一度に処理できるリクエスト数を示します。 例えば、通貨の値が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 を使用してアプリケーションを作成または更新する場合、 Resources & scaling タブの Autoscaling セクションで目標同時実行数を設定します。 CLIでは、--concurrency-targetオプションをapp createおよびapp updateコマンドで -
要求タイムアウト-アプリケーションが要求に応答しなければならない時間 (秒単位)。それ以外の場合は失敗します。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションで要求タイムアウト値を設定します。 CLIでは、
--request-timeoutオプションをapp createおよびapp updateコマンドで -
スケールダウン遅延 - アプリケーションがスケールダウンするまでに、同時実行性が低下した状態で経過しなければならない時間(秒)。 アプリケーションへの着信要求のパターンが分かっている場合は、デフォルトの
0より大きい値を指定して、アプリケーションのスケールダウンを遅らせることができます。 このオプションに高い値を使用すると、同時に実行されるアプリケーション・インスタンスの平均数が増加する可能性があり、追加コストが発生します。 スケール・ダウン遅延が0に設定されている場合でも、システムは、アプリケーションがインスタンス数をスケールダウンする前に短時間待機します。これにより、要求の並行性の低下が十分に安定し、スケールダウンが保証されます。 コンソールから Code Engine を使用してアプリケーションを作成または更新するときに、 「リソース」&「スケーリング」 タブの「自動スケーリング」セクションでスケールダウン遅延値を設定します。 CLIでは、--scale-down-delayオプションをapp createおよびapp updateコマンドで
例えば、インスタンスの最大数の値が 10 に設定され、並行性が 100 に設定されている場合、アプリケーションは、要求の潜在的なキューイングが発生する前に、1000 個の並行要求を処理できます。 同時に 1000 を超える要求が予期される場合は、アプリのインスタンスの最大数の値を増やすことを検討してください。
Code Engine の動作の詳細については、 アプリケーションの応答時間を短縮するための IBM Cloud Code Engine スケールダウン遅延の調整 を参照してください。
インスタンスの最小数をインスタンスの最大数と等しい値に設定すると、スケーリングは行われず、ターゲットの通貨とスケールダウン遅延の値は適用されません。 ただし、並行性の値は引き続き有効です。
自動スケーリングのシナリオ例
以下の自動スケーリング設定を使用して構成されたアプリケーションがあるとします。
- 最小インスタンス数 = 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で、1回の翻訳計算がリクエストあたり 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.private.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.private.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 がコンソールからアプリの実行中インスタンスの数を自動スケーリングする範囲を変更するには、以下の手順を実行します。
- アプリにナビゲートします。
- Configuration タブを選択する。
- リソースとスケーリングタブを選択します。
- アプリの最小インスタンス数と最大インスタンス数を設定します。
- (オプション) アプリを自動スケーリングするための要求の並行性とタイミングの設定を確認して設定します。
- Deploy をクリックして変更を保存し、アプリのリビジョンをデプロイします。
アプリケーションを更新すると、アプリによって新しいリビジョンが作成され、トラフィックがそのインスタンスにルーティングされます。
CLI を使用した自動スケーリング範囲の変更
CLI を使用して、 Code Engine がアプリの実行インスタンス数を自動スケーリングする範囲を変更するには、 --min-scale オプションと --max-scale オプションを、アプリに必要なインスタンス数に設定して application update コマンドを実行します。 オプションで、アプリケーションの要求の並行性とタイミングの設定を行うことができます。 これらのオプションには、 --concurrency、 --concurrency-target、 --request-timeout、および --scale-down-delay があります。 これらの自動スケーリング値の設定について詳しくは、 境界のスケーリング、および
並行性とタイミングの自動スケーリング設定 を参照してください。
アプリケーションを更新すると、アプリによって新しいリビジョンが作成され、トラフィックがそのインスタンスにルーティングされます。