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

 

뉴스 피드란?

=> 뉴스피드는 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들로, 사용자 상태 정보 업데이터, 사진, 비디오, 링크, 앱 활동 그리고 페이스북에서 팔로하는 사람들, 페이지, 또는 그룹으로부터 나오는 '좋아요' 등을 포함한다.

 

 

개략적 설계

피드발행 뉴스피드생성 두 가지 부분으로 설계

• 피드 발행
  • 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송한다.
• 뉴스 피드 생성
  • 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다.

 

뉴스 피드 API

• 클라이언트가 서버와 통신하기 위해 사용하는 수단이다.
• HTTP 프로토콜 기반, 상태 정보를 업데이트, 뉴스 피드를 가져오거나, 친구를 추가하는 등의 작업을 수행
• 그 중 피드 발행 API와 피드 읽기 API가 가장 중요하다.

 

피드 발행 API

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

 

POST /v1/me/feed

 

인자

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

 

피드 읽기 API

뉴스 피드를 가져오는 API

 

GET /v1/me/feed

 

인자

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

 

피드 발행

개략적 설계는 아래와 같다

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

 

 

뉴스 피드 생성(피드 읽기?)

• 사용자: 뉴스 피드를 읽는 주체
• 로드 밸런서: 트래픽을 웹 서버들로 분산
• 웹 서버: 트래픽을 뉴스 피드 서비스로 보낸다.
• 뉴스 피드 서비스: 캐시에서 뉴스 피드를 가져온다.
• 뉴스 피드 캐시: 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관

 

 

 

상세 설계

뉴스 피드 발행과 생성 설계를 상세히 보자.

 

"피드 발행 "흐름 상세 설계

웹 서버

• 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 기능 수행
  • 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 가능
  • 스팸을 막고 유해한 콘텐츠 올라오는 것 막기

 

 

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

• 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
• 쓰기 시점에 팬아웃(푸시) 모델과 읽기 시점에 팬아웃(풀) 모델이 있다.

 

쓰기 시점에 팬아웃 모델

• 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신
• 포스팅이 완료되면 사용자의 캐시에 해당 포스팅을 기록

장점

• 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
• 새 포스팅이 기록되는 순간에 뉴스 피드가 갱신되므로 뉴스 피드를 읽는데 드는 시간이 짧다.

단점

• 친구가 많은 사용자의 경우 모두의 뉴스 피드를 갱신하는데 많은 시간이 소요 - 핫키 문제라고 부른다.
• 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원 낭비

 

읽기 시점에 팬아웃하는 모델

• 피드를 읽어야 하는 시점에 뉴스 피드를 갱신
• 요청 기반 모델로, 사용자가 홈페이지나 타임라인을 로딩하는 시점에 새로운 포스트를 가져온다.

장점

• 로그인하기까지는 어떤 컴퓨팅 자원도 소모 하지않는다.
• 데이터를 친구에게 푸시하는 작업이 필요없으므로 핫키 문제도 생기지 않는다.

단점

• 뉴스 피드를 읽는데 많은 시간이 소요된다.

 

최종 설계

• 두 방법을 결합하여 장점은 취하고 단점을 버리는 전략을 적용한 설계를 한다.
• 뉴스 피드를 빠르게 가져오는 것이 중요하므로 대부분의 사용자에 대해서는 푸시 모델을 적용
• 친구나 팔로어가 많은 사용자의 경우에는 포스팅을 필요할 때 가져오는 풀 모델을 사용

 

팬아웃 서비스 순서

 

1. 그래프 데이터베이스에서 친구 ID 목록 가져온다.
2. 사용자 정보 캐시에서 친구들의 정보를 가져온다.
   • 사용자 설정에 따라 친구 일부를 걸러낸다.
     (피드 업데이트 무시)
3. 친구 목록과 새 스토리의 포스팅 ID를 메세지 큐에 넣는다.
4. 팬아웃 작업 서버가 메세지 큐에서 데이터를 꺼내어 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.
   • 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID> 쌍으로 보관하는 매핑 테이블
   • 메모리 용량 문제로 ID 값만 저장한다.

 

"피드 읽기 "흐름 상세 설계

이미지나 비디오와 같은 미디어 콘텐츠는 CDN에 저장해서 빨리 읽어갈 수 있도록 한다.

 

1. 사용자가 뉴스 피드를 읽으려는 요청을 보낸다.
2. 로드 밸런서가 요청을 웹 서버 가운데 하나로 보낸다.
3. 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출
4. 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다.
5. 뉴스 피드에 표시할 정보 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다.
6. 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보낸다.

 

 

캐시 구조

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

 

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

 

 

마무리

추가적으로 논의할 사항

 

• 데이터베이스 규모 확장
• 가능한 많은 데이터를 캐시할 방법
• 메세지 큐를 사용하여 컴포넌트 결합도 낮추기
• 등등