【2025年版】サービスメッシュに関連するOSSの動向調査記録

本記事の要約

本記事は、サービスメッシュに関連するOSSについて2025年時点での動向を調査したものです。具体的には以下の3点についてまとめました。

• 5つのサービスメッシュに関連するOSSを抜粋し、概要レベルで調査しました。
• 抜粋したOSSを2グループに分類し、各OSSの人気度合いとアーキテクチャの二軸で比較・分析しました。
• 比較・分析の結果から、サービスメッシュに関連するOSSの現状と今後の動向について考察しました。

はじめに

現代社会では新しい価値を提供するために、ITシステムの開発スピードの向上が重要視されています。また、AWSやAzureなどのクラウドサービスの台頭により、サーバールームがなくても、必要なスペックや台数のコンピュータを利用できるようになりました。これらの現状から、特に大規模なシステムをより効率的に開発・運用するために、マイクロサービスの採用が増加しています。

マイクロサービスは複数の独立したサービスで構成され、APIによって各サービス間が連携します。マイクロサービスを採用することで、システムのスケーラビリティや可用性が向上し、コードの再利用が容易になるなどの恩恵を得ることができます。また、サービスを細かく分割することで、開発チームのエンジニア一人ひとりが自身の担当実装に対して集中できるようになります。

例えば、マイクロサービスの導入事例として、NETFLIXにおける動画処理パイプラインの開発が挙げられます。NETFLIXの事例では、開発プラットフォームにマイクロサービスアーキテクチャを採用することで、システムの柔軟性や開発・リリースサイクルの向上を実現しました。

しかし、マイクロサービスの開発・運用にあたっては、従来は発生しなかったサービス間通信に起因する問題も考慮する必要があります。例えば、

• サービス間通信のための開発オーバーヘッド
• サービス間通信に関するトラブルシューティング
• サービス間通信のセキュリティ問題

などが挙げられます。

これらの問題を解決するために開発されたソフトウェアが、今回取り上げるサービスメッシュです。

サービスメッシュとは？

サービスメッシュとは、「マイクロサービス内の各サービス間通信をインフラ層から制御するソフトウェアレイヤー」です。サービスメッシュはマイクロサービス環境に対して、以下のような機能を提供します。

• サービス間のトラフィック制御
• サービスの詳細な挙動に関する監視
• 安全な通信を確保するための暗号化機能

サービスメッシュをマイクロサービスへ導入することで、各サービス間で最適かつ安全な通信が可能になり、サービス内の障害の原因を把握しやすくなります。

サービスメッシュは、「データプレーン」と「コントロールプレーン」という2つの要素で構成されます。
データプレーンは、各アプリケーション間の通信ネットワークを仲介・制御する役割を担います。一方、コントロールプレーンは、データプレーン全体の管理・構成を担当します。たとえば、サービス間通信のメトリクスを監視する場合、データプレーンでは各アプリケーションの通信状況のメトリクスを取得し、コントロールプレーンではサービスメッシュ全体のメトリクスを把握することができます。

標準的なサービスメッシュでは、データプレーン上の各ポッド（サービス単位）にサービスプロキシを設置し、そのサービスプロキシを介して通信を行います。このようなアーキテクチャは俗にサイドカーモードと呼ばれています。

標準的なサイドカーモードを採用したサービスメッシュの構成例として、Istioのアーキテクチャ構成図を示しました。

サービスプロキシを介することで、各サービスのコードを変更することなく通信制御が可能となり、サービス実装時にプログラミング言語の違いによる相性問題などに悩まされることもなくなります。

サービスメッシュの具体的な活用例として、障害リスクを低減しながら信頼性を担保するテスト手法である「カナリアデプロイ」が挙げられます。カナリアデプロイは、稼働中の一部のサービスを新バージョンに置き換えていき、全トラフィックのうち一部を新バージョンに振り分け、残りを従来サービスへ振り分けます。サービスメッシュを適用することによって、新旧バージョンに振り分けるトラフィックの比率が柔軟に設定でき、トラフィックの可観測性が向上します。

しかし、このような有用なサービスメッシュですが、近年ではサービスメッシュに関連するOSSに関する調査記事が以前ほど公開されなくなり、注目が薄れつつあります。そこで、現在のサービスメッシュに何が起きているのかについて興味を持ち、動向調査を行いました。

調べてみよう

サービスメッシュを導入するためのソフトウェアは、GitHubなどで公開されているOSSから入手できます。今回の調査では、CNCF (Cloud Native Computing Foundation) Landscapeに掲載されているOSSを調査しました。CNCFは、クラウド技術に関するオープンソースプロジェクトを支援する財団であり、サービスメッシュに関連するOSSで有名なIstioもCNCFのプロジェクトです。

