【図解】仮想化環境のパフォーマンス設計・分析

はじめに

Webシステムでは、物理サーバ上に複数の仮想マシン（VM）を配置し、CPU・メモリ・ストレージ・NICなどの物理リソースを共有する構成が広く利用されています。仮想化によって物理リソースを効率よく利用できる一方、性能設計では物理サーバとは異なる観点が必要になります。

仮想環境では、VMに割り当てたvCPUやメモリが、そのまま専用の物理リソースとして確保されているとは限りません。複数VMが同じ物理リソースを共有するため、CPU Scheduling、Overcommit、NUMA、Memory Reclamation、Storage I/O競合、Network I/O競合などによって待ち時間が発生することがあります。

したがって、仮想化環境の性能問題ではVM内部のCPU使用率やメモリ使用量だけを見るのではなく、VM → Hypervisor → Physical Hostの関係を確認することが重要です。本記事では、特定製品の設定値だけに依存せず、仮想化環境の性能設計で共通して使える考え方を中心に解説します。VMware環境でよく使われるCPU ReadyやBallooningなども具体例として取り上げます。

仮想化環境の性能設計とは

仮想化環境では、ApplicationやGuest OSとPhysical Hardwareの間にHypervisorが存在します。Hypervisorは複数VMからの要求を物理CPU、メモリ、NIC、ストレージへ割り当てます。

仮想化環境で重要なのは、単純な仮想化オーバーヘッドだけではありません。複数VMが同じPhysical Resourceを共有することで、CPU、Memory、NIC、StorageなどでResource競合が発生します。競合が発生すると、Hypervisorや各I/O LayerでScheduling、Queue、Waitが生じ、最終的にApplicationのResponse Timeへ影響します。

vCPUとpCPU

VMへ割り当てるCPUは一般にvCPU（Virtual CPU）として表現されます。一方、Hypervisorが実際に処理を実行する物理CPU側の実行リソースは、VMwareなどではpCPUという表現が使われます。ここで重要なのは、vCPUとPhysical CPUのCore / Threadが1対1で固定的に対応しているとは限らないことです。

複数VMのvCPUがHypervisorを介してPhysical CPUを共有する構成

複数VMのvCPUはHypervisorのCPU SchedulerによってPhysical CPUへ割り当てられます。そのため、VMに4 vCPUを割り当てたからといって、4つのPhysical Coreが常にそのVM専用として確保されるわけではありません。複数VMが同時にCPUを要求すると、同じPhysical CPUを利用するためのSchedulingが必要になります。

CPU SchedulingとCPU Ready

仮想化環境では、Guest OS上のvCPUが実行可能な状態になっても、すぐにPhysical CPUで実行できるとは限りません。利用可能なpCPUがなければ、vCPUはHypervisorのSchedulerによる割り当てを待ちます。

VMware vSphereでは、このようにvCPUが実行可能であるにもかかわらず、pCPUへ割り当てられるまで待っている時間を確認する代表的な指標がCPU Readyです。esxtopでは%RDYとして確認できます。

CPU Readyが増えている場合、Guest OSのCPU使用率だけでは見えないHost側のCPU競合が発生している可能性があります。たとえば、同一Host上の複数VMが同時にCPUを要求している場合や、VMへ割り当てたvCPU数がHostのCPU Resourceに対して大きすぎる場合などです。

ただし、CPU Readyは単一の固定しきい値だけで正常・異常を判断しません。VMのvCPU数、計測間隔、Host CPU使用率、同居VMの負荷、ApplicationのResponse TimeやThroughputと同じ時系列で確認することが重要です。

Co-Stopとは

複数vCPUを持つVMでは、CPU Readyに加えてCo-Stopも確認します。VMware ESXiでは、複数vCPUを持つVMに対してRelaxed Co-Schedulingを行います。vCPU間の実行進捗が大きくずれた場合、進みすぎたvCPUを一時的に停止させて進捗を調整することがあります。Co-Stopは、このCo-Schedulingに伴う停止時間を把握する代表的な指標で、esxtopでは%CSTPとして確認できます。

Co-Stopが目立つ場合は、VMへ必要以上のvCPUを割り当てていないかを確認します。vCPU数を増やすほど常に性能が向上するわけではありません。Workloadの並列性、Host側のCPU競合、VMのvCPU SizingをCPU ReadyやApplication性能と合わせて確認します。

