피드로 돌아가기
Dev.toBackend
원문 읽기
Hybrid Fan-out 전략을 통한 5,000만 팔로워 규모의 타임라인 딜리버리 최적화
Scale Wars #5 — Twitter: The Fan-out Pattern and the Architecture Behind 140 Characters
AI 요약
Context
사용자 트윗 발생 시 모든 팔로워의 타임라인을 업데이트하는 구조에서 팔로워 수가 많은 Celebrity 유저로 인한 쓰기 부하 및 DB Lock 발생. 단순 INSERT 방식의 Naive approach로는 수천만 건의 데이터 처리 지연으로 인해 실시간 타임라인 제공 불가능.
Technical Solution
- Fan-out-on-Write: 일반 유저(< 10,000 팔로워) 대상 트윗 발생 시 Redis 기반의 개별 타임라인 캐시에 즉시 분산 저장하여 Read Latency 최소화
- Fan-out-on-Read: Celebrity 유저(> 10,000 팔로워) 대상 트윗 작성 시 본인 저장소에만 기록 후 조회 시점에 팔로잉 목록과 Merge 하여 Write 부하 방지
- Hybrid Approach: 팔로워 수 기준의 임계값 설정을 통해 쓰기 비용과 읽기 비용의 Trade-off를 최적화한 이원화 구조 설계
- Manhattan DB 도입: 전 세계 데이터 센터 간 복제 및 고처리량 확보를 위해 맞춤형 Distributed Key-Value Store 구축
- Snowflake ID System: 타임스탬프, DC ID, Worker ID를 조합한 64-bit 분산 ID 생성기를 통해 중앙 집중식 병목 제거 및 시간 순 정렬 보장
실천 포인트
1. 읽기/쓰기 빈도 및 데이터 편차(Skew) 분석을 통한 전략적 분기 설계 검토
2. Redis 등 In-memory 캐시를 활용한 Pre-computed 타임라인 구조 적용 여부 판단
3. 분산 환경의 ID 생성을 위해 Snowflake, ULID, UUID v7 등 대체제 검토
4. 대규모 데이터 복제를 위한 Distributed Key-Value Store의 지연 시간 및 일관성 수준 정의