米Broadcom（ブロードコム）によるVMware買収とそれに伴うライセンス変更は、既存のVMwareユーザー企業に大きな影響を与えている。コスト増加だけでなく、ブロードコムのビジネス姿勢を不安視する向きもあり、「脱VMware」の動きは加速している。一方で、脱VMwareを、コスト高などネガティブな事象への対応という観点だけでとらえるべきではない。従来の仮想化基盤が抱えていた課題を見直し、将来を見据えたモダナイゼーションを推進するチャンスでもある。米Red Hat（レッドハット）と米Oracle（オラクル）の両社におけるレガシー仮想基盤脱却の異なるアプローチを紹介する。
（取材・文／谷川耕一　　編集／藤岡　堯）
 

プラットフォームをいち早くOpenShift化

　ブロードコムは2022年5月にVMwareを約8兆円で買収すると発表し、23年10月末に買収を完了した。買収後、ブロードコムはVMwareのライセンス体系を大きく変更。具体的には、従来の永続ライセンスを廃止してサブスクリプションライセンスに移行し、製品ラインアップも大幅に整理した。このため、ユーザー企業の選択肢は大きく減り、必要な製品だけの入手ができず、結果としてコスト負担が増加するケースが出ている。
 
　そのため市場では、「脱VMware」の動きも起きている。「（移行による）コスト面への懸念はあるが、ブロードコムのビジネスの姿勢に不安の声が出ている」とレッドハット日本法人ソリューション営業本部の大村真樹・セールススペシャリストは語る。

　一方で、値上げ問題がなくても、従来の仮想化基盤には、さまざまな課題があった。例えば、ビジネス部門で仮想マシンが必要になった場合、申請書を記入し、承認を得てから1カ月後に払い出されるケースも多い。また、VMwareの仮想基盤は3ティア構成の環境が多く、技術スタックごとにエンジニアがサイロ化しやすく、生産性向上が阻害される。
 
　コスト増は経営面ではピンチだが、現場のエンジニアにとってはチャンスでもある。これを機に、仮想基盤の課題を一掃できるかもしれない。そのため、「抜本的に考え直す機会と捉える企業が増えている」と大村セールススペシャリストは言う。この傾向は、欧米でも同様だ。ただし既に「OpenShift」を使っている企業も多く、「OpenShift Virtualization」があるなら、乗り換えれば良いと判断する事例が目立つ。一方日本は、コスト増の報告をパートナーから受けると、まずはパートナーの努力で吸収するか、追加コストを払い対応してもらおうと考える。しかし、コスト増は予想より大きく「これはまずいとなり、改めて仮想基盤の見直しを考えだしている」と、テクニカルセールス本部スペシャリストソリューションアーキテクト部の宇都宮卓也・シニアクラウドソリューションアーキテクトは指摘する。

　ただ、既存の仮想基盤ワークロードをコンテナ基盤のOpenShiftに一斉に移行するのは困難だ。VMwareの技術に依存した運用や可用性の設計、モノリシックなアプリケーション構成は、レッドハットが目指すオープン・ハイブリッドクラウドへの移行を阻む。

　そこで、アプリケーションアーキテクチャーは仮想基盤のまま、プラットフォームをクラウドネイティブ化する。それを実現するのがOpenShift Virtualizationだ。レッドハットは、この機能を活用した段階的なモダナイゼーションを、23年後半から積極的に提案している。日本では、OpenShiftはコンテナプラットフォームとしてのイメージが強いものの、仮想マシンの基盤としてもVMwareの代替になり、OpenShiftの価値も享受できる。

　数年前までは、システムはすべて同じライフサイクルで運用され、ハードウェアの更新などに合わせ一斉に改修が行われていた。しかし、事業部門のニーズは多様化しており、すべてのシステムを同じタイミングで改修するのが適切とは限らない。
 
　「システムの数だけ、事業部門の要求が存在する」と、テクニカルセールス本部の内藤聡・クラウドソリューションアーキテクト部部長は語る。これらの要求に応えるには、プラットフォームとアプリケーションの刷新が必要だ。

　実際には、仮想基盤に残るシステムはそのままに、優先度の高いものから順次コンテナ化を進めるケースが多かった。そのため、複数のインフラ管理が必要となり、IT部門の負担増が懸念された。しかし、今回の脱VMwareの動きを契機に、プラットフォーム全体を見直す動きが出ており、プラットフォーム移行のロードマップ提案が重要性を増している。

