💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「service mesh がまた難しくなった」

KubeCon EU 2024。あるSREがステージで冗談を飛ばした。「service mesh を知っていると言うのはやめてください。2年前に知っていた mesh はもう存在しません」。会場は笑ったが、半分は本当だった。

2024-2026年に起きたことをまとめると:

- **Istio Ambient mode が 1.22 で GA(2024年)** — サイドカーなしの Istio が現実になった。

- **Linkerd 3(Buoyant)** — 一部機能を paid edition に移し、コミュニティから強い反発。

- **Cilium / Isovalent → Cisco(2024年)** — eBPF メッシュがシスコの傘下に。

- **HashiCorp → IBM(2024年)** — Consul Connect のガバナンスが変わった。

- **Open Service Mesh(Microsoft) — 2024年1月 sunset**

- **AWS App Mesh — 2024年10月 sunset**

- **Kuma(Kong)** — federated multi-zone mesh として定着。

- **Gloo Mesh(solo.io)** — multi-cluster Istio 運用の事実上の標準。

- **Traefik Mesh** — 軽量オプションとして生き残り。

技術的にもっと興味深いのは **モデル自体が分裂した** ことだ。2020年は全員がサイドカー(Envoy が pod の隣に住む)だった。2026年には三つのモデルが共存している。

1. **サイドカーモデル** — 従来 Istio、Linkerd 2/3、Consul Connect のデフォルト。

2. **Ambient モデル(L4 + L7 分離)** — Istio Ambient(ztunnel + waypoint)、Linkerd の一部パターン。

3. **eBPF / proxyless モデル** — Cilium Service Mesh、gRPC-native、JVM の一部。

三つのモデルはトレードオフが異なり、ワークロードと運用体制によって正解が変わる。本稿は **各選択肢の 2026年現在の状態**、**サイドカー vs ambient vs proxyless 論争**、**運用パターン(mTLS・RBAC・トラフィックシフト・可観測性)**、そして **誰が何を選ぶべきか** を整理する。

ひとつだけ先に言っておく: **service mesh はデフォルトではない**。「Kubernetes を使うから mesh を入れる」は 2026年でも間違った推論だ。mesh なしで上手くやっているチームの方が、入れているチームより幸せなことが多い。ただし、本当に必要なチームにとっては、よく選ばれた mesh が運用の質を変える。

1章 · 2026年のサービスメッシュ地図 — 三モデル、七候補

| 選択肢 | モデル | ガバナンス | 2026年の状態 |

| --- | --- | --- | --- |

三モデルを一行でまとめると:

- **サイドカー** — ワークロードの隣に Envoy(または micro-proxy)pod をもう一つ立てる。最も成熟しているが、メモリ・CPU・起動時間・デバッグ複雑度すべてが高い。

- **Ambient** — ノードごとに L4 プロキシ(ztunnel)を置き、L7 ポリシーが必要な名前空間にだけ別の waypoint proxy を立てる。サイドカーのコストを大幅に下げる。

- **eBPF / proxyless** — カーネル空間の eBPF でポリシー・暗号化・可観測性を実装。データプレーンプロキシなしでも mTLS・ポリシーの一部が可能。L7 機能が必要なら Envoy に転送する。

三モデルは **異なるトレードオフ** を持つ。サイドカーは「成熟しているが重い」、ambient は「運用が単純化するが新コンポーネントが増える」、eBPF は「軽いがカーネル・OS・CNI 依存が強い」。普遍的な正解はない。

2章 · Istio Ambient(2024 GA) — ztunnel + waypoint

Istio Ambient mode は 2022年に alpha で始まり、2024年 1.22 で GA となった。中核アイデアは **データプレーンを二層に分ける** ことだ。

[Pod A] ────► [ztunnel(ノード DaemonSet)] ──mTLS──► [ztunnel] ────► [Pod B]

L4(TCP・HBONE トンネル)

L7 が必要なときだけ:

[Pod A] → [ztunnel] → [waypoint proxy(名前空間/サービス単位)] → [ztunnel] → [Pod B]

L7(HTTP route, RBAC, traffic shifting)

- **ztunnel**: Rust で新規実装されたノード DaemonSet。各ノードに 1 つ常駐し、そのノードの Pod トラフィックを HBONE(HTTP-Based Overlay Network Environment、HTTP/2 over mTLS)トンネルでノード間転送する。L4 のみ — TLS・ID・単純な mTLS。

