Service Mesh を使用した Red Hat OpenShift での仮想マシンの管理

コンテナ化されたアプリケーションと並行して仮想化ワークロードを管理することは、IT 運用にとって依然として根深い課題であり、管理環境のサイロ化をもたらすことが少なくありません。Red Hat Summit 2026 では、OpenShift Spotlight セッションに登壇し、仮想マシン (VM) とコンテナを単一プラットフォーム上で同等に扱えるようにすることで、Red Hat OpenShift がこの分断をどのように橋渡ししているかを実演しました。

Alan Cowles が Red Hat Summit 2026 の OpenShift Spotlight でプレゼンテーションを実施。

仮想マシンとコンテナ間のギャップを橋渡し

私のデモンストレーションでは、7 つの仮想マシンを実行する架空の旅行代理店のアプリケーションに焦点を当てました。このレガシー・アプリケーションは予約および請求機能をサポートし、アプリケーションの実行に必要な各サブ機能に対応する専用の VM を備えていました。たとえば、レンタカー予約アプリケーションの実行専用の VM、フライト予約専用の VM、ホテルの宿泊手配専用の VM などがありました。

多くの場合、組織は VM とコンテナで別々の管理コンソールを維持することを余儀なくされているのが現状です。これは、仮想化ソリューション内でコンテナ・プラットフォームをホストしているか、別々のチームによって管理されるベアメタル・インフラストラクチャ上で両方を並行して実行しているためです。これにより、運用効率を低下させる「トグル税)」が生じる可能性があります。このデモンストレーションでは、Red Hat OpenShift が仮想マシンをサービスメッシュなどのプラットフォームのネイティブ機能に直接統合することで、この問題をどのように軽減するかを紹介しました。

OpenShift の仮想マシンはそれ自体がコンテナ内で実行されるため、コンテナ化されたワークロードと同様に、OpenShift が提供するあらゆる高度なツールを仮想化ワークロードにも簡単に適用できます。Red Hat OpenShift Service Mesh を使用して、実行中の VM にサイドカーコンテナを注入し、以前は利用できなかった追加機能を提供しました。最初はトラフィックグラフが空でした。サイドカーコンテナがまだ注入されていなかったためです。仮想のキーボードでコマンドラインを素早く操作してサービスメッシュのサイドカーコンテナを注入すると、瞬く間に環境が一変しました。VM の Pod ビューは 2 つのコンテナから 3 つに拡張され、VM を構成するguest-consoleコンテナおよびcomputeコンテナとともに、istio-proxyコンテナが追加されました。注入が完了すると、サービスメッシュグラフに新しいデータが反映され始め、データベースやサポートサービスを含むアプリケーションフロー全体の包括的な可視化が実現しました。 

 OpenShift Service Mesh のトラフィックグラフ機能は、旅行代理店のアプリケーション・ワークフローの全体像を包括的に示します。 

サービスメッシュを通じたネットワーク接続を確認した後、OpenShift Service Mesh がネットワーク・トラフィックフローの可視化だけでなく、トラフィック制御にも有効であることを聴衆に示しました。これを実証するために、旅行代理店アプリケーションの更新バージョンのカナリアデプロイメントを披露しました。新しい「cars v2」VM をプロビジョニングし、サービスメッシュのトラフィック制御機能を活用して、トラフィックの 90% をレガシーバージョンのレンタカー・アプリケーションを実行している仮想マシンにルーティングし、バージョン 2 にはわずか 10% のみをルーティングするデプロイメントをスクリプト化しました (いわば、車の「試乗」のようなものです）。新バージョンの安定性を確認した後、別のコマンドを入力してトラフィックフローを 80/20 の比率に移行し、新しいバージョンのアプリケーションへの割り当てを増やしました。これにより、アプリケーションのレガシーバージョンを実行していた VM を廃止するという論理的な次のステップへと進めることができます。

このデモンストレーションではコンテナサービスと仮想マシンの間の複雑な相互作用が多数示されましたが、最大のポイントは、OpenShift が VM を単に「実行」するだけでなく、先進的でプログラム可能なアプリケーション基盤のネイティブコンポーネントとして扱い、アプリケーションを完全に書き換えることなく高度なデプロイメント戦略を可能にできるという点です。

OpenShift で VM を実行することで、旅行代理店はアプリケーションの書き換えを余儀なくされることなく、先進的なロールアウト戦略を用いて OpenShift のネイティブコンポーネントとして新機能をテストできるようになります。 

このインタラクティブなアーケードデモを通じて、このワークフローを体験し、プラットフォームの機能を実際にご確認いただけます。

現場からの視点：Abacus の軌跡

このデモンストレーションの最も良い点は、ここで説明した技術的な道筋が単なる理論にとどまらないことです。これは、Red Hat のお客様の 1 社が実践した戦略的転換を反映しています。金融および医療分野向けのマネージド・サービスプロバイダーである Abacus の CTO、Paul Ponzeka 氏が OpenShift Spotlight セッションで私と共に登壇し、アジリティの確保というニーズと持続不可能なベンダーの慣行への対応を背景とした、Abacus の OpenShift への移行の取り組みについて Red Hat の Stu Miniman と対談しました。

Abacus の CTO である Paul Ponzeka 氏が、レガシー VM のプロバイダーから Red Hat OpenShift Virtualization への移行の道のりについて語ります。(20:16)

Abacus がなぜ変革を必要としていたかの理由を尋ねられた Ponzeka 氏は、「VMware と Broadcom がバーに入ってきて…」と冗談を交えつつ、市場についての率直な見解を述べました。さらに同氏は、多くのサービスプロバイダーが直面した厳しい現実について詳しく語りました。「価格は 2 倍に跳ね上がり、サービスプロバイダー向けプラットフォームから締め出されつつありました…根本的に変革が必要だったのです」

Ponzeka 氏にとって、この移行は単なる値上げの回避ではなく、より先進的で効率的なアーキテクチャに対応できるようチームのスキルを向上させるためのものでした。同氏は、この移行によって思いがけないパフォーマンスの向上ももたらされたと述べています。「実際、OpenShift に移行したことでパフォーマンスが大幅に向上しました。大容量のポートでも最大レベルのスピードが出るようになりました」と同氏は語っています。

最終的に Abacus は、OpenShift への移行によって顧客のコンテナ化されたワークロードをオンプレミスに戻し、基幹業務 (LOB) の VM と並列でベアメタル上で実行できることを実感しました。これにより、移行の必要性が新たな製品ラインへと転換され、レガシーの制約から脱却することが真のインフラストラクチャのモダナイゼーションへの第一歩であることが証明されました。

まとめ

OpenShift の VM 統合機能は、インフラストラクチャをモダナイズしながらベンダーロックインからの脱却を目指す組織にとって、戦略的な推進力となります。私が行ったデモンストレーションは、レガシー・アプリケーションであっても先進的なクラウドネイティブ・プラットフォームの世界で十分に力を発揮できることを実証する一例となりました。また、Ponzeka 氏の体験談は、単なる移行として始まったものが競争上の優位性へと進化し、インフラストラクチャの制約を新たなビジネスチャンスへと転換できることを Abacus において証明するものとなりました。VM とコンテナを統合アプリケーション・プラットフォーム内で対等に扱うことで、企業は既存の投資を保護しながら、クラウドネイティブ運用のアジリティとコスト効率を確保できます。 

Red Hat OpenShift Virtualization の詳細 

• 製品の詳細を見る
• OpenShift Spotlight セッション全体を視聴する
• ラーニングハブでその他のリソースを確認する