CNCF Landscapeから調査する上で、現在OSS開発が行われているものに限定しました。
そこで、以下の項目を満たすOSSを選定しました。

• CNCF LandscapeのカテゴリーがService Meshであること
• GitHub上で公開されていること
• CNCFに所属しているプロジェクトであること（CNCF Archivedであるプロジェクトを除く）
• サービスメッシュそのものに関する機能を提供しているOSSであること
• 直近1年で、GitHubリポジトリに対するcommit数が10件以上あること

CNCF Archived であるプロジェクトとは、様々な理由でCNCFが求める要件を達成できず、アーカイブ化されたプロジェクトのことです。

その結果、次のOSSを対象として調査することにしました。

• Istio
• Linkerd
• Kuma
• Kmesh
• Sermant

さらに、対象としたOSSに対して、以下の項目について調査しました。

• 開発元とその所在国
• 初版リリース年
• CNCF参画年
• CNCFにおける成熟度
• ライセンス
• 各OSSに関する機能と概要
• コントロールプレーン
• データプレーンプロキシ

1. Istio

項目	説明
開発元	Google, IBM, Lyftなどが合同開発
初版リリース年	2017年
CNCF参画年	2022年
成熟度	CNCF Graduated
ライセンス	Apache-2.0
コントロールプレーン	Istio
データプレーンプロキシ	Envoy・ztunnel（アンビエントモードのみ）

Istioは、サービスメッシュに関連するOSSの中で最も人気のあるOSSです。

Lyftによって開発されたサービスプロキシであるEnvoyを最初に採用したプロジェクトであり、多くのサービスメッシュに関連するOSSへ影響を与えているOSSといえます。例えば、Docker-Hub上でIstioのDocker Imageは10億回以上pullされており、Image全体から見て上位に位置しています。

Istioのデータプレーンには、従来のサイドカー方式と、2022年に登場したアンビエントモードの2種類があります。アンビエントモードは、運用コストやリソース消費の削減を目的とした新しいアーキテクチャです。

サイドカー方式では、各ポッドにプロキシ（Envoyなど）を個別に配置し、アプリケーションの通信を制御します。一方、アンビエントモードでは、各ポッドにプロキシを配置するのではなく、各ノードに「ztunnel」と呼ばれる共通エージェントを導入し、TCPやUDPなどのL4（トランスポート層）通信を一元的に処理します。これにより、各アプリケーションポッドのオーバーヘッドを軽減できます。

ztunnelは、各ノード上で動作する軽量なプロキシであり、クラスタ内のL4レベルの通信（TCP・UDPなど）のセキュリティやトラフィック管理を担当します。L7（アプリケーション層）での高度な制御が必要な場合は、ztunnel間の通信経路上に「WayPoint Proxy」を配置することで、HTTPなどのL7プロトコルを処理することができます。

アンビエントモードを採用した場合のアーキテクチャ構成図

2. Linkerd

項目	説明
開発元	Buoyant（アメリカ）
初版リリース年	2017年
CNCF参画年	2017年
成熟度	CNCF Graduated
ライセンス	Apache-2.0
コントロールプレーン	linkerd2
データプレーンプロキシ	linkerd-proxy

Linkerdは、Istioと並び、CNCF Graduatedの成熟度を持つOSSです。

Linkerdの特徴は、シンプルさに加え、軽量かつ高速に動作する点です。また、セキュリティ面でも、米国国立技術研究所（NIST）が定める厳格なセキュリティ規格であるFIPS 140-2およびFIPS 140-3に準拠しており、高いセキュリティを実現しています。これらの特長は、Linkerdがサービスプロキシの開発言語としてRustを採用し、独自に開発されたことに由来します。開発当時、サービスプロキシにはEnvoyが利用されることが標準的でしたが、Rustで開発されたサービスプロキシは非常に珍しいものでした。

さらに、Buoyant社は、Linkerdをベースに構築された商用向けディストリビューション「Buoyant Enterprise for Linkerd」を有償で提供しています。特に、エッジコンピューティングのようなリソースに制約があり、かつ、セキュリティが重視される場面での活用が期待されています。

3. Kuma

項目	説明
開発元	Kong（アメリカ）
初版リリース年	2019年
CNCF参画年	2020年
成熟度	CNCF Sandbox
ライセンス	Apache-2.0
コントロールプレーン	Kuma
データプレーンプロキシ	Envoy

Kumaはenvoyベースで作成された、KubernetesとVMマシン両方に対応しているサービスメッシュに関連するOSSです。Kumaは商用化を意識しており、Kong MeshというKumaを商用化したサービスがあります。特にマルチゾーン展開を重視しており、Kongが提供するAPI Gatewayと組み合わせた、包括的なプラットフォームサービスを提供しています。

