なぜサービス依存関係の追跡が必要なのか

マイクロサービスアーキテクチャを運用していると、ある瞬間から**「このサービスが落ちたらどこまで影響が出るのか?」**という問いに答えられなくなります。サービスが10個なら頭の中で描けますが、100個を超えると話が変わってきます。障害発生時に原因サービスを特定するだけで数時間を費やす、という状況が繰り返されるのです。

Netflixが公開したサービストポロジーマップは、まさにこの課題を解決します。単なる図ではなく、リアルタイムで動き続ける依存関係の地図です。どのサービスがどのサービスを呼び出し、どの区間で遅延が発生し、障害がどこへ伝播するのかを一目で把握できるようにした点が核心です。

本記事では、Netflixのアプローチを分解しながら、自チームに適用できる実務ポイントを整理します。

Hybrid cloud infrastructure connecting on-premises datacenter to Azure control plane for unified management Technical Structure Concept

サービストポロジーマップの核心原理

Netflixのアプローチは大きく3つの段階に分かれます。

1. テレメトリ収集 (Telemetry Collection)

各サービスは自身が呼び出した対象、応答時間、エラー率などを構造化されたイベントとして出力します。Netflixは内部的にEdgarと呼ばれる分散トレーシングシステムを使用しています。OpenTelemetryのSpan/Traceの概念と同義です。

# OpenTelemetryベースの依存関係収集例
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# トレーサー初期化(サービスごとに1回のみ)
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)

# 外部サービス呼び出し時に依存関係情報をSpan属性として記録
def call_downstream_service(service_name: str, endpoint: str):
    with tracer.start_as_current_span(f"call-{service_name}") as span:
        span.set_attribute("peer.service", service_name)      # 呼び出し先サービス
        span.set_attribute("http.url", endpoint)              # エンドポイント
        span.set_attribute("dependency.type", "http")        # 依存関係の種類
        # ... 実際のHTTP呼び出しロジック

2. グラフ構築 (Graph Construction)

収集したSpanデータを有向グラフ(Directed Graph) に変換します。ノードはサービス、エッジは呼び出し関係です。ここで重要なのは時間ウィンドウ単位で集計する点です。5分単位のスライディングウィンドウでグラフを生成すれば、「今この瞬間」の依存関係状態を可視化できます。

3. リアルタイム可視化 (Live Visualization)

構築したグラフをUIとしてレンダリングします。Netflixはここにヘルス状態(Healthy/Degraded/Failing) を色で付与し、障害伝播経路を即座に把握できるようにしました。この部分が単なる監視ダッシュボードとトポロジーマップの決定的な違いです。

💡 実務のヒント: 最初から完璧なグラフを作ろうとしないでください。まずはサービス間の呼び出しログだけでも構造化して蓄積しておけば、後からグラフへ昇格させるのが格段に楽になります。

Global server fleet managed through Azure Arc with centralized policy and monitoring dashboards Programming Illustration

注意点とよくある落とし穴

⚠️ カーディナリティ爆発 (Cardinality Explosion)

サービスが増えるとエッジ数が幾何級数的に増加します。サービス100個なら理論上エッジは10,000個まで存在し得ます。すべてのエッジをリアルタイムレンダリングするとブラウザが落ちます。Netflixもこの問題を解決するため、閾値ベースのフィルタリングとクラスタリングを適用しているとされています。

⚠️ サンプリングバイアス (Sampling Bias)

トレースデータは通常1〜10%しかサンプリングされません。低トラフィックのサービスはサンプルに全く含まれない可能性があります。この場合、グラフからノードが欠落し、「存在しない依存関係」 のように見える錯覚が発生します。必ずサンプリングポリシーをグラフ解釈ガイドとともに文書化してください。

⚠️ 日本の開発現場における適用文脈

日本のSI案件では、モノリシックなレガシー + 新規MSAが混在するケースが多く見られます。この場合、トポロジーマップはレガシー区間で途切れます。レガシー区間は別途APM(Scouter、Jenniferなど) で補完し、MSA区間のみトポロジーで管理するハイブリッドなアプローチが現実的です。また、金融機関のようにネットワーク分離が行われている環境では、外部SaaS型のオブザーバビリティツールを利用できないため、セルフホスト可能なOSSスタック(Tempo + Grafanaなど)をまず検討してください。

Physical security operators using Azure Virtual Desktop to access critical monitoring applications Developer Related Image

まとめ: グラフは手段であり目的ではない

Netflixの事例から本当に学ぶべき点は、「綺麗な図」ではなく「意思決定の速度」 です。障害発生時に「どこから見ればいいか?」という問いに5秒以内に答えられるなら、それが成功したトポロジーマップです。

次のステップ学習の方向性

  1. OpenTelemetry Collector をローカル環境で起動 → サービス2〜3個で最小グラフを作成
  2. Grafana Tempo + Node Graphパネル でトポロジー可視化を実習
  3. SLOベースのアラート と組み合わせ、「依存関係グラフ + エラーバジェット」ダッシュボードを構成

トポロジーマップは一度作って終わりではなく、サービスが変化するたびに共に進化すべき生きたドキュメントです。小さく始めて、チームの運用文化として定着させることが鍵となります。

あわせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。