문제 이해 및 설계 범위 확정#
- 모바일 앱, 웹 둘 다 지원
- 시간 흐름 역순
- 한 명의 사용자는 최대 5000명의 친구
- 매일 천만 명이 방문
- 피드에 이미지나 비디오 등의 미디어 파일이 포함될 수 있음
개략적 설계안 제시 및 동의 구하기#
- 피드 발행: 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송된다.
- 뉴스 피드 생성: 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다.
뉴스 피드 API#
- 피드 발행 API: 새 스토리를 포스팅 하기 위한 API
POST /v1/me/feed
- 피드 읽기 API: 뉴스 피드를 가져오는 API
GET /v1/me/feed
상세 설계#
피드 발행 흐름 상세 설계#
- 웹 서버: 인증, 처리율 제한
- 포스팅 전송 서비스:
- 두 가지 모델
- 쓰기 시점에 팬아웃(fanout-on-write)
- 장점
- 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
- 새 포스팅이 기록되는 순간에 뉴스피드가 이미 갱신되므로, 뉴스 피드를 읽는 데 드는 시간이 짧아진다.
- 단점
- 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있다. (핫키 문제)
- 서비스를 자주 이용하지 않은 사용자의 피드까지 갱싱해야 하므로 컴퓨팅 자원이 낭비된다.
- 읽기 시점에 팬아웃(fanout-on-read)
- 장점
- 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않은 사용자의 경우에 컴퓨터 자원을 아낄 수 있다.
- 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않는다.
- 단점
- 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있다.
- 두 가지 모델을 결합하여 사용할 수 있다.
- 예시: 친구가 많은 사용자의 경우에는 읽기 시점 팬아웃, 대부분의 경우엔 쓰기 시점 팬아웃
- 아울러 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄여볼 수 있다.
- 뉴스 피드 캐시:
<포스팅 ID, 사용자 ID> 순서쌍을 보관하는 매핑 테이블이다.- 메모리 요구량을 지나치게 늘어나지 않기위해 사용자 정보와 포스팅 정보는 캐시에 저장하지 않는다.
- 메모리 크기를 적정 수준으로 유지하기 위해서, 캐시 크기에 제한을 두며, 해당 값은 조정이 가능하도록 한다.
피드 읽기 흐름 상세 설계#
- 사용자가 뉴스 피드 읽기 요청을 보낸다.
- 로드밸런서가 요청을 웹 서버 가운데 하나로 보낸다.
- 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출한다.
- 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다.
- 뉴스 피드에 표시할 사용자 이름, 사용자 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다.
- 생서된 뉴스 피드를 JSON 형태로 클라이언트에게 보낸다. 클라이언트는 해당 피드를 렌더링 한다.