仮想化基盤の選定 — 商用製品で固めるかKVM系で組むか

仮想化基盤の選定で最も多い失敗は、製品名から議論を始めてしまうことだ。VMwareかProxmoxか、あるいはHCI（ハイパーコンバージドインフラ）かという問いの前に、サービスレベル・障害ドメインの許容範囲・運用体制の現実を固めなければならない。商用製品が真に必要な条件は想定より狭く、OSSベースのKVM系で回せる環境も多い。本稿では判断を誤りやすいポイントを先に示しながら、選定軸を具体的に整理する。

製品を先に決めてから要件が合わず組み直す構造

逆順選定が生む再設計コスト

構築を任された担当者がまず製品ベンダーのカタログを開くのは珍しいことではない。問題は、その段階でまだ「どの程度の集約率を想定するか」「ストレージはどう共有するか」「HA（高可用性）の範囲をどこまでとるか」が固まっていないことだ。製品の機能に合わせて要件を後付けで書き直す場面が現場では頻繁に起きており、設計変更が2〜3回に及ぶケースも珍しくない。

さらに深刻なのは、製品選定後に発覚したストレージ要件の不一致や、ライセンス形態とVM台数上限の食い違いが、追加費用や工期延長という形で跳ね返ってくることだ。物理サーバー50台規模の集約案件で、ストレージの共有方式をあとから変更したために追加設計だけで3週間を要した事例もある。選定の順序を誤ると、技術的な問題ではなくプロセス上の問題がプロジェクト全体を圧迫する。

要件定義が後回しになりやすい背景

仮想化基盤の要件定義が後回しになる構造的な理由のひとつは、「まず動くものを見せたい」というプロジェクトの力学だ。POC（概念実証）を先行させてステークホルダーの承認を取りに行く進め方は合理的に見えるが、POCで選んだ製品がそのまま本番設計の前提になりがちで、設計の自由度を早期に失う。もうひとつの背景は、担当者の技術的な専門性が特定製品のエコシステムに偏っていることだ。VMwareに精通した担当者がいれば選定が自然とvSphereに傾くし、Linuxの知識を持つメンバーが主導すればKVMやProxmoxが候補に上がる。この傾きを補正するには、選定基準を先に文書化してから各製品を当てはめるという順序が有効だ。

先に確定すべき3つの設計前提

製品選定の前に固めておくべき前提は3点ある。第一は「障害ドメインの許容範囲」——物理ホスト1台が落ちたときに影響を受けてよいVMの最大数とサービスへの影響度合いを明確にする。第二は「運用体制と保守力」——夜間・休日の障害対応を社内で行うか、ベンダーサポートに委ねるか。第三は「拡張の方向性」——水平にノードを増やしていくスケールアウト型か、より高スペックのノードに集約するスケールアップ型か。この3点が定まれば、商用製品とOSSの選択肢はかなり絞り込まれる。

商用サポートが要る条件とOSS基盤で回せる条件の判断

商用製品が真に必要になる条件

商用仮想化製品——VMware vSphere/vSAN、Microsoft Hyper-V（Windows Server付帯）、Nutanix AOSなど——を選ぶべき場面は、次のいずれかが当てはまるときだ。まず、社内にLinuxカーネルレベルのトラブル対応ができる担当者がおらず、かつ障害時の窓口一本化が求められる場合。次に、コンプライアンス要件やセキュリティ監査の対象となり、サポート契約とパッチ適用の記録が審査で要求される環境。さらに、既存のVMware環境からの移行でvMotionの連続性やvSANのデータパスを維持することが優先される場合だ。

商用製品のサポートは「問題が起きたときに電話できる安心感」だけではなく、パッチ情報の優先提供・互換性マトリクスの管理・ハードウェアHCL（ハードウェア互換性リスト）の保証という形で設計の下支えになる。ハードウェアを100台規模で調達する案件では、HCLに載っていない機器を使ったときのサポート打ち切りリスクが設計品質に直接影響する。

OSS基盤で十分に回せる条件

一方、OSS系——Proxmox VE、KVM+libvirt、OpenStack（小規模プライベートクラウド）——で十分に機能する条件は以下だ。インハウスにLinuxの深い知識を持つエンジニアが複数名いること、障害対応をコミュニティドキュメントとソースコード調査で解決できる文化があること、そして本番環境のVMが数十台以内で設計の複雑さが限定されていることだ。

