TIL

11장 뉴스 피드 시스템 설계

• 뉴스 피드란?

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

뉴스 피드 시스템 개략적 설계안

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

뉴스 피드 API

• 상태 정보를 업데이트하거나 뉴스 피드를 가져오거나 친구를 추가하는 등의 작업을 수행

피드 발행 API

• 새 스토리를 포스팅하기 위한 API
• HTTP POST 형태로 요청
  • POST /v1/me/feed
  • 인자: 바디(포스팅 내용), Authorization 헤더

피드 읽기 API

• 뉴스 피드를 가져오는 API
  • GET /v1/me/feed
  • 인자: Authorization 헤더

피드 발행

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

뉴스 피드 생성

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

뉴스 피드 시스템 상세 설계

피드 발행 흐름 상세 설계

웹 서버

• 클라이언트와 통신
• 인증
• 처리율 제한 등
  • 스팸과 유해 콘텐츠 방지
  • 특정 기간 동안 한 사용자의 포스팅 수 제한

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

• 포스팅 전송(팬아웃)은 어떤 사용자의 새 포스팅을 그 사용자의 친구 관계의 모든 사용자에게 전달하는 과정
• 팬아웃의 두 가지 모델
  • 쓰기 시점 팬아웃 (푸시 모델)
  • 읽기 시점 팬아웃 (풀 모델)
• 쓰기 시점 팬아웃 모델
  • 새로운 포스팅을 기록하는 시점에 뉴스 피드 갱신 (피드 캐시에 기록)
  • 장점
    • 뉴스 피드 실시간 갱신 및 친구 사용자에게 즉시 전송
    • 피드 읽는 데 시간이 짧아진다.
  • 단점
    • 친구가 많은 사용자의 경우 모든 친구의 뉴스 피드를 갱신하는 데 많은 시간이 소요 (핫키 문제)
    • 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원 낭비
• 읽기 시점 팬아웃 모델
  • 피드를 읽을 때 피드 갱신
  • 장점
    • 서비스를 자주 이용하지 않는 사용자의 경우 이 모델이 유리
    • 데이터를 친구 각각에게 푸시하는 작업이 필요 없기에 핫키 문제도 생기지 않는다.
  • 단점
    • 뉴스 피드를 읽는데 많은 시간이 소요될 수 있다.
• 절충안
  • 대부분의 사용자에게 푸시 모델 사용
  • 친구, 팔로워가 많은 사용자의 경우 팔로어로 하여금 해당 사용자 포스팅을 가져올 땐 풀 모델을 사용
  • 안정 해시를 통해 요처오가 데이터를 보다 고르게 분산하여 핫키 문제 줄이기
• 팬아웃 서비스는 다음과 같이 동작
  1. 그래프 DB에서 친구 ID 목록을 가져온다.
  2. 사용자 정보 캐시에서 친구들 정보를 가져온다.
  3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
  4. 팬아웃 작업 서버가 메시지큐에서 데이터를 꺼내 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.
  5. <포스팅 ID, 사용자 ID>의 순서쌍을 보관
  6. 이 캐시에는 크기 제한을 두는데 어떤 사용자가 뉴스 피드의 수천 개 스토리를 전부 보지 않을 것이기 대문

피드 읽기 흐름 상세 설계

• 미디어 컨텐츠는 CDN에 저장하여 읽기 속도를 높였다.

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

캐시 구조

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

더 논의할만한 점

• 데이터베이스 규모 확장
  • 수직적 규모 확장 vs 수평적 규모 확장
  • SQL vs NoSQL
  • master-slave 다중화
  • 복제본(replica)에 대한 읽기 연산
  • 일관성 모델
  • 샤딩
• 그 외
  • 웹 계층을 무상태로 운영
  • 가능한 많은 데이터를 캐시할 방법
  • 여러 데이터 센터를 지원할 방법
  • 메시지 큐를 사용하여 컴포넌트 간 결합도 낮추기
  • 핵심 매트릭에 대한 모니터링