【仮想化基盤】 設計値ベースのキャパシティ管理が正しく機能しない理由

仮想化基盤のキャパシティ管理をしていると、設計資料に記載されたCPUやメモリの値を積み上げるほど「もうクラスタは限界なのでは」と感じる瞬間があります。ところが、実際のホストの使用率を確認すると、思っていたほど逼迫していない。むしろ余裕があるように見えることさえあります。

この“設計値と実使用値のズレ”は、担当者の経験不足や読み違いではなく、仮想化基盤という仕組みそのものが生み出しているものです。設計値は最大必要量として盛られやすく、実使用は平常時の平均値として小さくなる。さらにCPUはオーバーコミット前提で動くため、両者の乖離は構造的に避けられません。

この記事では、なぜ設計値ベースのキャパシティ管理が正しく機能しないのか、その理由を整理しながら、仮想化基盤を扱ううえで欠かせない視点をまとめていきます。

設計値は“最大必要量”として盛られやすい

キャパシティ管理で最初に理解しておきたいのは、設計資料に記載されるCPUやメモリの値は「最大必要量」であり、平常時の使用量とはまったく別物だという点です。設計値は、アプリケーションがピーク時に落ちないようにするための“上限”として申請されます。テナント担当者は、障害や性能劣化を避けるために、どうしても安全側に寄せた値を選びます。

そのため、4 vCPUと書かれていても、実際の平常時のCPU使用率は5〜15%程度しか使わないことが珍しくありません。メモリも同じで、8GBと申請されていても、実際には3〜4GBで安定しているケースが多い。設計値は「最大値」、実使用は「平均値」。この性質の違いが、後で大きな乖離を生みます。

設計値が盛られやすい背景には、いくつかの理由があります。

① ピーク時の安全性を確保したい

② アプリ担当者が実使用量を正確に把握できないことが多い

③ “少なめに申請して性能劣化したら困る”という心理が働く

こうした事情が積み重なることで、設計値はどうしても大きくなりがちです。そして、この“盛られた値”が、仮想化基盤のキャパシティ管理において大きな誤差を生む原因になります。

設計値は、あくまで「最大必要量の申請」であり、キャパシティ管理で使うべき指標ではありません。ここを誤ると、クラスタの状態を正しく把握できなくなり、増設の判断もずれてしまいます。

設計値の積み上げが『偽の逼迫』を生む理由

設計値が最大必要量として盛られやすいことは前の章で触れましたが、この性質が本当に問題になるのは、VMの台数が増えたときです。仮想化基盤では、1台のVMに対して盛られた設計値が、そのまま台数分だけ増幅されます。10台なら10倍、100台なら100倍、200台なら200倍。クラスタ規模が大きくなるほど、設計値の“盛られ具合”がそのままクラスタ全体の逼迫感として現れてしまいます。

例えば、200台のVMがあるクラスタを想像してみてください。設計値を積み上げると、CPUは800 vCPU、メモリは1.6TB必要だと見えます。数字だけを見ると「もう限界だ」「増設しないと収容できない」と感じてしまうかもしれません。しかし、実際の使用量はその半分どころか、三分の一以下ということも珍しくありません。多くの企業システムでは、実使用は設計値の20〜40%程度に収まるからです。

こうした乖離は、仮想化基盤ではむしろ自然な現象です。アプリケーションは常にピークで動くわけではなく、待機時間が長い処理も多い。OS自体もアイドル時にはCPUをほとんど使いません。メモリも、申請された容量を常時使い切るわけではなく、キャッシュやヒープの挙動によって実使用量は大きく変動します。つまり、設計値は「最大値」、実使用は「平常時の平均値」。この二つを同じものとして扱うと、クラスタの状態を正しく把握できなくなります。

設計値を積み上げるほどクラスタが逼迫して見えるのは、設計値という指標が“最大必要量として膨らむ性質”を持っているためであり、仮想化基盤では構造的に避けられない現象です。設計値は「最大必要量の申請」であり、キャパシティ管理で使うべき指標ではありません。ここを誤ると、増設の判断が早まりすぎたり、逆に本当に逼迫したタイミングを見逃したりすることにつながります。

この章で伝えたいのは、設計値を積み上げてクラスタの状態を判断する方法は、規模が大きくなるほど誤差が増幅され、正しく機能しなくなるということです。キャパシティ管理は、設計値ではなく、実際に使われている量を基準にしなければ成立しません。

CPUはオーバーコミット前提で動くため、設計値と実使用値の乖離はさらに広がる

仮想化基盤のキャパシティ管理を考えるうえで、もうひとつ欠かせない視点があります。それが CPUはオーバーコミット前提で動いている という事実です。これは、物理サーバーのCPUコア数以上の vCPU をVMに割り当てても、通常は問題なく動作するという仮想化の仕組みによるものです。