CPU ReadyとCo-Stopの違い

CPU ReadyとCo-Stopは、どちらもCPU Schedulingに関係する待ち時間ですが、意味は同じではありません。CPU Readyは「pCPUへ割り当てられるまでの待ち」、Co-Stopは「vCPU間の実行進捗を調整するための停止」として整理すると理解しやすくなります。

指標	何を表すか	主に確認すること
CPU Ready（%RDY）	vCPUが実行可能だが、pCPUへ割り当てられるまで待っている時間	Host CPU競合、Overcommit、同居VMの負荷、vCPU Sizing
Co-Stop（%CSTP）	Co-SchedulingによるvCPU間の進捗調整に伴う停止時間	vCPU Oversizing、SMP VMのScheduling、Host CPU競合

CPU Overcommit

仮想化では、物理CPUの実行リソース数より多くのvCPUをVMへ割り当てることがあります。すべてのVMが常にCPUを100%使用するわけではないため、ピークが重ならなければ物理CPUを効率よく共有できます。

Overcommit率だけを見て「何%までなら安全」と一律に決めることはできません。設計時にはピーク時のHost CPU、CPU Ready、Response Time、同時に高負荷となるVM、障害時の再配置まで確認します。

性能遅延が許容されないミッションクリティカルシステムにおいては、Overcommitしない設計とすることもあります。

vCPUを増やせば速くなるとは限らない

性能不足が発生するとVMへvCPUを追加したくなりますが、vCPUを増やせば必ず性能が向上するわけではありません。Applicationが十分に並列化できなければ追加したvCPUを活用できず、必要以上に大きなVMはSchedulingやNUMA配置を複雑にする可能性があります。

Reservation・Limit・Shares

VMwareではCPUやMemoryのResource制御として、Reservation、Limit、Sharesがあります。これらは物理Hostに余裕がある場合でもVMの性能へ影響するため、性能問題の切り分けで確認すべき項目です。

設定	意味	性能設計での注意点
Reservation	VMに対して確保するResource量	重要Workloadの最低Resourceを確保する用途。Cluster全体の予約量も考慮する
Limit	VMが利用できるResourceの上限	Hostに余裕があってもLimitを超えて利用できず、人工的なBottleneckになり得る
Shares	競合時の相対的な優先度	Resource競合が発生したときの配分に影響する

「HostのCPU使用率が低いからCPUには余裕がある」と判断する前に、VMやResource PoolにLimitなどの制約が設定されていないかを確認します。Memory Limitも同様に、Guest OSが認識している割り当てMemoryより小さい上限を設定すると、BallooningやVMkernel Swapなどにつながる場合があります。

NUMAとvNUMA

複数Socketを持つサーバでは、各CPU Socketの近くにMemoryが配置されるNUMA（Non-Uniform Memory Access）構成が一般的です。NUMAでは、CPUから見たMemoryの物理的な位置関係によってAccess Costが異なります。

同じNUMA Node内のMemoryへアクセスするLocal Accessに対し、別NodeへのRemote AccessではSocket間のInterconnectなどを経由するため、一般にMemory AccessのLatencyが高くなります。大規模VMではvCPUとMemoryが複数NUMA Nodeにまたがる可能性があるため、NUMAを意識した設計が重要です。

Hypervisorによっては物理NUMA構成を考慮してVMを配置し、Guest OSへ仮想的なNUMA topologyを提示するvNUMAの仕組みがあります。

大きなVMほどNUMA topologyを意識する

VMが1つのPhysical NUMA Nodeに収まる場合は、vCPUとMemoryを同一Nodeへ配置しやすく、Local Memory Accessを利用しやすくなります。一方、VMがNUMA Nodeの容量を超えて複数Nodeへまたがると、WorkloadによってはRemote Memory Accessの影響が大きくなる可能性があります。

vCPU数だけでなくMemory量、Physical NUMA NodeのCore数とMemory容量、Guest OSやApplicationのNUMA対応を合わせて確認します。また、CPU / Memory Hot Addなどの機能はVersionやVirtual Hardware構成によってvNUMAの見え方へ影響するため、大規模VMでは製品仕様を確認します。

Memoryの性能設計

仮想化環境のMemory設計では、各VMの割り当てMemoryだけでなく、Host全体で実際にどの程度Memoryを消費するかを確認します。Memoryも製品によってはOvercommitできますが、物理Memoryが不足した場合にはMemory Reclamationが必要になります。