- **waypoint proxy**: L7 ポリシー(HTTP route, header-based routing, RBAC, retry, mirror)が必要な名前空間または service account に限り別 Envoy Pod を立てる。ztunnel は L7 が必要なトラフィックを waypoint へ迂回させる。

**なぜこれが意味を持つのか?**

- **メモリ・CPU の節減**: Pod 100 個にサイドカー 100 個ではなく、ノード 10 個に ztunnel 10 + waypoint 2-3。サイドカー 1 個あたり 50-200 MB の Envoy メモリが不要に。

- **起動時間**: サイドカーは Pod 起動時に同時に立ち上がる必要があり、Pod 起動時間が伸びていた。Ambient はノード DaemonSet が事前に立っているため Pod 起動が速い。

- **アプリとサイドカーのカップリング解消**: サイドカー OOM がアプリを殺したり、サイドカーバージョンがアプリ lifecycle を縛ったりすることが消える。

- **L4 / L7 分離**: L7 が不要なワークロード(多い — 単純な gRPC backend、キューワーカーなど)は ztunnel だけで完結。

**なぜ全員が Ambient に行かないのか?**

- **新コンポーネント二つ**(ztunnel、waypoint)の運用学習。

- **CNI / ネットワーク依存性**: ambient は iptables の上に新しい netfilter ルールを敷く。一部 CNI(特に Cilium の一部バージョン)との衝突事例がある。

- **GA でも一部機能はサイドカー専用**: 特定の EnvoyFilter、WASM 拡張などは ambient で制限。

- **マイグレーションコスト**: 既に sidecar で動いているクラスタを ambient に移す作業自体が大きい。

2026年現在の推奨は **新規クラスタは ambient、既存 sidecar クラスタは段階的に移行**。solo.io の Gloo など商用ディストロが ambient 移行ツールを急速に整備中。

3章 · Istio sidecar(伝統) — 依然として多くの場所で

ambient が GA になったからといってサイドカー Istio が死んだわけではない。2026年現在 **本番稼働中の Istio クラスタの大多数は依然として sidecar** だ。理由は単純 — 「動いているものをわざわざ移さない」。

サイドカー Istio の長所は健在:

- **最も多い事例・ドキュメント・ブログ**。問題が起きれば検索で答えが出る。

- **すべての機能が動く**。EnvoyFilter、WASM 拡張、すべての telemetry v2 機能。

- **他の ingress/egress との統合事例が最も豊富**。

短所も健在:

- **メモリ・CPU コスト** — Envoy サイドカー 1 個あたり平均 50-200 MB。

- **Pod 起動時間の増加** — サイドカーが ready になるまでアプリがトラフィックを受けられない(`holdApplicationUntilProxyStarts`)。

- **アプリとサイドカーの lifecycle 結合** — サイドカー OOM がアプリトラフィックを切る。

- **Istio control plane(istiod) 負荷** — Pod 数が増えるほど xDS push コストが増える。

**いつ sidecar Istio が正解か?**

- 既に運用していて動いているとき(最頻出ケース)。

- 特定の sidecar 専用 EnvoyFilter や WASM がコア機能のとき。

- Ambient を採用するだけのチーム余力がないとき。

推奨: **新規は ambient、既存 sidecar の移行は段階的に**。最も多い間違いは「ambient GA したから即移行」 — 運用学習コストが大きい。

4章 · Linkerd 3 — Buoyant の有料化決定(2024)

Linkerd は 2017年から「サイドカーだが軽量」を武器に、サイドカー陣営のミニマリストを自称してきた。Rust で書かれた linkerd2-proxy(現 `linkerd-proxy`)は Envoy よりメモリ・CPU が大幅に少ない — サイドカー 1 個あたり 10-30 MB 程度。

そんな 2024年、Buoyant(Linkerd の親会社)は **stable release(production-ready ビルド)を paid edition に移すと発表**。無料で入手できるのは edge release(週次ビルド)のみで、production で stable channel を使うには Buoyant Enterprise ライセンスが必要になった。

コミュニティの反応は激しかった:

- 「オープンソース mesh の黄金期が終わった」

- 「これは事実上 source-available への後退だ」

- 「だが Linkerd を維持しているのは非常に小さな会社だ。無限に無料でいられるはずがない」

- 「CNCF graduation プロジェクトでこれは許されるのか?」

