要求が1秒に0.2件なら、立ち上げ待ちに当たる要求は0.0%でした。
0.005件まで下がると26.5%です。立ち上げの長さではなく、要求の頻度が割合を決めます。
常に見ているわけではありません。確認の間隔が、追いつくまでの遅れの下限になります。
GPUオートスケールの土台になる仕組みは、間隔を置いて動きます。出典はKubernetesは、水平方向の自動的な増減を、断続的に走る制御の輪として実装している。連続した処理ではないと述べています。
間隔も明示されています。既定の間隔は15秒という記述です。
つまり最短でも15秒は気づきません。増やす判断はそのあとになります。
この4つを足したものが、負荷が上がってから追いつくまでの時間です。
そのあいだの要求は、いまある台数で受けることになります。間に合わなければ待たされます。
出典は目的も述べています。Kubernetesでは、水平方向の自動増減の仕組みが、需要に合わせて能力を自動的に増減させることを目指して、作業負荷の資源を自動的に更新するという記述です。
「需要に合わせて」の需要をどう測るかは、こちらで決めます。待っている件数を見るか、使用率を見るかで挙動が変わります。
Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently (it is not a continuous process).原文Kubernetes 公式ドキュメント「Horizontal Pod Autoscaling」 この内容の有効期限2027-02-18
立ち上げの長さは、当たる割合を変えません。決めているのは要求の頻度だけです。
GPUオートスケールが増やすのは台数です。出典は水平方向の増減とは、増えた負荷に対する応答として、より多くの実体を配ることを意味すると定めています。
増やした台が使えるまでには、立ち上げの時間がかかります。どれだけの要求が当たるかを数えました。
300秒来なければ片付けられ、次は立ち上げからになる前提を置きました。6時間ぶんを通しています。
6時間ぶん。300秒来なければ片付けられ、次は立ち上げからになる 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 （待たされた要求の割合） 50ms 71.4% 26.5% 0.7% 0.0% 300ms 71.4% 26.5% 0.7% 0.0% 1500ms 71.4% 26.5% 0.7% 0.0% 5000ms 71.4% 26.5% 0.7% 0.0%
行がすべて同じ値です。立ち上げの長さは、当たる割合には関係しません。
決めているのは要求の頻度です。0.2件/秒で0.0%、0.005件/秒で26.5%になります。
平均の応答（立ち上げの分だけを足したもの） 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 50ms 35.7ms 13.2ms 0.3ms 0.0ms 300ms 214.3ms 79.4ms 2.1ms 0.1ms 1500ms 1071.4ms 397.1ms 10.3ms 0.3ms 5000ms 3571.4ms 1323.5ms 34.3ms 1.2ms
0.005件/秒の列では、50msと5000msで13.2msと1323.5msです。100倍の差になります。
つまり手を入れる先が2つあります。頻度を上げて当たる割合を下げるか、立ち上げを短くして当たったときを軽くするかです。
最小の台数を1以上にすれば、1列目の側に落ちなくなります。その代わり、使っていない時間も費用が立ちます。
当たる割合は頻度で決まり、重さは立ち上げの長さで決まる。
Horizontal scaling means that the response to increased load is to deploy more Pods.原文Kubernetes 公式ドキュメント「Horizontal Pod Autoscaling」 この内容の有効期限2027-02-18
同じ処理能力を分けた場合、待ちと合計の所要が逆を向きます。見る指標で結論が変わります。
GPUオートスケールの目的は、能力を需要に合わせることです。出典はKubernetesでは、水平方向の自動増減の仕組みが、需要に合わせて能力を自動的に増減させることを目指して、作業負荷の資源を自動的に更新すると定めています。
能力の合計を同じにしたまま、台数だけを変えた場合の差を数えました。
全体の到着は毎分 0.32件。処理能力の合計はどの構成でも同じで、使用率は8割になる 1台にまとめると1件あたりは速く、分けると1件あたりは遅くなる 構成 1件あたり 実測の使用率 平均の待ち 95%点の待ち 合計の所要 1台（速い） 2.5分 78.9% 9.3分 32.8分 11.8分 2台（中くらい） 5.0分 78.9% 8.2分 31.0分 13.2分 4台（遅い） 10.0分 78.9% 6.8分 28.9分 16.8分 8台（もっと遅い） 20.0分 78.9% 5.2分 26.0分 25.2分
待ちは9.3分から5.2分へ減ります。台数を増やすほど短くなります。
ところが合計の所要は11.8分から25.2分へ増えます。2.1倍です。
台数を増減させる指標として待ちを使うと、この表の左側だけを見ることになります。
利用者から見えるのは合計の所要です。待ちだけを指標にすると、増やす方向へ寄ります。
この構成は、1台あたりの能力が下がる場合の話です。同じ性能の台を増やすなら、この表は当てはまりません。
同じ表を、割り当ての側から読んだのがGPUスケジューラの記事です。並べ方を変えた場合の効き目も測りました。
要求の来る時刻は一定の割合で引いたもので、実際には時間帯の波があります。波がある場合、静かな時間帯の直後だけ立ち上げに当たりやすくなります。片付けられるまでの300秒という値も置いたものです。台数を変える計測も、処理能力の合計を同じに保つという前提で、増減にかかる時間は含めていません。ここで見せているのは、当たる割合が頻度だけで決まること、待ちと合計の所要が逆を向くことの2つです。
In Kubernetes, a HorizontalPodAutoscaler automatically updates a workload resource (such as a Deployment or StatefulSet), with the aim of automatically scaling capacity to match demand.原文Kubernetes 公式ドキュメント「Horizontal Pod Autoscaling」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る