# サービスメッシュ ## 定義 サービスメッシュ(service mesh)とは、アプリケーションが相互に通信し合う汎用の基盤層を用意することで、マイクロサービスアーキテクチャの構築と運用における緩衝地帯となるパラダイムである。「サイドカー」と呼ばれるハイパフォーマンスなプロキシをすべてのアプリケーションと組み合わせてデプロイし、単一言語(多くはC/C++)で1回だけ記述されたこのプロキシが必要な機能をすべてカプセル化することで、アプリケーション開発者はネットワークの実装・計装・信頼性の高い運用方法を基本的に意識せずに任意の言語でコードを書けるようになる。アプリケーションはサイドカーとだけ通信すればよく、サイドカー同士が発見と通信を一手に引き受けることでメッシュを形成する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] ch.26 §26.3) サービスメッシュは**データプレーン**(ネットワークトラフィックの転送に実際に関与する部分。サイドカープロキシ自体)と**コントロールプレーン**(トポロジのセットアップと高レベル設定を担う部分)に分離される。単純な実装は集中型の設定ジェネレータが変更を検知しプロキシへ配付する方式(HAProxy ベースの SmartStack)を取り、より複雑な実装は動的な設定APIを提供してプロキシのブートストラップ設定を最小化する(Envoy/Istio 系)。プロキシソリューションには HAProxy・NGINX・Linkerd・Traefik・Envoy があり、完全管理のソリューションとしては SmartStack(HAProxy 上に構築)と Istio(Envoy 上に構築)がある。(Source: ch.26 §26.3.6, §26.4) サービスメッシュがもたらす主要な価値は、プロセス外アーキテクチャによる機能の一括導入、ハイパフォーマンスな実装、プラガビリティ、高度なロードバランシング(再試行・回路遮断・レート制限・シャドーイング・外れ値検出)、そして何より一貫したオブザーバビリティ(あらゆるホップでの統一された統計情報・ログ・分散トレーシング)である。ただしコンテキスト伝播(リクエストID・トレースコンテキストのヘッダ伝播)だけはアプリケーション/言語固有の薄いライブラリに依存し続ける、サービスメッシュでは代替できない残存責務である。(Source: ch.26 §26.3.1, §26.3.5) ## 横断的知見 - **サイドカープロキシとスクリプタブルロードバランサーは、同じ問題を別レイヤーで解いている**: [[スクリプタブルロードバランサー]](ch.25)は「アプリケーション認識型のネットワーキング機能をロードバランシング層に集約する」ことでアプリケーションから関心事を抽象化する設計であり、シャードルーティング4方式の最終形態(判断をロードバランサーへ完全に移す)がまさにこれにあたる。サービスメッシュのサイドカーは、この機能集約を「中央のロードバランサー1箇所」ではなく「アプリケーションごとに1:1配置されたプロキシ群」で行う点が異なる。ch.26 自身が脚注で「HAProxy などのハイパフォーマンスなプロキシをアプリケーションと共にインストールするパターンは、完全なサービスメッシュへの前段階と考えることができる」(ch.26 p.465-466 脚注3)と明記しており、両者は「機能をアプリケーション本体から切り離す」という同一の設計思想の上で、配置の集中度が異なる連続体を成す。ロードバランサー層への集約(ch.25)は判断の一貫性と再利用性を高めるが単一障害点になりやすく、サイドカー配置(ch.26)は各アプリケーションに専用インスタンスを持つため障害の影響範囲を局所化できる一方、メッシュ全体の管理(コントロールプレーン)という新しい複雑さを持ち込む。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]], [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]]) - **サイドカーによるトレーシングは、[[ゼロコード計装]]の「第3の系統」として位置づけられる**: [[ゼロコード計装]] concept は eBPF系(OBI・DeepFlow等、カーネル/ネットワーク層フック)と言語ランタイム系(OpenTelemetry の言語別自動計装 SDK)の2系統を整理しているが、サービスメッシュのサイドカープロキシによるトレーシングはそのいずれとも異なる第3の機構である。ch.26 は「サービスメッシュでは、アプリケーションを一切関与させずに100%のトレーシングカバー率を実現できる」(ch.26 §26.3.3)と述べる一方、章の監訳注は「サイドカープロキシによる分散トレースは各サービスへのリクエスト/レスポンスレベルでのトレースは可能だが、サービス内の関数レベルでのスパンは取得できないため、計装を必要とする場面は依然として存在する」(ch.26 脚注4)と明確に限界を書いている。これは eBPF系(カーネル/ネットワーク層のシステムコール・I/Oを捕捉できるがユーザー空間のアプリケーションロジックは見えない)とも異なる、「ホップ単位」という粒度の限界であり、ゼロコード計装の3系統(eBPF・言語ランタイム・プロキシ/サイドカー)はいずれも「アプリケーションコード変更なし」という共通点を持ちながら、捕捉できる粒度が異なることが分かる。(Source: ch.26 §26.3.3、脚注4) - **サービス依存グラフの構築源としてのサイドカー統計は、既存の未解決の問いに実運用の具体例を与える**: [[サービス依存グラフ]] concept は「Service Mesh(Istio・Linkerd)の sidecar から得られる依存情報を直接SDGとして使う設計」を未解決の問いとして掲げていた。ch.26 は、サイドカーが「あらゆるホップで一貫した統計情報」を提供し、「発信元と送信先のサービスをドロップダウンリストから選択」できるサービス対サービスダッシュボードが自動生成できると述べており(ch.26 §26.3.3)、Lyft の Envoy 導入ではこれが実際に「グローバルなEnvoyダッシュボード」として運用されている(ch.26 §26.4.2.1)。ただし章はこれをサービス依存グラフの構築そのものを目的とした設計としては論じておらず、統計・トレース・ログ収集の副産物として言及するにとどまる点には留意が必要である。sidecar統計を体系的にSDG構築へ転用する設計は、本チャプターの範囲を超える。(Source: ch.26 §26.3.3, §26.4.2.1) - **サービスメッシュはコンテナオーケストレーションとは独立した軸として立ち上がった**: [[コンテナオーケストレーション]] concept は「サービスメッシュ(Istio・Linkerd)は Pahl ら(IEEE TCC 2019, 2016年カットオフ)の分類フレームワークで再分類可能か」を未解決の問いとして持つ。ch.26(2018年執筆)の時点で、Istio(Envoyベース)と SmartStack(HAProxyベース)はすでに「完全管理のソリューション」として並列に語られており、これはコンテナのクラスタオーケストレーション(Kubernetes等のスケジューリング・配置)とは異なる、通信とオブザーバビリティに特化した層の関心事として発展したことを示す。すなわちサービスメッシュは Pahl 2019 の分類フレームワークの「クラスタオーケストレーション」カテゴリの下位区分ではなく、ネットワーキング/オブザーバビリティという別軸のカテゴリとして追加する必要がある。(Source: ch.26 §26.4) ## 未解決の問い - サイドカー配置によるレイテンシ・CPU/RAM消費のオーバーヘッドは、eBPF系ゼロコード計装(OBI等)と定量的にどう比較されるか。ch.26 はネイティブC/C++実装であればテイルレイテンシへの影響は無視できるとするが、具体的なベンチマーク数値は示していない。 - コンテキスト伝播(x-request-id・トレースコンテキストヘッダ)という「アプリケーション側に残る責務」は、後続のOpenTelemetry標準化(W3C Trace Context)によってどこまで薄いライブラリの実装コストが下がったか。ch.26 執筆時点(2018年)ではこの領域の収束は将来予測にとどまっていた(ch.26 §26.3.5)。 - コントロールプレーンの単一障害点化・複雑化のリスク([[スクリプタブルロードバランサー]]が指摘する「正確性と弾力性のトレードオフ」と同型の問題)は、Istio 等の後継のサービスメッシュ製品でどのように緩和されているか。 - サイドカーの統計・トレース・依存関係情報を体系的にサービス依存グラフ構築へ転用する設計は、実際のAIOps/RCA研究([[サービス依存グラフ]] concept が扱う VOCE・GRLIA 等)でどこまで採用されているか。 ## 関連 - 概念: [[スクリプタブルロードバランサー]] / [[マイクロサービスアーキテクチャ]] / [[ゼロコード計装]] / [[分散トレーシング]] / [[サービス依存グラフ]] / [[コンテナオーケストレーション]] / [[オブザーバビリティ]] - 実体: [[Matt Klein]] / [[Lyft]] / [[Envoy]] / [[Istio]] / [[Linkerd]] / [[Consul]] - ソース: [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] / [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ## 出典 - [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]](サービスメッシュの定義、サイドカーのメリット、データプレーン/コントロールプレーン、Lyft/Envoy ケーススタディ) - [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]](スクリプタブルロードバランサーとの比較材料。脚注3のHAProxy言及)