**Linkerd 3 の技術変更**:

- サイドカーはそのまま Rust micro-proxy。依然として軽い。

- 一部 ambient スタイルのパターン(サービス単位のポリシー委譲)を導入。

- multi-cluster mTLS と federated 証明書管理の強化。

- **policy** リソースがより豊富に(L7 RBAC など)。

**2026年現在の視点**:

- 技術的には依然として魅力的。**サイドカーで最も軽い**。

- 運用面で本当にシンプル。Istio のように数十の CRD を覚える必要がない。

- しかし production stable ビルドの paid 化により、**CNCF 卒業プロジェクトという安心感を削った**。

- edge channel は自由に使えるが、エンタープライズが unsupported channel を使うのは政治的に難しい。

**選定基準**:

- 軽量でシンプルな sidecar mesh が欲しく、Buoyant Enterprise コストを許容できるなら依然として良い選択。

- 「ベンダーロックイン」が怖いなら Istio Ambient や Cilium Service Mesh で迂回可能。

- 小さなチームが素早く mTLS だけ欲しいなら、依然として最もきれいな選択肢の一つ。

5章 · Cilium Service Mesh — eBPF + Cisco 買収(2024)

Cilium は元々 CNI(Container Network Interface)として始まったが、eBPF ベースの強力さを武器に Service Mesh 領域へ拡張した。2022年に OSS で service mesh 機能を公式化し、2023-2024年に本格的に production 採用が増えた。

**2024年に Cisco が Isovalent(Cilium 親会社)を買収**。eBPF 市場でのシスコの影響力が一気に拡大し、Cilium のエンタープライズディストリビューション — Isovalent Cilium Enterprise — の将来がシスコのセキュリティ・ネットワーキング製品群への統合方向に向かっている。

**Cilium Service Mesh のモデル**:

- **L4 mTLS + ポリシー**: eBPF のみで動作。サイドカー・waypoint なしでノードカーネルで処理。

- **L7 機能(HTTP routing, gRPC, Kafka filter)**: ノードごとの Envoy(DaemonSet)または ingress gateway 形式。サイドカーではない。

- **可観測性**: Hubble で L3/L4/L7 の可視性。eBPF でキャプチャするためサイドカーなしでも非常に豊か。

- **Network Policy 統合**: CiliumNetworkPolicy で L3-L7 を一箇所で。

**なぜ eBPF mesh が魅力的か?**

- **サイドカー 0 個** — メモリ・CPU・起動時間すべて削減。

- **L4 はカーネルで処理** — context switch なしで速い。

- **mesh + CNI が一つ** — 二つのコンポーネントを別管理する必要がない。

- **Hubble 可観測性** — すべてのトラフィックが eBPF でキャプチャされるためサンプリングなしで見える。

**現実的な制約**:

- **カーネル依存**: 新機能には新カーネルが必要。5.x 後半または 6.x 推奨。

- **L7 機能は結局 Envoy** — サイドカーがないだけで、Envoy 自体はどこかに存在する。

- **運用学習**: eBPF・iptables・CNI・NetworkPolicy のインタラクションが複雑。

- **Istio API 互換不足**: Istio に慣れているチームには運用パターンが異なる。

**2026年時点の推奨**:

- 新規クラスタを敷くなら Cilium は CNI として使う価値が十分(多くのクラウドの推奨 CNI)。

- Cilium Service Mesh は「Cilium CNI を既に使っているなら」自然な拡張。

- シスコ買収後のライセンス / ガバナンス変化を注視すること。

6章 · Consul Connect — HashiCorp → IBM 買収(2024)

Consul は 2014年から HashiCorp の service discovery・KV store として始まり、Consul Connect で service mesh 領域に進出した。**VM と Kubernetes を同時に扱う mesh** という点が最大の差別点だった — Istio・Linkerd が Kubernetes-first であるのに対し、Consul は最初から VM・bare-metal までを mesh に束ねられた。

**2024年に IBM が HashiCorp を買収**。Terraform・Vault・Consul・Nomad など HashiCorp の全製品が IBM 傘下へ。ガバナンス・ライセンス(既に 2023年に BSL へ変更)の両方に影響が出た。

**Consul Connect の強み(健在)**:

- **ハイブリッド環境**: VM + Kubernetes + bare-metal を一つの mesh に。

- **multi-datacenter / WAN federation**: 早期からよく対応。