Memory Overcommit

複数VMへ割り当てたMemoryの合計が物理Memoryを上回っていても、各VMが同時に全量を使用しなければ動作できる場合があります。しかし、ピークが重なってHost Memoryが逼迫するとHypervisorはMemoryを確保するための処理を行います。単純な割り当て比率だけで安全性を判断せず、HostのMemory消費、VMごとの実利用量、ピークの重なりを確認します。

Ballooning

VMware環境では、HostのMemoryが逼迫した際にMemoryを回収する仕組みの一つとしてBallooningがあります。Guest OS内のBalloon DriverがMemoryを確保することで、HypervisorがそのVMに割り当てていた物理Memoryを他の用途へ再利用できるようにします。

Ballooningが発生したこと自体だけで性能問題と断定するのではなく、Guest OS側でMemory不足やSwap、Page Cache縮小などが発生し、Application性能へ影響していないかを確認します。

Hypervisor Swap

VMware ESXiでは、Host Memoryの逼迫が進むとVMkernel Swapが発生する場合があります。VMのMemory PageがStorageへ退避されると、MemoryとStorageのAccess Latencyの差によってApplication性能へ大きな影響を与える可能性があります。Ballooningと合わせて、Guest OS側のSwapとVMkernel側のSwapを区別して確認します。

Storage I/Oの性能設計

仮想環境のStorage I/Oは、ApplicationからPhysical Storageまで複数のLayerを通過します。

Guest OSでI/O Latencyが高くても原因がGuest OS内部にあるとは限りません。同じDatastoreやStorageを共有する他VMのI/O、Hypervisor側のQueue、Storage Network、Physical Storageなど複数Layerを確認します。

VMware ESXiでは、後述するGAVG / KAVG / DAVGを確認することで、Guestから見たStorage I/OのLatencyをVMkernel側とDevice側に分け、どのLayerで待ち時間が発生しているかを切り分けやすくなります。

Thin ProvisioningとThick Provisioning

Virtual Diskでは、実際の利用量に応じて物理容量を消費するThin Provisioningと、作成時に仮想ディスクの全容量を確保するThick Provisioningがあります。VMwareではThick ProvisioningにLazy ZeroedとEager Zeroedがあります。

方式	作成時	Write時
Thin	仮想容量全体を物理的に事前確保しない	書き込みに応じて物理容量を消費
Thick Lazy Zeroed	全容量を確保	初めて書き込むBlockをZeroingしてからWrite
Thick Eager Zeroed	全容量を確保し、全領域をZeroing	Zeroing済みの領域へWrite

Lazy ZeroedとEager Zeroedの違いは、主にZeroingを行うタイミングです。Lazy Zeroedは初回Write対象のBlockをその時点でZeroingするのに対し、Eager ZeroedはVirtual Disk作成時に全領域をZeroingします。

Provisioning方式は性能だけでなく、容量効率、作成時間、Storage機能、運用方法、製品仕様を含めて選択します。「Thinなら遅い」「Thickなら必ず速い」と固定的に判断せず、利用するStorageとHypervisorの仕様、本番相当のI/O特性で確認します。

Storage I/Oも複数VMで共有する

同じDatastoreやPhysical Storageへ複数VMを配置すると、それぞれのI/Oが互いに影響する可能性があります。Storage性能はIOPS、Throughput、Latencyだけでなく、I/O Size、Read / Write比率、Random / Sequential、Queue Depth、他VMとの競合を合わせて評価します。

Network I/Oの性能設計

VMのNetwork通信もPhysical NICへ直接到達するとは限りません。一般的にはvNIC、Virtual Switch、Physical NICなどを経由します。

複数VMが同じPhysical NICを共有する場合、Host単位で帯域やPacket Rateに余裕があるかを確認します。またVM内部だけでなくVirtual SwitchやPhysical NICでDropやErrorが発生していないかも確認します。

Noisy Neighbor

仮想化環境では、自分のVMに大きな変更がなくても、同一Hostや共有Storage上の別VMの負荷によって性能が変化することがあります。このような共有環境における他Workloadからの影響はNoisy Neighborという考え方で説明されます。

VM単体のメトリクスだけでは原因が見えにくいため、Hostや共有Resource全体の時系列データを確認します。

