Istioを使うならSidecarよりAmbientが良いのか — 人々がAmbientへ移行する理由

結論から言えば、新たにIstioを導入するKubernetes環境であれば、Ambientをまず検討する理由は十分にあります。ただし、Ambientは「L7プロキシをなくす技術」ではありません。すべてのPodに付与していたEnvoy sidecarをなくし、L4セキュリティはノードごとのztunnelで共通化し、HTTP・gRPCのようなL7機能が必要な場所にのみwaypoint Envoyを配置する構造です。

Istioを検討する際、依然として最も馴染みのある図は、アプリケーションコンテナの隣にEnvoy sidecarが付いている姿です。この構造は長年の運用で十分に検証されており、mTLSからきめ細やかなL7トラフィック制御まで一貫して提供します。

しかし、サービスとPodの数が増えるにつれて疑問も生じます。すべてのPodが本当に専用のL7プロキシを持つ必要があるのでしょうか？データベース接続や単純な内部TCP通信にも、HTTPを解釈できるEnvoyが常に必要なのでしょうか？プラットフォームチームがプロキシをアップグレードするためにアプリケーションPodまで再起動しなければならない構造が最善なのでしょうか？

Istio Ambient Meshは、この問題に正面から取り組みます。2024年11月にIstio 1.24で安定版となり、Istioプロジェクトは、新規ユーザーだけでなく既存のsidecarユーザーもAmbientへの移行を積極的に検討していると説明しています。だからといってsidecarが廃止されるわけではありません。公式ロードマップもsidecarを廃止せず、移行は自発的であると明確に述べています。

この記事では、Ambientが実際に何を変えるのか、なぜ人々がこの方式に惹かれるのか、そしてどのような環境では依然としてsidecarがより安全な選択肢なのかを順を追って見ていきます。

まず正すべき誤解：Ambientはプロキシレスメッシュではない

「sidecarless」という表現のため、Ambientをプロキシのないサービスメッシュと理解しがちです。しかし、Ambientにもプロキシは存在します。単にプロキシの位置と責任を変えるだけです。


階層	Sidecarモード	Ambientモード
L4セキュリティ・転送	各PodのEnvoyが処理	各ノードのztunnelが処理
L7 HTTP・gRPC処理	各PodのEnvoyが常に可能	必要なサービス・namespaceのwaypointが処理
デプロイ単位	アプリケーションPodごとに1つ	ノード別ztunnel + 選択的waypoint
プロキシ実装	Envoy	ztunnelはRust、waypointはEnvoy
運用責任	アプリケーションデプロイと強く結合	プラットフォームコンポーネントとして分離

ztunnelはL3・L4のみを処理する軽量なノードプロキシです。ワークロードIDベースのmTLS、L4認可、TCP可観測性、暗号化されたトンネルを担当します。HTTPリクエストを終端したり、ヘッダーを読み取ったりすることはありません。

一方、waypointはEnvoyベースのL7プロキシです。HTTPヘッダーベースのルーティング、リトライ、タイムアウト、サーキットブレーキング、フォールトインジェクション、L7認可、リクエスト単位のメトリクスとトレースが必要な場合に使用します。通常、namespaceやサービスのようなセキュリティ境界単位で共有され、アプリケーションPodの外で別途インストールおよび拡張されます。

したがって、正確な表現は「AmbientがL7プロキシを削除する」ではなく、「すべてのワークロードにL7プロキシを強制しない」です。

図：ztunnelとwaypointを経由するAmbient L7データパス · 出典：Istio Ambient data plane公式ドキュメント, Apache-2.0

人々がAmbientへ移行したい第一の理由：プロキシコストの単位が変わる

Sidecarモードでは、Podが1つ増えるたびにEnvoyも1つ増えます。アプリケーションが20個あり、各サービスが10個のPodで実行される場合、プロキシも200個になります。各プロキシはCPUとメモリを要求し、設定を受け取り、接続とテレメトリーを処理します。

この方式の利点は、隔離が明確であることです。各ワークロードが自身のプロキシを持つため、負荷と障害範囲がPod単位で分かれます。一方、実際のトラフィックが少ないPodにも最悪の瞬間を考慮してプロキシリソースを予約する必要があるため、レプリカ数が多くトラフィックの変動が大きい環境では、使用されない余剰リソースが累積します。

