Featured image of post 11. 뉴스 피드 시스템 설계
Common

11. 뉴스 피드 시스템 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초

뉴스 피드란?

페이스북의 도움말 페이지에서는 아래와 같이 뉴스 피드를 설명하고 있다.

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

뉴스 피드 시스템 설계는 아주 유명한 면접 문제이다.

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

  • Q. 모바일 앱, 웹 어떤걸 지원해야하는가?
    • A. 둘다.
  • Q. 주요 기능은?
    • A. 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야함
      • 친구들이 올리는 스토리를 볼 수도 있어야함
  • Q. 어떤 순서로 스토리가 표시되는가? 최신 포스트? 토픽 점수 기반?
    • A. 시간 흐름 역순으로 표시(Reverse chronological order)
  • Q. 한 명의 사용자는 최대 몇 명의 친구를 가질 수 있는가?
    • A. 5,000명
  • Q. 트래픽 규모는?
    • A. 매일 천만 명 방문한다고 가정
  • Q. 피드에 이미지나 비디오 스토리도 올라올 수 있는가?
    • A. 이미지나 비디오 등 미디어 파일이 포함될 수 있음

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

뉴스 피드 시스템 설계는 피드 발행(Feed publishing)과 뉴스 피드 생성(News feed building) 두 가지 구분으로 나눌 수 있다.

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

뉴스 피드 API

뉴스 피드 API는 HTTP 프로토콜 기반으로 클라이언트가 서버와 통신하기 위해 사용하는 수단이다.

  • 상태 정보를 업데이트 할 때
  • 뉴스 피드를 가져올 때
  • 친구를 추가하는 등 다양한 작업 수행

피드 발행 API

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

HTTP POST 형태로 요청을 보낸다.

1

POST /v1/me/feed
  • 인자
    • body: 포스트 내용
    • Authorization 헤더: API 호출을 인증하기 위해 사용한다.

피드 읽기 API

뉴스 피드를 가져오는 API다.

1

GET /v1/me/feed
  • 인자
    • Authorization 헤더: API 호출을 인증하기 위해 사용한다.

피드 발행

피드 발행 구조

  • 사용자
    • 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체
    • POST /v1/me/feed API를 사용
  • 로드밸런서(load balancer)
    • 트래픽을 웹 서버들로 분산
  • 웹 서버
    • HTTP 요청을 내부 서비스로 중계하는 역할을 담당
  • 포스팅 저장 서비스(Post service)
    • 새 포스팅을 데이터베이스와 캐시에 저장
  • 포스팅 전송 서비스(Fanout service)
    • 새 포스팅을 친구의 뉴스피드에 푸시(push)
    • 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 해야함
  • 알림 서비스(notification service)
    • 친구들에게 새 포스팅이 올라왔음을 알림
    • 푸시 알림을 보냄

뉴스 피드 생성

뉴스 피드 생성 구조

  • 사용자
    • 뉴스 피드를 읽는 주체
    • GET /v1/me/feed를 이용
  • 로드 밸런서
    • 트래픽을 웹 서버들로 분산
  • 웹 서버
    • 트래픽을 뉴스 피드 서비스로 보냄
  • 뉴스 피드 서비스(news feed service)
    • 캐시에서 뉴스 피드를 가져오는 서비스
  • 뉴스 피드 캐시(news feed cache)
    • 랜더링할 때 필요한 피드ID를 보관

3단계: 상세 설계

피드 발행 흐름 상세 설계

웹 서버와 포스팅 전송 서비스에 초점을 두고 확인한다.

웹 서버

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

  • 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 할 수 있어야 한다.
  • 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 사용자가 올리 수 있는 포스팅 수를 제한을 둬야한다.

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

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

포스팅 전송 서비스

두 가지 유형이 존재하며 각기 장단점을 가진다.

푸시 모델(push model)

새로운 포스팅을 기록하는 시점(쓰기 시점)에 뉴스피드를 갱신하게 된다.

다시 말해, 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록한다.

  • 장점
    • 뉴스피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
    • 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로(pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아짐
  • 단점
    • 친구가 많은 사용자의 경우 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수도 있음
      • 핫키(Hotkey) 문제
    • 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 자원 낭비

풀 모델(pull model)

피드를 읽어야 하는 시점에 뉴스 피드를 갱신한다.

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

  • 장점
    • 로그인하기까지는 어떤 컴퓨팅 자원도 소모하지 않으므로 비활성화된 사용자는 이 모델이 유리하다.
    • 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않는다.
  • 단점
    • 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있다.

이번 설계안은 두 가지 방법을 결합하여 장점은 취하고 단점은 버린다.

  • 뉴스피드를 빠르게 가져올 수 있도록 하는 것은 아주 중요하므로 대부분의 사용자에 대해서 푸시 모델 사용
  • 친구, 팔로워가 아주 많은 사용자의 경우는 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델을 사용
  • 안정 해시(consistent hashing)을 통해 요청과 데이터를 고르게 분산하여 핫 키 문제를 완화

  1. 그래프 데이터베이스에서 친구 ID 목록을 가져온다.
    • 그래프 데이터베이스는 친구 관계나 친구 추천을 관리하기 적합하다.
  2. 사용자 정보 캐시에서 친구들의 정보를 가져온후, 설정에 따라 일부 걸러낸다.
    • 차단 등 이유로
  3. 친구 목록과 새 스토리의 포스팅 ID를 메시키 큐에 넣는다.
  4. 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.
    • 뉴스 피드 캐시: <포스팅 ID, 사용자 ID>
    • 모든 데이터를 포함하면 메모리 요구량이 지나치게 늘어날 수 있다.
    • 어떤 사용자가 뉴스 피드에 올라온 수천 개의 스토리를 볼 확률은 지극히 낮다.(캐시 미스 확률이 낮다.)

피드 읽기 흐름 상세 설계

피드 읽기 흐름

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

  1. 사용자가 뉴스 피드 읽기 요청을 보냄
  2. 로드밸런서가 요청을 웹 서버 가운데 하나로 보냄
  3. 피드를 가져오기 위해 뉴스 피드 서비스 호출
  4. 뉴스 피드 캐시에서 포스팅 ID 목록을 조회
  5. 사용자 이름, 사용자 사진 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드 생성
  6. JSON 형태로 응답

캐시 구조

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

5계층 캐시 구조

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

4단계: 마무리

이번 설계안은 뉴스 피드 발행, 뉴스 피드 생성 두 부분으로 구성되어 있다.

설계를 진행하고 기술을 선택할 때는 그 배경에 어떤 타협적 결정들이 있었는지 잘 이해하고 설명할 수 있어야 한다.

시간이 남는다면 규모 확장성 이슈를 논의하는 것이 좋을 수 있다.

데이터베이스 규모 확장

  • 수직적 규모 확장 vs 수평적 규모 확장
  • SQL vs NoSQL
  • master-slave 다중화
  • 복제본(replica)에 대한 읽기 연산
  • 일관성 모델(consistency model)
  • 데이터베이스 샤딩

그 외

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