4. Kmesh

項目	説明
開発元	OpenEuler (中国)
初版リリース年	2023年
CNCF参画年	2024年
成熟度	CNCF Sandbox
ライセンス	Apache-2.0
コントロールプレーン	Istio
データプレーンプロキシ	なし（プロキシの役割をeBPFで代用）

Kmeshは、eBPFとプログラマブルカーネルを活用した、サイドカーレスのサービスメッシュを実現するOSSです。Kmeshでは、メッシュ間の通信をカーネルレベルで処理し、コントロールプレーンとデータプレーン間のやり取りは「Kmesh-daemon」を介して行われます。

eBPFとKmesh-daemonを活用することで、パケットの処理をユーザー空間ではなくカーネル空間で直接行うことができるため、従来のサイドカー方式に比べて処理速度が大幅に向上します。これにより、アプリケーションの負荷を低減し、通信のレイテンシも抑えられるため、より高速かつ効率的なサービスメッシュを実現しています。

開発元のOpenEulerは、Huaweiが主導するクラウドサービス向けOSSコミュニティであり、中国国内の多くの企業が参画しています。Kmeshは、OpenEulerプロジェクトの一つとして位置づけられています。

Kmeshのサービスメッシュアーキテクチャ構成図

5. Sermant

項目	説明
開発元	Huawei Cloud（中国）
初版リリース年	2022年
CNCF参画年	2024年
成熟度	CNCF Sandbox
ライセンス	Apache-2.0
コントロールプレーン	Sermant
データプレーンプロキシ	なし

Sermantは、Javaベースのマイクロサービスに特化したプロキシレスのサービスメッシュに関するOSSです。Sermantのアーキテクチャは、「Plugin layer」と「Framework layer」の2層構造で設計されています。

Plugin layerは、SPI（Service Provider Interface）を利用して実装されており、Sermantに独自の機能を柔軟に追加できる拡張性を持っています。具体的には、トラフィック制御や認証・認可などの機能をプラグインとして開発し、組み込むことが可能です。

Framework layerは、Plugin layerで作成された各プラグインが動作するための基本的な実行環境やライフサイクル管理、プラグインの呼び出し制御などの基盤機能を提供します。これにより、プラグインの開発者は細かな制御処理を意識せず、機能追加に集中できます。

また、Sermantは他のサービスメッシュとは異なり、Java Agentを使用してアプリケーションに直接トラフィック制御などの機能を注入します。Java Agentは、Java仮想マシン（JVM）の起動時や実行時にバイトコードを書き換えることができるため、Sermant内でプラグインを作成・実行する際の基盤技術として利用されています。

Sermantのサービスメッシュアーキテクチャ構成図

調査結果からわかること・考察

調べてみようでは、サービスメッシュに関連するOSSについて概要を紹介しました。
これらのサービスメッシュに関連するOSSについて、人気とアーキテクチャの2つの観点で比較・分析を行います。さらに、これらの分析から今後のサービスメッシュに関連するOSSの動向について考察します。

まず、5つのサービスメッシュに関連するOSSを眺めていると、直近5年でパラダイムシフトが起こっていそうと考えました。そのため、リリース年が2017年から2020年の初期段階でリリースされたOSS（Group A）と2022年以降にリリースされたOSS（Group B）の2つのグループに分類し、考察してみたいと思います。

サービスメッシュに関連するOSSに関する分類図。Gourp AにはIstio、Kuma、Linkerdの3つのOSSが含まれており、Group BにはKmeshとSermantの2つのOSSが含まれています。

サービスメッシュに関連するOSSの人気に関する比較分析

サービスメッシュに関連するOSSの動向を定量的に把握するため、各OSSについて年ごとにGitHubのスター数の推移とその増加量を算出し、比較しました。データセットはGitHub Star Historyから取得しています。

まず、Istioは最もスター数が多く、リリース年が早いほど累積スター数も大きい傾向が見られました。一方で、リリース初期と比べて現在のスター数の増加率は鈍化しており、これはサービスメッシュに関連するOSS全体に共通する傾向です。すなわち、サービスメッシュに対する需要や関心が以前より低くなっていることを示しています。実際、CNCFによる2024年の年次調査では、2023年と比べてサービスメッシュに関連するOSSの導入に慎重な姿勢を取る企業が増加し、本番環境での運用数も低下傾向であることが確認されています。

ただし、OSSを提供する企業や団体の所在国について考慮する必要があります。Group Aに属するOSSはアメリカや欧州の企業によって開発されたものであり、特に規制されることなくGitHubから使用することができます。一方、Group Bに含まれるOSSは中国コミュニティによって開発されたものであり、中国国内ではサイバーセキュリティ法などの規制により、中国版GitHubである gitee のような現地プラットフォームが主流となっています。このため、Group BのOSSは中国国内で広く利用されている可能性があります。しかし、今回の調査データには中国国内での使用・運用数が十分に反映されていない可能性があり、グローバルな比較の際にはこの点を考慮する必要があります。

