[System Design] 11. 뉴스 피드 시스템 설계

date

Aug 1, 2023

slug

book-system-design-interview-11

author

status

Public

뉴스 피드 시스템(news feed system)을 설계해보자

홈 페이지 중앙에 지속적으로 업데이트되는 스토리의 모음, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 팔로우하는 사람들, 페이지, 또는 그룹으로부터 나오는 ‘좋아요’ 등 모든 정보를 포함하는 뉴스 피드 시스템을 설계해보자.

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

어떤 형태(모바일 앱/웹 등)의 서비스를 제공해야 하는가?

모바일 앱과 웹 중 어떤 형태의 시스템인지, 아니면 둘 다 지원해야 하는지 확인해야 한다.

주요 기능(업로드, 읽기 등)에는 무엇이 있는가?

포스트 업로드, 피드 읽기(이때 노출되는 포스트의 기준은 유저의 친구가 업로드한 포스트)

뉴스 피드는 어떤 기준으로 정렬되어야 하는가?

최신 포스트가 위에 와야 하는지, 토픽 점수(topic score) 같은 다른 기준이 있는지(가까운 친구의 포스트는 좀 더 우선순위가 높다 등)

한 명의 사용자가 가질 수 있는 최대 친구 수가 있는가?

트래픽 규모 추정 및 친구 수 별 사용자 분리 시스템을 구상하기 위한 용도

트래픽 규모는 어느정도인가?

매일 방문하는 유저의 수, 유저의 읽기 횟수 등

업로드 하는 포스트의 종류는 무엇이 있는가?(이미지/비디오 등)

만약 이미지/비디오와 같은 미디어 파일이 포함된다면 CDN 등 저장소를 설계에 포함시켜야 한다.

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

(최소 기능을 위한)뉴스 피드 시스템을 설계는 크게 아래 2가지 부분으로 나누어 진행된다.

💭

1️⃣ 피드 발행(feed publishing) : 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송된다.

2️⃣ 뉴스 피드 생성(news feed building) : 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다.

들어가기 : 뉴스 피드 API는 HTTP 프로토콜을 기반으로 한다.

HTTP 프로토콜을 기반으로하여, 상태 정보를 업데이트하거나, 뉴스 피드를 가져오거나, 친구를 추가하는 등의 다양한 작업을 한다. 이 중 가장 중요한 API는 피드 발행과 피드 읽기 API이다.

1) 피드 발행 API

Method : POST
Param :

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

2) 피드 읽기 API

Method : GET
Param :

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

피드 발행 : 포스트 업로드 ~ 피드 발행을 위한 시스템 구조 설계

사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 업로드하는 주체. POST API를 통해 포스트를 업로드한다.

로드밸런서 : 트래픽을 웹 서버들로 분산시킨다.

웹 서버 : HTTP 요청을 내부 서비스로 중계하는 역할을 담당한다.

포스팅 저장 서비스(post service) : 새 포스팅을 데이터베이스와 캐시에 저장한다.

포스팅 전송 서비스(fanout service) : 새 포스팅을 친구의 뉴스 피드에 push 한다. 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.

알림 서비스(notification service) : 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보낸다.

피드 생성 : 사용자가 피드를 읽어오기 위한 시스템 구조 설계

사용자 : 뉴스 피드를 읽는 주체. GET API 를 사용하여 발행된 뉴스 피드를 읽어 온다.

로드 밸런서 : 트래픽을 웹 서버들로 분산시킨다.

웹 서버 : HTTP 요청을 뉴스 피드 서비스로 보낸다.

뉴스 피드 서비스(news feed service) : 캐시에서 뉴스 피드를 가져온다.

뉴스 피드 캐시(news feed cache) : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관한다.

3단계 상세 설계

피드 발행 상세한 흐름

웹 서버 : 인증, 스팸 방지/처리율 제한

웹 서버는 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행한다.

인증 : 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅을 할 수 있어야 한다.

처리율 제한 : 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅의 수에 제한을 두어야 한다.

포스팅 전송(팬아웃) 서비스 : 1)push model, 2)pull model

포스팅 전송(팬아웃, fanout)은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정이다.

쓰기 시점에 팬아웃(fanout-on-write) = push model 푸시모델

읽기 시점에 팬아웃(fanout-on-read) = pull model 풀 모델

두 가지 모델 각각의 장단점을 알아보자.

1️⃣ 쓰기 시점에 팬아웃(fanout-on-write)

새로운 포스팅을 기록하는 시점에 모든 뉴스 피드를 갱신한다.

장점 - 실시간 반영, 새로 읽어들이는 시간 단축