　その際にOpenShift Virtualizationは、コンテナ化に不向きなアプリを仮想基盤のままOpenShiftプラットフォームに載せ、OpenShiftによる一元管理で運用管理を効率化する。この時レッドハットは、プラットフォームだけの変更を提案するのではなく、常にクラウドネイティブな未来像を提示していると、内藤部長は強調する。

なるべく手を入れずにOCIで短期間に移行

 　オラクルは、さまざまなワークロードのクラウド化を支援する「Oracle Cloud Lift Service」を提供している。脱VMwareの動きを受け「最近はVMware環境に関する相談が増えている」と日本オラクルの宮原雅彦・理事クラウド事業統括クラウド・エンジニアリングCOE統括本部長は述べる。
   
　「『Oracle Cloud Infrastructure』（OCI）で利用できる「Oracle Cloud VMware Solution」（OCVS）は、オンプレミスの運用ノウハウをそのまま生かせるため、現状を維持したまま短期間で移行できる」と宮原理事。移行によって生まれた時間の余裕を活用し、モダナイズされた将来像に向けてロードマップを検討することが重要になる。

　OCVSは、既存のVMware製品のライセンスを持ち込め、オラクルが提供するVMwareライセンスも利用できる。従量課金制を採用しており、OCIの割引プログラムも活用できるため、ブロードコムのライセンス変更によるコスト増を抑制できる可能性が高い。コストを抑えつつ、将来的なレガシー仮想基盤からのモダナイズのための時間を稼げる方法となりうる。

　Cloud Lift Serviceでは、事例を共有してクラウドのメリットを共有する「ケーススタディ支援」、現行システムを評価して課題とロードマップを可視化する「フィジビリティスタディ支援」、移行に向けた「実証検証（PoC）の支援」、移行プロジェクトの初期フェーズの「早期立ち上げ支援」の四つを、プリセールスのサービスとして無償提供している。VMwareについては、移行に関するケーススタディの確認や性能面の検証、運用方式の確認を行うケースが多い。

　OCVSは、OCI上にVMware SDDC （Software-Defined Data Center） をネイティブに構築できる。主要なVMware製品をOCI上でそのまま実行でき、ユーザーがvCenter Serverを含むVMware環境全体の管理者権限を保持するため、オンプレミス環境と同様に、VMware環境の設定や運用を自由にコントロールできる。ネットワークもオンプレミス環境と同一の構成を維持でき、サードパーティー製品の利用も継続可能である。

　「大規模なミッションクリティカルなシステムだと、手を入れづらいことも多く、いったんはそのままクラウドに持っていきたい。限られた時間と予算の中では、既存の環境になるべく手を入れたくない」と近藤暁太・事業戦略統括事業開発本部担当シニアマネジャーは言う。

　ミッションクリティカルなシステムの場合、アプリは仮想基盤で稼働している一方で、データベース（DB）は「Oracle Exadata」などが別途稼働しているケースも多い。DBも同じ基盤に配置した方が良いと判断し、DBのOCI化も同時に行う場合もある。OCIであれば、仮想基盤とは別に稼働するDBも含めて既存環境にあまり手を加えずにクラウド化できる。移行後の運用も大きく変更する必要がなく、結果的に安定した稼働につながる。「パッチ適用などのメンテナンスのスケジュールもユーザーのニーズに合わせられる」と近藤シニアマネジャー。自社のタイミングで運用できる点は、エンタープライズ用途では重視されるポイントである。

　既存の仮想基盤をそのまま持っていくだけでなく、Cloud Lift Serviceのフィジビリティスタディ支援では、アプリのリビルドやリアーキテクト、リプラットフォームの議論を顧客と行い提案もする。生涯ずっと仮想基盤を使い続けるわけではないだろう。近藤シニアマネジャーは「将来的にモダナイズするからこそ、現状に手をかけて移行するのはコスト的にも手間の面でも見合わない。そう考える顧客は多い」とも指摘する。

将来を見据えたモダナイゼーション戦略を

　レッドハットのアプローチは、OpenShiftをプラットフォームとしていち早く導入し、モダナイゼーションを促進することである。一方、オラクルのアプローチは、ミッションクリティカルなシステムにおけるVMwareのコスト問題を解決することを優先する。そのため、既存環境にできる限り手を加えずにOCIに移行し、モダナイゼーションのための時間をしっかりと確保する。

　仮想基盤で稼働しているシステムの要件によって、最適なアプローチは異なる。重要なのは、数年後の短期、そしてその先の中長期的なプラットフォーム像を明確に描くことである。目標に到達する方法は一つとは限らない。自社のニーズに応え、将来像を共に目指せるパートナーを見極める必要がある。