仮想化環境のサイジング

仮想化環境のサイジングでは、個々のVMへ必要なResourceを割り当てるだけでは不十分です。HostやCluster全体で複数VMのピーク負荷、集約率、障害時の再配置まで考えます。ピーク時にもCPU、Memory、I/O、Networkを使い切らず、負荷変動やHost障害時の再配置を吸収できる性能余力を確保することが重要です。

障害・縮退時の性能設計

ClusterでHAを構成していても、「Host障害後にVMを起動できること」と「Host障害後も性能要件を満たせること」は別です。 可用性のために再起動先を確保するだけでなく、縮退後のCPU、Memory、Storage、Network負荷まで含めて性能を設計します。

1台のHostが停止すると残存HostへVMが再配置され、CPU、Memory、Storage、Networkの負荷が増える可能性があります。ClusterのサイジングではN+1などの障害条件を想定し、残存Hostだけで必要な処理能力を確保できるか確認します。

仮想化環境の性能試験

性能試験ではVM単体だけでなく、共有Resourceの競合が起こる条件を含めて確認します。

試験	確認すること
通常負荷	通常時のResponse Time、Throughput、Resource使用状況
ピーク負荷	CPU Ready、Co-Stop、Memory、I/O、Networkが飽和しないか
競合試験	複数VMが同時に高負荷となった場合の影響
Storage負荷	共有StorageでLatencyやQueueが増加しないか
Host障害	残存Hostへ集約後も性能要件を満たせるか
Migration	VM移動時にApplication性能へ許容できない影響がないか

試験中はApplicationのResponse TimeやThroughputと同時に、VM、Hypervisor、Physical Hostのメトリクスを同じ時系列で取得します。

仮想化環境のボトルネックを確認する

VM上のApplicationが遅い場合、Guest OSだけを確認して原因を決めつけないことが重要です。

Resource	VM側	Hypervisor / Host側
CPU	CPU使用率、Load	Host CPU、CPU Ready、Co-Stop、vCPU競合、Limit
Memory	使用量、Swap	Host Memory、Ballooning、Memory Reclamation
Storage	I/O、await、Queue	Datastore / Storage Latency、共有I/O負荷
Network	Throughput、Drop、TCP	vSwitch、Physical NIC、共有帯域

esxtopで仮想化Layerを観測する

Guest OSのtop、vmstat、iostatだけでは、Hypervisor側のSchedulingやResource競合を直接確認できません。VMware ESXiでは、esxtopやvSphere Performance Chartを使ってVMとHostの状態を確認します。

Resource	代表的な指標	見るポイント
CPU	%USED	VM / HostがCPUをどの程度使用しているか
CPU	%RDY	vCPUが実行可能なのにpCPUへの割り当てを待っていないか
CPU	%CSTP	Co-SchedulingによるvCPU間の進捗調整に伴う停止が増えていないか
Memory	Active / Consumed	実際のMemory需要と割り当て量が適切か
Memory	Balloon	Memory Reclamationが発生していないか
Memory	Swap	Hypervisor側Swapが発生していないか
NUMA	Locality	Remote Memory Accessが増えていないか
Storage	GAVG / KAVG / DAVG	Guest視点のLatencyをKernel側・Device側に分けて、どこでI/Oが待っているか
Network	Throughput / %DRPTX / %DRPRX	vNICからPhysical NICまでで帯域競合やPacket Dropがないか

重要なのは単一のしきい値だけで判断することではなく、ApplicationのResponse TimeやThroughputが悪化した時刻と、CPU Ready、Co-Stop、Memory、Storage Latencyなどの変化を対応付けることです。

GAVG・KAVG・DAVGでStorage I/Oの遅延箇所を切り分ける

esxtopでStorage I/OのLatencyを確認する際は、GAVG、KAVG、DAVGの違いを理解しておくことが重要です。

これらはすべてI/O Latencyに関する指標ですが、観測している範囲が異なります。GAVGだけを見るのではなく、KAVGとDAVGに分けて確認することで、ESXi側で待っているのか、Storage側で時間がかかっているのかを切り分けやすくなります。

指標	意味	主に確認する箇所
GAVG	Guestから見たI/O全体の平均Latency	Storage I/O全体
KAVG	VMkernel内で発生する平均Latency	ESXiのStorage Stack、Queue
DAVG	Device側で発生する平均Latency	HBA、SAN / iSCSI、Physical Storageなど

