'데이터 중심 애플리케이션 설계'를 읽다가 트윗 방식의 변화에 대해서 이해가 되지 않아 정리하였다.
방법 1.
트윗 작성은 간단히 새로운 트윗을 트윗 전역 컬랙션에 삽입한다. 사용자가 자신의 홈 타임라인을 요청하면 팔로우하는 모든 사람을 찾고 이 사람들의 모든 트윗을 찾아 시간순으로 정렬해서 합친다.
방법 2.
각 수신 사용자용 트윗 우편함처럼 개별 사용자의 홈 타임라인 캐시를 유지한다. 사용자가 트윗을 작성하면 해당 사용자를 팔로우하는 사람을 모두 찾고 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다. 그러면 홈 타임라인의 읽기 요청은 요청 결과를 미리 계산했기 때문에 비용이 저렴하다.
두 방법의 차이는 읽기 작업과 쓰기 작업의 비용 및 복잡성 배분에 따라 결정된다.
방법 1. 트윗 전역 컬렉션에 삽입 후 정렬
작업 수행 과정
- 사용자가 트윗 작성 시 트윗 데이터를 전역 컬렉션에 저장한다.
- 사용자가 홈 타임라인 요청 시
- 사용자가 팔로우하는 모든 사람의 ID를 찾음
- 각 팔로우 사용자의 트윗을 가져옴
- 시간순으로 정렬 후 합침
이러한 작업 수행 과정을 거치게 된다면 읽기 작업과 쓰기 작업 방식은 아래와 같다.
특징
- 쓰기 작업 : 트윗 작성 시 전역 컬렉션에 추가만 하면 된다.
- 읽기 작업 : 사용자가 홈 타임라인을 요청할 때마다 팔로우 관계를 조회하고 각 사용자의 트윗을 가져오고 시간순 정렬이 이뤄진다.
즉, 쓰기 작업은 빠르고 단순하여 최적화시킬 수 있지만 읽기 작업은 많은 조회 과정을 거치게 됨으로써 성능이 매우 떨어지게 된다.
그래서 트윗은 사용자가 많아지게 되고 읽기 작업보다 쓰기 작업이 훨씬 덜 이뤄지기 때문에 방법 2로 바꾸게 된다.
방법 2. 사용자별 홈 타임라인 캐시 유지
작업 수행 과정
- 사용자가 트윗을 작성하면 팔로워 목록을 조회하여 각 팔로워의 홈 타임라인 캐시에 새로운 트윗을 삽입한다.
- 사용자가 홈 타임라인 요청 시에는 미리 계산된 캐시 데이터를 반환한다.
쓰기 작업과 읽기 작업은 아래 과정을 따르게 된다.
특징
- 쓰기 작업 : 트윗 작성 시 팔로워 전원을 조회하고 각각의 캐시에 데이터를 삽입한다.
- 읽기 작업 : 사전에 계산된 데이터를 바로 반환한다.
방법 2는 매번 홈 타임라인 요청 시 팔로우를 조회하는 것부터 수행해야하는 과정들을 생략하기 위해 홈 타임라인 캐시를 사용한다.
이렇게 된다면 읽기 작업 시에는 미리 준비된 데이터로 방법 1보다 훨씬 빠르게 데이터를 반환할 수 있다.
하지만 쓰기 작업에서는 팔로워 수가 많을 수록 작업 시간이 늘어나게 되며 팔로우/언팔로우 시 캐시 동기화 작업 등 여러 작업 처리가 동반될 수 있다.
정리
트위터 사례에서는 사용자당 팔로워의 분포는 팬아웃 부하를 결정하기 때문에 확장성을 논의할 때 핵심 부하 매개변수가 된다.
애플리케이션마다의 특성을 고려하는 것이 매우 중요하다.
