OCP APAC 2026 | CPU利用率の分布から、ラックに収める台数を見積もる

たとえば、ラックにまだ空きがあるのに、電力の上限が気になってサーバーを追加できない場面を考えてみます。一台ずつの最大消費電力を足せば慎重に見積もれますが、実際には全台が同じ強さで動き続けるとは限りません。反対に、平均値だけで台数を決めると、負荷が重なったときの余裕を見落とします。

2026年8月のOCP APAC SummitでMicrosoftが示したのは、実際に動くサーバー群の利用率と消費電力の分布から、ラックへの搭載台数を見積もる考え方です。最大性能を測る試験から少し視点を変え、「普段はどんな負荷で動き、ときどきどこまで電力が増えるのか」を計画に持ち込みます。^［1・2］

一台分の電力を、どの負荷で決めるか

講演では、ラックや電力区画に収めるノード数を elevation と呼んでいます。ここでいうノードは、電力を見積もる単位となるサーバーです。台数を少なく抑えすぎれば、同じサーバー数により多くのラックや床面積が必要になります。多く詰め込みすぎれば、電力を抑えるための性能制限が働き、利用者の仮想マシンに影響するおそれがあります。^［2］

その間を探る手がかりが、利用率に対して電力がどう変わるかを表すロードラインです。ただし、試験用の負荷で描いた曲線が、実際のクラウドと同じ形になるとは限りません。資料の比較例では、従来のベンチマークは低い利用率では実フリートより電力が小さく、高い利用率では逆に大きくなっていました。曲線上の一点だけを選ぶと、選んだ負荷によって余裕を大きく見積もったり、小さく見積もったりします。^［2］

CPUの平均利用率が同じでも、中の動きは違う

フリートとは、運用中のサーバー群のことです。資料にある複数のフリートでは、CPU利用率の分布も、利用率に対する電力の曲線も異なります。立ち上がり途中のフリートと、運用が進んだフリートでは、よく現れる利用率の範囲さえ変わります。CPUだけでなく、メモリーやその他の部品が使う電力も、ノード全体の見積もりに含める必要があります。^［2］

もう一つの違いは、CPU内部の負荷の偏りです。論理プロセッサー（LP）は、この資料ではハードウェアスレッドを指します。たとえば、少数のLPが忙しく残りが休んでいる状態と、全LPがほどほどに動く状態では、平均利用率が同じでも内訳は違います。資料の実測例も、LPごとの利用率が均一ではないことを示しています。平均を一つ読むだけでは、この違いが消えてしまいます。^［2］

平均と偏りを、電力予測の入力にする

Microsoftは対象の「Fleet A」で、LP全体の平均利用率、利用率の偏りを示すジニ係数、平均動作周波数、周波数のばらつきを示す変動係数の四つを使い、ブレードの電力を予測しました。報告された決定係数R²は約0.97、平均絶対誤差（MAE）は約18Wです。^［2］

R²は、観測された電力のばらつきをモデルがどれだけ説明できたかを見る指標です。MAEは、予測と実測の差の絶対値を平均したもの。したがって、この結果を「すべての予測が18W以内に収まる」「どのサーバーでも97％の精度が出る」と読むことはできません。対象フリートで、平均に加えて負荷の偏りを持ち込む意味があった、と受け止めるのが自然です。

実際のフリートに近い負荷を、試験でも作る

モデルで傾向をつかんだら、試験用の負荷も現実に近づけます。発表の最初の試作は、整数演算とメモリー負荷を組み合わせ、LPごとに動く時間と休む時間を変えるものでした。ディスクとネットワークにも軽い負荷を加え、CPUだけを一様に動かす試験から一歩進めています。^［2］

二つ目の試作では、圧縮、暗号処理、キーバリュー処理、グラフ処理、メモリーアクセスを混ぜました。資料の比較図では、三つのフリートに対する電力曲線が初回の試作からさらに近づいています。ただし、二つ目にはその時点でI/O負荷がなく、発表者も完全な一致とはしていません。これは公開クラウドの負荷を再現するための概念実証であり、完成した汎用ベンチマークの紹介ではありません。^［2］

台数の増加例には、電力超過の条件が付く

搭載台数の図では、Fleet Aの利用率分布とノード間の違いを使い、利用率50％のベンチマーク値を基準にする従来の方法と比べています。たとえばラックの電力枠が20kWの場合、電力が枠を超える確率の目標を1％とした例では、22台から28台へ増える計算です。同じ20kWでも、超過確率の目標を0.01％にすると26台になります。^［2］

ここで変わったのは、ラックが供給できる電力ではなく、負荷の分布と許容する超過確率を踏まえた台数の見積もりです。図は単純化した例で、28台ならどの環境でも安全という設置指針ではありません。また、この確率を、そのまま年間の停止時間やサービスの障害率へ換算することもできません。

ラックの外側と、これからの負荷も含めて考える

実際の計画には、曜日や季節、地域、特定顧客の使い方が関わります。ラック単体に余裕があっても、列やデータセンター全体の電力枠が先に制約になることもあります。AI処理が増えれば、これまで観測した分布がそのまま続くとも限りません。資料は、こうした複雑さと、性能制限をどこまで許容できるかを未解決の条件として挙げています。^［2］

発表の呼びかけは、事業者の運用データをそのまま公開せずに、共通の用語、検証手順、匿名化した根拠の示し方をOCPコミュニティで作ろう、というものでした。電力計画を平均一つで済ませず、普段の負荷とまれな大きな負荷を一緒に読む。そのために、テレメトリーと試験をつなごうとする提案です。^［2］

Microsoftの事業をもう少し知る

今回の発表を行ったMicrosoftは、Azureだけでなく、業務ソフトやWindowsなども展開しています。会社全体の事業と設備投資については、cyclewaveの企業解説にまとめています。

参考資料

2026年9月26日確認。公式スライド全24ページと、グラフ・試作条件を照合しました。講演動画の音声・質疑は確認対象に含めていません。

［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題・登壇者・公式資料への導線。

［2］Microsoft「Telemetry-Driven Power Estimation for Rack-Level Provisioning in Public Cloud Data Centers」公式掲載スライド。課題とロードラインはpp.2–6、実フリートはpp.7–11、モデルはpp.12–13、試作はpp.14–19、搭載台数例と条件はpp.20–22。