[가상 면접 사례로 배우는 대규모 시스템 설계 기초]11. 뉴스 피드 시스템 설계
https://product.kyobobook.co.kr/detail/S000001033116
가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고
가상 면접 사례로 배우는 대규모 시스템 설계 기초 | “페이스북의 뉴스 피드나 메신저,유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?” IT 경력자라도 느닷없이 대규모 시스템
product.kyobobook.co.kr
1장 사용자 수에 따른 규모 확장성 : https://inhyeok-blog.tistory.com/40
2장 개략적인규모추정 : https://inhyeok-blog.tistory.com/41
3장 시스템 설계 면접 공략법 : https://inhyeok-blog.tistory.com/42
4장 처리율제한장치의설계 : https://inhyeok-blog.tistory.com/43
5장 안정해시설계 : https://inhyeok-blog.tistory.com/44
6장 키-값저장소설계 : https://inhyeok-blog.tistory.com/45
7장 분산시스템을위한유일 ID 생성기설계 : https://inhyeok-blog.tistory.com/46
8장 URL 단축기설계 : https://inhyeok-blog.tistory.com/47
9장 웹크롤러설계 : https://inhyeok-blog.tistory.com/48
10장알림시스템설계 : https://inhyeok-blog.tistory.com/49
11장뉴스피드시스템설계 : https://inhyeok-blog.tistory.com/50
12장채팅시스템설계 : https://inhyeok-blog.tistory.com/51
13장검색어자동완성시스템 : https://inhyeok-blog.tistory.com/52
14장유튜브설계 : https://inhyeok-blog.tistory.com/53
15장구글드라이브설계 : https://inhyeok-blog.tistory.com/54
뉴스피드 설계는 개인적으로 이해하기 어려운 부분이 있었다. 마이크로 서비스를 시작으로 시스템을 설계하기 때문이다. 하지만 천처히 따라가 보자.
요구사항
- 모바일과 웹 둘다 자원하는 시스템이다
- 주요기능 : 새로운 스토리를 올릴 수 있어야 하고, 친구가 올리는 스토리를 볼 수 있어야 한다.
- 뉴스피드는 시간 흐름 역순으로 표시한다.
- 한명의 사용자는 최대 5000명의 친구를 가질 수 있다.
- 매일 천만 명이 방문한다.
- 스토리에 미디어 파일이 포함될 수 있다.
개략적 설계안 제시 및 동의 구하기
설계는 피드 발행(feed publishing)과 뉴스 피드 생성(news feed building)의 두 부분으로 나뉘어 진다.
- 피드 발행: 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 DB에 저장하며, 새 포스팅은 친구의 뉴스 피드에도 전송된다.
- 뉴스 피드 생성: 뉴스 피드는 모든 친구의 포스팅을 시간 흐름에 따라 역순으로 만든다.
피드 발행(개략적 설계)
뉴스 피드 생성(개략적 설계)
피드 발행 흐름 상세 설계
이 시스템은 사용자가 포스팅을 하면 포스트를 DB에 저장하는 피드 발행 시스템과 사용자가 피드를 확인하면 포스트들의 집합을 보여주는 피드 시스템으로 이루어져 있다. 여기서 가장 부하가 많고, 고민스러운 부분은 뉴스 피드를 조회했을 때 수많은 포스트 중에 사용자에게 보여줘야하는 피드가 무엇인지 선택하는 것이다. 심지어 최대한 빠르게 말이다. 이를 위해서 책에선 포스팅 시스템에 전송 서비스를 넣어 둔 것이다. 이를 통해서 사용자에 따라 피드를 빠르게 구성할 수 있다. 여기서 설계자는 포스팅 전송(팬아웃) 서비스를 구성하기 위해 2가지 전략을 선택할 수 있다.
- 쓰기 시점에 팬아웃 하는 모델(푸시 모델)
포스팅을 기록하는 시점에 뉴스 피드를 갱신. 즉, 포스팅이 완료되면 바로 해당 사용자의 캐시에 기록
장점
1. 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
2. 새 포스팅이 기록되는 순간 뉴스 피드가 갱신되므로, 뉴스 피드를 읽는 속도가 빠름
단점
1. 친구가 많은 사용자는 전송에 시간이 오래걸린다. 이는 핫키(hotkey) 라고 부르는 문제이다.
2. 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신하는 비효율이 존재
- 읽기 시점에 팬아웃 하는 모델(풀 모델)
피드를 읽어야하는 시점에 뉴스 피드를 갱신(on-demand model)
장점
1. 비활성화/자주 사용하지 않는 유저를 위한 컴퓨터 자원을 소모하지 않는다.
2. 핫키 문제가 발생하지 않는다.
단점
1. 뉴스피드를 읽는데 오래 걸릴 수 있다.
저자는 2가지 방법의 장점을 취하고 단점을 버리는 전략을 제안한다. 대부분에 사용자에 대해서는 푸시 모델을 사용하고, 핫키 문제가 발생할 수 있는 친구나 팔로어가 맣은 사용자는 풀 모델을 사용하는 것이다. 아울러 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 최소화 한다.
피드 읽기 흐름 상세 설계
미디어 파일은 CDN에 저장해서 전송 속도를 높혔다.