CPU使用率の平均だけでは台数を説明できません

Cloud Runは、コンテナ（アプリと実行環境をまとめた単位）を動かす基盤です。自動スケールは、要求や負荷に応じて台数を増減する仕組みです。ここではHTTP（Webの通信規約）で要求を受けるサービスを扱います。インスタンスはコンテナの実行単位です。目標変更で作られる新しい設定版を、ここではrevisionと呼びます。[7]

CPU（中央処理装置）の使用率が低く見えても、台数が増えることがあります。CPU使用率は、割り当てた全vCPU（仮想CPU）の平均です。複数vCPUの一つだけが忙しい場合、平均は低く見えます。メモリ（一時的なデータを保持する領域）の使用率は、スケーリングの指標ではありません。[3]

同時処理は、1台が同時に受け持つ要求数です。[8]

ACT（Adaptive Concurrency Tuning）は、短時間のCPU負荷に応じて同時処理の実効容量を調整する仕組みです。平均CPUが低くても、ACTが容量を絞って推奨台数を押し上げる場合があります。[1]

Cloud Runの指標ベースのスケーリングでは、CPU、同時処理、ACTがそれぞれ推奨台数を出します。Cloud Runはその最大値を採用します。ドライバーは、各推奨値を計算する仕組みを指します。[1]

後輩CPUの目標使用率（推奨台数の計算に使う割合）を上げても変わらないなら、設定が効いていないのでしょうか。

先輩別のドライバーが最大の推奨を出していれば、CPU側の推奨を下げても最大値は変わらない場合があるよ。

後輩CPUの数字だけで、余分な台数だと判断するのは早いんですね。

先輩そうだね。台数を押し上げた条件を先に確認しよう。

自動スケールの目標と台数設定は役割が違います

CPUと同時処理の目標使用率は、どちらも既定値が60%です。問題がなければ、この既定値を運用の出発点にできます。カスタム目標は、推奨台数を計算するときに使う割合を変える設定です。[6]

最大同時処理数は、1台が同時に受け持つ要求件数の上限で、目標使用率とは別の設定です。上限を下げると、同じ要求量でも必要な台数が増える場合があります。[8]

設定役割主な制約
最大同時処理数1台が同時に処理する要求件数の上限アプリが並列処理を効率的に行えるかも確認します。[8]
目標使用率CPUや同時処理の推奨台数を計算する割合CPUは10〜90%、同時処理は10〜95%です。[6]
最小インスタンス数起動済みの台数を維持する目標料金がかかり、設定台数の維持は保証されません。[9]
最大インスタンス数台数増加を制限する上限短期間には設定値を超える場合があります。[10]

最小台数はベストエフォート（維持に努めるが保証はしない）の目標です。インスタンスは再起動される場合もあります。最小インスタンス数の設定は、起動待ち時間がなくなることや、サービスを常に利用できる状態を保証しません。[9]

最大台数にはサービス全体とrevisionごとの設定があり、適用範囲が異なります。複数revisionへ要求を分ける場合、revisionの上限をサービス全体の上限と混同しないことが必要です。短期超過もあるため、厳密な請求上限とは扱えません。[10]

目標を下げる余裕と、費用の増加を分けて考えます

指標ベースでは、各ドライバーが別々に推奨台数を計算し、最大値を選びます。次の図はその関係だけを示す概念図です。[1]

CPUの推奨台数は、直近1分の平均CPU使用量を、1台あたりのvCPU数とCPU目標で割って求めます。同時処理では、revision全体の1分平均と10分平均の同時要求数を比べ、大きい方を使います。1分平均と10分平均のうち大きい同時要求数を、1台の最大同時処理数と目標使用率で順に割り、切り上げます。[2]

説明用の仮定例として、revision全体の平均同時要求40件、1台の上限10件なら、目標60%の推奨は40÷10÷0.6を切り上げた7台です。目標30%なら14台です。[5]

これは同時処理ドライバーだけの説明計算です。この例はGoogleの実測値ではありません。また、実台数や費用が2倍になることを示すものでもありません。推奨と実台数の間には、ほかのドライバー、台数の制限、要求に応じた起動などが関わります。[1, 5]

0台からの起動は、要求に応じて起動するオンデマンド方式が担います。新しい実行単位の起動を待つコールドスタートを、目標変更だけでなくせる保証はありません。図も、この起動や最小・最大台数を含む完全な構成図ではありません。[4]

低い目標は余裕を増やす一方、余分な台数で費用が増える可能性があります。高い目標ではスケール開始まで長く待ち、一度にまとめて台数が増える場合があります。一律の最適値や改善率は示されていません。[13]

最大の推奨を出すドライバーから調整します

指標を見るには、Cloud Monitoring（監視サービス）のMetrics Explorer（指標を見る画面）を開きます。

run.googleapis.com/scaling/recommended_instancesを選びます。Aggregation（集約方法）をUnaggregated（集約しない表示）にすると、ドライバー別の推奨台数を確認できます。最大値を出すドライバーが、指標ベースの推奨台数を決めます。[11]

最大の推奨を出す指標確認する対象
CPUCPU目標と1台あたりのvCPU数、平均使用率を確認します。[2, 3]
同時処理同時処理目標と最大同時処理数を確認します。[2, 8]
ACT短時間のCPU負荷による容量の絞り込みを見て、CPU割当や同時処理設定を確認します。[12]

CPU以外が最大なら、CPU側の推奨を下げても、その時点の最大推奨は変わらない場合があります。実台数は別の要因でも変わるため、CPU目標だけで台数が減るとは断定できません。[1, 12]

CPUと同時処理のドライバーは、片方だけ無効化できます。両方を無効にはできず、ACTは働き続けます。既定値への復元はdisabled（無効化）ではなくdefault（既定値）です。目標値を変更すると新しいrevisionが作成され、変更した目標値は明示的に変更するまで後続のrevisionにも引き継がれます。[7]

少量導入と、負荷をそろえた比較で確かめます

Googleは、少しずつ目標を変え、数分待って効果を観測することを勧めています。新しい目標を適用したrevisionへ少量のトラフィック（流入する要求）を流し、問題がなければ配分を全体へ広げます。[13]

revisionごとのトラフィック割合を指定でき、以前のrevisionへ戻すこともできます。ただし、振り分け変更は瞬時ではなく、処理中の要求は完了まで続きます。[14]

比較では要求量とCPU割当の条件をそろえ、台数、遅延、エラー、費用を確認することを勧めます。異なる量の要求を受けるrevisionの絶対台数だけで、目標変更の効果とは断定できません。これは台数の計算とトラフィック配分を踏まえた比較上の助言で、Googleの実測結果ではありません。[2, 14]

後輩少量だけ流した新revisionの台数が少なければ、設定変更に成功したのでしょうか。

先輩流した要求の量が違えば、その台数差だけでは設定の効果と判断できないよ。

後輩段階導入で問題を探すことと、効果を比べることは分ける必要があるんですね。

先輩そうだね。条件をそろえて応答も確認し、結果を見て判断しよう。

改善がなければ、以前のrevisionや既定目標へ戻す選択肢があります。目標値を変える前に台数の理由を特定し、変更後のサービス応答で効果を確かめることが必要です。[7, 14]

参考にした解説：G-gen Tech Blog