Ambientはコストの単位を変えます。

ztunnelはノードごとに1つ実行されます。
L7が不要なワークロードはztunnelのみを使用します。
L7が必要なサービスのみwaypointを使用します。
waypointは一般的なKubernetes Deploymentのように複数のワークロードが共有し、水平拡張できます。

つまり、コストがなくなるのではなく、Podごとの固定コストがノードごと・L7境界ごとの共有コストに移行します。プラットフォームチームは、実際のL4とL7トラフィック規模に合わせてztunnelとwaypointをそれぞれ容量計画できます。

公式Istio 1.24ベンチマークでは、毎秒1,000個の1KB HTTPリクエストを処理する際、2ワーカーのsidecar1つは約0.20 vCPUと60MB、waypoint1つは約0.25 vCPUと60MB、ztunnel1つは約0.06 vCPUと12MBを使用しました。これらの数値は特定のハードウェアとテスト条件の参考値であり、運用環境での性能を保証するものではありません。重要なのは、個々の数値よりも、ztunnelとwaypointを独立して配置できる構造です。

図：Istio 1.24公式HTTP/1.1 P99遅延時間比較。特定のベンチマーク環境の結果であり、一般的な性能保証ではない · 出典：Istio Performance and Scalability公式ドキュメント, Apache-2.0

第二の理由：メッシュ導入とアプリケーション再起動を分離する

Sidecarの注入はアプリケーションPodの形態を変えます。namespaceにinjectionラベルを付けても、すでに実行中のPodにはsidecarが生成されないため、再起動が必要です。プロキシのバージョンや注入テンプレートを変更する際も、ワークロードのローリング再起動を管理する必要があります。

Ambientでは、namespaceやワークロードにambientラベルを付けるだけで、実行中のPodをL4メッシュ内に登録できます。アプリケーションコンテナのspecを変更したり、sidecarを追加したりすることもありません。

この変更が特に重要な対象は以下の通りです。

再起動コストが大きいステートフルワークロード
実行時間が短く、sidecarの起動・終了と衝突しやすいJob
数百のDeploymentを複数のチームが分担して管理するクラスター
プラットフォームチームがアプリケーションリリースとは別にメッシュをアップグレードしたい組織

ただし、既存のsidecarからAmbientへ移行する際は順序を守る必要があります。公式ガイドでは、waypointの有効化、ambient登録、sidecar injectionの削除、既存Podの再起動の順序を推奨しています。Ambient登録自体には再起動は不要ですが、既存Podで既に実行中のsidecarを削除するには、結局一度はPodを交換する必要があります。

第三の理由：L4セキュリティとL7機能を段階的に導入できる

伝統的なsidecarは機能が豊富である反面、事実上バンドル商品です。mTLSだけが必要な場合でも、各PodはHTTPルーティングとリトライを実行できるEnvoy全体を持ちます。

Ambientはメッシュ導入を2段階に分けます。

まずztunnelでワークロードID、mTLS、L4認可、TCPテレメトリーを適用します。
実際にHTTP認識が必要なnamespaceやサービスにのみwaypointを追加します。

この方式は、サービスメッシュを一括で全社適用するのが難しい組織に現実的な導入点を提供します。最初は「クラスター内部通信をIDベースのmTLSで暗号化し、L4ポリシーを統一する」という目標だけを達成し、その後カナリアルーティングやL7認可が必要なサービスだけを選択できます。

L7機能が必要な代表的なケースは以下の通りです。

URL・ヘッダー・メソッドベースのルーティングと認可
HTTPリトライ、タイムアウト、サーキットブレーキング
トラフィック分割とフォールトインジェクション
リクエスト単位のメトリクス、アクセスログ、分散トレース

Ambientの魅力はL7を諦めることにはありません。L7が必要な理由とコストをサービスごとに明示させることにあります。

第四の理由：プラットフォームチームとアプリケーションチームの責任境界が明確になる

SidecarはアプリケーションPod内にありますが、ほとんどがプラットフォームチームによって管理されます。この曖昧な位置が運用上の対立を生み出します。

