# サービストポロジ(Service Topology) マイクロサービスアーキテクチャにおける**サービス間の実行時依存関係をグラフ構造で表現した地図**。「どのサービスが誰を呼ぶか」「障害の波及範囲(ブラスト半径)はどこまでか」「問題は上流か自サービスか」に即答するための基盤となる。 ## 定義 サービストポロジは、ノード(マイクロサービス)とエッジ(実行時通信)で構成される有向グラフである。従来の静的なアーキテクチャ図と異なり、実際のトラフィックを継続的に反映する**リビングマップ**であることが現代的要件とされる。 ## 主要ユースケース | ユースケース | 説明 | |---|---| | インシデント調査 | 障害サービスを起点に上流・下流を辿り箇所特定を高速化 | | [[ブラスト半径]]モデリング | メンテナンス前に影響範囲を事前推定 | | 依存関係監査 | 意図しない依存・循環依存・廃止依存の検出 | | 変更影響分析 | デプロイが他サービスに与える影響の可視化 | | 自動 RCA | AI エージェントがグラフを巡回して根本原因を推定 | ## データソースによる 3 層設計(Netflix の実装) [[Netflix]] の Service Topology は 3 種のデータソースを独立グラフとして構築・統合する。 1. **[[eBPF]] ネットワークフロー**: 計装不要でカーネルレベルの通信を網羅するが、アプリ層の詳細を欠く 2. **[[IPCメトリクス]]**: 計装済みサービスのエンドポイント詳細を提供するが、未計装サービスをカバーしない 3. **分散トレース**: 実際のリクエスト経路と条件分岐を捉えるが、サンプリング制約がある 3 層の補完関係により、カバレッジと精度を両立する。 ## 構築アプローチの比較 | アプローチ | 方法 | カバレッジ | 精度 | 例 | |---|---|---|---|---| | eBPF ネットワークフロー | カーネルレベルのソケット観測 | 計装不要で全サービス | IP/ポートレベル | Netflix eBPF 層 / [[go-conntracer-bpf]] | | IPC メトリクス | アプリ層の計装(gRPC/REST) | 計装済みサービスのみ | エンドポイント詳細 | Netflix IPC 層 | | 分散トレース | リクエスト伝搬の追跡 | サンプリングに依存 | リクエスト経路 | Netflix トレース層 | | パケット観測 + 推論 | パッシブパケット観測+統計モデル | 計装不要 | 推定(偽陽性あり) | Sherlock / Orion | eBPF ソケットベース手法の中でも、転送フロー数をサービス数に依存させる**カーネル内フローバンドリング**(Tsubouchi+2022 [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]])は、短命接続が多い環境でのCPUオーバーヘッドを 2.2% 以下に抑える実用的な手法として実証されている。詳細は [[ネットワーク依存性発見]] を参照。 ## 横断的知見 - **3 層融合はトレードオフの補完であり計装の置き換えではない**: Netflix の eBPF + IPC + トレースの 3 層は、それぞれが「カバレッジ vs 詳細度 vs 経路精度」の異なる軸を担う。eBPF が全サービス間の存在を保証し、IPC が詳細を、トレースが経路を補完する。1 つの手法で全てを賄おうとすると必ず死角が生まれる点は、[[ネットワーク依存性発見]] の手法分類とも一致する。 - **ソケットベースとパケットベースで「依存性」の観測方法が根本的に異なる**: パケット手法(Sherlock/Orion)は相関・遅延から依存を「推定」するが、ソケット手法は実際のコネクションから「直接観測」する。前者は計装不要だが偽陽性を生む。後者は正確だがカーネルアクセスを要する。eBPF の普及により後者のコストが下がった。 ## 未解決の問い - Netflix の 3 層統合は「論文ではなく TechBlog での公開」であるため、3 層の融合アルゴリズムの詳細が不明。具体的にどう重み付けするか? - カーネル内フローバンドリングはコンテナ化・Kubernetes 環境(network namespace が多数存在)でどう動作するか? [[go-conntracer-bpf]] のコンテナ対応状況は? - 依存グラフの「正解」(ground truth)をどう構築するか。IaC・コード・設計書から LLM で自動生成できるか? ## 関連概念 - [[ネットワーク依存性発見]] — サービストポロジの構築方法論(手法分類) - [[リアルタイム依存性マップ]] — 動的に更新される依存性マップの概念 - [[ブラスト半径]] — 障害影響範囲の推定 - [[オブザーバビリティ]] — メトリクス・ログ・トレースとの統合文脈 - [[Fault Localization]] — 障害箇所特定への応用 - [[AIOps]] — エージェントによる自動 RCA との接点 ## 実装例 - [[Netflix]] Service Topology: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]] - [[go-conntracer-bpf]]: ソケットベースのカーネル内フローバンドリング — [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]