All Things OpenからSolo.ioのBrian Gracely氏にインタビュー。サイドカーレスサービスメッシュとは？

All Things Open 2022でIstioのコントリビューターであるSolo.ioのBrian Gracely氏にインタビューを行った。Gracely氏は元Red Hatの製品戦略のシニアディレクターで、過去にもThinkITでインタビューを行ったことがある。過去のインタビューについては2018年にRed HatのCTOとともにインタビューした記事と2020年のKubeCon San Diegoでインタビューした記事を参照されたい。

●参考：
2018年：Red HatのCTOとOpenShiftのディレクターに訊く。パックの行く先にいたRed Hatの強さ
2020年：KubeCon＠San Diego前日に開催のOpenShiftのコミュニティイベント

2022年3月にRed HatからSolo.ioに移り、現在はSolo.ioのマーケティングのトップとして仕事をしている。今回は久しぶりの再会となった。

Solo.ioのマーケティング責任者、Brian Gracely氏

久しぶりですね。少し太りましたか？

そうですね。パンデミックで髪の毛を切りに行くことが面倒になったので少し伸びたかな？（笑）

いままで何度もRed Hatの人としてインタビューを行いましたが、今回はSolo.ioの人ということでどうして移ったのかを教えてください。

クラウドネイティブなシステムに関わってゼロから始めたいと思ったこともありますが、Soloの創業者であるIdit Levineとは約10年位前からの知り合いでもあったんです。お互いEMCで働いていた時に少しだけ知っていたというのもありますが、私がRed Hatで働いていた時も彼女から2ヶ月ごとに「そろそろうちで働かない？」ってお誘いのメールが来ていて、それまではずっと「またね」って返していたんですが、今が良いタイミングかなと。Red Hatでは製品戦略をやっていましたが、Soloではマーケティング全般をやっています。Red Hatであれば誰でもRed Hatのことは知っているので認知してもらうと言うより顧客と会ってニーズを聴いたりするのが仕事でしたが、Soloでは会社を知ってもらうことも必要ですし、マーケティングのためのマテリアルも作らないといけないということで毎日忙しく仕事してますよ。

先週はデトロイトでKubeConがありました。KubeConについて何か思うことはありますか？

ここ数年のKubeConを見ていて今年は特に感じたことですが、Kubernetesがメインではなくなったことを実感しましたね。これまではKubernetes自体が話題になっていましたが、もう安定していて基盤としては当たり前になった。その上で他のソフトウェアは何ができるのか？ が話題の中心になっていますよね。Kubernetesというワントピックから、10も20もトピックがあるカンファレンスになったと思います。Dan KohnがExecutive Directorとしていた時は、クラウドネイティブなシステムの最適なソフトウェアスタックを構成するために何が必要か？ を考えてプロジェクトをホストしていたと思いますが、ある時に競合するプロジェクトであってもCNCFがホストすることでエコシステムが広がる、選択はユーザーに任せるというように変化したんだと思います。

今までユーザーが抱えている問題は、どうやってアプリケーションをクラスターの上で実行するのか？ というシンプルなものだったわけですが、今やクラスターの数も増えセキュリティやネットワークなどさまざまな新しい問題を抱えるようになりました。単にコンテナを実行するだけではユーザーの問題は解決しないようになってきた。そしてそれはSoloにとっては良い状況になっていると思います。これまではサービスメッシュを使いたいけどIstioはCNCFに入っていないと言われていましたが、IstioもCNCFのプロジェクトになりましたし、Istio自体もサイドカーを使わない新しい機能が追加されました。

Solo.ioのブースの前で

私はサービスメッシュに関してはずっとLinkerdのシンプルさを評価して記事にも書いてきましたが、Gracelyさんの目から見てLinkerdとIstioの違いはなんですか？

これにはいくつかのポイントがあると思います。Soloは最初、API Gatewayを提供する会社でした。そしてSoloの最初の顧客はAmerican Expressだったんです。当時のAmerican Expressはレガシーなシステムがいくつも動いていて、その一つがメインフレームのシステムでした。そのシステムはTier 1と呼ばれ、絶対に落ちてはいけない重要なシステムだったんです。そしてSoloのAPI Gatewayも同じくTier 1のシステムとして稼働することを求められました。Idit（SoloのCEO）はIstioをサービスメッシュとして使う前にService Mesh Interface（SMI）という仕様に取り組んでいました。しかしSMIはそれほど普及せず、American ExpressのためにサービスメッシュとしてIstioを使うことになったんです。Soloの顧客は同じように複雑でレガシーなシステムとの連携を求めています。T-MobileにもSAPにも同じようなニーズがありました。Linkerdはシンプルで入れればすぐに動くという点は広く認められていますが、複雑なシステムに求められる機能を満たせるか？ という意味でIstioが優れていると思いますね。シンプルという点ではKubernetesと同時期にDockerのSwarmもありました。Swarmもシンプルなシステムでしたが、結局、Kubernetesにはなれなかったんです。