アプリケーションチームは、要求していないコンテナとリソース予約を受け入れなければなりません。
プラットフォームチームは、プロキシをアップグレードするためにアプリケーションのデプロイ日程を調整しなければなりません。
障害が発生した場合、アプリケーションとsidecarのどちらが原因であるかを共同で調査する必要があります。
HPA、startup probe、Job終了などの動作がsidecarのライフサイクルの影響を受ける可能性があります。

Ambientのztunnelとwaypointは、アプリケーションPodの外にある明示的なインフラコンポーネントです。プラットフォームチームはプロキシのデプロイ、拡張、アップグレードを担当し、アプリケーションチームはどのようなL4・L7ポリシーが必要かを宣言します。

特にwaypointがKubernetes Gateway APIを使用するという点も重要です。waypoint自体はGatewayリソースとしてデプロイし、HTTPRouteやAuthorizationPolicyのようなポリシーは対象サービスに接続します。これにより、プロキシトポロジーとアプリケーションデプロイを分離し、Kubernetes標準に近い運用モデルを構築できます。

第五の理由：L7リクエストがプロキシを通過する回数を減らせる

SidecarモードでサービスAがサービスBを呼び出す場合、通常、リクエストはAのsidecarとBのsidecarを順に通過します。L7処理は出発地と目的地の両方で発生します。

Ambientでは、L7ポリシーは基本的に目的地のwaypointが担当します。AのztunnelがBを担当するwaypointにリクエストを送り、waypointがポリシーを処理した後、Bノードのztunnelに転送します。同じリクエストに対してL7 Envoyを一度だけ通過する構造です。

これが常に速いという意味ではありません。waypointまでのネットワークパス、共有プロキシの負荷、接続再利用、パケットサイズ、ポリシーの複雑さによって結果は異なります。しかし、両方のsidecarで繰り返されていた同じL7処理のパスを、目的地中心の1点に単純化する可能性は明らかです。

性能を判断する際は、製品紹介資料の平均値よりも、実際の環境で以下を測定する必要があります。

L4専用パスとL4+L7パスのp50・p95・p99遅延時間
waypointがないサービスとあるサービスのCPU・メモリ使用量
waypoint水平拡張中の接続とエラー率の変化
障害が発生したztunnelまたはwaypointの影響範囲
テレメトリーレベルに応じたコスト変化

セキュリティは無条件に良くなるのではなく、信頼境界が変わる

Ambientを説明する際に「sidecarよりも安全だ」と断定すると、重要なトレードオフを見落とします。

Sidecarモードは、ワークロードごとに個別のプロキシとIDキーを持つため、プロキシ自体が侵害されていないという前提では最もきめ細やかな隔離を提供します。しかし、アプリケーションコンテナとsidecarは同じPodのネットワークとセキュリティ境界を共有します。アプリケーションPodが完全に侵害された場合、攻撃者がsidecar通信やメッシュ資格情報にアクセスする危険性があります。

Ambientでは、アプリケーションPodにメッシュキーを配置しません。ztunnelが自身のノードにあるワークロードのIDとトラフィックを担当するため、一般的なアプリケーションコンテナが侵害されても、メッシュ資格情報を直接取得することは困難です。

逆に、ztunnelはノード上の複数のワークロードを共有します。ztunnelが侵害された場合、そのノードにあるワークロードのネットワークとキーが影響を受ける可能性があります。つまり、AmbientはアプリケーションPodとプロキシ間の信頼境界を分離する代わりに、ノード単位の共有プロキシを重要なセキュリティ境界とします。


セキュリティ観点	Sidecar	Ambient
メッシュキー位置	各アプリケーションPodのsidecar	ノードのztunnel
アプリケーション侵害時	同じPodのプロキシ・キーアクセス危険	メッシュキーがアプリケーションPodの外にある
プロキシ侵害影響	該当ワークロード中心	該当ノードワークロードへ拡大可能
隔離単位	Pod	ztunnelはノード、waypointは選択した境界

どちらがより安全かは脅威モデルによって異なります。「アプリケーションコンテナを信頼できない境界と見なす」のであれば、Ambientの分離が強みです。「共有ノードプロキシの影響範囲を最小限に抑えることが最優先」であれば、sidecarのPodごとの隔離がより馴染み深いかもしれません。

では、新規IstioはAmbient-firstが正解なのか

以下の条件が多く当てはまる場合、Ambientをデフォルト候補とするのが合理的です。

