Virt 屋のひとりごと : CPUとメモリのオーバーコミット

※本記事は OpenShift Virtualization アドベントカレンダーの 6日目の記事です。

皆さんこんにちは、OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。

万物は有限です。数字や時間のような概念的な一部の例外を除けば、大抵のものには限りがあります。石油だってお金だって、ミミズやオケラやうつぼの命だって限りがあります。そんな限りある資源をうまく使うことが私たち生を受けている者に与えられた使命なのです。

ということで今日のテーマはオーバーコミットです。

オーバーコミットの概念とリスク
- そもそもオーバーコミットとは
CPUのオーバーコミット
メモリのオーバーコミット
- 安定運用のためのメモリ設定
まとめ

オーバーコミットの概念とリスク

Red Hat OpenShift Virtualization の環境を最大限に活用し、安定性、パフォーマンス、そしてリソース効率のバランスを取るためには、リソースのオーバーコミットの理解が不可欠です。
本稿では特に CPU とメモリという二大リソースに焦点を当てて、それぞれのオーバーコミットに対する推奨、技術的な背景、および具体的な設定方法について詳細に解説します。

そもそもオーバーコミットとは

オーバーコミット（Overcommit）とは、物理サーバー（=Compute ノード）が持つ実際のハードウェアリソース量（CPUコア数、物理メモリ容量など）よりも、そのノード上で稼働する全てのワークロード（VMやコンテナ）に割り当てられたリソースの要求総量が上回っている状態を指します。

メリット：

リソース利用効率の向上： ワークロードが常にリソースを全開で使うわけではないという前提に基づき、浮いている状態のリソースを他のワークロードに再割り当てすることで、物理ハードウェアの稼働率を高めます。
コスト削減： 少ない物理サーバーでより多くのワークロードを稼働できるため、インフラコスト（ハードウェア、電力、設置場所）を削減できます。

リスク：

パフォーマンスの低下： すべてのワークロードが同時に割り当てられたリソースを要求した場合、リソースの取り合いが発生し、処理の遅延やスループットの低下を招きます（競合）。
システム不安定化： 特にメモリのオーバーコミットが過度になると、最悪の場合ノード全体の不安定化やサービス停止に繋がります。

CPUのオーバーコミット

CPU のオーバーコミットは、OpenShift Virtualization 環境において一般的に推奨・使われることが多いプラクティスです。その理由は、仮想マシンに割り当てられる仮想 CPU（vCPU）の性質にあります。

CPU オーバーコミットの特徴

多くの VM ワークロード、特に Web サーバー、開発・テスト環境、一部のデータベースなどでは、割り当てられた vCPU を常に 100% 使い切ることはまずありません。
つまり vCPU はアイドル状態にある時間が多いため、物理コアに対して複数の vCPUを「多重化」して割り当てることで、物理ハードウェアのアイドル時間を最小限に抑え、リソース効率を飛躍的に向上させることができます。
最悪、タイミング悪くワークロードが高騰して CPU の競合が起きても、パフォーマンスの低下で済みます。サービスが止まるまでの影響はないことが多いでしょう。

クラスターレベルでのオーバーコミット率の設定：`vmiCPUAllocationRatio`

OpenShift Virtualizationでは、クラスター全体に対するデフォルトの CPU オーバーコミット比率を、HyperConverged カスタムリソース（CR）で定義できます。

パラメータ	説明	デフォルト値	意味
`vmiCPUAllocationRatio`	ノード上の物理 CPU コアに対する vCPU の割り当て比率。	10	物理コア1つあたり最大10個のvCPUを割り当て可能（10:1）。

このデフォルト値の "10" という値は、VMware をご存知の方は「高すぎるのでは？」と思うでしょう。何を隠そう私もそう思います。
しかしデフォルトがこうなっているということは、「一般的な VM ワークロードって普通 CPU 使用率は 10% くらいでしょ？だったらこの値で OK じゃないの？」という KubeVirt コミュニティからのメッセージを感じますね。
確かに理論的にはそうかもしれないけど、でもこれって、「物理サーバーのコストを減らしたい！たとえ競合になってサービス品質を多少落としたとしても！」という覚悟が必要ですよね。

だから個人的にはリソース効率の追求より安全をみて、少なくとも設計段階では 1:1 ～ 4:1 くらいで見ておくのが手堅い んじゃないかと思います。

VM 単位で詳細設定：`requests`と`limits` の活用

