インタビューMicrosoft は、Kubernetes 上で実行される軽量かつ拡張可能なサービス メッシュとされる新しいオープン ソース プロジェクト、Open Service Mesh (OSM) を Cloud Native Computing Foundation (CNCF) に寄贈することを計画しており、そのためのプロセスを開始しました。
Kubernetesのサービスメッシュを考える際に最初に思い浮かぶのはIstioです。最近、GoogleがCNCFへのIstioの寄贈を拒否し、代わりにGoogleが新たに設立したOpen Usage Commonsに商標を寄贈したことが話題になりました。Istioは最もよく使用されていますが、CNCFがホストするLinkerdなど、他にも選択肢があります。LinkerdはIstioのような機能をすべて備えているわけではありませんが、そのパフォーマンスと小型さから一部の人々に好まれています。
Linkerdは、Kubernetes上のサービスメッシュの標準インターフェースの構築を目指して、MicrosoftやHashicorpなどのベンダーによって2019年5月に導入されたService Mesh Interfaceを実装しています。Istioはアダプターはあるものの、SMIを実装していません。SMIはCNCFによってもホストされています。
Microsoftは今回、SMIの新たな実装であるOSMを発表しました。Linkerdと同様に、OSMは「Kubernetes上で動作する軽量で拡張可能なサービスメッシュ」として提供されていますが、OSMのプロキシと通信バスにはEnvoyを使用しているのに対し、Linkerdはlinkerd2-proxyを使用しているという大きな違いがあります。これにより、Linkerdは「Envoyベースのサービスメッシュよりも大幅に小型で高速」になるとMicrosoftは述べています。IstioもEnvoyを使用しています。
Microsoft Azure アプリケーション プラットフォームの製品ディレクターの Gabe Monroy 氏が、この新しいプロジェクトについて語ってくれました。
コモンズの大義：IBM、オラクル、CNCFがGoogleのIstioガバナンスの取り扱いに抗議
続きを読む
なぜまた別のサービス メッシュが必要なのでしょうか。「実際には、2 つの重要な差別化要因があります」と Monroy 氏は言います。
まず、OSMはSMIのリファレンス実装として設計されています。サービスメッシュ実装とSMIが提供する機能セット間の移植性という考え方を受け入れれば、OSMの素晴らしい体験が得られるでしょう。
「そして第二に、SMIがニーズに合わず、例えばサーキットブレーキングのような高度な処理が必要な場合でも、Envoy xDS APIを安全に利用できます。この組み合わせは、他のサービスメッシュの機能セットに圧倒されがちなお客様にとって最適なソリューションです。」
なぜLinkerdを使わないのですか？「Envoyを中心とした統合に関心が高いと聞きました。Linkerdにはそれが見当たりません。Envoyには利点があり、パフォーマンスも優れていますが、エコシステムの多くはEnvoyを支持しています。」
Microsoft自身はKubernetesの利用拡大において、どのような技術を採用しているのでしょうか？「社内でどのような実装を行っているかは詳細には公開していません。ただし、様々な実装に対応しなければならないことは確かです。それがSMIの正当性の一つです。SMIによって、共通のAPIセットを利用できるようになります。」
私たちは、OSM は業界標準とも言える Istio と比べてどうなのかと尋ねました。
主な違いは、OSM がはるかに軽量であることです。多くの AKS (Azure Kubernetes Service) のお客様が Istio の使用に苦労しており、サポートチケットの件数からもそれが伺えます。Istio の設計理念は、Envoy エコシステム全体を取り込み、それらの API を Istio API サーフェス内に組み込むことです。
開発者にとって、ほとんどの人が主に3つのことに興味を持っているのに、Istioを学ぶのは負担です。それは、サービス間の安全な通信を実現するmTLS、インテリジェントなルーティング、そしてサービス間の自動メトリクス、レイテンシ、エラー率です。顧客が求めているものを実現するために、Istioのすべてが必要なわけではありません。実際、複雑さのせいでクラスターが機能しなくなることもあります。
モンロイ氏は、OSMを軽量と呼ぶことは、機能が不足していることを意味するわけではないと述べた。「重要なのは、優れたエンジニアリングです。どのAPIを公開するかを意図的に選択しているのです」と彼は述べた。
OSMはシンプルに理解できるものにしたいと考えています。それには代償が伴い、高度な機能へのアクセスが困難になります。
OSMはシンプルに理解できるものを目指しています。そのためには、高度な機能へのアクセスという代償が伴います。私たちは、APIサーフェスに機能を追加するのではなく、Envoy APIの生の機能を補完することで、高度な機能を実現しています。
OSMはどれくらい使える状態になっているのでしょうか？「現在、これはオープンソースプロジェクトであり、まだ初期段階です。私たちの目標は、OSMを中心としたコミュニティを育成し、OSMを強化して実稼働環境への導入を支援することです。マイクロソフト社内ではすでに開発が進められており、主要なSMI APIはすべて動作しています。Envoyベースのサービスメッシュコントロールプレーンを独自に構築している方々（数多くいらっしゃいます）がOSMに興味を持ってくれることを期待しています。」
モンロイ氏によると、マイクロソフトはローンチに向けてまだパートナーを選定していないという。「プロジェクトを早期にリリースしたかったのです。協力体制を築くためには、完成したソフトウェアをいきなり全員に提供するわけにはいきません。フィードバックをいただきたいのです。」
CNCFへの寄付計画は、GoogleがIstioへの寄付を拒否したことへの反撃のようにも思えますが、モンロイ氏はこの件についてどのようにお考えですか？「オープンガバナンスをめぐる多くの騒動は、技術が機能するかどうかに注力している顧客に不利益をもたらしています。
オープンガバナンスというより広い観点から言えば、CNCFとLinux Foundation、そして彼らがクラウドネイティブ・エコシステムで行ってきた活動には非常に満足しています。Microsoft、Amazon、Google、Alibabaといった企業が集結している財団は他に考えられません。オープンソース・エコシステムにおいては、競合他社と協力しなければなりません。Open Usage Commonsを見ると、そこに見られるようなマルチベンダーの多様性は見られません。公平を期すために言うと、まだ初期段階ですが、私はCNCFに満足しており、異なる立場を取る理由は見当たりません。
モンロイ氏は、Kubernetesは依然として注目の技術だと述べた。「Kubernetesの利用は爆発的に増加しています。Azureコンピューティング史上、最も急速に成長しているサービスです。」また、OSMのリリースは、Linkerdなどの他のオプションをサポートしないことを意味するものではないとも述べた。「この分野には意見があります。パートナーのためのスペースも確保する必要があります」と彼は述べた。
彼はまた、マイクロソフトは開発者によるKubernetesの利用をさらに簡素化していく予定であり、OSMがその好例だろうと述べています。「Kubernetesの開発者エクスペリエンスは既に解決済みだと言う人は、私が見てきたものを見ていないのです」と彼は言います。®