Kubernetes中心の新規Istio環境である。
優先的に必要な機能はmTLS、ワークロードID、L4認可である。
L7ポリシーは一部のnamespaceやサービスにのみ必要である。
PodやJobにsidecarを注入し、再起動する運用負担を避けたい。
プラットフォームチームがメッシュデータプレーンをアプリケーションと独立して管理したい。
Gateway APIを中心にトラフィックポリシーを標準化する計画がある。
小さなPodが多く、Podごとのプロキシリソース予約の非効率が大きい。

特に「サービスメッシュを導入したいが、すべてのチームにsidecar運用負担を転嫁したくない」のであれば、Ambientの価値は大きいです。L4セキュリティ基盤をまず提供し、L7は実際の要求が生じたときにのみ追加できるからです。

依然としてSidecarがより保守的な選択である場合

Ambientが安定版に達したとはいえ、すべてのIstio機能が同じ成熟度で移行したわけではありません。以下の条件では、sidecarを維持するか、十分な検証後に移行する方が安全です。

1. VMワークロードをメッシュ内に含める必要がある

現在、AmbientはVMワークロードをサポートしていません。Kubernetes PodとVMを同じメッシュでまとめることが主要な要件であれば、sidecarベースのIstioがより適しています。

2. 複雑なマルチクラスター・マルチネットワーク構成が重要である

Ambientのマルチネットワーク、マルチプライマリマルチクラスターはIstio 1.29からベータ版として提供されます。しかし、primary-remoteトポロジーはサポートしておらず、単一ネットワーク構成も現在の公式インストールパスの中心ではありません。複数のCNI、VM、複雑なトポロジーが混在している場合は、sidecarの長年の運用経験がより安全です。

3. EnvoyFilterや特殊な拡張に大きく依存している

waypointを対象とするEnvoyFilterは現在サポートされていません。カスタムEnvoyフィルター、特殊なWasm拡張、またはきめ細やかなプロキシ調整が重要であれば、機能ごとの互換性をまず確認する必要があります。

4. 既存のVirtualServiceが非常に複雑である

Ambient移行ガイドではVirtualServiceのサポートはAlphaと表示されており、Gateway APIのHTTPRouteへの移行パスが推奨されています。同じワークロードにVirtualServiceとHTTPRouteを混在させることもできません。専用APIに複雑なポリシーが多く蓄積されている場合、変換と回帰テストのコストが大きくなります。

5. L7認可に一瞬の空白も許容できない

SidecarとAmbientは同じクラスター内で共存でき、namespace単位でロールバックも可能です。しかし、L7ポリシーを使用する既存のワークロードは、現在完全な無停止移行が困難です。移行中に一時的なポリシー適用空白が生じる可能性があり、継続的なL7強制が必須であればメンテナンスウィンドウが必要です。

既存Sidecar環境で特に注意すべき移行の落とし穴

Ambientは段階的に導入できますが、ラベル1つですべての作業が完了するわけではありません。

混合区間でwaypoint迂回可能性を確認する

Sidecarから発信されたトラフィックは、移行中に目的地のwaypointを迂回する可能性があります。目的地にwaypointベースのL7 AuthorizationPolicyを作成していても、発信元ワークロードがまだsidecarであれば、期待したポリシーが適用されない可能性があります。

Ingressから入るトラフィックも基本的にwaypointを迂回する

Ingress gatewayがバックエンドに送信するリクエストは、デフォルト設定ではwaypointを経由しません。waypointでL7ポリシーを強制するには、istio.io/ingress-use-waypoint設定を検討する必要があります。

ポリシーの対象指定方式が変わる

AmbientのL7 AuthorizationPolicyは、selectorではなくtargetRefsでwaypointやサービスを指定します。RequestAuthenticationとWasmPluginもwaypointに接続する必要があります。既存のYAMLをそのまま移行すると、意図と異なる階層にポリシーが適用される可能性があります。

可観測性の形状も変わる

Sidecarからztunnelとwaypointへ移行すると、reporterラベル、メトリクス収集位置、トレーススパンの形式が変わります。既存のGrafanaダッシュボードやアラートをそのまま維持できると仮定してはいけません。istioctl proxy-statusもztunnelの状態を表示しないため、istioctl ztunnel-config workloadsのようなAmbient専用の点検方法を運用手順に反映する必要があります。

