VM の移行を超えて：リフトアンドシフトの先にあるもの

私はインフラチームと、この話を何十回も交わしてきました。彼らは、レガシーのハイパーバイザーからの VM 移行を終えたばかりか、その真っ最中です。困難な作業はほぼ完了した。少なくとも、彼らはそう考えています。

ここで、多くの人が語らない重要な点があります。それは、移行そのものは簡単な部分だということです。それは戦術的な作業であり、明確な「始まり」「中間」「終わり」があります。その後に続く、インフラの運用方法を実際にモダナイズすることこそが、真の作業であり、最大の価値が生まれる場所なのです。

これらの移行を推進する業界の変化は、最新のインフラストラクチャにとって戦略的な機会となっています。ライセンスの効率化、コストの最適化、ベンダーの柔軟性といった課題に取り組む中で、組織はかつてないペースで Red Hat OpenShift Virtualization を採用しており、 2024 年初頭以来、お客様の導入率は 178% 急増しています。多くの議論が移行という行為のみに焦点を当てていますが、真の価値は移行後に起こるイノベーションにあります。

先見の明のある組織は、移行を最終目標と見なすのではなく、出発点として捉えています。この移行は、単に過去の課題を解決するだけではありません。将来を見据えた、最新かつ統合されたアプリケーションプラットフォームの機能を最大限に活用できる基盤の構築を支援するものです。

そのより広範なロードマップが、実際にはどのようなものかをご紹介します。

ステージ 1：Linux 環境を整理する

移行後は、 OS のスプロールの評価を実行することを検討する必要があります。ほとんどの組織は、意図的な選択ではなく、長年にわたる自然発生的な成長によって蓄積された、さまざまなディストリビューション、バージョン、サポート契約を抱えています。さて、はっきりさせておきたいのですが、オープンソース企業として、 Red Hat は「単一構成が常に正解だ」と主張するつもりはありません。多様性には確かなメリットがあります。それは、共通の障害モードを減らし、単一の欠陥クラスによる影響範囲を限定できるからです。その多様性の一部は意図的なものであり、正当化できるものです。

しかし、大企業では、その多くがそうではありません。それは技術的負債なのです。2019 年に誰かがプロジェクト用に立ち上げた Ubuntu インスタンスが、今では重要な業務を支えているようなケースです。それは、ライフサイクル終了 (EOL) の発表後に誰もパッチを適用しなかった CentOS マシンです。それは、その役割を誰も正確には把握していないものの、もしオフラインになれば大問題になる Windows XP のようなものです。

ハイパーバイザー層を標準化したら、次の自然なステップはゲスト OS の状況を見直すことです。Red Hat Enterprise Linux（RHEL）とRed Hat OpenShiftを併用することで、より一貫性のある運用モデルが実現します。つまり、パッチ適用の一元化、サポート体制の整合性、そして環境全体で実際に機能するポリシーの適用が可能になるのです。「2024 年版 世界のテクノロジートレンド」における Red Hat の調査によると、企業の 45% がアプリケーションスタックのモダナイゼーションを最優先事項に挙げていることがわかりました。実際に効果を上げているモダナイゼーションの取り組みはすべて、同じ原則に従っています。それは、正当な理由のない OS の多様性を排除し、正当なビジネス上の根拠がある OS のみを維持することです。

ステージ 2：新しいプラットフォームを古いプラットフォームと同じように管理するのをやめる

これは、私たちが最も頻繁に目にする間違いです。チームは移行を完了した後も、古い環境を管理していたのとまったく同じ方法で新しい環境を管理し続けてしまいます。同じ手動プロセス、同じチケットベースのパッチ適用サイクル、コンソールを介した同じその場しのぎの変更を繰り返します。

移行後の環境は白紙の状態です。これは、自動化を正しく構築するための、おそらくこれまでで最高の機会となるでしょう。

Red Hat Ansible Automation Platform を使用すると、チームは数週間かかっていた手動の展開作業を数時間に短縮できます。Playbook が整えば、プロビジョニング、パッチ適用、コンプライアンス対応が自動的に行われます。

チームがすでに GitOps を実践している場合、 Red Hat Advanced Cluster Management for Kubernetes はその同じ規律を仮想化にもたらします。ポリシーはコード化され、 Git に保存されます。コンソール操作による構成のドリフトは発生しません。つまり、より厳格なドリフト制御、より迅速なロールアウト、そしてより予測可能な Day 2 運用が可能になります。

現実的な事実として言えるのは、モダナイゼーションの道のりにおいて、自動化は「あれば便利なもの」ではありません。自動化こそが、後の段階をそもそも可能にする要素なのです。

ステージ 3：ワークロードを本来あるべき場所で実行する

すべてのワークロードが永久に仮想マシン (VM) のままである必要はありません。コンテナ化に最適なワークロードもあります。しかし、目標はすべてをコンテナ化することではありません。目標は、各ワークロードを最も最適な場所で実行することです。

OpenShift を使えば、同じプラットフォーム上で VM とコンテナを管理できます。つまり、「すべてをリフトアンドシフトする」か「すべてをクラウドネイティブに書き換える」かの二者択一を迫られる必要はありません。その誤った二者択一の考え方は、この業界全体で途方もない時間と費用の浪費を招いてきました。 PNC Bank は、このアプローチを実用的に実践した好例です。同行は新しい基準を採用し、デリバリー期間を 8 週間から 10 日を目標に短縮しました。

多くのチームがこの段階で足踏みしてしまいます。技術的な部分は難しくありません。難しいのは、どのワークロードを、いつ、どのような順序で移行すべきかを判断することです。以前に同様の経験を持つ人材がいるかどうかで、モダナイゼーションのサイクルを 13 カ月から 6 カ月に短縮できるかどうかの違いが生まれます。 Forrester の調査もこれを裏付けています。ある複合組織は、経験豊富な指導者の助言を得て、OpenShift の導入と VM の移行期間を 13 カ月から 7 カ月に短縮しました。

ステージ 4：必要になる前に AI について考える

AI について言えることは、導入に成功した企業は、すでに混乱していたインフラに後付けで AI を導入した例は一つもないということです。 Gartner® によると、2026 年の世界の AI 支出額は合計 2.5 兆ドルに達すると予測しています。

移行が完了する前に AI の計画を立てるべきだと言っているのではありません。しかし、これをうまくこなしているチームには、ある共通点がありました。それは、基盤となるインフラが整然としており、自動化されているということです。AI ワークロードは、コンピューティング、ストレージ、可観測性に対して高い要求を求めます。長年の自然発生的な成長によって複雑化した環境を解きほぐすよりも、標準化された Kubernetes ネイティブのプラットフォーム上で解決する方が賢明です。

移行は「移動」です。モダナイゼーションは「変革」です。

移行とは、もはや利用し続けたいと思わないプラットフォームから離れることですモダナイゼーションは、実際に必要なプラットフォームを構築するものです。これらは根本的に異なるものであり、その間のギャップこそが、真の取り組み（そして真の価値）が存在する場所なのです。

Gartner プレスリリース、Gartner、2026 年の世界の AI 支出額は合計 2.5 兆ドルに達すると予測 、2026 年 1 月 15 日

GARTNER は、Gartner, Inc. および/またはその関連会社の商標です。