JVMを搭載したLinkerdサービスメッシュをサポートするBuoyantが、Kubernetes用の新たな試験的サービスメッシュとして“Conduit”をリリースした。Conduitのプロキシ“サイドカー”データプレーンはRustで、コントロールプレーンはGo言語で記述されている。ConduitはLinkerd 2.0ではない -- Kubernets専用であり、ターゲットとするユースケースも異なる。Buoyantは今後もLinkerdの開発やメンテナンス、有償サポートの提供を継続する、と述べている。
サービスメッシュ導入に対する関心は、LinkerdやEnvoyといったL7プロキシがオープンソースとしてリリースされたことや、IstioプロジェクトがLyft、Google、IBMの協力の下で公表されたことを受けて、昨年から劇的に高まっており、先日のCNCF CloudNativeConなどのカンファレンスでも取り上げられた。インターネット大手企業や“ユニコーン”企業の多くが、今日ではサービスメッシュと認識されているテクノロジを以前から利用している。LyftのEnvoy、TwitterのFinagle、GoogleのStubbyやGlobal Software Load Balancer (GSLB)などはその例だ。Buoyantによると、Linkerdは“世界で最も広く展開されているプロダクションサービスメッシュ”であり、SalesforceやPaypal、Expedia、AOL、Monzoなどで運用されている。
Linkerdは、BuoyantのチームがTwitterに在籍していた時に、Finagle RPCフレームワークを使用していた経験を基に開発された。Buoyantのブログ記事“Introducing Conduit”で述べられているように、Linkerdを使用した企業と協業した過去18ヶ月の開発から新たに分かったのは、LinkerdのJVMリソース使用量が異常に高いデプロイメントモデルが存在することだ。
Linkerdの使用するビルディングツール -- Finagle、Netty、Scala、JVM -- は、CPUとRAMが潤沢に使用可能な環境であれば、極めて高い作業負荷までスケールアップを可能にする一方で、リソースが限られている環境向けにスケールダウンするようには設計されていない。このことは、Kubernetesデプロイメントでは一般的なパターンである、アプリケーションコードと一緒に実行される“サイドカー”プロセスとしてLinkerdプロキシを運用する場合に、特に問題となる。
ConduitはBuoyantの“次世代”サービスメッシュであり、そのプロキシデータプレーンはRustで、“シンプルかつパワフル”なコントロールプレーンはGoで記述されている。Conduitのデプロイにおける最大の関心事はパフォーマンスだ、とBuoyantは主張する -- 単一のConduitプロキシはミリ秒単位のp99レイテンシを持ち、10mb 以下のRSSで動作する。さらにセキュリティの面では、フレームワークの通信手段の標準としてTLS (Transport Layer Security)を実装するとともに、Rustのメモリ安全性保証を活用している。
今回のリリースがLinkerdに与える意味について、何人かのエンジニアがTwitterを通じて質問しているが、Buoyant Conduitブログによる公式な回答は、“当面はごくわずか”というものだ。
Linkerdの開発、メンテナンス、有償サポートの提供は今後も継続します。数多くの商用版Linkerdユーザに引き続き満足頂けることを、当社は約束します。
ConduitはLinkerd 2.0ではない、とも記事にはかかれている。Conduitは非常に明確な環境 -- Kubernetes -- をターゲットとしており、AWS ECSやMesos、あるいはLinkerdのサポートする統合ユースケースのように、広範なプラットフォームに対応する計画はない。
Conduitの詳細については、プロジェクトのWebサイト、およびGitHubリポジトリを参照してほしい。ConduitのGitHub READMEには、プロジェクトが現時点では実験段階であり、HTTP/2のみをサポートする(従ってgRPCには特に適している)点が明記されている。
この記事を評価
- 編集者評
- 編集長アクション