Istioの新しいAmbient Meshについて教えてください。

Istioが複雑だと言われるのにはそのような多くの機能を要求されるからという側面がありますが、それをもう少し簡単にしたいとSoloも思っていましたし、同時期にGoogleも考えていたようです。なので一緒にそのシステムについて検討した結果、サイドカーをなくしてシンプルなアーキテクチャーにする方向で開発を始めたんです。Kubernetesとは違ってサービスメッシュについてはレイヤーごとにその機能を分けることができるというのが発想の最初の方ですね。Kubernetesであれば全部の機能を使う、それを分けて個々に使うことはないのが当たり前ですが、サービスメッシュにおいてはそれが可能だし、それが求められていると思います。そしてIstioに慣れているエンジニアであれば、コントロールプレーンは同じでデータプレーンの部分だけが異なっていることはすぐに理解できますし、管理は同じなんです。なのでAmbient Meshによってシステムの負担も軽くなりますし、運用管理も同じという利点があるわけです。

PodごとにProxyを入れるのではなくサービスごとにProxyを入れるサイドカーレス実装

Ciliumもサイドカーレスのサービスメッシュを提供していますが、違いは？

Ciliumもサービスメッシュを実装してβ版として公開を始めました。Ciliumのサービスメッシュの部分は、Istioと同じEnvoyを使って実装しています。ただユーザーの視点からはレイヤーごとに違うソフトウェアが担当することになります。例えばあるセキュリティポリシーを実装したフィルターを開発しようとした時にeBPFで実装するべきなのか、Envoyで実装するべきなのか、デベロッパーが悩まないといけないことになりますよね。その点Istioであれば、どれもEnvoyで実装しているのでソフトウェアの選択に悩むということはありません。

●参考：Try eBPF-powered Cilium Service Mesh - join the beta program!

Solo.ioのビジネスの全体について教えてください。

Soloのビジネスは単純に言えば、Istioの有償サポート、これはRed HatがLinuxに対して行っていることと同じですね、それから顧客のニーズによっては、FIPS（Federal Information Processing Standard(s)、連邦情報処理規格）への対応を有償で行うことや大規模なマルチクラスターなどの複雑なIstioの構成の構築支援なども行っています。

そして最後はちょっとユニークなんですが、他社のAPI Gatewayを使っている顧客から外部向けのAPI Gatewayと内部向けのサービスメッシュを統合して欲しいというニーズに応えることもあります。これはAPI GatewayとしてレガシーなNGINXやHAProxyなどを使っている場合、内側のトラフィックをサービスメッシュで構成しようとした時にIstioを使うわけですが、外部はNGINX、内部はEnvoyというのではなく、Soloのソリューションを使えばどちらもEnvoyベースのデータプレーンで構成してコントロールプレーンをひとつにまとめることができるわけです。こういうシステム構成を実現できるのは、今のところSoloだけですね。これは感覚としてはAppleの製品に近いと思います。最初に出た製品も後から出た製品も同じ使い勝手ですぐに連携できるようになる。最初はAPI Gatewayを使って、Kubernetesクラスターでアプリケーションを実行して、サービスメッシュを入れた時も同じEnvoyベースで同じように連携して動き出す、管理も同じシステムで行えるという感じですね。

最後にこれからの予定を教えてください。

KubeConで感じたことと同じで、ユーザーもベンダーもKubernetesの次を見据えていると思います。Kubernetesを動かすことはもう通り過ぎて次の段階、つまりビジネスが要求するワークロードをどうやって実装するのか？ という段階ですね。それはSoloも同じでAPI Gatewayとサービスメッシュを実装するだけではなくGraphQLやWebAssemblyなどの新しい技術をどうやって使うのか？ それをEnvoyにどうやって組み込んでいくのか？ という段階のシステムに移行していくんだと思います。エッジデバイスとの連携という意味ではWebAssemblyには大きな意味がありますし、GraphQLもWebのテクノロジーとしては重要だと思います。

Red Hatという大企業からSolo.ioというベンチャーに移ってからもユーザーとしてはAmerican ExpressやT-Mobile、SAPなどの複雑で大規模なシステムを手掛けているSolo.ioのGracely氏だが、Solo自体の訴求とIstioの新しいサイドカーレスの実装、Ambient Meshについて熱く語ってくれた。Ambient Meshについては同じくSolo.ioのLin Sun氏のセッションも参考にして欲しい。スライドの写真はLin Sun氏のセッションで撮影したものを利用した。

ztunnelを通じてサービスごとに実装されたWaypoint Proxyが通信を行う

●参考：ISTIO is in CNCF, What is Next? - Lin Sun