来た順に流すと、長い仕事の平均の待ちは31.9分でした。
短いものから流すと20.7分です。短い仕事だけでなく、長い仕事の待ちも減りました。
並べ方を変えるだけで、両方の種類の待ちが減りました。ただし種類による差は開きます。
GPUスケジューラが行うのは、順位付けと割り当てです。出典は採点の段では、割り当てる役が残った節に順位を付け、最も適した置き場所を選ぶと述べています。
順位の付け方で結果が変わります。並べ方を2通り試して数えました。
窓口4台、仕事2万件です。8割が短い仕事、2割が長い仕事という偏りを付けました。
窓口 4台。仕事 20000件のうち8割が短い仕事（平均2分）、2割が長い仕事（平均42分） 全体の平均は10分。使用率はどちらの並べ方でも同じ 並べ方 仕事の種類 平均の待ち 中央値 95%点 99%点 来た順 短い仕事 31.8分 11.1分 123.8分 223.3分 来た順 長い仕事 31.9分 11.0分 121.6分 253.0分 短いものから 短い仕事 5.2分 1.1分 24.7分 49.3分 短いものから 長い仕事 20.7分 3.8分 91.5分 196.2分
短い仕事は31.8分から5.2分へ、6分の1になります。
長い仕事も31.9分から20.7分へ減りました。どちらの種類も減っています。
短い仕事を先に流すと、待っている仕事の総数がすぐ減ります。列そのものが短くなります。
長い仕事も、その短い列の後ろに並ぶことになります。結果として待ちが縮みます。
使用率はどちらも同じです。同じ量の仕事を、同じ台数で処理しています。変えたのは順番だけです。
来た順なら、種類による差は31.8分と31.9分でほぼありません。
短いものからでは5.2分と20.7分で、約4倍の差が付きます。
だから「長い仕事が後回しにされている」という声は出ます。実際には減っているのに、比べる相手が速くなったためです。
どちらも減るが、種類による差は開く。
In the scoring step, the scheduler ranks the remaining nodes to choose the most suitable Pod placement.原文Kubernetes 公式ドキュメント「Kubernetes Scheduler」 この内容の有効期限2027-02-18
同じ処理能力でも、分け方で待ちと所要が逆を向きます。どちらを見るかで結論が変わります。
GPUスケジューラは、まず置ける場所を絞ります。出典は絞り込みの段では、その仕事を割り当てられる節の集合を見つけると述べています。
絞った先の構成で、1台にまとめるか分けるかが変わります。その差を数えました。
処理能力の合計はどの構成でも同じにしてあります。使用率も8割で揃えました。
全体の到着は毎分 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件を早く終わらせたい場合です。この計測では11.8分と25.2分の差になります。
The filtering step finds the set of Nodes where it's feasible to schedule the Pod.原文Kubernetes 公式ドキュメント「Kubernetes Scheduler」 この内容の有効期限2027-02-18
条件を満たす機械がないと、そもそも割り当てられません。要求の書き方が先に効きます。
GPUスケジューラが探すのは、条件を満たす機械です。出典はまとまりの中で、ある仕事の割り当ての要件を満たす節を、割り当て可能な節と呼ぶと定めています。
満たす節がなければ、並べ方も分け方も関係ありません。待ち続けることになります。
要求を多めに書くと、置ける場所が減ります。どれだけ載るかを詰め方で数えた結果が参考になります。
1台の容量 80・20台。仕事 600件の要求の合計は 8474 全部を隙間なく詰められたとしても 106台ぶんになる 詰め方 載った仕事 載らなかった 使えた容量 空いたまま 来た順に詰める 127件 473件 99.2% 13 大きい順に詰める 60件 540件 99.9% 1 小さい順に詰める 258件 342件 97.3% 44
同じ20台でも、載る仕事が60件から258件まで変わります。4.3倍です。
「使えた容量」は大きい順が99.9%で最も高くなります。件数とは逆を向きます。
1番目と2番目が先です。置けなければ、3番目と4番目は意味を持ちません。
台への詰め方そのものはAKSの記事でも扱いました。同じ表を、費用の側から読んだものです。
仕事の長さの分布は8割が短く2割が長いという形で置きました。この偏りが弱ければ、短いものから流す効き目も小さくなります。到着の時刻も一定の割合で引いており、実際には波があります。詰め方の計測も、仕事ごとの要求の大きさを式で作ったものです。ここで見せているのは、順番を変えるだけで両方の待ちが減ること、待ちと合計の所要が逆を向くことの2つです。
In a cluster, Nodes that meet the scheduling requirements for a Pod are called feasible nodes.原文Kubernetes 公式ドキュメント「Kubernetes Scheduler」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る