Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned
Netflix は、エンジニアが分散アーキテクチャのトラブルシューティングと理解を支援するために、リアルタイムのサービス依存関係マップを開発しました。このシステムは、eBPF ネットワークフロー、IPC メトリクス、および分散トレーシングを独立したグラフレイヤーに組み合わせています。初期バージョンはローカルで動作しましたが、本番環境では Kafka コンシューマーラグやメモリの問題など、重大なスケーリングの課題が明らかになりました。コアアーキテクチャの決定は、ストリーミングファーストのアプローチであり、毎時のバッチ処理ではなく、ほぼリアルタイムのトポロジー更新を提供しました。これは、インシデント対応とライブイベント監視にとって非常に重要でした。毎秒数百万件のフローレコードをデータ損失なしで処理するために、システムはバックプレッシャーを備えたリアクティブストリームを採用しており、ダウンストリームシステムが過負荷になった場合にアップストリームコンポーネントに減速をシグナルします。これにより、クラッシュやデータ損失ではなく、正常な劣化が保証されます。アーキテクチャは、ネットワーク、IPC、およびトレーシングレイヤーの物理ストレージ分離を備えたマルチレイヤー設計を使用しており、独立した最適化を可能にします。ネットワークレイヤーの取り込みは、3段階の分散集計パイプラインに依存しています。ステージ 1 は Kafka からの初期集計を実行し、ステージ 2 はネットワーク中間体(ロードバランサーなど)を直接アプリケーションレベルの依存関係に解決し、ステージ 3 は最終集計、外部データによるエンリッチメント、およびグラフデータベースへの永続化を処理します。この3段階パイプラインは、中間体の解決とエンリッチメント中のデータ集中による「ホットノード」に悩まされていた初期の2段階設計からの重要な進化でした。これらの責任を3つのステージに分割することで、ワークロードが分散され、ボトルネックが防止されます。Server-Sent Events (SSE) は、gRPC のパフォーマンスオーバーヘッドにより、ステージ間通信のために gRPC に取って代わりました。このオーバーヘッドは、スケール時に過剰な CPU とメモリを消費していました。