各OSSごとの年別のGitHubのスター数に関する推移図

各サービスメッシュのアーキテクチャに関する比較分析

調べてみようで紹介した各OSSのアーキテクチャの特徴を表にまとめました。

OSS名	グループ名	アーキテクチャの特徴
Istio	Group A	サイドカーモード・アンビエントモード（2022年以降）
Linkerd	Group A	サイドカーモード
Kuma	Group A	サイドカーモード
Kmesh	Group B	カーネル空間でのデータ通信（サイドカーレス）
Sermant	Group B	JavaMeshを用いたサイドカーレス

上表から、GroupAに属するOSSでは、サイドカーモードを採用しているものがほとんどでした。
一方、2022年以降のOSSでは、これまで主流だったサイドカーモードによる実装を避けるようなアーキテクチャ設計を行っています。
この変化は、サイドカーモードの問題点から生じたものであり、例として以下が挙げられます。

• クラスター内でCPUやメモリリソースを余分に占有してしまうこと
• サイドカーで行われるHTTPなどの処理から生じる遅延が避けられないこと

そのため、2022年以降のサービスメッシュでは下記に示すアプローチによってサイドカーモードの問題点を解消する動きがみられました。

• Pod間の通信をカーネルレベルで制御することで、プロキシを経由することによるオーバーヘッドを削減する。（Kmesh）

• 各ノード上のすべてのPodがアクセスできる共有プロキシを配置することで、クラスタ内の計算リソースを効率的に分配する。（アンビエントモード）

• アプリケーションそのものにJava Agentを挿入することで、プロキシなしにアプリケーションの動作を変更する。（Sermant）

しかし、多様なアーキテクチャが存在していますが、現状ではサイドカーレスサービスメッシュの設計方法が統一されていません。そのため、今後もサイドカーレスサービスメッシュのアーキテクチャはさらに多様化していき、やがていくつかの実現方式へと収束すると考えられます。

今後の動向

サービスメッシュに関連するOSSの人気に関する比較分析で示した通り、サービスメッシュに関連するOSSに対する関心は低下傾向にあります。その背景として、2024年CNCF年次調査では、以下のような要因が挙げられています。

Service Mesh は、過去と比較して組織からの関心度がやや低下しているようです。(中略) この状況には、複雑さ、コスト、パフォーマンスに関する懸念など、複数の要因が考えられます。多くの組織は、Service Mesh の導入が運用上のオーバーヘッドを大幅に増加させ、管理や維持が困難になることを指摘しています。Service Mesh は専門的な知識を要するメンテナンスが必要で、パフォーマンスのオーバーヘッドを引き起こし、遅延やスループットの問題を引き起こす可能性があります。また、よりコスト効率が高く軽量なソリューション（例えば Kubernetes）が台頭していることも要因の一つです。

このうち、

Service Mesh の導入が運用上のオーバーヘッドを大幅に増加させ、管理や維持が困難になることを指摘しています。

という指摘は、サービスメッシュ自体が抱える導入・運用上の課題を示しています。サービスメッシュによって高機能なマイクロサービスを実現できる一方で、その代償としてインフラの複雑化や運用コストの増加が避けられません。また、技術的難易度の高さから、十分な知識・経験を持つ技術者の確保も課題となっています。こうした課題を対応するために、ベンダー側がサービスメッシュに関連するOSSの商用版を提供していると考えられます。たとえば、「Buoyant Enterprise for Linkerd」 や 「Kong Mesh」 では、専門のエンジニアによる技術サポートや導入コンサルティングを受けることが可能です。これにより、企業はサービスメッシュの設計・導入・運用に関する専門的な知見やベストプラクティスを活用でき、社内に十分な知見を持つ技術者がいない場合でも安心してサービスメッシュを活用できる環境が提供されます。

分析結果を踏まえたサービスメッシュに関連するOSSの動向をまとめると以下のようになります。

• 現状、サービスメッシュ運用の障壁が高いため、運用上のリスクを許容できるケースのみ導入されている。
• 既存のサイドカーモードの問題点を改良したサービスメッシュのアーキテクチャが開発され、いくつかの実現方式へと統合されていく。
• 既存OSSを商用化し、技術スタッフによるサービスメッシュの運用サポートを含めて提供するケースが増加すると予想される。

感想

サービスメッシュに関するOSSを調査してみて、技術的・社会的な観点で変化や特徴があって面白かったです。今後は、Istioのアンビエントモードについて興味があるので詳しく調べたいと思います。