BT9G LABS / DHT 심층 분석 #17

수십억 InfoHash를 Dedup하는 법: 중복 Metadata 작업을 줄이는 다층 설계

Exact key, Bloom filter, hot cache, durable state를 조합한 대규모 DHT ingestion dedup 아키텍처입니다.

BT9G Labs게시일 3 분 읽기

BT9G Labs / DHT Deep Dive #17. Deduplication은 단순한 DB EXISTS가 아니라 crawler의 장기 비용을 결정하는 독립적인 서브시스템입니다.

수십억 InfoHash를 Dedup하는 법: 중복 Metadata 작업을 줄이는 다층 설계

빠른 요약

  • 주제: 수십억 InfoHash를 Dedup하는 법: 중복 Metadata 작업을 줄이는 다층 설계
  • 핵심 키워드: InfoHash deduplication, Bloom filter, Redis, large-scale DHT, Metadata scheduler
  • 대상 독자: 백엔드 엔지니어, 프로토콜 연구자, 검색 엔지니어, BitTorrent 구현자
  • 목표: DHT와 BitTorrent의 동작 원리를 실제 크롤러, 인덱싱, 검색 아키텍처 설계에 활용할 수 있을 정도로 정확하게 설명합니다.

시스템 뷰

다층 Dedup이 필요한 이유

인기 InfoHash는 짧은 시간에 반복해서 나타납니다. 모든 event마다 primary DB를 조회하고 새 Metadata job을 만들면 중복 작업이 자원을 소모합니다. process-local recent set → Bloom filter → hot cache → durable exact store 순서로 비용을 줄이는 방식이 실용적입니다.

최종 source of truth는 정확한 저장소에 둡니다.

Bloom Filter는 진실이 아니다

Bloom filter는 메모리 효율이 높고 빠르며 false negative가 없지만 false positive는 있습니다. 따라서 '아마 이미 봤다'를 빠르게 걸러내는 전단계에는 좋지만, 새로운 hash를 영구 폐기하는 최종 판정으로 사용해서는 안 됩니다.

필요할 때 exact store를 조회해 확인해야 합니다.

Existence와 Scheduling State 분리

'전에 본 hash'와 '다시 Metadata를 가져올 필요가 없음'은 다른 문제입니다. durable record에는 first_seen, last_seen, metadata_state, retry_state, activity를 별도로 보관해야 합니다.

수십억 키 규모라면 hash prefix 기반 partitioning, primary-key exact lookup, index size, backup 비용을 미리 고려합니다.

구현 스케치

CREATE TABLE infohash_state (
  hash VARBINARY(32) NOT NULL,
  hash_type TINYINT NOT NULL,
  first_seen DATETIME NOT NULL,
  last_seen DATETIME NOT NULL,
  seen_count BIGINT NOT NULL,
  metadata_status TINYINT NOT NULL,
  next_retry DATETIME NULL,
  PRIMARY KEY(hash_type, hash)
);

BT9G Labs 엔지니어링 노트

BT9G 같은 인덱싱 시스템에서는 이벤트 수 자체보다 콘텐츠 식별자, 수명이 짧은 네트워크 관측값, 수집 상태, 검색용 문서를 분리하는 것이 중요합니다. DHT나 Peer에서 얻은 필드에는 출처와 타임스탬프를 남기고, discovery, 연결, handshake, 확장 지원, Metadata 수집, 검증, 저장, 검색 반영을 단계별로 측정해야 실제 병목을 찾을 수 있습니다.

흔한 오해

  • raw event마다 primary DB를 조회하는 것.
  • Bloom filter를 절대적인 source of truth로 쓰는 것.
  • seen만 저장하고 Metadata/retry 상태를 분리하지 않는 것.
  • 십억 건이 된 뒤에야 partitioning을 고민하는 것.

관련 BT9G Labs 글

참고 자료

다음 글: 실패한 InfoHash도 남겨야 하는 이유: 장기 Retry Scheduler 설계 →

이 글은 공개 BitTorrent 프로토콜의 동작을 엔지니어링 및 연구 목적으로 설명하며, 관측된 모든 Swarm이 사용 가능하거나 유효하거나 재배포 허가를 받았음을 의미하지 않습니다.