ch11 뉴스 피드 시스템 설계

4/12/2025

#시스템 디자인

뉴스 피드 시스템 설계

뉴스 피드(news feed) : 페이스북 홈 페이지 중앙에 지속적으로 업데이트되는 스토리, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱활동, 팔로우 사람들, 그룹 좋아요 등등..

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

모바일을 위한 시스템인지, 웹? 둘다 지원해야하나?
중요한 기능들에 대한 질문
뉴스 피드에 조회 순서, 최근 포스트 위치? 기준이 있는지?
한 명의 사용자는 최대 몇 명의 친구를 가질 수 있는지?
트래픽 규모
피드에 이미지, 비디오도 올릴 수 있는지?

요구사항

모바일, 웹 둘다 지원
뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야함, 친구들이 올리는 스토리도 볼수 있게
포스트는 시간 흐름 역순으로 표시
최대 친구는 5000명
매일 천만명(10million DAU) 방문
스토리에 이미지, 비디오 올라갈수있음

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

피드 발행(feed publishing) : 사용자가 스토리 포스팅하면 캐시, 데이터베이스에 기록, 새포스팅은 친구 뉴스 피드에도 전송
뉴스 피드 생성(news feed building) : 모든 친구 포스팅을 시간 흐름 역순으로 모아서 만듬

뉴스 피드 API

HTTP 프로토콜 기반

상태 정보 업데이트 뉴스 피드 가져오기 친구 추가 와 같은 기능들에 사용

피드 발행 API

새 스토리를 포스팅 하기 위한 API HTTP POST 형태

POST /v1/me/feed

인자:

바디(body) : 포스팅 내용
Authorization 헤더 : API 호출 인증

피드 읽기 API

뉴스 피드 가져오기

GET /v1/me/feed

인자:

Authorization 헤더 : API 호출 인증

사용자 : 모바일 앱, 브라우저 , POST /v1/me/feed 로 요청중
로드밸런서(load balancer) : 웹서버 트래픽 분산
웹 서버(web server) : HTTP 요청을 내부 서비스로 중계
포스팅 저장 서비스(post service) : 새 포스팅을 데이터베이스, 캐시에 저장
포스팅 전송 서비스(fanout service) : 새 포스팅을 친구 뉴스 피드에 푸시, 캐시에 보관하여 읽기 빠르도록
알림 서비스(notification service) : 친구들에게 새 포스팅 알림

뉴스 피드 생성

사용자: GET /v1/me/feed API 사용
로드밸런서(load balancer) : 웹서버 트래픽 분산
웹 서버(web server) : HTTP 요청을 내부 서비스로 중계
뉴스 피드 서비스(news feed service) : 캐시에서 뉴스 피드 가져오기
뉴스 피드 캐시(news feed cache) : 뉴스 피드 렌더링시 필요한 피드 ID 보관

3단계 상세 설계

피드 발행 흐름 상세 설계

웹 서버

클라이언트 통신
인증, 처리율 제한 기능 수행
인증 토큰을 Authorization 헤더에 넣기
API 호출하는 사용자만 포스팅
유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅 수 제한

포스팅 전송 서비스

팬아웃(fanout) : 어떤 사용자의 새 포스팅을 친구에게 전달하는 과정

쓰기시점에 팬아웃하는 모델 : 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신, 사용자의 캐시에 포스팅을 기록하는 것

장점

뉴스 피드가 실시간으로 갱신, 친구에게 즉시 전송됨
새 포스팅이 기록되는 순간에 이미 갱신되므로 읽는데 드는 시간이 짧아짐

단점

친구가 많으면, 뉴스 피드를 갱신하는데 시간이 많이 걸림. 핫키(hotkey)
서비스를 자주 이용하지 않는 사용자의 피드까지 갱신하므로 자원이 낭비됨

읽기 시점에 팬아웃하는 모델 : 피드를 읽는 시점에 갱신한다. 요청 기반(on-demand) 모델이다.

장점

비활성화된 사용자, 거의 로그인하지 않는 사용자의 경우 유리, 로그인하기전까지는 자원을 소모하지 않음
친구에게 각각 푸시하는 작업도 없으니 핫키 문제도 생기지 않음

단점

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

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

뉴스 피드를 빠르게 가져오기 위해 대부분 사용자는 푸시모델 사용 친구, 팔로어가 많은 사용자는 팔로어의 포스팅이 필요할 때 가져가도록 하는 풀 모델을 사용하여 과부하를 방지

? 팔로어의 포스팅이 필요한 시기는 언제일까?

추가로 안정해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄여볼 수 있다.

그래프 데이터베이스에서 친구 ID 목록 가져오기

그래프 데이터베이스는 친구 관계, 추천을 관리하기 적합

사용자 정보 캐시에서 친구 정보 가져오기

사용자 설정에 따라 친구 일부를 걸러내고(피드 업데이트 무시로 설정)

친구 목록과 새 스토리 포스팅 ID를 메시지 큐에 넣기
팬아웃 작업 서버(fanout workers) 는 큐에서 꺼내어 뉴스 피드캐시(news feed cache)에 넣기

<포스팅 ID, 사용자 ID> 순서쌍

사용자 정보, 포스팅 정보를 저장하지 않는 이유

메모리 요구량이 지나치게 늘어날 수 있음

캐시 크기 제한을 두어 메모리 크기 적정 수준을 유지

사용자가 천 개의 스토리를 전부 훑어보는 일이 벌어질 확률은 지극히 낮음 대부분의 사용자가 보려 하는 것은 최신 스토리이기에 캐시 미스가 일어날 확률은 낮음

피드 읽기 흐름 상세 설계

사용자가 뉴스 피드 읽기 요청
로드밸런서가 요청을 웹서버 중 하나로 전송
웹서버는 뉴스 피드 서비스를 호출
뉴스 피드 캐시에서 포스팅 ID 목록을 가져옴
뉴스 피드에 표시할 사용자 이름, 사용자 사진, 포스팅 컨텐츠, 이미지등을 사용자 캐시, 포스팅 캐시에서 가져와 뉴스 피드를 생성
JSON형태로 클라이언트에게 전송

캐시 구조

캐시는 뉴스 피드시스템의 핵심 컴포넌트이다.

캐시를 5계층으로 나눈다.

뉴스 피드 : 뉴스 피드 ID
콘텐츠 : 포스팅 데이터 보관, 인기 컨텐츠는 따로 보관
소셜 그래프 : 사용자 간 관계 정보 보관
행동(action) : 포스팅에 대한 사용자의 행위 정보 보관, 포스팅에 대한 좋아요, 답글
횟수(counter) : 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등,,

4단계 마무리

논의해보면 좋을 만한것

데이터베이스 규모 확장

수직적vs 수평적
SQL vs NoSQL
다중화
복제본에 대한 읽기 연산
일관성 모델
샤딩
웹계층을 무상태로 운영하기
가능한 많은 데이터를 캐시할 방법
여러 데이터 센터를 지원할 방법
메시지 큐를 사용하여 컴포넌트 사이 결합도 낮추기
핵심 메트릭에 대한 모니터링
트래픽 몰리는 시간대 QPS(Queries Per Second)
사용자가 뉴스피드 새로고침 할때 지연시간

다음 챕터