BT9G LABS / DHT 詳解 #20

BT9GがBitTorrent Metadataを大規模索引するための参照DHTアーキテクチャ

DHT discovery、永続 InfoHash state、Metadata acquisition、検索インデックス、observability を統合する BT9G 向け参照設計。

BT9G Labs公開日 2 分で読めます

BT9G Labs / DHT Deep Dive #20. シリーズ全体のプロトコル知識とシステム設計を、BT9G 型検索基盤の 1 つの参照アーキテクチャにまとめます。

BT9GがBitTorrent Metadataを大規模索引するための参照DHTアーキテクチャ

クイックサマリー

  • テーマ: BT9GがBitTorrent Metadataを大規模索引するための参照DHTアーキテクチャ
  • 主要キーワード: BT9G, DHT architecture, Metadata indexing, BitTorrent search, distributed crawler
  • 対象読者: バックエンドエンジニア、プロトコル研究者、検索エンジニア、BitTorrent 実装者
  • 目的: DHT と BitTorrent の仕組みを、実際のクローラ・インデックス・検索基盤の設計判断に使える精度で説明すること。

システム構成

Discovery EdgeとHash Ledger

最外層の DHT nodes/crawlers は KRPC、routing table、InfoHash/Peer activity の軽量 event 化に集中します。Metadata を同期取得しません。すべての content identity は durable hash ledger へ入り、exact dedup、first_seen/last_seen、retry state、activity aggregation を管理します。

Peer endpoint は InfoHash より寿命が短いため TTL 付き candidate store に置く方が自然です。

Metadata Acquisition Fleet

Scheduler が activity、過去 failure、resource budget から InfoHash を選び、workers が Peer を探して接続し、BEP 10/BEP 9 で Metadata を取得します。identity validation を通過したものだけが canonical metadata に昇格します。

workers は discovery と独立して scale し、concurrency は success rate と p95 latency、host resource を見て調整します。

Serving・Ranking・Observability

検証済み content は canonical store から Elasticsearch 等へ派生させ、serving layer は安定字段と説明可能な activity signal を使います。text relevance、freshness、quality、network activity を組み合わせて ranking します。

DHT query、unique hash、Peer connect、BEP support、Metadata success、indexing lag を一貫して計測すれば、BT9G の成長を制限している層を特定できます。

実装スケッチ

DHT observers
    |
    v
Hash event bus ---> metrics
    |
    v
Exact hash ledger <---- fresh activity wakes cold hashes
    |
    v
Retry / priority scheduler
    |
    v
Metadata fleet -> hash validation -> canonical metadata DB
                                   |
                                   v
                              enrichment
                                   |
                                   v
                              search index
                                   |
                                   v
                                BT9G

BT9G Labs エンジニアリングノート

BT9G のようなインデックス基盤では、イベント件数そのものより、コンテンツ ID、短命なネットワーク観測、取得状態、検索用ドキュメントを分離することが重要です。DHT や Peer から得た値には取得元と時刻を持たせ、discovery、接続、handshake、拡張対応、Metadata 取得、検証、保存、検索反映を段階別に計測すると、実際のボトルネックを特定しやすくなります。

よくある誤解

  • discovery worker に Metadata と indexing まで全部持たせる。
  • Peer endpoint を InfoHash と同じ永続 entity として扱う。
  • validation 前の Metadata を serving に出す。
  • 総 throughput だけで stage ごとの success/latency を計測しない。

関連する BT9G Labs 記事

参考資料

本記事は公開 BitTorrent プロトコルの挙動を技術・研究目的で解説するものであり、観測されたすべての Swarm が利用可能、正当、または再配布を許可されていることを意味しません。