•
뉴스 피드란 페이스북의 정의를 빌려, 여러분의 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들로, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 팔로잉 페이지, 그룹 등을 포함한다.
•
뉴스 피드 시스템 설계는 아주 유명한 단골 설계 문제로, 비슷한 유형의 문제로 페이스북 뉴스 피드, 인스타그램 피드 설계 등이 있다.
1단계 문제 이해 및 설계 범위 확정
•
뉴스 피드 설계를 위해 다음과 같은 사항들을 질문해볼 수 있다.
◦
지원해야하는 시스템이 무엇인지, 웹인지, 앱인지
◦
주요 기능으로는 무엇이 있는지
◦
뉴스 피드에 데이터를 표시하는 정책이 있는지
◦
트래픽 규모는 어느 정도인지
◦
게시물의 구성(이미지, 비디오 등)이 어떻게 되는지
2단계 개략적 설계안 제시 및 동의 구하기
•
크게 뉴스 피드 시스템은 피드 발행과 뉴스 피드 생성 두 부분으로 구성된다.
◦
피드 발행 : 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송된다.
◦
뉴스 피드 조회 : 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 정렬 요구사항에 적합하게 만든다고 가정한다.
뉴스 피드 API
•
다음과 같이 설계한 API를 적절한 논리에 맞춰, 인자, 헤더, Uri 등을 설명하면 된다.
◦
피드 발행 API
◦
피드 읽기 API
피드 발행
•
피드 발행 시스템의 개략적 형태에서 각 모듈들은 다음의 역할을 수행한다.
◦
사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 올린다.
◦
로드밸런서 : 트래픽을 웹 서버들로 분산한다.
◦
웹 서버 : HTTP 요청을 웹 애플리케이션 서버에 위임하는 역할을 담당한다.
◦
포스팅 저장 서비스 : 새 포스팅을 데이터베이스와 캐시에 저장한다.
◦
포스팅 전송 서비스 : 새 포스팅을 친구의 뉴스 피드에 푸시한다. 뉴스 피드 데이터는 캐시하여 빠르게 읽을 수 있도록 한다.
◦
알림 서비스 : 새 포스팅이 추가되는 경우, 구독자들에게 이를 알린다.
뉴스 피드 조회
•
뉴스 피드 조회 시스템의 개략적 형태에서 각 모듈들은 다음의 역할을 수행한다.
◦
사용자 : 뉴스 피드를 조회하는 주체다.
◦
로드 밸런서 : 트래픽을 웹 서버들로 분산한다.
◦
웹 서버 : 트래픽을 뉴스 피드 서비스에세 위임한다.
◦
뉴스 피드 서비스 : 캐시에서 뉴스 피드를 가져온다.
◦
뉴스 피드 캐시 : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관해둔다.
3단계 상세 설계
•
개략적으로 설계한 후, 추가적으로 구체적인 설계가 필요한 부분에 한정하여 상세 설계를 진행한다.
피드 발행 상세 설계
•
웹 서버
◦
클라이언트와 통신을 시작하는 첫 지점이므로 인증이나 처리율 제한의 기능을 추가할 수 있다.
•
포스팅 전송 서비스
◦
새로운 포스트가 추가되어 이를 푸시하는 서비스로, 팬아웃에 해당하며, 푸쉬, 풀 모델로 구분된다.
▪
푸쉬 모델(발행 시점에 뉴스 피드를 갱신한다)
•
장점
◦
뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송된다.
◦
새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는데 드는 시간이 줄어든다.
•
단점
◦
친구가 많은 사용자의 경우, 갱신에 오랜 시간이 소요될 수도 있다. 이는 핫키라고 부르는 문제다.
◦
서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원이 낭비된다.
▪
풀 모델(조회 시점에 뉴스 피드를 갱신한다)
•
장점
◦
유령 사용자가 많은 경우, 이 모델이 유리하다.
◦
데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않는다.
•
단점
◦
뉴스 피드를 조회하는데, 많은 시간이 소요될 수 있다.
피드 읽기 흐름 상세 설계
•
캐시 구조
◦
캐시는 뉴스 피드 조회 시스템의 핵심 컴포넌트다. 그렇기 때문에 더 상세하고 구체적인 설계가 필요하다.
◦
여러 캐시를 사용하게 되는데, 해당 예제에서는 다음과 같은 항목들을 캐시하게 된다.
▪
뉴스피드, 콘텐츠(인기, 일반), 소셜 그래프(팔로워, 팔로잉), 행동(좋아요, 답글, 조회 등), 횟수(좋아요, 답글, 조회, 팔로잉, 팔로워 등)
4단계 마무리
•
이번 설계안은 뉴스 피드 발행과 생성(조회, 발행 시점)의 두 부분으로 구성되어 있다.
•
시간이 좀 남는다면 규모 확장성 이슈를 논의하는 것도 바람직하다.
◦
데이터베이스 규모 확장
▪
수직적 규모 확장 vs 수평적 규모 확장
▪
데이터 구조, 특성에 따른 SQL vs NoSQL
▪
주-부 다중화
▪
복제본에 대한 읽기 연산
▪
일관성 모델
▪
데이터베이스 샤딩
•
이 외에도 논의해 보면 좋을 만한 주제로는 다음이 있다.
◦
웹 계층을 Stateless로 만드는 방법
◦
가능한 많은 데이터를 캐시할 방법
◦
여러 지역적인 데이터 센터를 지원할 방법
◦
메시지 큐를 사용하여 컴포넌트 사이의 결합도를 낮추도록 개선하는 방법
◦
핵심 지표에 대한 모니터링을 제공할 방법