- **Vault 統合**: Consul Connect の CA を Vault に委譲可能。

- **Service mesh + service discovery + KV**: 統合プラットフォーム。

**弱み・懸念**:

- **BSL ライセンス(2023)**: 既に自由 OSS ではない — 競合 SaaS 提供が制限される。

- **IBM 買収後のロードマップ不透明**: 一部ユーザーは OpenTofu 系の fork(Consul 向けは未成熟)を懸念。

- **Kubernetes-only 環境** では Istio / Linkerd 比で魅力が下がる。

**いつ Consul Connect が正解か?**

- VM と Kubernetes を同時に扱うハイブリッド環境。

- 既に HashiCorp スタック(Terraform・Vault・Nomad)を深く使っている組織。

- multi-region / multi-datacenter mesh が中核。

**いつ避けるか?**

- 純粋な Kubernetes-only で、ベンダーロックインが負担なとき。

- ライセンス変更に敏感な OSS-first 組織。

7章 · Kuma(Kong) — federated mesh

Kuma は Kong が 2019年に作成し、2020年に CNCF Sandbox に寄贈した mesh。技術的には Envoy ベースのサイドカー mesh だが、最大の特徴は **multi-zone / federated** モデルだ。

**Kuma のアーキテクチャ**:

- **global control plane**(グローバルポリシー管理) + **zone control plane**(各クラスタ/リージョン)。

- 一つの mesh が複数クラスタ・複数クラウド・VM を横断できる。

- Universal mode(VM/bare-metal)と Kubernetes mode の両方をサポート。

**他 mesh 比の強み**:

- **multi-zone が first-class**: Istio・Linkerd の multi-cluster より運用モデルがシンプル。

- **policy → mesh 単位で fan-out**: 一箇所で定義すれば全 zone に伝播。

- **Kong API Gateway との統合**: API ゲートウェイまで mesh の一部に。

**弱み**:

- Istio ほどの広範なドキュメント / 事例が不足。

- 一部 L7 高度機能は Istio 比で遅れて入る。

- Kong の商用化戦略次第で OSS feature set が影響を受ける可能性。

**いつ Kuma?** multi-cluster / multi-cloud / hybrid 環境で運用シンプルさが核のとき。特に既に Kong API Gateway を使っているなら自然。

8章 · Gloo Mesh(solo.io) — multi-cluster Istio

solo.io の Gloo Mesh は **Istio の上に載せた商用 multi-cluster コントロールプレーン** だ。Istio 単体は単一クラスタ運用はうまく動くが、**複数クラスタを一つの mesh に束ねる作業**(多クラスタ federation、共通証明書、cross-cluster service discovery)は運用上複雑。Gloo Mesh はその部分を商用製品で抽象化する。

**Gloo Mesh が解決する問題**:

- **multi-cluster Istio federation の自動化**: 証明書・trust domain・east-west gateway セットアップが GUI / CLI で単純化。

- **グローバルポリシー管理**: ポリシーを一箇所で定義 → 全クラスタに伝播。

- **VirtualService・DestinationRule の abstraction**: より高水準の RouteTable・VirtualGateway CRD。

- **Ambient マイグレーション支援**: solo.io が ambient 陣営の主要コントリビュータの一つ。

**誰が使うか**: 大規模エンタープライズ、特に multi-cluster Istio が中核な場所。金融・通信・一部ビッグテック SRE 組織。

**代替**: OSS Istio + 自前 multi-cluster セットアップ(可能だが運用コスト大)、または Cilium ClusterMesh。

9章 · Traefik Mesh — 軽量オプション

Traefik Mesh(旧 Maesh)は **DaemonSet ベースの軽量 mesh** だ。サイドカーモデルではなく、ノードごとのプロキシ(Traefik 自体)が一つでそのノードのトラフィックを処理する。モデル的には ambient の ztunnel に近い — ただし作られた時期はずっと早い(2019)。

**長所**:

- **サイドカーなし** — メモリ・起動時間の負担が少ない。

- **運用シンプル** — Traefik に慣れたチームにとっては学習コストが小さい。

- **SMI(Service Mesh Interface) 互換** — 標準 API。

**短所**:

- **L7 ポリシーの豊富さが Istio レベルではない**。

- **mTLS・複雑な RBAC** は他 mesh より単純。

- **コミュニティ規模が Istio・Linkerd・Cilium より小さい**。