Proxmox VEは特に中小規模——物理ノード3〜8台、VM 50〜200台程度——で実績が積み上がっており、Corosync/Pacemakerベースのクラスタ機能・Ceph統合・スナップショット・バックアップが標準で使える。Proxmox移行後の運用工数が前のvSphere環境比で約4割減ったという話を現場でよく聞く。ただし、これはチームの技術スタックとの親和性が前提条件であり、その点を抜きに「コストが安い」という理由だけで選ぶと、運用フェーズで行き詰まる。

判断を分けるチームの保守力

商用とOSSの境界は「製品の機能差」よりも「チームの保守力」で引くほうが現実的だ。OSSを選んだ場合、バグや脆弱性への対応は自組織が主体になる。KSM（Kernel Samepage Merging）の設定・CPUピンニングの最適化・NUMAトポロジへの対応など、パフォーマンスに影響する設定の判断は担当者の知識に依存する。商用製品ではベンダーがこれらの推奨値をドキュメント化しているが、OSS環境では自力でチューニングの根拠を積み上げる必要がある。

商用仮想化基盤・OSS系・HCIアプライアンスの比較

選定軸で見る比較表

以下の比較表は代表的な仮想化基盤の選定軸を整理したものだ。各項目は「機能の優劣」ではなく「どの条件で優位になるか」という観点でまとめている。

項目	商用仮想化（vSphere / Hyper-V）	OSS系（Proxmox / KVM）	HCIアプライアンス（Nutanix等）
サポート窓口	ベンダー一本化・SLA明確	コミュニティ＋有償サポートの組み合わせ	ベンダー一本化・ハードも含む
ライセンス形態	コアまたはCPU単位・VM数上限あり	基本無償・有償サポートは任意	ノード単位・ハードウェア込み
共有ストレージ	vSAN / SMBダイレクト / 外部SAN	Ceph / NFS / iSCSI（要別途設計）	分散ストレージ内蔵（追加設計は最小）
ライブマイグレーション	vMotion / Live Migration（製品標準）	KVM live migration（共有ストレージ必要）	標準搭載・ノード間自動バランス
運用スキル要件	製品固有GUI / CLIへの習熟	Linuxカーネル知識・CLI操作が必須	アプライアンス操作中心・導入障壁低
拡張性	ライセンス追加コストが発生	ノード追加でスケールアウト可	ノード単位で拡張・最小3ノード構成
障害ドメイン制御	DRS / アフィニティルールで詳細制御	CPUピンニング・NUMAトポロジ設定	アプライアンス側ポリシーで管理
適合規模感	中〜大規模（50台以上が費用対効果高）	小〜中規模（3〜30ノード）	3ノード以上・追加設計を最小化したい環境

比較表の読み方と典型的な誤解

この表で最も誤解されやすいのは「HCIアプライアンスは設計が不要」という受け取り方だ。ハードウェアと分散ストレージが一体になっているため初期構成の手間は確かに少ないが、ノード間のネットワーク帯域・フォールトトレランスドメイン・レプリカ数の設定は依然として設計判断が必要だ。「アプライアンスだから任せておけば動く」という前提で進めると、ノード障害時の縮退動作や性能劣化の想定が抜け落ちる。HCIを選ぶ主な理由は「設計の省力化」ではなく「ストレージとコンピュートを一体で調達・保守したい」という運用体制上の判断だと捉えるほうが正確だ。

集約率とオーバーコミットをどこまで許すか

CPUとメモリのオーバーコミット設計

仮想化基盤の設計で見落とされやすいのが、オーバーコミット（物理リソースを超えた仮想リソースの割り当て）の上限設定だ。CPUについては物理コア1つに対してvCPUを4〜8程度割り当てることが一般的な目安だが、これはワークロードの性質に大きく依存する。バッチ処理や深夜に集中するジョブが混在する環境では10を超えることもある。一方、リアルタイム性が求められるデータベースVMや決済処理に近いVMがある場合は、オーバーコミット比を1:2程度に抑えなければ応答時間の悪化が表面化する。

