Twitter는 140자 정도의 짧은 글을 올릴 수 있는 소셜 네트워킹 서비스(SNS)이다. Twitter에서의 Timeline은 사용자가 Follow(구독)하는 사용자들의 최근 트윗을 확인할 수 있는 페이지이다. 2012년 당시 Twitter는 15만명이 넘는 실시간 활동 사용자와 초당 30만 건이 넘는 Timeline 요청이 발생했었다. 이러한 규모의 Timeline 요청을 데이터베이스에 직접 접근하는 방식으로 처리하면 Query가 복잡해짐에 따라 속도가 현저히 떨어지는 문제가 발생한다. Twitter는 이 문제를 해결하기 위해 메모리 기반 NoSQL 기술인 Redis를 사용하였다.
Twitter의 데이터 센터에 존재하는 방대한 양의 Redis Cluster는 각 사용자의 Timeline에 노출될 Tweet의 정보(Tweet ID, 작성자 ID)를 List 형태로 약 800개 정도 캐싱한다. 발생하는 Timeline 요청은 바로 데이터베이스로 접근하지 않고 Redis에 캐싱된 Timeline 정보를 먼저 가져와서, 이를 토대로 Query를 단순화하여 데이터베이스에 접근하여 처리한다.
모든 사용자의 Timeline을 캐싱하게 되면 메모리가 부족해질 수 있으므로, 로그인을 안한 지 30일이 지난 사용자의 Timeline은 Redis Cluster에서 삭제한다. Redis Cluster에서 삭제된 사용자의 Timeline 정보는 해당 사용자가 다시 로그인을 할 시에 재생성 하는데, 데이터베이스에 직접 접근하는 과정이 필요하기에 시간이 다소 소요된다.
Timeline 캐시에 Tweet 정보를 삽입하는 과정에 관여하는 모듈은 Write API, Fanout, Social Graph 모듈이다. Write API는 사용자가 트윗을 작성했을 때 호출되는 API로, 해당 API는 Tweet의 작성자 ID, Tweet의 고유 ID를 Fanout 모듈로 전달한다. Fanout 모듈은 사용자의 Following, Follower 정보를 담고 있는 Social Graph 모듈로부터 Tweet 작성자의 Follower 목록을 받아오고, 해당 Follower 목록에 포함된 사용자들의 Timeline 캐시에 Tweet 정보를 삽입한다.
요약하면 다음과 같을 것이다
1. 내가 트윗을 함
2. 내 팔로워들의 타임라인 캐시에 내 트윗 ID를 추가함
3. 내 팔로워들이 자신들의 타임라인에 들어가면 타임라인 캐시에 있는 나의 Tweet ID로 DB에 요청함
Redis를 이렇게 사용하고 있다는건 개발자가 이렇게 발표를 해서 확실한데,
DB 접근에 관해서는 확실하지 않다.. 단지 이렇게 할 것 같다고 추측한다
참고자료 : https://www.infoq.com/presentations/Twitter-Timeline-Scalability/