アンビエントメッシュ（サイドカーレスサービスメッシュ）

サイドカー方式が抱える「N倍」の問題

サービスメッシュ（/devops/service-mesh-sidecar-internals/）は本来、通信の暗号化・再試行・可視化をアプリから引き剥がすための仕組みでした。従来方式はこれを 各ポッドに Envoy サイドカーを注入する ことで実現します。ポッド数が N なら Envoy プロセスも N 個立ち上がり、各々がメモリ・CPU・起動時間を消費します。

この設計には構造的な欠点があります。プロキシのメモリはワークロード本体の通信量ではなく ポッド数 に比例して増える。ポッドがスケールアウトするたびにサイドカーも複製され、クラスタ全体では「アプリのメモリ + サイドカーのメモリ×N」が積み上がります。さらに init コンテナによるインジェクションはポッド起動順序に依存し、サイドカーの起動・再起動はアプリのライフサイクルに縛られます（sidecar なしでポッドが立ち上がってしまう競合や、メッシュ設定変更のたびに全ポッド分のサイドカーへ配信が要る運用コストも同根です）。

アンビエントメッシュは、この「1ポッド=1プロキシ」という前提そのものを外します。

ztunnel と waypoint：2層のデータプレーン分離

アンビエントメッシュの核心は、サイドカー方式が1つのEnvoyへ集約していた仕事を L4 と L7 で別プロセス・別スケール単位に分ける ことです。

ztunnel はノードあたり1つだけ動く軽量プロキシで、同一ノード上の全ポッドの L4 通信を代行します。ポッドが増えても新しい ztunnel は立たず、既存の ztunnel に登録が増えるだけです。ztunnel は Rust で実装され、HTTP パースや L7 のポリシー評価を持たない分だけ薄く、mTLS のハンドシェイクと SPIFFE ID の検証に処理を絞っています。

waypoint はサイドカー方式の Envoy に相当する仕事——L7 のリトライ・タイムアウト・ヘッダベースルーティング・きめ細かい認可——を担いますが、全ポッドに刺さるのではなく、L7 制御が必要な名前空間やサービスアカウント単位でのみ配置 されます。L7 の機能を使わない通信はwaypointを経由せず、ztunnel止まりで完結します。

[サイドカー方式]
Pod-A(App+Envoy) → Pod-B(App+Envoy)   ※ Envoy はポッド数と同数

[アンビエントメッシュ]
Pod-A(App) → ztunnel(Node-A) → ztunnel(Node-B) → Pod-B(App)   ※ L4のみで完結する場合
Pod-A(App) → ztunnel(Node-A) → waypoint(必要な場合のみ) → ztunnel(Node-B) → Pod-B(App)

トラフィック傍受の変化：ポッド単位からノード単位へ

サイドカー方式は iptables や eBPF でポッド内のトラフィックを同一ポッドのサイドカーへ迂回させていました（/devops/service-mesh-sidecar-internals/、/devops/cni-pod-networking/）。アンビエントメッシュでは迂回先がポッド内ではなく ノード上の ztunnel になるため、傍受の実装も変わります。多くの実装は各ポッドのネットワーク名前空間に軽量な転送ルールを敷き、送信パケットをノードの ztunnel（HBONE と呼ばれる mTLS トンネルプロトコルを使うことが多い実装もあります）へ送る形を取ります。ここでも狙いは変わらず「アプリのコードもソケット先も変えずに経路を曲げる」ことですが、曲げた先がポッドごとの専用プロセスではなくノード共有プロセスである 点が構造上の違いです。

サイドカー方式との対比で見るトレードオフ

新たに生じるコストが 段階的なホップ増 です。L4 だけなら送信元ノードの ztunnel と宛先ノードの ztunnel の2ホップで済みますが、L7 制御が必要な経路は waypoint を経由する分、経路が伸びます。全通信を一律に1〜2ホップで扱っていたサイドカー方式に比べ、アンビエントメッシュは 通信ごとにホップ数が変わる非対称な経路 になります。運用者は「どのサービスにL7ポリシーが要るか」を明示的に切り分け、waypointの配置範囲を設計する判断を新たに引き受けることになります。

まとめ

• サイドカー方式は「1ポッド=1Envoy」でL4/L7を一括処理するためポッド数に比例してリソースが増える。アンビエントメッシュは ztunnel（ノード共有・L4）と waypoint（必要箇所のみ・L7） に分離し、コストの単位をポッド数から「L4は常時最小」「L7は使用箇所のみ」へ変える。
• トラフィック傍受はポッド内サイドカーではなくノード上のztunnelへ向かうよう変わるが、「アプリ無改変で経路を曲げる」という原理自体はサイドカー方式と共通。
• 引き換えに、L7制御はwaypointを経由する通信にしか効かないという 適用範囲の非対称性 が生まれ、どこにwaypointを置くかという新しい設計判断が必要になる。/devops/service-mesh-sidecar-internals/ のmTLS/L7制御の原理はztunnel/waypoint双方の内部でも共通して働いている。