**いつ Traefik Mesh?** 小さなクラスタ、単純なトラフィックポリシーのみ必要な場所、既に Traefik ingress を使っている場所。

10章 · OSM / AWS App Mesh 終了の意味

**Open Service Mesh(Microsoft)** — 2024年1月 sunset。

**AWS App Mesh** — 2024年10月 sunset。

二つの mesh 終了は業界にシグナルを残した。

**OSM の終了が示すこと**:

- Microsoft が自前 mesh より **Istio・Cilium の採用を追う方が合理的** と判断。

- AKS(Azure Kubernetes Service)は今や Istio add-on をデフォルト推奨。

- **クラウドベンダーが自前で mesh を構築するモデルの限界** — コミュニティモメンタムについていけない。

**App Mesh の終了が示すこと**:

- AWS も自前 mesh を諦めた。**AWS Cloud Map + ALB/NLB + EKS 上の OSS mesh(Istio/Linkerd)** パターンへの回帰。

- EKS 顧客が App Mesh より Istio/Linkerd/Cilium をより多く採用したことを認めた決定。

- AWS は代わりに **App Mesh を deprecate し、マイグレーションガイドを提供** する形で整理。

**全体の教訓**:

1. **mesh は OSS コミュニティ + CNCF 傘下が強い場所に集中する** — Istio、Linkerd、Cilium、Kuma。

2. **クラウドベンダー自前 mesh は生き残りにくい** — Google ですら ASM(Anthos Service Mesh)を Istio ベースで作る。

3. **mesh の価値は portability** — 一つの mesh で複数クラウドを束ねるのが核。ベンダー固有 mesh はその価値と衝突する。

11章 · mTLS / RBAC / Traffic shifting / 可観測性パターン

どの mesh を選んでも結局運用するパターンは似ている。中核の 4 つ。

11.1 mTLS — 最も多い導入理由

mesh を入れる最頻出理由。ゼロトラストネットワークの第一歩。

- **STRICT mode**: mesh 内部のすべてのトラフィックは mTLS のみ許可。外部からの平文は拒否。

- **PERMISSIVE mode**: mTLS と平文の両方を許可。マイグレーション段階で使用。

- **CA 管理**: Istio は istiod が CA、Cilium は SPIRE 統合、Consul は Vault 委譲。

運用 Tips:

- **段階導入**: PERMISSIVE → STRICT の順。一気に STRICT にすると未識別平文トラフィックで事故になる。

- **外部統合**: データベース・Kafka・外部 API は mesh の外。egress gateway でポリシーを別に組む。

- **証明書ローテーション**: 7日がデフォルト。短すぎると control plane 負荷増。

11.2 RBAC — 誰が誰を呼べるか

`AuthorizationPolicy`(Istio)、`Server` / `ServerAuthorization`(Linkerd)、`CiliumNetworkPolicy`(Cilium)で表現。

Istio 例 — frontend ServiceAccount のみが backend の /api を呼べる

apiVersion: security.istio.io/v1

kind: AuthorizationPolicy

metadata:

name: backend-policy

spec:

selector:

matchLabels:

app: backend

rules:

- from:

- source:

principals: ['cluster.local/ns/default/sa/frontend']

to:

- operation:

paths: ['/api/*']

運用 Tips:

- **default-deny → allow ルール**: ゼロトラスト原則。

- **principal は ServiceAccount ベースで** — 名前空間・ラベルベースは変更に弱い。

- **L7 ポリシーを過度に細かく組まない** — コード変更のたびにポリシー変更が必要になる。

11.3 Traffic shifting — canary / blue-green / A/B

mesh のキラー機能。weighted routing で新バージョンを段階公開。

Istio — v1 に 90%、v2 に 10%

apiVersion: networking.istio.io/v1

kind: VirtualService

metadata:

name: payment

spec:

hosts: ['payment']

http:

- route:

- destination: { host: payment, subset: v1 }

weight: 90

- destination: { host: payment, subset: v2 }

weight: 10

運用 Tips:

- **Argo Rollouts / Flagger と組み合わせる**: 自動 progressive delivery。

- **メトリクスベース自動 rollback**: error rate / latency が閾値超で自動復旧。

- **header-based routing で内部 dogfood**: 特定ヘッダ付きリクエストのみ v2 へ — 社員トラフィックで先に検証。

11.4 可観測性 — golden signals

mesh が自動キャプチャする 4 つ:

1. **トラフィック**: RPS、bytes/sec

2. **エラー**: 5xx 比率、gRPC error code

3. **レイテンシ**: p50、p95、p99

4. **飽和**: キュー長、コネクションプール

ダッシュボード:

- **Istio**: Kiali(サービスグラフ) + Grafana(メトリクス) + Jaeger/Tempo(トレース)。

- **Linkerd**: 自前 viz extension(軽量)。

- **Cilium**: Hubble UI(eBPF ベース、非常に豊富)。

運用 Tips:

- **trace sampling は 1-5%**: 100% はバックエンド(Tempo/Jaeger)負荷大。

- **メトリクス cardinality 管理**: pod label をそのままメトリクスに載せない(Prometheus 爆発)。

- **サービスグラフは発見用**: 平常時は見ない、事故時に最速のツール。

12章 · サイドカー vs ambient vs proxyless 論争

2024-2026年で最も激しかった mesh 論争。一行まとめ:

- **サイドカー**: 成熟しているが重い。

- **Ambient**: コストを下げるが新コンポーネントが増える。

- **eBPF / proxyless**: 最も軽いがカーネル・CNI 依存が強い。

サイドカーの立場(Istio sidecar、Linkerd 2/3)

- **すべての機能が動く** — EnvoyFilter、WASM、telemetry v2。

- **isolation が強い** — ある Pod の mesh 設定が他 Pod に影響しない。

- **デバッグが直感的** — どの Pod のサイドカーを見ればよいか分かる。

- コスト? 「メモリ 100 MB はクラウドインスタンスに比べれば小さい」

Ambient の立場(Istio Ambient)

- **メモリ・起動時間の大幅減** — Pod 100 個 × 100 MB = 10 GB が消える。

- **アプリとサイドカーの lifecycle decoupling** — サイドカー更新 ≠ アプリ再起動。

- **L4 / L7 分離** — L7 ポリシーが必要な場所にのみ waypoint。

- 短所? 「新コンポーネント二つの運用。それでもサイドカーよりまし」

eBPF / proxyless の立場(Cilium)

- **サイドカー・waypoint・ztunnel すべてなし** — ノードカーネルが処理。

- **L4 mTLS・ポリシーはカーネルで** — 最も軽い。

- **Hubble でサンプリングなしに観察** — 可観測性が豊富。

- 短所? 「L7 機能は結局 Envoy が必要。カーネル依存が強い」

2026年のコンセンサス(緩やかだが)

1. **新規クラスタ** → ambient(Istio)または eBPF(Cilium)。サイドカーは新規には推奨しない。

2. **既存 sidecar クラスタ** → 運用チームの余力に応じて段階的に ambient へ。

3. **CNI を新規選定中** → Cilium は強力な候補。Cilium を選んだなら Cilium Service Mesh も自然。

4. **ハイブリッド(VM + K8s)** → Consul Connect または Kuma。

論争は終わっていない。ただしサイドカー only の時代は終わった。

13章 · 韓国 / 日本の事例 — Toss、Kakao、メルカリ、サイボウズ

Toss — Istio + 段階的 ambient 実験

Toss は決済・証券・銀行を一つの K8s で運用。セキュリティ・監査要件で mTLS は必須で、Istio sidecar で開始。2024-2025年から **ambient mode を新規クラスタに限り導入**、段階的に sidecar クラスタを移行中。

中核の選定理由:

- **金融監査要件**: mTLS、監査ログ、RBAC を mesh で一元化。

- **multi-cluster 可視性**: Kiali + Grafana + Tempo 組み合わせ。

- **新規は ambient**: Pod メモリ削減効果が千単位 Pod 運用で大きい。

Kakao — Istio + 自前 control plane ツール

Kakao は大規模マイクロサービスインフラに Istio sidecar ベース。**自前 control plane ツール**(VirtualService・DestinationRule をより安全に管理する GitOps レイヤー)を作り、運用チームと開発チームのポリシー変更の摩擦を減らした。

中核パターン:

- **canary は自前 progressive delivery ツールで**: Argo Rollouts ベース。

- **mTLS は STRICT、RBAC は default-deny**。

- **trace sampling は 1%、error trace は 100%**。

メルカリ(日本) — Istio + Cloud Run/GKE ハイブリッド

メルカリは GKE ベース Istio sidecar で開始。一部ワークロードを Cloud Run に移すにつれ mesh 外部呼び出しが増え、**ingress/egress gateway パターン** で外部統合をきれいに整理した。