vCPUは「同時に使える権利」であって、常時使うわけではありません。多くのアプリケーションは、処理の待機時間が長く、CPUを継続的に使い続けることはほとんどありません。OS自体もアイドル時にはCPUをほぼ使わないように設計されています。そのため、4 vCPUのVMがあっても、平常時のCPU使用率が数％しかないという状況は珍しくありません。

この性質が、設計値と実使用値の乖離をさらに広げます。設計値は「最大必要量」として申請されるため、vCPU数はどうしても大きくなりがちです。しかし、実際の使用量はそのごく一部に留まる。結果として、設計値を積み上げるとクラスタは逼迫して見えるのに、実使用値を見るとまだ余裕がある、という状況が生まれます。

オーバーコミットが前提である以上、設計値を合計してクラスタの状態を判断する方法は、構造的に正しく機能しません。設計値は「最大値」、実使用は「平均値」、そしてCPUは「必要な時だけ使う権利」。この三つの性質が混ざることで、設計値ベースのキャパシティ管理は必ず悲観的になります。

キャパシティ管理の目的は、クラスタが本当に逼迫する前に増設のタイミングを捉えることです。そのためには、設計値ではなく、実際に使われているCPUの推移を基準に判断する必要があります。オーバーコミットという仮想化基盤の前提を理解しておくことは、キャパシティ管理を正しく行ううえで欠かせない視点です。

キャパシティ管理の目的は“収容不可になる前に増設タイミングを捉えること”

キャパシティ管理という業務は、単にリソースの数字を眺めて「余裕があるかどうか」を判断するだけの作業ではありません。本質的な目的はもっと明確で、もっとシビアです。それは、クラスタが本当に逼迫する前に、設備増設のタイミングを正しく捉えることです。

仮想化基盤では、テナントから新規VMの搭載計画が継続的に上がってきます。追加されるVMは、当然ながらCPUやメモリを消費します。もし既存クラスタのリソースが不足している状態で新規VMを搭載しようとすると、最悪の場合「収容不可」という状況が発生します。これは、テナント側の計画に影響を与えるだけでなく、基盤運用側にも大きな負荷をもたらします。

だからこそ、キャパシティ管理では「いつ逼迫するか」を正しく予測することが重要になります。しかし、設計値ベースではこの予測がうまくいきません。設計値は最大必要量として盛られやすく、実際の使用量とは大きく乖離します。設計値を積み上げるとクラスタは常に限界に見えてしまい、増設の判断が早まりすぎたり、逆に本当に逼迫したタイミングを見逃したりする可能性があります。

キャパシティ管理の目的を達成するためには、設計値ではなく、実際に使われている量の推移を基準に判断する必要があります。CPUやメモリの平均値とピーク値を日次で収集し、月次の増加ペースを把握する。そして、実使用率が85%に到達するタイミングを予測し、その数ヶ月前に設備部門へ増設の相談を行う。これが、キャパシティ管理を正しく機能させるための基本的な流れです。

設計値は「申請内容」としての役割はありますが、キャパシティ計算には使いません。使うべきは、実際に使われている量だけです。未来の逼迫は、設計値の合計ではなく、実使用値の増加ペースで決まります。この視点を持つことで、キャパシティ管理は初めて正しく機能します。

まとめ：設計値は“最大値”。キャパシティ管理は“実使用値”でしか正しく機能しない

ここまで整理してきたように、仮想化基盤のキャパシティ管理が難しくなる理由は、設計値と実使用値が構造的に乖離するためであり、数値の読み方ではなく“仕組みそのもの”に起因します。設計値という指標の性質と、仮想化基盤そのものの構造が、設計値と実使用値の間に大きな乖離を生み出しているからです。

設計値は最大必要量として盛られやすく、平常時の使用量とはまったく別物です。VMの台数が増えるほど、その“盛られた値”がそのまま増幅され、クラスタは常に逼迫しているように見えてしまいます。さらにCPUはオーバーコミット前提で動くため、設計値を積み上げてもクラスタの実態を正しく表すことはできません。

キャパシティ管理の目的は、クラスタが本当に逼迫する前に増設のタイミングを捉えることです。そのためには、設計値ではなく、実際に使われている量の推移を基準に判断する必要があります。CPUやメモリの平均値とピーク値を日次で収集し、月次の増加ペースを把握し、実使用率が85%に到達するタイミングを予測する。こうした実使用値ベースの管理こそが、キャパシティ管理を正しく機能させる唯一の方法です。

設計値は申請内容としての役割はありますが、キャパシティ計算には使いません。使うべきは実使用値だけです。未来の逼迫は、設計値の合計ではなく、実使用値の増加ペースで決まります。この視点を持つことで、仮想化基盤のキャパシティ管理は初めて正しく機能します。

仮想化基盤を扱うSEにとって、設計値と実使用値の違いを理解することは、キャパシティ管理の第一歩です。設計値を信じるのではなく、実際に使われている量を見て判断する。このシンプルな原則が、仮想化基盤の安定運用を支える大切な視点になります。