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

개요

• 뉴스 피드란 어트 홈페이지 중앙에 지속적으로 업데이트 되는 스티로들로 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동 그리고 파로우, 페이지 좋아요 등을 포함하는 것으로 SNS 설계라고 이해하면 된다.

요구사항

1. 모바일 앱과 웹 모두 지원해야 한다.

2. 중요한 기능으로는 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있고, 친구들이 올리는 스토리도 볼 수 있어야 한다.

3. 스토리는 시간 흐름 역순으로 표시된다.

4. 한 사람당 최대 5,000명의 친구를 가질 수 있다.

5. 트래픽 규모는 매일 천만 명이 만문한다고 가정한다.

6. 스토리에는 이미지나 비디오 등 미디어 파일이 포함될 수 있다.

 

개략적 설계

아래 항목에 대한 설계로 나눈다.

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

 

뉴스피드 API

피드 발행 API

• 새 스토리를 포시틍하기 위한 API로 HTTP POST 형태로 요청을 보낸다.
• 인자

POST /v1/me/feed
바디 (body) : 포스팅 내용에 해당
Authorization 헤더 : API 호출을 인증하기 위해 사용.

 

 

피드 읽기 API

• 뉴스 피드를 가져오는 API
• 인자

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

 

 

피드 발행

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

 

뉴스 피드 생성

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

 

상세 설계

피드 발행의 상세 설계

 

웹 서버

• 웹 서버는 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행
• 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 가능
• 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅 수에 제한

 

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

• 팬아웃이란 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정으로 두가지 모델이 있다.
• 쓰기 시점의 팬애웃 (fanout-on-write, push모델이라고도 함)
  • 새로운 포스팅을 기록하는 시점에 뉴스 피드 갱신
  • 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록
  • 장점
    • 뉴스피드가 실시간으로 갱신되어 친구 목록에 있는 사용자에게 즉시 전송
    • 새 포스팅이 기록되는 순간에 뉴스피드가 이미 갱신되므로 (pre-conputed) 뉴스 피드를 읽는데 드는 시간이 짧음
  • 단점
    • 친구가 많은 사용자의 경우 친구 목록을 가져오고 이들의 뉴스피드를 갱신하는데 시간이 오래 걸림. (이 문제를 핫키(hotkey)라도 한다.)
    • 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신하여 컴퓨팅 자원이 낭비.

 

• 읽기 시점에 팬아웃 (fanout-on-read)
  • 피드를 읽어야 하는 시점에 뉴스피드를 갱신함 (요청 기반 (on-demnd) 모델)
  • 사용자가 본인 홈페이지나 타임라인을 로딩하는 시점에 새 포스트를 가져오게 됨
  • 장점
    • 비활성된 사용자 또는 서비스에 거의 로그인하지 않는 사용자의 경우 유리
      • 로그인 하기 전까지 어떤 컴퓨팅 자원도 소모하지 않기 때문
    • 데이터를 친구 각각에 푸시하는 작업이 필요 없어 핫키 문제도 생기지 않음
  • 단점
    • 뉴스 피드를 읽는데 많은 시간이 소요될 수 있음

• 위 그림의 상세 설계는 두 모델의 장점을 살려 결합한 설계안
• 뉴스 피드를 빠르게 가져올 수 있도록 푸시 모델을 사용
• 친구나 팔러워가 아주 많은 사용자의 경우 팔로워로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델을 사용해 시스템 과부하 방지
• 안정 해시를 통해 요청과 데이터를 고르게 분산하여 핫키 문제 줄임

위 설계안에서 팬아웃 서비스에 관한 부분의 설계

동작 원리

1. 그래프 DB에서 친구 ID 목록을 가져온다.
   • 그래 DB는 친구 관계나 친구 추천을 관리하기 적합하다.
2. 사용자 정보 캐시에서 친구들의 정보를 가져온 후 사용자 설정에 따라 친구 일부를 걸러낸다. (뉴스 피드 읽기 허용된 친구만 필터)
3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
4. 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내 뉴스 피드 데이터를 뉴스 피드 캐시에 넣고 새로운 포스팅이 만들어질 때 마다 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID>순으로 순서쌍을 보관하는 매핑 테이블에 레코들이 추가된다.
   • 피드 정보와 사용자 정보를 모두 저장하면 메모리 낭비가 심하므로 ID만 저장한다.
   • 메모리 크기를 적정 수준으로 유지하기 위해 캐시에 크기에 제한을 두며 해당 값은 조정이 가능하도록 한다.

 

피드 읽기 흐름 상세 설계

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

1. 사용자가 뉴스 피드를 읽기 위해 /v1/me/feed로 요청이 전송된다.
2. 로드밸런서가 요청을 웹 서버 가운데 하나로 보낸다.
3. 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출한다.
4. 뉴스 피드에 표시할 사용자 이름, 사용자 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다.
5. 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보내면 클라이언트는 해당 피드를 렌더링한다.

 

캐시 구조

• 캐시는 뉴스 피드 시스템의 핵심 컴포넌트로 아래 그림은 캐시를 다섯 계층으로 나눈 것이다.

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

 

정리

• 설계를 진행하고 기술을 선택할 때에는 그 배경에 어떤 타협적 결정들 (trade-off)이 있었는지 잘 이해하고 설명할 수 있어야 한다.
• 다루면 좋을만한 주제 목록
  • DB 규모 확장
    • 수직적 규모 확장 vs 수평적 규모 확장
    • SQL vs NoSQL
    • 주 부(master-slave)다중화
    • 복제본(replica)에 대한 읽기 연산
    • 일관성 모델 (consistency model)
    • 데이터베이스 샤딩(sharding)
  • 기타
    • 웹 계층 (web tier)을 무상태로 운영하기
    • 가능한 한 많은 데이터를 캐시할 방법
    • 여러 데이터 센터를 지원할 방법
    • 메시지 큐를 사용해 컴포넌트 사이의 결합도 낮추기
    • 핵심 메트릭 (key metric)에 대한 모니터링 (트래픽이 몰리는 시간대의 QPS), 사용자가 뉴스 피드를 새로고침 (refresh)할 때의 지연시간 등)