Red Hatの製品担当VPにインタビュー。機械学習のインフラとしてのOpenShiftとは

Red Hatの製品担当VP、Mike Barrett氏が来日、ThinkITのインタビューに応えた。Barrett氏は製品担当としてHybrid Cloud関連製品、OpenShift関連製品、そしてCNCFにコントリビュートされたソフトウェアでRed Hatが関わっているプロジェクトにも携わっていると説明した。今回の来日は、2023年5月にボストンで開かれたRed Hat Summitを日本向けに紹介するRed Hat Summit Connect 2023が10月11日に東京で開催される前にブリーフィングを行うのが目的だろう。メディア向けのインタビューも複数設定されており、10月に初めてRed HatのCEOとしてMatt Hicks氏が来日するための土壌作りとも言えるかもしれない。

Mike Barrett氏（左）とレッドハット株式会社の岡下氏（右）

同席した岡下浩明氏は日本だけではなくAPAC担当の顧客向けストラテジストという肩書きを持つ。これまでレッドハットの記者説明会では何度もスピーカーや質疑応答の担当として対応してくれたベテランだ。

自己紹介をお願いします。

Barrett：私はOpenShift、Hybrid Cloud関連のプロダクトを担当しています。私が管理しているプロダクトは50以上ありますが、OpenShiftだけではなくその関連プロダクトも含まれますので、非常に多くのプロダクトを担当していると言えますね。オーストラリアに住んでいますが、オンラインで常にコミュニケーションをとっているので問題はないですね。

今回、特に強調しておきたいポイントは何ですか？

Barrett：最初にこのガートナーのマジッククアドラントのリサーチ結果を紹介したいと思います。これはDevOpsの領域でRed Hatがチャレンジャーとして位置付けられていることを示しています。

ここではGitLab、JFrog、CircleCIなどとともにRed Hatの名前が挙げられている

Barrett：これまでは主に開発ツールのベンダーが挙げられていましたが、プラットフォームエンジニアリングが注目されるに従ってRed Hatもそのコンテンダー（競争者）として注目されていることを示しています。開発ツール、DevOpsのためのCI/CDツールではなく、これまではインフラストラクチャーの会社と思われていたRed Hatがプラットフォームエンジニアリングの文脈の中で注目されているのは嬉しいですね。

仮想マシンを取り巻く環境も変わってきている

Barrett：このスライドでは仮想マシンに関する環境も変わりつつあることを説明しています。ペットと家畜という例えで「システムをどう扱うのか？」という観点がありますが、かつてはペットのように大事に運用してきた仮想マシンもこれからはクラウドネイティブのように必要であればいつでも立ち上げて不要になれば消してしまうというように、いわば家畜的に扱うことが必要になります。

仮想マシンから仮想マシンをクラウド的に扱うOpenStack、そしてもっとクラウドに特化した形でのコンテナオーケストレーターとしてのOpenShiftに移行していく、ということですね。

Barrett：そうです。その中で顧客が求めるものはオンプレミスのデータセンターだけ、パブリッククラウドだけではなく、両者を組み合わせたハイブリッドクラウドだというのがRed Hatの提供する新しいデータセンターです。そしてもうひとつ、HyperShiftについても簡単に説明しておきましょう。これはひとつのクラスターを管理するためにコントロールプレーンが存在しますが、それを複数用意して複数のクラスターを容易に管理可能にするものです。

複数のコントロールプレーンをホストするHyperShift

Barrett：HyperShiftについては、公式ドキュメントに存在する単独のOpenShiftクラスターとの比較をみれば理解が進むだろう。この図ではスタンドアロンのOpenShiftではコントロールプレーンとワーカーが密に結合した形で実装されるが、HyperShiftではコントロールプレーン自体が複数存在し、それぞれに切り離された形で管理が可能であると記述されている。より詳細には以下のブログを参照されたい。

●参考：A Guide to Red Hat Hypershift on Bare Metal

スタンドアロンのOpenShiftとHyperShiftとの比較

これはいわゆるマルチクラスターとは違うものですか？

Barrett：HyperShiftはすべてOpenShiftのインスタンスとして存在し、Kubernetesのツールもすべて同じものが使えるというのがポイントですね。コントロールプレーンを複数実装してそれを同時に管理できることで、コンテナプラットフォームをスケールさせることが可能になります。

Barrett：他にも機械学習を通常のアプリケーションと同じように扱うための新しいプロジェクトCodeFlareがあります。これにはOpenShiftの上で実装するための新しいスケジューラー、MCAD（Multi-Cluster-App-Dispatcher）やInstacale、KubeRayなどがあります。

ここでは深い説明は省かれたが、OpenShift上でのAIについては以下の紹介ビデオを参照して欲しい。●参考：AI/ML Models Batch Training at Scale with Open Data Hub

Red Hatが過去に紹介したプロダクトの中でApplication Interconnectについて先ほど、少しだけスライドで見せてもらいましたが、これはVPNをオープンソースで実装したものという理解で間違いないですか？

Barrett：そうですね、元のオープンソースプロジェクトはSkupperという名称のプロジェクトです。それをRed Hatがエンタープライズ向けにビルドしたということになります。

●参考：Use Skupper to connect multiple Kubernetes clusters

これは以前にApplication Interconnectが日本で紹介された時にも質問した覚えがあるんですが、企業間の通信を安全に行うことを可能にする、いわゆる、法人向けのVPN（Virtual Private Network）をオープンソースで実装したというものだとすると、Red Hatのパートナーである通信会社が法人向けにサービスとして行っているビジネスを浸食するものではないか？ と思うのですがそれについては？

Barrett：Red Hatはいつもオープンソースを使って何かを破壊してきたと言えるのかもしれませんね（笑）。これはHyperShiftについても言えるのですが、テレコム事業者がKubernetesを使ってサービスを提供する際に実際にやっていることは複数のコントロールプレーンを使って顧客別にKubernetesを使えるようにすることと同じなのです。つまりそれをHyperShiftというプロジェクトで実装し公開しています。

Barrett：またMicroShiftについても同様で、これまでK3sやMetal³（MetalKube）というエッジでKubernetesを実装するプロジェクトがありましたが、Red HatもMicroShiftというプロジェクトを近々公式のプロジェクトとして公開する予定があります。このようにオープンソースプロジェクトには破壊的（Disruptive）な性格がついて回るものなのです。

岡下：ただApplication Interconnectについては、我々はVPNという用語を使って説明してはいませんね。あとApplication InterconnectはService Interconnectという名前に変更になりました。

機械学習のOpenShiftへの実装からKubeRayやCodeFlareの紹介、そしてHyperShift、Application Interconnect/Service Interconnectまで、多種多様なプロダクトに対して駆け足で説明を行ったMike Barrett氏だが、1時間では足らないという印象だった。AnsibleのAIを応用した自動化のソリューション、Ansible Lightspeedについては10月のイベントの楽しみとして取っておこう。

●参考：Skupper.io: Let your services communicate across Kubernetes clusters

ちなみに上記のブログはService InterconnectのベースとなったSkupperを紹介するもので、2020年1月1日に公開された記事だが、文中に以下のような記述がある。

Skupper is a layer seven service interconnect. It enables secure communication across Kubernetes clusters with no VPNs or special firewall rules.

ここではVPNもファイアウォールのルール設定も不要になるというのがService Interconnectの大きな売りであることがわかる。ちなみに日本語のドキュメントサイトはまだApplication Interconnectという表記のままのようだが、英語のサイトではすでにService Interconnectに改称されている。

日本語サイトではまだApplication Interconnectのまま

●参考：Product Documentation for Red Hat Service Interconnect 1.4