Phase 8레슨 40
Twitter/X 아키텍처
Tweet, Timeline, Retweet, Celebrity Problem — 500M 트윗/일을 실시간으로
💡ELI5·
게시판과 Twitter
일반 사용자 트윗: 작성 → 팔로워 500명 타임라인에 복사 (Fan-out on Write) → 각 팔로워가 타임라인 열면 이미 있음 (빠름) 유명인 트윗 (수천만 팔로워): 작성 → 저장만 (Fan-out X) → 팔로워가 타임라인 열 때 실시간으로 가져옴 (Fan-out on Read) → 쓰기 폭발 방지
💡 비유 — 게시판. 일반 사용자의 글은 각 팔로워의 수신함에 미리 넣어둠. 유명인의 글은 수신함에 넣기엔 너무 많아서, 수신함을 열 때 게시판에서 직접 가져옴.
🔬Deep Dive·
하이브리드 Fan-out (Twitter 방식)
| 사용자 | 팔로워 | 전략 | 이유 |
|---|---|---|---|
| 일반 | < 수천 | Fan-out on Write | 쓰기 비용 낮음, 읽기 빠름 |
| 유명인 | 수백만~수천만 | Fan-out on Read | 쓰기 폭발 방지 |
| 중간 | 수만~수십만 | 선택적 | 임계값으로 결정 |
Twitter는 팔로워 수 임계값(예: 10만)을 기준으로 Fan-out 방식을 자동 전환. 이 하이브리드 방식이 Instagram과 유사 — 둘 다 Celebrity Problem을 같은 방식으로 해결.
🔬Deep Dive·
Redis Timeline 구조
# 각 사용자 타임라인 = Redis Sorted Set
# key: timeline:user:123
# score: timestamp, value: tweet_id
ZADD timeline:user:123 <timestamp> <tweet_id>
ZRANGE timeline:user:123 0 19 REV # 최근 20개
# Fan-out on Write:
# 트윗 작성 → 모든 팔로워의 timeline에 ZADD
# 500 팔로워 → 500번 ZADD (Redis 파이프라인으로 일괄 처리)
# 유명인:
# 트윗 저장만 (tweets 테이블)
# 타임라인 읽기 시:
# 1. Redis에서 일반 팔로워 트윗 가져옴
# 2. 유명인 트윗을 DB에서 실시간으로 가져옴
# 3. 합쳐서 시간순 정렬⚖️Trade-off·
Twitter 아키텍처의 Trade-off
| 선택 | 이점 | 대가 |
|---|---|---|
| Redis Timeline (in-memory) | 읽기 1ms 이내 | 메모리 비용 (수억 사용자) |
| 하이브리드 Fan-out | Celebrity Problem 해결 | 두 경로의 일관성 유지 복잡 |
| Microservices | 독립 배포/확장 | 분산 추적, 디버깅 어려움 |
| 실시간 타임라인 | 사용자 경험 | Fan-out 쓰기 부하 |
❓ 체크포인트 질문
- 1.Twitter의 Celebrity Problem이 무엇인가?
- 2.Twitter가 Redis에서 Timeline을 관리하는 방식은?
- 3.Retweet이 Fan-out 비용을 어떻게 증가시키는가?
- 4.Twitter가 2010년 Redis로 전환한 이유는?
- 5.Twitter가 Monolith에서 Microservices로 전환한 과정은?