트위터 팔로워 타임라인 시스템 분석

트위터 팔로워 서비스 특징

트위터의 액티브 유저는 3억명이상이다. 

초당 600개 이상의 트윗이 생성되고, 초당 60만건 이상의 트윗 조회가 발생하고 있다.

트위터 팔로워 시스템 고려사항

• 읽기 요청이 헤비하다.
• Eventually Consistent 특성이 있다.
  • 약간의 딜레이를 허용한다.
• 데이터 저장소 비용을 최적화해야한다.

준비물

1. 장기 보관용 RDB 데이터베이스

2. 인메모리 캐시용 Redis

데이터 설계

MySQL InnoDB

• 유실되면 안되는 정보는 RDB에 저장한다. RDB에 저장되는 데이터는 회원 / 트윗 / 팔로워 테이블 3개이다. 

Redis Cache

• 트윗 조회 요청에 빠르게 응답하기 위해, 타임라인 정보는 캐시에 저장한다.
• 빠른 계산을 위하여, 타임라인 캐시는 사전에 집계해둔다.
  • 모든 유저를 대상으로 타임라인 캐시를 사전집계하는 경우, 모수가 너무 많다.
  • 때문에 최근 15일 이내의 액티브 유저를 사전집계해두는 것이 성능을 최적화하는 데에 도움이 된다.
• 회원 트윗 캐시는 최신순으로 정렬해서 저장해둔다.
  • LIST 데이터에 RPUSHX 함수를 호출해서 저장함. 캐시가 없는 경우, DB를 조회해서 새로 생성해야할듯.
• 트윗 정보는 RDB에 저장되어 있지만, 빠른 응답을 위해 캐시에도 저장한다.

 

타임라인 캐시 

새로운 트윗을 작성한 트위터의 팔로워 수에 따라 타임라인 캐시를 만드는 방식이 달라진다.

이 방식은 크게 두가지 방식으로 나뉜다.

 

1. 팔로잉 수가 많은 셀럽들을 대상으로 한 방식

유명 트윗터인 경우 팔로워가 8000만명이 넘는 경우도 있다. 이 경우, 팬아웃 방식을 사용하는 것은 시스템 부담이 있다.

그래서 이 경우, 타임라인 조회 요청 시, 일반 타임라인 캐시에 유명 트윗터의 트윗을 합쳐주는 방식을 사용해야한다.

SELECT
	*
FROM
	tweets
	JOIN USER ON tweets.sender_id = user.id
	JOIN follows ON follows.followee_id = user.id
WHERE
	follows.follower_id = user_id

RDB에서 데이터를 조회한다. 

 

2. 일반 팔로워를 대상으로한 FanOut 방식

트위터 쓰기 요청이 들어오면, 팔로워의 타임라인 캐시에 새로운 트윗 아이디를 추가해준다.

 

용어사전

Eventually Consistent 

최종 정합성 혹은 최종 일관성이라고도 부른다. 즉시는 아니더라도, 일정 시간이 지나면 데이터 일관성 (무결성)을 보장해주는 데이터 특성을 의미한다. 

후기

팔로우 타임라인 시스템 대다수가 Redis Cache를 사용하고 있는 것 같다. 😮

참고

[Medium] System design for Twitter

[Youtube]https://youtu.be/wYk0xPP_P_8

[SlideShare]Timeline Service Write API Fanout Raffi Krikorian, Twitter Timelines at Scale

[Medium] Building a follower model from scratch

[도서]<마틴 클러스만> 데이터 중심 애플리케이션 설계