Netflixが公開した「リアルタイムサービス依存関係マップ」：3層データ収集で実現したMSA運用のベストプラクティス

はじめに：午前3時、あなたは何を見ていますか？

運用中のサービスで突如エラー率が急上昇。ユーザーからのクレームが増えていく中、原因を特定しなければなりません。しかし、数千ものマイクロサービスのうち、どこで問題が始まったのか…

Netflixも全く同じ課題を抱えていました。彼らはこの問題を解決するために、Service Topology というリアルタイム依存関係マップを自社で構築しました。本記事では、そのアプローチと私たちが学べる教訓を詳しく見ていきます。

本記事は Netflix TechBlog 原文 を基に再構成しています。

なぜ既存のツールでは不十分だったのか？

従来の可観測性ツールは、それぞれ断片的な情報しか提供しません。

• メトリクス: 症状とパフォーマンス特性のみ
• ログ: 個別サービスの振る舞いのみ
• トレース: 単一リクエストの流れのみ

問題は、エンジニアがこれらすべてを頭の中で繋ぎ合わせなければならない点です。午前3時に複数のツールを行き来しながら情報を組み立てるのは、遅く、エラーが発生しやすく、ストレスが溜まります。

Netflixの解決策：3つのデータソースをハイブリッド活用

Netflixは、単一のデータソースでは完全な状況を把握できないという結論に至りました。そこで、3つの補完的なソースからそれぞれ独立した依存関係グラフを作成し、それらを統合して表示する方式を採用しました。

これら3つを組み合わせることで：

• ネットワークフローは完全性（漏れなし）を保証
• IPCメトリクスは詳細なアプリケーション情報を提供
• トレーシングは実際の動作パターンを反映

各ソースが互いの制限を補完する構造です。

コアアーキテクチャ：3段階分散集約パイプライン

リアルタイムで数百万のフローログを処理するパイプラインの概念的な流れは以下の通りです。

# 概念的なパイプラインの流れ (擬似コード)

# ステージ1: Kafkaからの初期集約
stage1_aggregation = consume_from_kafka(topic="network_flows")

# ステージ2: 中間者(LB, NAT Gateway等)の識別とパス再構築
#    App A -> LB -> App B のログを App A -> App B に変換
stage2_resolution = resolve_intermediaries(stage1_aggregation)

# ステージ3: ヘルスステータス統合と最終集約後、グラフDBに保存
stage3_final = aggregate_with_health(stage2_resolution)
save_to_graph_db(stage3_final)

この3段階アプローチにより、特定のサービスが他より100倍以上のトラフィックを受ける ホットスポット問題 を分散処理で解決しています。

エンジニアにもたらす実質的な価値

このシステムの稼働後、Netflixのエンジニアは以下の作業が可能になりました。

1. 依存関係の可視化: どのサービスが誰に依存しているかをリアルタイムグラフで確認
2. ブラストレーダスの把握: サービスメンテナンス前に影響範囲を事前予測
3. ヘルスステータスオーバーレイ: コールチェーン上で現在問題が発生しているサービスを一目で識別
4. プログラムによるアクセス: gRPC APIを通じて自動化システム（例：障害対応自動化）に統合
5. タイムトラベル: 過去の特定時点のトポロジーを照会し、変更履歴を追跡

日本市場における適用コンテキスト

日本の大規模プラットフォーム企業やSIer環境でも、このアプローチは非常に有効です。特に以下のようなシチュエーションで直接的なメリットがあります。

• レガシーシステムと新規MSAの共存: eBPFによるネットワークレイヤー収集は、計装されていないレガシーサービスも自動的に発見します。
• 大規模デプロイサイクル: 多くの日本企業が夜間・週末にデプロイを行う中、タイムトラベル機能でデプロイ前後の依存関係変化を即座に把握できます。
• チーム間依存関係管理: 複数チームが運用するサービス間の依存関係を明確に可視化し、変更時の事前調整範囲を正確に特定できます。

Qiitaコミュニティでも話題になる「マイクロサービスの地獄絵図」問題に、このアプローチは具体的な解決策を示しています。

参考: Airbnbのマルチプロダクトデータアーキテクチャ事例 でも、同様の「分離と統合」の教訓を見ることができます。

注意点：この方法の限界と課題

Netflixのアプローチは強力ですが、すべての環境に完璧に適用できるわけではありません。

1. インフラの複雑さ: eBPF、Apache Pekko Streams、分散グラフDBなど、相当なインフラ能力が必要です。
2. 運用コスト: 3レイヤーのデータをそれぞれ収集・保存・集計するには、ストレージとコンピューティングコストが大きくなります。
3. データの整合性: 異なるソースから収集したデータ間の時刻同期と重複除去が困難です。
4. 組織的な準備: このツールの真価は、エンジニア文化がデータ駆動型の意思決定に慣れているときに発揮されます。

次のステップとしての学習方向

このテーマに興味がある方は、以下を追加で学習することをお勧めします。

• eBPFの基礎: Linuxカーネルにおける可観測性の現代的標準
• OpenTelemetry: 分散トレーシングによるリクエストレベルの可視性確保
• グラフデータベース(Neo4j, Amazon Neptune): 複雑な関係データのモデリング
• リアクティブストリーム: バックプレッシャー処理と分散パイプライン設計

まとめ：リアルタイム依存関係マップがもたらす未来

Netflixはこのトポロジーマップを、単なる監視ツールではなく 自動化された根本原因分析(RCA) の基盤となる知識グラフへと進化させようとしています。障害が発生すると、エージェントがトポロジーグラフを探索し、依存関係チェーンを辿って原因を追跡するのです。

このアプローチの核心的な教訓は以下の通りです。

「完璧な単一データソースは存在しない。複数の視点を組み合わせ、それぞれの強みを活かして相互補完せよ。」

私たちのチームのマイクロサービス環境でも、今すぐeBPFとIPCメトリクス、トレーシングのすべてを構築できるわけではないでしょう。しかし、依存関係マップを作るという概念そのものは、どのような規模でも適用可能です。まずは、サービス間の呼び出しログを収集してグラフに描いてみることから始めてみてはいかがでしょうか。

合わせて読みたい記事：

• Airbnbのマルチプロダクトデータアーキテクチャ：分離と統合の7つの教訓
• ゲームをリアルタイム生成するAI、Waypoint-1の可能性と動作原理