ネットワーク依存性発見 - yuuk1's Digital Garden

# ネットワーク依存性発見 ## 定義ネットワーク依存性発見(network service dependency discovery)とは、分散アプリケーションやエンタープライズネットワークを構成するサービス間で「どのサービスがどのサービスに依存しているか」を、手動設定調査ではなく観測データや能動実験から自動的に特定する取り組みである。依存性 A→B は、A の処理に B へのアクセスが必要、または B の遅延・劣化・障害が A の遅延・劣化・障害を直接または間接的に引き起こす関係を指す。結果は [[サービス依存グラフ]] や [[サービストポロジ]] として利用され、影響範囲分析、再構成計画、[[Fault Localization]] の基盤になる。(Source: [[@2008__OSDI__Automating Network Application Dependency Discovery - Experiences, Limitations, and New Solutions]], [[@2012__LISA__On the Accurate Identification of Network Service Dependencies in Distributed Systems]], [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]) 主な観測粒度は、パケット、ソケット、トランザクションである。パケット/フロー観測は計装不要で広いカバレッジを持つが、相関を因果と誤る危険がある。ソケット観測は Linux カーネルの TCP/UDP 状態から通信を直接捉え、eBPF による低オーバーヘッド実装と相性がよい。トランザクション観測は [[分散トレーシング]] に近く、リクエスト単位の詳細を得られる代わりにアプリケーションやミドルウェアの計装を要する。 ## 横断的知見 - **Sherlock→Orion→NSDMiner→Rippler は、受動観測の偽陽性を段階的に削る系譜である**: Sherlock はパッシブ観測と Inference Graph で多層依存性を推論し、Orion は遅延スパイク分析で固定ウィンドウ依存を減らし、NSDMiner はネスト化フローと対数スコアリングで候補を削減した。Rippler は遅延注入により「遅延が伝播するか」を直接試すことで、受動観測全体の相関と因果のギャップに答えた。(Source: [[@2007__SIGCOMM__Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies]], [[@2008__OSDI__Automating Network Application Dependency Discovery - Experiences, Limitations, and New Solutions]], [[@2012__LISA__On the Accurate Identification of Network Service Dependencies in Distributed Systems]], [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]]) - **固定ウィンドウは受動観測ベース手法の共通ボトルネックである**: 共起確率ベースの Sherlock/eXpose はウィンドウが小さいと遅延の大きい依存関係を見逃し、大きいと無関係な共起を拾う。Orion は遅延分布のスパイクに着目してこのパラメータ感度を下げたが、完全な偽陽性除去には至らない。(Source: [[@2008__OSDI__Automating Network Application Dependency Discovery - Experiences, Limitations, and New Solutions]]) - **比率スコアから対数スコアへの変更は、観測量の多寡を信頼度へ組み込む設計である**: NSDMiner 初版の `weight(A→B) / weight(A)` は少数観測でも高スコアを出しやすい。Peddycord+ は `log_{weight(A)}(weight(A→B))` により、観測量が多い候補を適切に評価しつつ確信の増分を逓減させ、偽陽性を削減した。(Source: [[@2012__LISA__On the Accurate Identification of Network Service Dependencies in Distributed Systems]]) - **ソケットベース手法では「どこで集約するか」が CPU オーバーヘッドを決める**: ストリーミング方式はフローを即時にユーザー空間へ送るため RTT/s に比例して負荷が増える。カーネル内集約やフローバンドリングは、同一宛先サービスへの短命接続をカーネル内で束ね、転送量をサービス数に近づける。これは [[eBPF]] の「計装層で先に削減する」設計原則の具体例である。(Source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]], [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]) - **依存グラフは、受動観測、能動実験、分散トレースの 3 系統が相補的に作る**: 受動観測は導入しやすいが因果の確証が弱く、遅延注入は因果を直接検証できるが実験コストが高い。分散トレーシングはリクエスト単位の正確な経路を得るが計装前提が重い。現代の [[サービス依存グラフ]] は、これらを単独で選ぶより、サービスメッシュ、eBPF ソケット観測、分散トレースを組み合わせる方向へ向かう。(Source: [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]], [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]) - **リレーの可視性は「新規ソケットを生成するか」で二分され、ソケットベース手法共通の限界になる**: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]](§3.5.2)は、リレーを TCP/UDP セッション終端型(プロキシ等が自身のソケットを新規生成)とパケット転送型(NAT 等、ヘッダのみ書き換えソケットを生成しない)に二分する。前者はクライアント↔リレー・リレー↔サーバの 2 区間として発見可能だが、後者は束ねの有無を問わずソケットベース手法一般で検出不能であり、転送履歴(NAT テーブル)と観測フローの突き合わせでのみ緩和できる。これは、既存の「NAT、ロードバランサ、サイドカー、プロキシが挟まる場合、ソケットベース観測はどの層の依存性を見ていると解釈すべきか」という本頁の未解決の問いに対し、少なくとも NAT/パケット転送のケースについては「原理的に不可視」という具体的な境界を与える。ただしサイドカー・サービスメッシュ(mTLS 終端を伴う)がセッション終端型・パケット転送型のいずれに近いかは本ソースでは論じられておらず、未解決のまま残る。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]]) - **「コールの有向性」を定義する 2 つの層(トポロジ的定義 vs 因果的定義)が同一著者の連作の中で使い分けられている**: 本章(博士論文 Ch.3, §3.2.1)は「固定ポートで listen する側 = サーバ」という構造的・実装しやすい慣習でコールの有向辺(client→server)を定義し、UDP のようにコネクションレスなプロトコルにも同じ慣習を一貫して適用する。一方、同じ著者による査読付き論文([[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]])は Zand et al. の因果的定義(S1 の遅延/劣化/障害が S2 の遅延/劣化/障害を直接・間接に引き起こすとき S2 は S1 に依存する)を「依存性」の定義に採用する。両者は矛盾しないが層が異なる——前者は「コールがどちら向きに発生したか」というトポロジ構築時の実装上の判定基準であり、後者は「発見したコールグラフのエッジが何を意味するか」という下流分析での解釈基準である。本頁の定義がどちらの層を指しているかを明示せずに引用すると、2 つの定義の混同が生じうる。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]], [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]) - **束ね率(bundling rate)の低下は 1,000 サービスまでは実害を生まないが、10,000 サービス規模では集約手法との差が消える**: 本頁の既存の未解決の問い(「1,000 サービス超の環境で集約率低下を階層的なサービスグループで緩和できるか」)に対し、博士論文 Ch.3(§3.4.2, §3.5.1)は定量的な境界を与える。束ね率 $R = 1 - B/T$ はサービス数 200→1,000 で 0.98→0.90 へ低下するが CPU 使用率は 2% 未満を維持する一方、サービス数が 10,000 規模に達すると R がほぼ 0 に近づき、カーネル内フロー束ねとカーネル内フロー集約(Neves+2020 系)の性能差が消失すると論じる(ただし 10,000 規模の実測値そのものは本章に記載がなく理論的な考察にとどまる)。「階層的なサービスグループで緩和できるか」という問い自体はまだ実験的に検証されていない。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]]) ## 未解決の問い - Kubernetes、サービスメッシュ、mTLS、短命 Pod が一般化した環境で、(ip, port, protocol) ベースの依存表現はどこまで有効か。サイドカー・mTLS 終端はセッション終端型リレーとパケット転送型リレーのいずれに近い可視性を示すか(§3.5.2 の二分法では未整理)。 - 受動観測で候補を絞り、能動的な遅延注入で偽陽性を落とすハイブリッド手法は、本番でどの程度の実験時間とリスクで運用できるか。 - 1,000 サービス超の環境で、カーネル内フローバンドリングの集約率が低下する問題を階層的なサービスグループで緩和できるか。博士論文 Ch.3 は 10,000 サービス規模で集約手法との差が理論上消えると論じるが、実測による検証はまだ無い。 - 正解の依存グラフをどう作るか。設計書、IaC、サービスメッシュ、トレース、LLM 抽出を組み合わせた ground truth 構築は可能か。 ## 関連 - 出力概念: [[サービス依存グラフ]] / [[サービストポロジ]] / [[リアルタイム依存性マップ]] - 隣接概念: [[マイクロサービスコールグラフ]] / [[トラフィック相関分析]] / [[遅延注入]] / [[分散トレーシング]] / [[eBPF]] / [[暗黙のコンテキスト伝搬]] - 応用: [[Fault Localization]] / [[コンテナ配置最適化]] / [[ブラスト半径]] - エンティティ: [[NSDMiner]] / [[go-conntracer-bpf]] / [[Orion]] ## 出典 - [[@2007__SIGCOMM__Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies]](Sherlock、Inference Graph、多層依存性推論) - [[@2008__OSDI__Automating Network Application Dependency Discovery - Experiences, Limitations, and New Solutions]](Orion、遅延スパイク、受動観測の評価) - [[@2012__LISA__On the Accurate Identification of Network Service Dependencies in Distributed Systems]](NSDMiner、対数スコアリング、依存性推論、サービスクラスタ検出) - [[@2014__INFOCOM__Rippler Delay Injection for Service Dependency Detection]](遅延注入による能動的依存性検証) - [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]](カーネル内フロー集約とコンテナ配置最適化) - [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]](eBPF による TCP/UDP ソケット観測とフローバンドリング) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]](§3.2.1 コールの有向定義、§3.4–3.5 束ね率とスケール限界、§3.5.2 リレー越しの識別性限界)