メモリについては、KSM（Kernel Samepage Merging）やバルーンドライバーを活用すれば物理メモリを超えた割り当てが一見機能するが、スワップが発動した瞬間にVM全体の性能が急落する。設計上の上限として物理メモリの80〜90%を稼働VMに割り当て、残りをハイパーバイザーのバッファとして確保する原則を守ることが、運用フェーズでの予期せぬ性能劣化を防ぐ。この余剰を「もったいない」と詰め込んだ環境ほど、ピーク時に予測不能な性能劣化を起こしやすい。

集約率設計の現実的な上限

集約率——1台の物理サーバーに乗せるVMの数——は「技術的に乗せられる限界」と「運用上の適切な上限」を分けて考える必要がある。物理メモリ512GBのホストに4GBのVMを128台乗せることは計算上できるが、ホスト障害時の縮退やメンテナンス時のライブマイグレーションコストを考えると、実際には60〜80台程度を上限にして余剰を持たせる設計が現場では機能しやすい。

特にHAクラスターを構成する場合、ノード数とHA用リザーブの計算が重要になる。3ノード構成でHA用リザーブを1ノード分とると、稼働リソースは実質2ノード分しか使えない。設計段階でこの点を見落とし、3ノード分のリソースをすべて見込んでVM配置計画を立てた現場が追加ノードの購入を余儀なくされた事例がある。「クラスターを組めばHAになる」という認識と「HAリザーブを考慮したリソース計画」は、全く別の話だ。

ライブマイグレーションと共有ストレージ要件の詰め方

ライブマイグレーションが成立する前提条件

ライブマイグレーション（vMotionやKVM live migration）を前提にした設計では、「ストレージが共有されているか」という条件が先に来る。KVM環境でライブマイグレーションを行う場合、ゲストのディスクイメージが移行元・移行先の双方からアクセスできる共有ストレージ上に存在しなければならない。NASのNFS共有、iSCSI LUN、あるいはCephなどの分散ストレージがこれに当たる。ローカルストレージだけでKVM環境を構成したあとにライブマイグレーションが動かないことに気づき、後から共有ストレージを追加構成した事例は少なくない。

強調したいのは「ライブマイグレーションを設計に含めるかどうかは、ストレージアーキテクチャの選択と同時に決める」という順序だ。この2つを別々のフェーズで決めると、ストレージ設計が固まった後にライブマイグレーション要件が追加されて設計の大幅な見直しが発生する。実際の手順はセミナーや詳細実装で確認するとして、設計段階ではこの依存関係を先に押さえておくことが肝要だ。

共有ストレージ選定の判断軸

共有ストレージの選定では、性能・耐障害性・管理コストのトレードオフが中心になる。Cephは分散ストレージとしての冗長性が高く、ノード追加によるスケールアウトが可能だが、初期の設計・チューニングが複雑でネットワーク帯域（推奨は10GbE以上）への依存度が高い。NFSv4.1以降は構成がシンプルで既存の運用知識を流用しやすいが、NFSサーバー自体がSPOF（単一障害点）にならないようHA構成が別途必要だ。iSCSIはブロックレベルのアクセスで性能を出しやすいが、マルチパスの設計とゾーニング管理が増える。

判断の出発点は「どの程度の書き込み性能が必要か」と「チームがどの技術を運用できるか」の2軸だ。小規模なProxmox環境であれば、まずNFSで始めてボトルネックが見えたらCephに移行するという段階的なアプローチが現実的だ。最初からCephの全機能を使いこなそうとして設計が複雑化し、本番稼働が3ヶ月以上遅延したという話を現場でよく聞く。

集約を詰めすぎて1台の障害が全体に及ぶ境界

障害ドメインの設計という発想

集約率を高めることは物理コストの削減につながるが、同時に「1台の物理ホストが障害を起こしたときの影響範囲」が拡大する。これを「障害ドメイン」として明示的に設計しておくと整理しやすい。障害ドメインの設計とは、どのサービスグループを同じ物理ホスト上に乗せてよいか、あるいは分離しなければならないかを意識的に決めることだ。

典型的なアンチパターンは、WebサーバーとDBサーバーとキャッシュ層のVMが同一物理ホストに集約されているケースだ。ホスト障害が発生すると三層すべてが同時に落ちる。VMware DRSのアンチアフィニティルールやProxmoxのHA設定では、特定のVMを同じホストに配置しないよう制御できるが、この設定が抜け落ちていた環境では本番障害の影響範囲が当初想定の5倍以上に及んだという事例がある。ルール設定を「あとでやる」と後回しにしたまま本番を迎えるケースが現場では多い。

