11장 - 뉴스 피드 시스템 설계

목표

뉴스피드는 여러분의 홈 페이지 중아에 지속적으로 업데이트되는 스토리들로 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 팔우하는 사람들, 페이지등을 포함한다고 설명하고있다. 이러한 뉴스피드를 설계하여보자.

1단계 문제 이해 및 설계 범위 확정

어떤 기능을 지원해야하는지 반드시 파악해야 한다.

지원자 질문

모바일 앱, 웹 둘다 지원해야하는지?
중요한 기능은 무엇인지
뉴스피드에는 어떤 순서로 스토리가 표시되어야 하는지? 최신 포스트가 위에? 토픽점수(가까운 친구의 포스트) 기준이 있는지?
한 명의 사용자는 최대 몇 명의 친구를 가질 수 있는지?
트래픽 규모는 어느 정도인지?
피드에 이미지나 비디오도 올라올 수 있는지?

면접관 질문

모바일 앱, 웹 둘다 지원해야함
중요한 기능으로 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야 하고, 친구들이 올리는 스토리를 볼 수도 있어야 한다.
시간 흐름 역순으로 피드 표현
한명은 최대 5000명과 친구 가능
트래픽의 규모는 매일 천만 명 방문
피드에 이미지나 비디오등 미디어 파일이 포함되어야함

2단계 개략적 설계안 제시 및 동의 구하기

피드발행, 뉴스 피드 생성 두가지 부분으로 나누어 개략적 설계

피드 발행 : 피드를 생성하면 해당 데이터를 캐시와 데이터베이스에 기록하고 뉴스 피드에 전송된다.
뉴스 피드 생성 : 뉴스 피드는 모든 친구의 포스팅을 역순으로 모아서 만든다고 가정

뉴스 피드 API

HTTP 기반으로 여러 작업을 수행하는 데 사용한다. 가장 중요한 두 가지 API를 알아보자

피드 발행 API

새 스토리를 포스팅하기 위한 API

인자

body : 포스팅 내용
Authorization 헤더 : API 호출을 인증하기 위해 사용

피드 읽기 API

뉴스 피드를 가져오는 API

인자

Authorization 헤더 : API 호출을 인증하기 위해 사용

피드 발행

피드 발행 시스템의 개략적 형태는 다음과 같다.

사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체
로드밸런서 : 트래픽을 웹 서버들로 분산한다.
웹 서버 : HTTP 요청을 내부 서비스로 중계하는 역할을 담당한다.
포스팅 저장 서비스 : 새 포스팅을 데이터베이스와 캐시에 저장
포스팅 전송 서비스 : 새 포스팅을 친구의 뉴스 피드에 푸시한다. 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.
알림 서비스 : 친구들에게 새 포스팅이 올라왔음을 알림, 푸시 알림을 보냄

피드 생성

뉴스 피드 서비스 : 캐시에서 뉴스 피드를 가져오는 서비스다.
뉴스 피드 캐시 : 뉴스 피드를 랜더링할 때 필요한 피드 ID를 보관

3단계 상세 설계

피드 발행 흐름 상세 설계

웹 서버

클라이언트와 통신 + 인증 + 처리율 제한 등 기능도 수행해야함

인증 : 인가한 사람만 게시물 등록 처리율 제한 : 스팸, 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 특정기간 올리 수 있는 포스팅 수 제한

포스팅 전송(팬아웃) 서비스

포스팅 전송은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정이다.
fanout에는 두가지 모델이 있다.

쓰기 시점에 팬아웃(fanout-on-write)
포스팅을 기록하는 시점에 뉴스 피드를 갱신, 해당 사용자의 캐시에 해당 포스팅을 기록하는 것

장점
- 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사요자에게 즉시 전송
- 기록되는 순간 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는 데 드는 시간이 짧아진다.
단점
- 친구가 많은 사용자의 경우 그 목록에 있는 사용자의 뉴스피드를 갱신하는데 많은 시간이 소요(핫키,hotkey 문제)
- 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신함으로 자원이 낭비
읽기 시점에 팬아웃(fanout-on-read)
피드를 읽어야하는 시점에 뉴스 피드를 갱신, 요청 기반 모델
즉, 사용자가 페이지를 로딩하는 시점에 포스트를 가져옴

장점
- 자주 사용하지않는 사용자, 비활성화된 사용자의 경우 유리
- 데이터를 친구 각각에 푸시하는 작업이 없어 핫키 문제가 생기지 않음
단점
- 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있다.

이 두가지 방법을 결합하여 장점은 취하고 단점은 버리는 전략 사용

대부분의 사용자에 대해서 쓰기 시점에 팬 아웃하는 모델을 사용
팔로어가 아주 많은 사용자의 경우 읽기 시점에 팬 아웃하는 모델을 사용하여 과부화 방지
안정 해시를 이용해 요처오가 데이터를 고르게 분산하여 핫키 문제를 줄임

실제 팬아웃 서비스는 다음과 같이 작동한다

그래프 데이터베이스에서 친구 ID목록을 가져옴
사용자 정보 캐시에서 친구들의 정보 가져옴, 사용자 설정에 따라 친구 가운데 일부를 걸러냄(차단기능)
친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
팬아웃 작업서버가 메시지 큐에서 데이터를 꺼내 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.
뉴스 피드 캐시는 (포스팅 ID, 사용자 ID) 순서쌍으로 보관한다.

피드 읽기 흐름 상세 설계안

이미자나 비디오는 CDN을 이용하여 빨리 읽어갈 수 있도록 최적화한다.

사용자의 요청이 들어온다.
로드밸런서가 요청을 웹서버 가운데 하나로 보낸다.
웹서버는 뉴스 피드 서비스를 호출해 피드를 가져온다.
뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다.
뉴스 피드에 표시할 정보등을 사용자 캐시와 포스팅 캐시에서 가져와 완젼한 뉴스피드를 만든다.
생성된 뉴스피드는 JSON형태로 클라이언트에게 보낸다. 클라이언트는 해당 피드를 랜더링한다.

캐시 구조

캐시는 뉴스 피드 시스템의 핵심 컴포넌트다. 다음과 같이 다섯 계층으로 나누어 설계하였다.

뉴스피드 : 뉴스피드
뉴스 피드의 ID 보관
콘텐츠 : 인기 콘텐츠, 일반 콘텐츠
포스팅 데이터를 보관한다. 인기 콘텐츠는 따로 보관
소셜 그래프 : 팔로워, 팔로잉
사용자 간 관계 정보 보관
행동 : '좋아요', 답글, 기타
포스팅에 대한 사용자의 행위 정보 보관
횟수 : 좋아요 횟수, 답글 횟수, 기타
여러 횟수 정보를 보관한다.

4단계 마무리

이번 설계안은 뉴스피드 발행과 생성의 두 부분으로 구성되어 있다.
설계 후 시간이 좀 남는다면 규모 확장성 이슈(데이터 베이스 규모확장)를 논의해보는 것도 괜찮다.

이외에도 다음과 같은 항목을 이야기 해볼만하다.

웹 계층 을 무상태로 운영하기
가능한 한 많은 데이터를 캐시할 방법
여러 데이터 센터를 지원할 방법
메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
핵심 메트릭에 대한 모니터링
트래픽이 몰리는 시간 대의 QPS, 뉴스피드를 새로고침 할 떄의 지연시간 등