意思決定表：私たちのチームには何が合うか


質問	Ambientが有利な答え	Sidecarが有利な答え
すべてのワークロードにL7が必要か	一部にのみ必要	ほぼすべてに必要
プラットフォームとアプリリリースを分離したいか	強く望む	現在の結合で問題なし
VMがメッシュの核心か	いいえ	はい
既存EnvoyFilter依存度が高いか	低い	高い
Gateway APIへ移行できるか	可能	複雑なVirtualService維持が必要
共有プロキシを運用する準備ができているか	waypoint容量・障害隔離可能	Pod別隔離がより馴染み深い
既存L7ポリシーの瞬間的空白を許容できるか	メンテナンスウィンドウ確保可能	移行空白不可
新規構築か	Ambient-first検討	検証済みsidecar要求が明確

実務的なデフォルト値は次のようにまとめられます。

新規Kubernetesメッシュであれば、AmbientでL4基盤をまず構築し、L7が必要な境界にのみwaypointを追加する。既存のsidecar環境であれば、機能リストよりもポリシー・可観測性・セキュリティ強制パスを基準にnamespace単位の移行を設計する。

Ambientを検証する際に確認すべきチェックリスト

本番稼働前に小さなnamespaceで以下の項目を実際に検証することをお勧めします。

機能

ztunnelのみを使用する場合、mTLSとL4 AuthorizationPolicyが期待通りに動作するか
waypointを追加した後、HTTPRoute、リトライ、タイムアウトが正確に適用されるか
ingress、egress、クロスnamespace呼び出しがwaypointを予想通りに経由するか
既存のVirtualService、DestinationRule、EnvoyFilterのうち、代替が必要なものは何か

セキュリティ

waypointがないL4区間とあるL7区間のポリシー境界が明確か
STRICT PeerAuthenticationとAuthorizationPolicyの組み合わせが意図通りに動作するか
sidecarとAmbientが共存する期間に迂回経路がないか
ztunnelとwaypointサービスアカウントの権限が最小化されているか

運用

ztunnelとwaypoint障害時の影響範囲と復旧時間はどれくらいか
waypointオートスケーリング基準と最小レプリカ数が適切か
アップグレードとロールバックをアプリケーションデプロイなしで実行できるか
既存のGrafanaダッシュボード、アラート、トレースが新しいデータパスを反映しているか

性能

L4とL4+L7パスのp95・p99遅延時間はどれくらいか
トラフィックが集中した際にwaypointのCPU・メモリとキューがどのように変化するか
sidecarと比較してノードの総予約リソースと実際の使用量がどれくらい異なるか
大規模な設定デプロイとエンドポイントの変化が安定的に収束するか

結論：AmbientはSidecarの削除ではなく、役割の再配置である

人々がAmbientへ移行したい理由は、単にsidecarコンテナを1つなくすためだけではありません。

Ambientはサービスメッシュの責任を再分配します。すべてのワークロードに共通して必要なID、mTLS、L4ポリシーはノードのztunnelに集約し、コストが大きいL7処理は実際に必要なサービスのwaypointにのみ配置します。プロキシのライフサイクルをアプリケーションデプロイから分離し、プラットフォームチームが共有インフラとして運用できるようにします。

そのため、新規Kubernetes中心環境であればAmbient-firstが自然なデフォルト候補となっています。リソース予約、Pod再起動、Job互換性、設定デプロイ規模、チーム間の責任境界において、sidecarよりも扱いやすい運用モデルを提供するからです。

しかし、Ambientがsidecarの完全な上位互換ではありません。VM、複雑なマルチクラスター、EnvoyFilter、既存のVirtualService、無停止L7ポリシー移行などの要件は依然として注意が必要です。共有ztunnelとwaypointが作り出す障害・セキュリティ境界も新たに設計する必要があります。

最善の選択は流行を追うことではなく、データパスを明確にすることです。自身のワークロードのうち、どこまでL4で十分か、どのサービスにL7が必要か、誰がプロキシを運用するか、移行中にどのようなポリシー空白を許容できるかをまず答えるべきです。その答えが出たとき、Ambientは単なる「sidecarのないIstio」ではなく、より段階的で運用可能なサービスメッシュ設計となります。