基本的な関係は、次のように整理できます。

GAVG = KAVG + DAVG

たとえばGAVGが大きい場合でも、原因がPhysical Storageにあるとは限りません。KAVGが大きければESXi側のQueueやStorage Stack、DAVGが大きければStorage DeviceやStorage Network側を中心に確認します。

特にKAVGでは、VMkernel内部でI/OがQueueされていないかを確認することが重要です。一方、DAVGが増加している場合は、Physical Storageだけでなく、HBA、FC / iSCSIなどStorageまでのI/O Pathも調査対象になります。

したがってStorage性能問題では、「Storageが遅い」とすぐに判断するのではなく、GAVGをKAVGとDAVGに分解して、どのLayerでLatencyが発生しているかを確認することが重要です。

また、GAVG、KAVG、DAVGはいずれも平均値であるため、単一の固定しきい値だけで正常・異常を判断するのではなく、ApplicationのResponse Time、IOPS、Throughput、Queue Depth、I/O Size、Read / Write比率などと同じ時系列で確認します。

物理Hostの設定で確認すること

仮想化基盤ではHardware Virtualizationなど、Hypervisorが必要とするCPU機能を利用できる状態にします。CPUのSMT / Hyper-Threading、Turbo機能、Power Managementなどは、サーバ機種、CPU、Hypervisor、性能要件、消費電力要件によって適切な設定が異なります。

そのため、「Hyper-Threadingなら必ず一定割合高速化する」「Power Managementは必ず無効にする」といった固定的なルールではなく、利用するHypervisorとHardware Vendorの推奨構成を確認し、本番相当のWorkloadで性能を測定します。

まとめ

仮想化環境の性能設計で重要なのは、VMへResourceを割り当てることだけではありません。Physical Resourceを複数VMで共有した結果、どこで競合・Scheduling・Queue・Waitが発生するかを理解することが重要です。

vCPU：VMに見えるCPUとPhysical CPUは同じではなく、HypervisorがSchedulingする。
CPU Ready / Co-Stop：pCPUへの割り当て待ちと、vCPU間の実行進捗調整に伴う停止を分けて確認する。
Overcommit：固定比率だけで判断せず、実際の競合と性能を確認する。
vCPU Sizing：vCPUを増やせば必ず速くなるわけではない。
Reservation / Limit / Shares：Hostに余裕があってもResource制御がVMの性能を制限する場合がある。
NUMA：大規模VMではCPUとMemoryの物理配置、vNUMA、Localityも性能へ影響する。
Memory：Host Memory逼迫時のBallooningやSwapなどを確認する。
Storage：VMからPhysical Storageまでの複数Layerと共有I/Oを確認し、GAVG / KAVG / DAVGでVMkernel側とDevice側のLatencyを切り分ける。
Network：vNIC、Virtual Switch、Physical NICの共有と競合を見る。
Noisy Neighbor：同一Hostや共有Storage上の他VMから影響を受けることがある。
縮退時：HAできることと、HA後も性能要件を満たせることは別である。
Observability：esxtopやPerformance Chartで%RDY、%CSTP、Memory、NUMA、I/Oを観測する。
Troubleshooting：Guest OSだけでなくHypervisorとPhysical Hostまで確認する。

ApplicationのResponse TimeやThroughputと、VM・Hypervisor・Physical HostのResource状態を同じ時系列で観測し、共有Resource上で発生している「待ち」を特定することが、性能設計とトラブルシューティングの基本になります。

参考資料

仮想化製品のScheduler、Memory管理、NUMA、Storage、Networkの実装や推奨設定は、製品・Version・Hardwareによって異なります。実際の設計・変更時は、利用しているHypervisorおよびHardware Vendorの公式ドキュメントを確認してください。

VMware / Broadcom：vSphere Performance Best Practices
VMware / Broadcom：vSphere Resource Management
VMware / Broadcom：vSphere Monitoring and Performance
Broadcom KB 438023：Rightsizing virtual machines on ESXi 8.0: vCPU, memory, and CPU topology guidance
Broadcom KB 326270：Impact of virtual machine memory and CPU resource limits
Red Hat：Virtualization performance and optimization guidance

【図解】仮想化環境のパフォーマンス設計・分析｜VMware・CPU Ready・NUMA・esxtop