뉴스 피드가 실시간으로 갱신되며, 친구 목록에 있는 사용자에게 즉시 전송된다.
새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로(pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아진다.

단점 - 핫키, 컴퓨팅 자원 낭비

친구가 많은 사용자의 경우, 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수도 있다. 이 문제를 핫키(hotkey)라고 부르기도 한다.
서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원이 낭비된다.

2️⃣ 읽기 시점에 팬아웃(fanout-on-read)

피드를 읽어야 하는 시점에 뉴스 피드를 갱신한다. 따라서 요청 기반(on-demand) 모델이다. 사용자가 본인 홈페이지나 타임라인을 로딩하는 시점에 새로운 포스트를 가져오게 된다.

장점 - 컴퓨팅 자원 절약, 핫키 발생 X

비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 이 모델이 유리하다. 로그인하기까지는 어떤 컴퓨팅 자원도 소모하지 않아서다.
데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않는다.

단점 - 시간 오래 걸림

뉴스 피드를 읽는 데 많은 시간이 소요될 수 있다.

3️⃣ 하이브리드 팬아웃 모델

위 두 가지 방법을 결합하여 장점은 취하고 단점은 최대한 피할 수 있는 전략을 설계해보자.

뉴스 피드를 빠르게 가져올 수 있도록 하는 것은 아주 중요하므로 대부분의 사용자에 대해선 푸시 모델(fanout-on-write)을 사용한다.

친구나 팔로어가 아주 많은 사용자의 경우, 핫키로 인한 시스템 과부하 방지를 위하여, 팔로어로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델(fanout-on-read)을 사용한다.

아울러 안정 해시(consistent hashing)를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄일 것이다.

팬아웃 상세 동작 과정(번호는 위 아키텍처 사진에 있는 번호를 참고)

그래프 데이터베이스에서 친구 ID 목록을 가져온다.

사용자 정보 캐시에서 친구들의 정보를 가져온다.

사용자 설정에 따라 친구 일부를 걸러낸다(사용자 mute, 일부 사용자에게만 공유 등).

친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.

팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.

뉴스 피드 캐시는 <post_id, user_id> 의 순서쌍을 보관하는 매핑 테이블이다.
id 값만 저장하도록 하여, 불필요한 메모리 사용을 최소화한다.
메모리 크기를 적정 수준으로 유지하기 위하여, 이 캐시의 크기에 제한을 두고 해당 값은 조정할 수 있도록 한다.
한 사용자가 뉴스 피드에 올라온 수천 개의 스토리를 전부 훑어볼 확률은 지극히 낮으므로 캐시 미스가 일어날 확률 또한 매우 낮을 것이다.

피드 읽기 상세한 흐름

상세 동작 과정

사용자가 뉴스 피드를 읽기 위한 HTTP 요청을 보낸다.

로드밸런서가 해당 요청을 웹 서버 중 하나로 보낸다.

웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출한다.

뉴스 피드 서비스는 뉴스 피드 캐시에서 해당 유저의 포스팅 ID 목록을 가져온다.

뉴스 피드에 사용할 사용자 이름, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다.

생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보낸다. 클라이언트는 해당 피드를 렌더링한다.

캐시 구조

매 초마다 수백 수천 건의 요청이 들어오는 뉴스 피드 시스템의 핵심은 캐시다. 다양한 예시가 있겠지만, 본 설계안에서는 캐시를 다섯 계층으로 나누었다.

뉴스 피드 : 뉴스피드의 ID를 보관한다.

콘텐츠 : 포스팅 데이터를 보관한다. 인기 콘텐츠는 따로 보관한다.

소셜 그래프 : 팔로어, 팔로잉 등 사용자 간 관계 정보를 보관한다.

행동(action) : 포스팅에 대한 사용자의 행위에 관한 정보를 보관한다. 포스팅에 대한 ‘좋아요’, ‘답글’ 등이 이에 해당한다.

횟수(counter) : ‘좋아요’ 횟수, 응답 수, 팔로워 수, 팔로잉 수 등의 정보를 보관한다.

4단계 마무리

뉴스 피드 시스템은 1)피드 발행과 2)피드 생성의 두 부분으로 나뉜다.

설계 문제에 정답은 없다. 회사마다 다른 제약, 요구조건이 있기 때문에 시스템을 설계할 때는 다양한 점을 고려해야 한다.

설계를 진행하고 기술을 선택할 때는 그 배경에

어떤 타협적 결정들(trade-off)이 있었는지 잘 이해하고 설명할 수 있어야 한다.

설계를 마친 후에도 시간이 남는다면 면접관과 규모 확장성 이슈를 논의하는 것도 좋을 것이다.

수직적 규모 확장 vs 수평적 규모 확장

SQL vs NoSQL

주-부(master-slave) 다중화

복제본(replica)에 대한 읽기 연산

일관성 모델(consistency model)

데이터베이스 샤딩(sharding)

이 외에도 논의해 보면 좋을 만한 주제

웹 계층(web tier)을 무상태로 운영하기

가능한 한 많은 데이터를 캐시할 방법

여러 데이터 센터를 지원할 방법

메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기

핵심 메트릭(key metric)에 대한 모니터링(트래픽이 몰리는 시간대의 QPS, 새로고침할 때의 latency 등)

다음 화 예고…

💡

처리율 제한 장치를 설계해보자!