Twitter 시스템 설계

 

* 인터뷰시 인터뷰어는 원하는 방향으로 면접자를 가이드하면서 면접자의 property를 검증하려고 한다. 따라서, 인터뷰어가 가이드 할 수 있게 놔둘 것

* "트위터는 어떻게 설계되어있을까요?"라고 질문한다면, 바로 답을 도출하지 말고 답을 풀어가는 과정을 보여줄 것 (~~ 기능들을 수행해야하니 어떤 것이 필요하고, 또 그것을 위해서는 어떤 것이 필요하고,, 이런식) 

---

Core Features

1. Tweeting

2. TimeLine

• User TimeLine :  본인 트윗 + 리트윗한 트윗 (More easy too design! => 자신의 트윗과, 리트윗한 액션을 리스트업하면 됨)
• Home TimeLine : 팔로우한 사람들의 트윗 

3. Following

다른 기능들은 비교적 단순하니 Home TimeLine에 집중해서 설명

 

Naive Solution

tweet 테이블(기본키 : tweet ID), user 테이블(기본키 : user ID), 팔로워 테이블을 두고, tweet 테이블에서 user ID를 외래키로 갖는다. 접속할 때 마다 팔로워 테이블에 있는 유저ID에 해당하는 트윗을 검색해 가져온다. 

 Characteristics

• Read가 Tweet 양보다 많다. (Read가 Write 보다 빨라야 함)
• 자신의 팔로워 A, B가 있을때, A가 B보다 몇초 늦게 자신의 새 트윗을 읽는 것은 문제가 되지 않지만, A와 B 모두 내 트윗에 접근을 못한다면 문제가 될 수 있음 (Importance : Availability > Consistency) => Eventual Consistency

Optimized Solution

1. 100명의 팔로워를 가진 앨리스가 트윗을 작성한다. 작성한 트윗은 LB로 전달된다.
2. 작성한 트윗은 Redis cluster로 분산해서 Fan out 된다. 이때 Alice를 팔로워하는 100명의 모든 사용자들의 홈 타임라인 리스트에 앨리스가 작성한 트윗이 insert 된다. 
3. 레디스에 저장되는 리스트는 (3)과 같은 형태로 구성된다. 모든 유저는 홈 타임라인을 위한 리스트를 갖는다.

* 최적화 할 수 있는 방법은?

팔로워의 리스트를 업데이트 할때, 모든 팔로워가 아닌 특정 기준에 부합하는 팔로워들만을 대상으로 한다. (ex) 최근 2주이내 접속한 유저

 

* 팔로워가 많은 Super User라면? 

저스틴 비버처럼 팔로워가 Million 단위가 되는 Super User 라면, fan out 시키는데 시간이 많이 소요되고, 이에 따른 일관성 문제가 발생할 수 있다. (fan out 지연시간으로 인해 A는 비버의 새 트윗을 아직 보지 못하지만, 친구 B는 이미 새 트윗을 보고, 해당 트윗에 댓글을 달았을 경우, A는 비버의 새 트윗을 보는 것 보다 B가 작성한 댓글을 먼저 보게 될 수도 있다)

 

 

결과적으로 Bob이 홈 타임라인에 접속할 때, 위와 같은 플로우가 발생한다.

Get 요청을 보내면, Bob의 홈 타임라인 리스트를 갖고있는 레디스를 찾고, 찾은 밥의 타임라인을 가져와 바로 띄워준다. Write에는 부하가 있을지 몰라도 Read하는 시점에서는 빨리 가져올 수 있다.

(여기서는 한 유저의 홈 타임라인을 레디스 클러스터 3군데에 중복저장한다고 했는데, 정확한 이유는 잘 모르겠다. 분산해서 저장하기 위함이 아닐까..)

 

 

 

[강의 출처]

https://www.youtube.com/watch?v=KmAyPUv9gOY&ab_channel=SuccessinTech