技術ブログ公開事例:

- **mTLS をすべての service-to-service で義務化**。

- **Backstage + Istio CRD** 統合でポリシー変更を PR ベースワークフローに。

- **gRPC + Envoy gRPC-Web filter** — フロントエンド統合。

サイボウズ(日本) — Linkerd 2/3 採用、軽量優先

サイボウズ(kintone など)は OSS フレンドリーなエンジニアリング文化で有名。**Linkerd を選んだ理由はシンプルさ**。Istio の複雑さを引き受けるより、Linkerd の軽い運用パターンを好む。

2024年の Buoyant 有料化発表後に再評価したが、**edge channel + 一部 community ビルドで運用を維持する方向** を検討中という後談(公式発表なし — コミュニティ推測)。

14章 · 誰が何を選ぶべきか — 決定木

Q1. mesh が本当に必要か?

├── いいえ(mTLS のみ必要) → cert-manager + アプリライブラリ mTLS / SPIFFE/SPIRE 直接

├── いいえ(trace のみ必要) → OTel SDK + Tempo/Jaeger

└── はい → 次へ

Q2. 環境は?

├── 純 K8s、単一クラスタ

│ ├── 新規 → Istio Ambient or Cilium Service Mesh

│ └── 既存 sidecar → 段階移行

├── 純 K8s、多クラスタ

│ ├── OSS のみ → Cilium ClusterMesh or Kuma

│ └── エンタープライズ支援必要 → Gloo Mesh(solo.io)

├── ハイブリッド(VM + K8s)

│ └── Consul Connect or Kuma(Universal mode)

└── 非常に小さなクラスタ、単純ポリシー

└── Traefik Mesh

Q3. チーム余力は?

├── 運用人員が少ない → Linkerd 3(軽量、有料許容可なら)or Traefik Mesh

├── 運用人員が多い → Istio Ambient(フル機能)

└── eBPF 経験あり → Cilium Service Mesh

Q4. CNI は?

├── Cilium 使用中 → Cilium Service Mesh が自然

├── Calico/その他 → Istio Ambient / Linkerd

└── クラウドデフォルト CNI → それが互換するか先に確認

**一行推奨(2026年5月基準)**:

- 一般新規 K8s: **Istio Ambient** または **Cilium Service Mesh**。

- 小さなチーム、シンプルさ優先: **Linkerd 3**(有料許容可なら)または **Traefik Mesh**。

- ハイブリッド(VM + K8s): **Consul Connect** または **Kuma**。

- 多クラスタエンタープライズ: **Gloo Mesh**。

最も重要なメタ推奨: **mesh を入れる前に、mesh なしで生きられないかもう一度問え**。本当に mesh が必要なチームは思ったより少ない。

参考 / References

- Istio Ambient Mode — https://istio.io/latest/docs/ops/ambient/

- Istio 1.22 Release Notes(Ambient GA) — https://istio.io/latest/news/releases/1.22.x/announcing-1.22/

- Linkerd by Buoyant — https://linkerd.io/

- Buoyant stable release policy change(2024) — https://buoyant.io/blog/changes-to-stable-distribution

- Cilium Service Mesh — https://cilium.io/use-cases/service-mesh/

- Isovalent acquired by Cisco(2024) — https://www.isovalent.com/blog/post/welcome-isovalent-cisco/

- HashiCorp + IBM(2024) — https://www.hashicorp.com/blog/hashicorp-joins-ibm

- Consul Connect — https://developer.hashicorp.com/consul/docs/connect

- Kuma — https://kuma.io/

- Gloo Mesh(solo.io) — https://www.solo.io/products/gloo-mesh/

- Traefik Mesh — https://traefik.io/traefik-mesh/

- Open Service Mesh sunset announcement — https://github.com/openservicemesh/osm

- AWS App Mesh end-of-support — https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html

- CNCF Service Mesh Landscape — https://landscape.cncf.io/?group=projects-and-products&view-mode=card#orchestration-management--service-mesh

- Envoy Proxy — https://www.envoyproxy.io/

- SPIFFE/SPIRE — https://spiffe.io/

- Service Mesh Interface(SMI) — https://smi-spec.io/

- メルカリ Tech Blog — https://engineering.mercari.com/

- サイボウズ Tech Blog — https://blog.cybozu.io/