Kubernetes の基本的なリソース管理の仕組みである requests と limits は、VM の実体のリソース定義である VirtualMachineInstance (VMI) でも利用されます。
CPU オーバーコミットの本質は、この 2 つの値を意図的に離すことで実現します。

requests.cpu (要求値)： VM がスケジューリングされ、安定稼働するために最低限保証される CPU リソース量。VM をノードにスケジュールする際の判断基準となり、この値に基づいたリソースがノード上に確保されます。
limits.cpu (制限値)： VMが最大で利用できるCPUリソースの上限。VM が CPU を過剰に使いすぎることを防ぎ、ノード上の他のワークロードへの影響を抑制するために機能します。

オーバーコミットを実現する設定例 (Burstable QoS):

spec:
  domain:
    cpu:
      cores: 4 # vCPUの総数
    resources:
      requests:
        cpu: "1" # 1 vCPU 分は保証する
      limits:
        cpu: "4" # 最大4 vCPU 分まで利用を許可

この例では、VM は常に 1 vCPU 分は保証されながらも、ノードの CPU に余裕がある場合には割り当てられた vCPU 数（4コア）まで利用することが可能になり、効率的なオーバーコミットを実現します。
ユースケースごとにオーバーコミット率を変える運用をしたい場合は、このように設定していきましょう。

メモリのオーバーコミット

結論から言うと、メモリのオーバーコミットは、Red Hat OpenShift Virtualization 環境において 強く推奨されません。これは、メモリと CPU の性質が根本的に異なるためです。

非圧縮性・非共有性： CPU時間（処理能力）は分割して共有できますが、メモリは一度 VM に割り当てられてしまえば、VM が使用していなくてもホスト側から他のプロセスに割り当てることが困難です。
競合時のインパクト：ノード上でプロビジョニングされたメモリ総量が物理メモリ容量を超えて、実際に VM が必要とするメモリが不足した場合、ノードの RHCOS は次のような問題を引き起こします。
- スワッピングの発生：ホスト OS がディスクへの swapping を開始して I/O latency が劇的に増加し、ノード全体のパフォーマンスが低下します。
- OOM Killerの起動：Out Of Memory (OOM) Killer が出動してメモリを大量に消費しているプロセス（VM を実行している QEMU プロセスなど）を強制終了し、VM が停止します。

安定運用のためのメモリ設定

安定したパフォーマンスと信頼性の高い運用を確保するためには、メモリの割り当てには以下の原則に則ることを推奨します。

requests.memory = limits.memory：メモリの requests と limits は常に同じ値を設定し、VM に対して必要なメモリ量を完全に予約（Guaranteed QoS）します。
物理容量の管理：ノードに割り当てられる全ての VM（および、ノード上で稼働するコンテナや OpenShift コンポーネント）の requests.memory の合計が、そのノードの物理メモリ容量を超えないように容量計画とスケジューリング管理を行います。

メモリの推奨設定例 (Guaranteed QoS):

spec:
  domain:
    memory:
      guest: 4Gi # VMが認識するメモリ量
    resources:
      requests:
        memory: 4Gi # 4GiBを完全に保証・予約する
      limits:
        memory: 4Gi # 最大量も4GiBに設定（requestsと同じ）

これにより、VM の起動時に必要なメモリが確実に予約され、VM が他のワークロードからのメモリ競合によって性能低下や停止に見舞われるリスクが排除されます。

まとめ

OpenShift Virtualization を最適に運用するためのリソースオーバーコミット戦略は、以下の表に集約されます。

リソース	オーバーコミット推奨度	制御パラメータ	推奨される戦略	QoS (Quality of Service)
CPU	推奨	`vmiCPUAllocationRatio` と VM ごとの `requests` と `limits`	`requests` <= `limits`とし、ノードに余裕があるときにバースト利用を可能にすることで、リソース効率を最大化する。	Burstable
メモリ	強く非推奨	VM ごとの `requests` と `limits`	`requests` = `limits` とし、VMに必要な全メモリを保証することで、システムの安定性を最優先する。	Guaranteed

OpenShift Virtualizationは、コンテナとVMを統合する強力なプラットフォームですが、その力を最大限に引き出すためには、CPUとメモリの特性を理解し、異なるオーバーコミット戦略を適用することが重要です。
ワークロードの特性（I/O集中型か、CPU集中型か、レイテンシ要求レベルなど）を詳細に分析し、適切に設計・設定することで、高いリソース効率と安定性の両立が可能となります。

ということで今日はここまで。