ライセンス改定と保守費用の見直しをきっかけに、仮想化基盤の再検討に着手する企業が増えています。話題として大きいのは事実ですが、現場の反応は一様ではありません。
よく耳にするのは、次のようなパターンです。
更新時期が 1〜2 年後に迫っており、次の 5 年をどう設計するかで悩んでいる
保守費用が想定より跳ね上がり、予算稟議のロジックを組み直す必要が出た
経営層から「クラウドへ寄せられないか」と再度問われ、オンプレ縮退の圧力が強まった
いずれのケースでも、情シスの本音は「性急に決めたくない」というものです。仮想化基盤は、業務システムのほぼすべてが乗る土台にあたります。値上げのニュースを起点に短期間で置き換えを決めると、後工程 ( バックアップ、監視、DR、運用手順 ) の作り直しがボディーブローのように効いてきます。
まずは焦らず、状況を整理するところから始めた方が結果的に早い、というのが実務の感覚です。
代替検討は、どうしても「ハイパーバイザーを何に替えるか」という話に閉じがちです。ただ、実際に手を動かすとわかりますが、仮想化基盤は次のような広い範囲と結びついています。
サーバー・ストレージ・ネットワークの構成
バックアップ・DR の仕組みと運用
監視、ジョブ管理、構成管理などの運用ツール
運用手順書・トラブルシューティングのナレッジ
情シスと運用委託先のスキルセット
つまり、ハイパーバイザーを差し替えるという意思決定は、周辺の運用資産をどこまで作り替えるかという意思決定でもあります。この視点を持たずに製品比較に入ると、「機能的には要件を満たすが、うちの運用体制では回せない」という結論に、PoC の後半で気づくことになりがちです。
上位から俯瞰する視点は、面倒でも最初に一度、押さえておいた方が安全です。
判断のフレームとして、次の 4 つを先に固めることを勧めます。
VM 数、リソース使用率、ホスト間の依存関係、外部システムとの連携。棚卸しが甘いと、代替製品の要件定義そのものが崩れます。
ライセンス費用だけで判断すると、移行費用・並行稼働費用・教育費用・運用ツール改修費用が抜けます。3〜5 年の TCO で見ないと、乗り換えた方が高くつくケースも実在します。
クラウド比率をどこまで上げるのか、拠点統廃合の計画はあるのか。中期戦略と切り離して基盤だけ決めると、翌年に別の見直しが必要になります。
新しい基盤の学習コストを、誰が、いつ吸収するのか。ここが空白のまま製品選定を進めると、導入後の運用が特定担当者に張り付きます。
この 4 つが曖昧なまま製品比較に入ると、意思決定の場で必ず揉めます。逆に、ここが揃っていれば、どの製品が選ばれても大きく外しません。
選択肢は「他のハイパーバイザーへの移行」だけではありません。まず全体像を並べます。
更新時期まで数年ある場合、あるいは移行コストが削減効果を上回る場合、当面継続するのは合理的な判断です。並行して、VM 数の削減・統合による費用圧縮も検討できます。
代表的な候補と特徴を、極力フラットに整理します。
HCI としての実績が厚い一方、既存 3-Tier 資産の活用可否や、ハードウェア構成の柔軟性は要確認
ライセンスコストを抑えやすい反面、国内でのサポート体制や運用ノウハウの蓄積は自社側の見極めが必要
Windows 中心の環境と親和性が高いが、Linux 資産中心の環境では設計思想の見直しが要る
コンテナと VM を同じ基盤で扱いたい場合に選択肢となるが、運用スキルの前提が高い
HPE ハードウェアとの親和性、および Morpheus によるマルチクラウド／マルチハイパーバイザー管理への拡張性が特徴。既存 HPE 環境を活かしつつ、将来的にクラウドを含めた統合管理へ広げたい場合の候補となります。ただし、国内での事例蓄積は今まさに増えている段階のため、周辺エコシステム ( 対応するバックアップ製品や監視製品など ) は自社要件と照らして個別確認が必要です
仮想化基盤の刷新を機に、パブリッククラウドへ寄せる判断もあります。ただし、これは「ハイパーバイザーの選び直し」とは別種の意思決定です。
どれが正解かは、前章の 4 つの前提次第で変わります。「最も語られている選択肢」が「自社にとって最良の選択肢」とは限らない、という点だけは意識しておきたいところです。
製品比較の議論は盛り上がる一方で、次のような論点は会議の場で抜け落ちがちです。
バックアップ製品との適合性: 対応エージェント、API 連携、リストアの検証。ハイパーバイザーが変われば、バックアップ設計は基本的に作り直しになる前提で見ておく
監視・ジョブ管理・構成管理: 監視項目、しきい値、通知ルール、ジョブ定義。既存資産をどこまで流用できるかは、机上では読み切れない
DR 構成: レプリケーション方式、切替手順、テスト計画。DR 側の基盤も同時に見直す必要があるかを確認
運用手順書とナレッジ: 現場で属人的に蓄積されている暗黙知は、基盤変更で一度リセットされます
教育コスト: 情シスだけでなく、運用委託先や、場合によっては開発部門にも学習負荷がかかる
PoC の段階では性能や機能に目が向きがちですが、運用に持ち込んでから発覚しやすいのはこちら側です。「バックアップの整合性が取れず、切替を延期した」「監視から漏れたホストで障害を検知できなかった」といった声は、実際の現場でよく聞かれる話です。
読者の状況によって、判断の難しさが集中する場所は違います。代表的な 3 つを挙げます。
更新時期まで距離があるなら、無理に前倒しで動く必要はないケースもあります。判断軸は、次年度以降の予算計画に組み込めるか、代替を並行検討する体制が確保できるか、の 2 点です。
一見合理的に見えますが、運用が二重化する期間が長くなるほど、情シスの負荷は増します。部分移行を選ぶ場合は、「並行稼働をいつ終わらせるか」まで先に決めておくのが安全です。
仮想化基盤の刷新とクラウド移行を同時に走らせるのは、成功すれば効果が大きい反面、失敗した際の影響も大きくなります。対象を絞る、段階を分ける、という原則を崩さない方が無難です。
どれも「絶対に正しい選択」があるわけではありません。判断のためのチェック観点として、自社の状況と照らし合わせて使ってください。
代替を選ぶと決めた場合、進め方の骨格は次の 5 フェーズで大きく変わりません。
現状調査 ( 資産棚卸し・依存関係の可視化 )
PoC ( 性能・機能・運用手順・障害復旧・バックアップ整合性 )
移行計画 ( 対象システムの優先順位、並行稼働期間、切替手順 )
段階移行 ( リスクの低いシステムから )
運用定着 ( 手順書、教育、監視の作り直し )
ここで強調したいのは、PoC を「製品評価」だけで終わらせないことです。運用リハーサルとして PoC を使うことで、切替後にはじめて発覚するはずだった落とし穴を、事前に潰せます。具体的には、次の観点を PoC の評価項目に組み込みます。
障害発生時の切り分け手順が、既存運用と大きく乖離しないか
バックアップからのリストア時間が、RTO の要件を満たすか
監視・アラートが、既存の運用フローに乗せられるか
情シスの担当者が、独力で日常運用を回せる水準まで到達できるか
「動いた／動かなかった」ではなく、「運用に載せられるか」まで確認するのが、失敗しないための分かれ目です。
代替製品を導入すれば運用が楽になる、という期待は禁物です。冷静に見ると、次のような問題は、製品を変えても残ります。
属人化: 特定の担当者しか触れない状態は、基盤を変えても引き継がれます。手順書化・教育のプロセスを同時に見直さないと、新しい基盤の上で属人化が再生産されます
EOL・保守: 代替製品側にも当然サポート期限があります。「今回の刷新で 10 年もつ」とは限りません。次の見直しタイミングを最初から想定に入れておく方が現実的です
体制: 情シス人員が縮小傾向のなかで、新基盤の学習と既存運用の維持を両立させるのは容易ではありません。運用委託や外部支援の使い方も、選定と同時に議論した方がよいテーマです
製品選定は入口にすぎません。運用設計と体制づくりの方が、時間もエネルギーも大きくかかる、というのが実感です。
一方で、「何もしない」ことにもリスクは存在します。バランスを取るために、こちらも整理しておきます。
保守費用の継続上昇による、中期予算計画への圧迫
サポート条件やライセンス形態の変化に、対応が後手に回る可能性
情シス内で代替製品への対応知見が蓄積されず、いざ動く時に選択肢が狭まる
ベンダーロックインが強まり、交渉余地が減る
「動く」「動かない」どちらにもリスクがあります。だからこそ、判断は感情ではなく、前提と数字で行う必要があります。
横河レンタ・リースでは、VM Essentials ( HPE Morpheus VM Essentials ) を含む仮想化基盤の PoC メニュー、機器の手配、構築、運用支援まで幅広く関わっています。ただ、記事の趣旨と重なる部分ですが、「必ず代替を勧める」立場ではありません。
具体的には、次のような関わり方が可能です。
現状の資産棚卸しと、代替検討の必要性そのものの整理
PoC メニューによる、性能と運用の両面からの検証支援
移行を選ぶ場合の設計・構築、選ばない場合の運用改善提案
導入後の運用支援 ( 監視、障害対応、継続的な改善 )
判断の前段階から、実行、運用まで、必要な範囲だけを切り出して相談いただける形にしています。
A. 一律に「すぐ乗り換えるべき」とは言い切れません。更新時期までの猶予、コスト影響、社内の体制によって最適解は変わります。当面継続しつつ、次の更新に向けて代替検討を並行して進める、という選び方も現実的な選択肢です。
A. できること／できないことは、どの機能を重視するかで評価が変わります。基本的な仮想化機能に加えて、Morpheus によるマルチクラウド管理への拡張性が特徴です。一方で、周辺エコシステム ( 対応するバックアップ製品や監視ツール ) は、自社要件と照らして個別に確認が必要です。カタログスペックだけではなく、PoC で確認するのが安全です。
A. 製品選定より先に、現行環境の棚卸しです。VM 数、依存関係、バックアップ・監視・DR の構成、運用手順書の状況までを見える化しておくと、その後の選定・PoC・移行計画の精度が大きく変わります。
A. 一概には言えませんが、性能検証だけでなく運用手順や障害復旧まで含めると、数週間で終わらせるのは難しいケースが多くなります。フェーズを区切って評価項目を明確にし、途中でスコープを見直せる進め方が現実的です。
A. 選択肢として成立します。ただし、並行稼働期間の運用負荷が想定より重くなるケースが多いため、「いつ並行稼働を終わらせるか」まで先に決めておくことを勧めます。
VMware 代替は、いま多くの情シスが直面しているテーマです。ただ、話題の大きさに引かれて製品比較から入ると、周辺システムや運用体制への影響が後回しになり、切替後に苦しむケースが少なくありません。
本記事で整理した内容を、あらためて振り返ります。
代替検討の前に、現行環境・コスト・IT 戦略・体制の 4 前提を固める
選択肢は「他基盤への移行」だけでなく、「継続」「部分移行」「クラウド化」も含めて並列に見る
VM Essentials を含む代替製品は「選択肢の一つ」として、フラットに評価する
PoC は製品評価にとどめず、運用リハーサルとして活用する
「動く」「動かない」どちらにもリスクがあることを、前提と数字で共有する
代替検討の初期段階で、判断材料の整理から一緒に考えたい場合は、資料ダウンロードや個別相談をご活用ください。移行を前提とせず、「そもそも動くべきか」から一緒に整理する進め方も可能です。
横河レンタ・リース株式会社は、日本ヒューレット・パッカード社の Platinum パートナーとして、サーバーの販売から構築・運用・管理まで一貫したサービスをご提供しています。自社サーバーの導入・リプレースをご検討中、またはサーバー運用に課題をお持ちの企業さまは、ぜひお気軽にお問い合わせください。