VMware のオーバーコミットの仕組みと適正な集約率（CPU/メモリ比）の考え方

はじめに

仮想化基盤の設計や運用に携わるエンジニアなら、一度は頭を悩ませるキーワード「オーバーコミット」。

これは、物理サーバーが持つリソース量（実在庫）よりも多くの仮想リソースを割り当てることで、リソースの利用効率を高め、インフラコストを劇的に削減できる技術です。しかしその反面、やりすぎるとシステム全体のパフォーマンス低下や障害を招く「諸刃の剣」でもあります。

本記事ではパフォーマンスを犠牲にせず、安全にリソースを集約するための設計指針を実務的な視点で解説します。

オーバーコミットとは？

そもそも「オーバーコミット」とは、物理ホストが実際に持っているリソース量（実在庫）を超えて、仮想マシンにリソースを割り当てることを指します。

例えば、物理 CPU が「10コア」しかないサーバー上で、仮想マシン 4台に「4コアずつ（合計16コア）」割り当てるような状態です。物理的には足りていないはずなのに、仮想化の世界ではこれが成立します。

仕組みのイメージ: 飛行機のオーバーブッキング

この仕組みは、よく「飛行機の座席予約（オーバーブッキング）」に例えられます。

航空会社は、定員 100名の飛行機に対して、キャンセルを見越して 110名や 120名の予約を受け付けることがあります。これは「全員が同時に乗ってくる（リソースを使う）ことは稀である」という統計的予測に基づいています。

仮想化もこれと同じです。

• 飛行機の座席 = 物理 CPU/メモリ
• 乗客の予約 = 仮想マシンへの割り当て

メリット: インフラコストの圧縮

オーバーコミットを行う最大のメリットは、コスト削減です。

多くのサーバー（特に Web サーバーや開発環境など）は、一日中 CPU をフル稼働させているわけではありません。稼働率が 10%〜20% 程度の「隙間時間（アイドルタイム）」が大半を占めるケースも珍しくありません。

オーバーコミットを活用すれば、この「使われていない隙間時間」を他の仮想マシンに貸し出すことができるため、少ない物理サーバーでより多くの仮想マシンを稼働させることが可能になります。結果として、ハードウェア購入費やデータセンターのラック費用、電気代といったインフラコストを大幅に圧縮できます。

CPU とメモリで異なる「攻め」の考え方

オーバーコミットを設計する際、CPU とメモリを同じ感覚で扱ってはいけません。 両者はハードウェアとしての性質が全く異なるため、「CPU は攻め（積極的）」、「メモリは守り（保守的）」 というスタンスで設計するのが定石です。

CPU のオーバーコミット（時分割）

CPU のオーバーコミットは、「時間を切り売りする（時分割）」 アプローチです。

CPU は常に計算し続けているわけではありません。Web サーバーであればリクエストが来た瞬間だけ動き、それ以外は待機しています。この「計算していない待ち時間（アイドルタイム）」が多いため、CPU は比較的積極的にオーバーコミット（集約）しやすいリソースです。

イメージ

1つの会議室を複数のチームで予約し合っている状態

仕組み

ハイパーバイザーが「ミリ秒単位」で CPU の利用権を各 VM に切り替えます。Aさんが使っていない瞬間に、Bさんが使う、といった譲り合いが成立しやすいため、物理コア数以上の vCPU を割り当てても（ある程度までは）問題なく動作します。

メモリのオーバーコミット（空間分割）

一方、メモリのオーバーコミットは「場所を共有する（空間分割）」 アプローチであり、非常にシビアです。

メモリは計算能力ではなく「データ置き場」です。データが存在する限り、常にその場所（容量）を占有し続けます。もし物理メモリが足りなくなると、システムはハードディスクの一部をメモリ代わりにする「スワップ（Swap）」や「バルーニング」という処理を行います。

しかし、ハードディスクの速度はメモリに比べて桁違いに遅いため、スワップが発生した瞬間にシステムのパフォーマンスは劇的に低下します。

イメージ

倉庫に荷物を詰め込んでいる状態。満杯になったら、遠くの倉庫（ディスク）まで荷物を取りに行かなければならず、作業が止まってしまう。

【鉄則】

パフォーマンス低下が許されない本番環境（特に DB サーバーなど）では、メモリのオーバーコミットは基本的に避け、物理メモリ容量の範囲内で設計する（＝メモリ予約をする）のが一般的です。

推奨される vCPU / pCPU 比率（集約率）

では、実際どのくらいまで詰め込んでいいのでしょうか？ VMware の公式ガイドラインや、ハードウェアベンダーのホワイトペーパーに基づいた推奨値を紹介します。

CPU の目安（vCPU / pCPU）

ワークロード（システムの用途）によって許容範囲が大きく異なります。

ミッションクリティカル (DB 等): [ 1:1 〜 2:1 ]