集約上限の引き方と縮退設計

集約上限を引く基準として有効なのは「1台の障害でサービスに出てよい影響の最大値」から逆算する方法だ。たとえば「同時に影響を受けてよいVMは全体の30%以内」という基準を設けた場合、HAクラスターの最小ノード数と1ノードあたりの最大VM数が決まる。5ノードクラスターでHA用リザーブを1ノード分とした場合、稼働4ノードのうち1台が落ちても残り3ノードに全VMを収容できるよう、1ノードあたりの集約数に上限を設けることになる。

縮退時の性能低下を想定した設計も重要だ。N台構成でN-1台稼働になったとき、全VMが許容性能の80%以上を維持できるか、それとも一部VMを停止する優先順位付けが必要かを事前に決めておく。この判断を障害発生後に初めて議論する現場では対応が後手に回りやすく、復旧時間が長引く。縮退シナリオの文書化は運用手順書ではなく設計書に含めるべき内容だ。

仮想化基盤設計チェックフレーム

設計着手前に確認すべき判断軸チェックリスト

以下のチェックリストは製品選定・設計着手の前に確認しておくべき判断軸をまとめたものだ。すべての項目に答えが出た状態で製品選定に入ることで、後戻りリスクを大幅に下げられる。

1. ワークロードの消費特性の把握: 対象ワークロードのCPU・メモリのピーク消費量と平均消費量を把握しているか。バースト時の最大消費がオーバーコミット設計の基準になる。
2. 障害許容範囲の定義: 物理ホスト1台が完全停止したときに許容できるサービス停止時間（RTO）とデータ損失範囲（RPO）は定義されているか。
3. HAとFTの必要範囲: HA（フェイルオーバー）で十分か、FT（フォールトトレランス・ノーダウンタイム）が必要なVMは存在するか。FTを使う場合、物理リソースが実質2倍必要になる点を設計に含めているか。
4. ストレージ共有方式の確定: ライブマイグレーションを前提にしているか。前提にする場合、共有ストレージの方式（Ceph / NFS / iSCSI / SAN）と性能要件は確定しているか。
5. ネットワーク分離の設計: ライブマイグレーション用・ストレージトラフィック用・VMトラフィック用のネットワークを物理または論理で分離しているか。
6. チームの保守力の確認: 選定した製品のトラブル対応を社内で完結できるスキルセットがあるか。OSSを選ぶ場合、カーネルパラメータ調整・コミュニティ情報の読解を担当できるエンジニアがいるか。
7. 拡張計画との整合: 3年後のVM台数・ワークロード増加を見越したノード追加計画と、そのときのライセンスコスト・スキル要件の変化を試算しているか。
8. 集約率と縮退設計の整合: 1ノードあたりの最大VM数の上限を決め、N-1台での縮退時に全サービスを維持できるリソース余剰を確保しているか。
9. 障害ドメインの分離設定: 同一サービス内の複数VM（Web / DB / Cache等）が同じ物理ホストに集約されないよう、アフィニティルール等で制御しているか。
10. バックアップとリストアの検証計画: バックアップの取得方式と、リストアに要する時間（実測値）を設計段階で確認しているか。「バックアップが取れている」と「リストアが機能する」は別の問いだ。

設計フェーズと判断の優先順位

このチェックリストは一度に全項目を埋めようとするより、フェーズに分けて確認する使い方が現実的だ。要件定義フェーズでは1〜3番（ワークロード特性・障害許容・HA範囲）、基本設計フェーズでは4〜6番（ストレージ・ネットワーク・保守力）、詳細設計フェーズでは7〜10番（拡張計画・集約上限・障害ドメイン・バックアップ）に対応する。設計フェーズをまたいで判断が変わった場合は、下位フェーズで確定した項目に遡及影響がないかを必ず確認する。

仮想化基盤の設計は「どの製品が優れているか」ではなく「この環境でどこに線を引くか」の連続だ。製品選定は線を引いた結果として導かれるものであり、製品から入るとその逆になる。設計の順序を正しく保つことが、後工程での手戻りを最小化する最も確実な方法だ。