単一 VM の vCPU はどこまで割り当てるべきか – 物理コア数、NUMA、オーバーコミットで考える

仮想化環境では、CPU オーバーコミットは一般的な設計手法です。しかし、単一 VM に対して vCPU をどこまで割り当てるべきかは、ホスト全体のオーバーコミット率とは別に考える必要があります。

この記事で扱う主題は、CPU オーバーコミットを許容するかどうかではありません。単一 VM が、物理ホストの CPU 構造を超えるような vCPU 数を持つべきかどうかです。

特に、仮想アプライアンス、NFV、低レイテンシ用途、常時高負荷を前提とする VM では、vCPU 数は単なるスペック表の数字ではなく、実行モデルそのものに関係します。

vCPU は多ければ速いわけではない

VM に割り当てる vCPU 数を増やすと、一見すると性能が上がるように見えます。しかし、実際にはアプリケーションが並列処理できるか、ホスト側で vCPU を同時に実行できるか、NUMA をまたぐか、スケジューラがどう扱うかによって結果は変わります。

単一 VM に過剰な vCPU を割り当てると、ゲスト OS からは大きな CPU を持つように見えます。しかし、ホスト側ではそれだけ多くの実行単位をスケジューリングする必要があります。

つまり、vCPU を増やすことは、VM の能力を増やすだけでなく、ホスト側に同時実行の要求を増やすことでもあります。

物理コア数を超える vCPU 割り当ては慎重に考える

単一 VM に、物理ホストの実コア数を超える vCPU を割り当てる構成は、基本的には慎重に扱うべきです。

検証環境や性能劣化を許容する用途であれば成立することもあります。しかし、性能要件のある VM や、仮想アプライアンスのように常時処理を行う VM では、物理コア数を超える vCPU 割り当ては、分かりやすい性能向上ではなく、スケジューリング競合の増加として表れる可能性があります。

特に、すべての vCPU が同時に動ける前提で設計されたアプリケーションでは、ホスト側で同時実行できないことが性能の揺らぎになります。

CPU オーバーコミットと単一 VM の vCPU 設計は別問題

ホスト全体で CPU オーバーコミットすることと、単一 VM に過剰な vCPU を割り当てることは、似ているようで別の問題です。

観点	意味
ホスト全体のオーバーコミット	複数 VM の合計 vCPU が物理 CPU を超える設計。全 VM が同時に最大負荷にならない前提で成立する。
単一 VM の過剰 vCPU	1 台の VM が大量の vCPU を持つ設計。対象 VM 自身のスケジューリングと並列性が問題になる。
低負荷 VM	vCPU を多めに見せても実害が少ない場合がある。
常時高負荷 VM	割り当てた vCPU を実際に使おうとするため、ホスト側の実行能力と衝突しやすい。

CPU オーバーコミットは、複数 VM の利用率が時間的にずれることを利用する設計です。一方で、単一 VM が常時多くの vCPU を使うなら、その VM はホストに対して大きな同時実行要求を出し続けることになります。

NUMA をまたぐと別の問題が出る

物理サーバーが NUMA 構成の場合、vCPU 数やメモリ割り当てが NUMA ノードをまたぐことで、メモリアクセスの遅延が増えることがあります。

単一 VM を大きくしすぎると、1 つの NUMA ノードに収まらず、複数 NUMA ノードをまたいだ VM になります。これ自体が悪いわけではありませんが、ゲスト OS、アプリケーション、ホスト側の NUMA 配置を理解していないと、性能が安定しにくくなります。

特に、低レイテンシ用途やネットワーク処理では、CPU、メモリ、NIC、割り込みの位置関係が効いてくるため、NUMA を無視した巨大 VM は扱いにくくなります。

仮想アプライアンスではスペック表だけを信じない

仮想ルーター、仮想ファイアウォール、ロードバランサー、IPsec 終端のような仮想アプライアンスでは、ベンダーが推奨 vCPU 数を示していることがあります。

ただし、その推奨値がどの実行モデルを前提としているかを確認する必要があります。CPU ピニングありなのか、専有ホストなのか、NUMA を意識しているのか、SR-IOV や DPDK を使うのかによって、同じ vCPU 数でも意味が変わります。

単に vCPU 数を増やせば仮想アプライアンスの性能が上がる、という理解は危険です。ネットワーク I/O、割り込み、キュー数、暗号処理、メモリ帯域、NUMA まで含めて見る必要があります。

CPU ピニングとの関係

CPU ピニングは、vCPU と pCPU の対応を固定し、実行タイミングの揺らぎを抑えるための設計です。単一 VM に多くの vCPU を割り当てる場合、CPU ピニングの有無によって性能特性は大きく変わります。

CPU ピニングありなら、専有実行に近い性質を作れます。一方で、CPU ピニングなしで大量の vCPU を割り当てると、ホストスケジューラと他 VM の影響を受けやすくなります。

つまり、vCPU 数だけを見ても十分ではありません。その vCPU がどの pCPU で、どのような競合条件の中で実行されるのかを確認する必要があります。

パブリッククラウドでは見えにくくなる

パブリッククラウドでは、物理 CPU、NUMA、ホスト上の他 VM、CPU ピニングの有無が利用者から見えにくくなります。

そのため、vCPU 数だけで性能を判断すると、オンプレミスや自前の仮想化基盤とは違う挙動になります。インスタンスタイプ、専有ホスト、ベアメタル、CPU クレジット、ネットワーク性能、帯域保証の有無などを合わせて見る必要があります。

クラウド上で NFV 型や低レイテンシ型の VM を動かす場合は、単に vCPU 数が多いインスタンスを選ぶだけでは足りません。実行モデルが要件に合っているかを見る必要があります。

実務上の目安

単一 VM の vCPU 割り当ては、用途によって考え方を変えるべきです。

• 軽量な業務 VM では、必要最小限から始めて観測しながら増やす
• 常時高負荷 VM では、物理コア、NUMA、他 VM との競合を確認する
• 仮想アプライアンスでは、ベンダー推奨値の前提条件を確認する
• NFV や低レイテンシ用途では、CPU ピニングや専有実行モデルを検討する
• vCPU 数だけでなく、レイテンシ、ジッタ、パケットドロップ、スループットを見る

基本的には、小さく始めて観測し、必要に応じて増やす方が安全です。最初から過剰な vCPU を割り当てると、性能が良くなるどころか、問題の切り分けが難しくなります。

関連記事

• CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ
• VM パフォーマンス Day2 – CPU 最適化と NUMA / CPU ピニングの考え方
• VM パフォーマンス Day3 – メモリ最適化と HugePages / TLB / NUMA の考え方
• パブリッククラウド上で NFV 型 NF は成立するのか – アンダーレイ / オーバーレイ / 帯域制約で考える
• クラウドを AWS だけで理解してはいけない – 本質は場所ではなく運用モデルである

まとめ

単一 VM の vCPU は、多ければ多いほど良いわけではありません。vCPU 数は、物理コア、NUMA、CPU ピニング、ホストスケジューラ、他 VM との競合、アプリケーションの並列性を含めて考える必要があります。

特に、NFV、低レイテンシ用途、仮想アプライアンスでは、vCPU 数は単なるスペックではなく、実行モデルの一部です。

CPU オーバーコミット全体の議論と、単一 VM にどこまで vCPU を持たせるかの議論を分けることが、仮想化基盤の性能設計では重要です。