• 重視点: パフォーマンス・安定性
• データベースサーバーや、遅延が許されない基幹システムが該当します。ここではオーバーコミットをほとんど行わず、物理コアに近い性能を保証します。

一般サーバー (Web/App): [ 3:1 〜 4:1 ]

• 重視点: コストと性能のバランス
• Web サーバー、AP サーバー、ファイルサーバーなど、一般的な業務システムです。多くの企業で採用される標準的な「黄金比」はこのあたりです。

VDI (仮想デスクトップ): [ 5:1 〜 10:1 ]

• 重視点: 高集約・コスト削減
• 社員が使う PC 環境です。人間が操作するため「思考中の待ち時間」が多く、CPU が空いている時間が長いため、非常に高い比率で集約可能です。

メモリ の目安（vRAM / pRAM）

前述の通り、メモリは「枯渇＝即パフォーマンス劣化」に繋がるため、基本は保守的に設計します。

本番環境: [ 1:1 ] (オーバーコミットなし)

推奨: 物理メモリの範囲内に収めることを強く推奨します。スワップ発生のリスクをゼロにし、安定稼働を最優先します。

開発・検証環境: [ 1:1.5 〜 1:2 ]

条件付き許容: コスト削減を優先したい開発環境などに限り、オーバーコミットを許容するケースがあります。ただし、「メモリ使用率の監視」が必須です。

根拠・参考資料

本記事の推奨値は、以下の公式ドキュメントやベストプラクティスに基づいています。

1. VMware vSphere Performance Best Practices
   • VMware 公式のパフォーマンスチューニングガイドです。「CPU Ready 時間の監視」や「メモリバルーニングの影響」について詳細に記述されています。
   • Performance Best Practices for VMware vSphere 8.0 (PDF)
2. VDI 環境のサイジング指針
   • VDI（Horizon）における CPU 要件の見積もりについては、ユーザータイプ（ナレッジワーカー/パワーユーザー）ごとのガイドラインが参考になります。
   • Estimating CPU Requirements for Virtual Machine Desktops (Omnissa Docs)
3. ハードウェアベンダーの検証データ
   • Dell や HPE などのベンダーが発行するホワイトペーパーでは、一般的なワークロードにおける「3:1 〜 5:1」という比率がベンチマークとしてよく採用されています。
   • Dell Technologies: VMware vSphere Best Practices (参考)

オーバーコミット設計における3つの注意点

「推奨値の範囲内だから大丈夫」と安心するのは危険です。 実際のシステムが健全に動くかどうかは、以下の3つのリスク要因に左右されます。これらを考慮して設計・運用しましょう。

➀「CPU Ready Time」の監視

オーバーコミット環境で最も注視すべき指標が 「CPU Ready Time (%RDY)」 です。

これは、VM が「計算処理をしたいのに、物理 CPU が空いていないため待たされている時間」を示します。 推奨値の範囲内であっても、この値が高くなるとシステムは体感できるレベルで遅延します。

危険信号の目安

一般的に、vCPU あたり 5%（または 1000ms）を超えるとパフォーマンスに影響が出始めると言われています。

対策

この数値が高い場合は、オーバーコミット率を下げる（VM を別のホストに移動する）か、vCPU の割り当てを減らす検討が必要です。

➁HA（高可用性）と障害時のリソース確保

「平常時に全台動いている」だけでは不十分です。「物理ホストが1台故障したとき、残りのホストで全 VM を支えられるか？」 を計算に入れる必要があります。

ギリギリまでリソースを詰め込んでいると、いざ障害が発生した際に、避難先のホストも満員で VM が再起動できない（HA が失敗する） という最悪の事態を招きます。

対策

常に「N+1 構成（1台壊れても大丈夫な余力）」を維持するために、クラスター全体のリソース使用率には 20〜30% 程度のバッファを持たせておくのが鉄則です。

➂ワークロードの特性（ピークタイムの重複）

オーバーコミットは「みんなが同時に CPU を使わない」という前提で成り立っています。 そのため、ピークタイムが完全に重なるシステム同士 は、相性が最悪です。

NG 例

全サーバーが毎朝 9:00 に一斉に始業時バッチ処理を行う環境

対策

こうした環境ではオーバーコミットは機能しません。バッチ処理の時間をずらすか、リソースを占有割り当て（予約）にする必要があります。

まとめ

オーバーコミットは、「コスト効率」 と 「パフォーマンス」 のトレードオフです。 魔法のような技術ですが、銀の弾丸（万能な解決策）ではありません。

成功の鍵は、最初から限界ギリギリを攻めるのではなく、まずは 安全な比率（CPU 3:1、メモリ 1:1 程度） からスタートすること。そして、実際の稼働状況（CPU Ready Time やメモリ使用率）をモニタリングしながら、徐々に設定を最適化していく「運用のサイクル」を回すことです。

本記事の指針を参考に、ぜひ自社の環境に最適な「攻めと守りのバランス」を見つけてください。

以上、最後までお読みいただきありがとうございました。