서론
뉴스 피드: 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들
Ex) 페이스북 뉴스 피드 설계, 인스타그램 피드 설계, 트위터 타임라인 설계

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

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

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

뉴스 피드 API

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

피드 발행 API

• 새 스토리 포스팅용 API
• 형태: POST/v1/me/feed
• 인자
  1. 바디(body): 포스팅 내용에 해당
  2. Authoruzation 헤더: API 호출을 인증하기 위해 사용

피드 읽기 API

• 뉴스 피드 가져오는 API
• 형태: GET/v1/me/feed
• 인자
  1. Authoruzation 헤더: API 호출을 인증하기 위해 사용

피드 발행

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

뉴스 피드 생성

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

3단계 상세 설계

피드 발행 흐름 상세 설계

웹 서버, 포스팅 전송 서비스(fanout service)가 중심

웹 서버

웹 서버 담당 기능

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

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

포스팅 전송 = 팬아웃(fanout)

• 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
  팬아웃 두 가지 모델
• 쓰기 시점에 팬아웃(fanout-on-write, push 모델)
• 읽기 시점에 팬아웃(fanout-on-read, pull 모델)

fanout-on write 모델

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

장점

• 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송됨
• 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로(pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아짐

단점

• 핫키(hotkey): 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신할 때 많은 시간이 소요될 수 있음
• 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 해서 컴퓨팅 자원이 낭비됨

fanout-on read 모델

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

장점

• 비활성화된 사용자, 서비스에 거의 로그인하지 않는 사용자의 경우에 이 모델이 유리함, 로그인하기까지 어떤 컴퓨팅 자원도 소모하지 않음
• 데이터를 친구 각각에 푸시하는 작업이 필요없어 핫키 문제 발생 X

단점

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

두 가지 방법 결합 설계안

• 대부분의 사용자의 경우 푸시 모델 사용
• 친구나 팔로어가 아주 많은 사용자의 경우에 팔로어로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델을 사용해서 시스템 과부하 방지
• 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제 줄임
• 아래 그림은 팬아웃 서비스만 따로 떼어 옮긴 것
  
  팬아웃 서비스 동작

1. 그래프 데이터베이스에서 친구 ID 목록을 가져옴

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

2. 사용자 정보 캐시에서 친구들의 정보를 가져옴 -> 사용자 설정에 따라 친구 가운데 일부를 걸러냄
3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣음
4. 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스 피드 데이터를 뉴스 피드 캐시에 넣음

• 뉴스 피드 캐시: <포스팅 ID, 사용자 ID> 순서쌍을 보관하는 매핑 테이블
• 따라서 새로운 포스팅이 만들어질 때 이 캐시에 레코드가 추가될 것
• 사용자 정보, 포스팅 정보 전부를 이 테이블에 저장하지 않는 이유는 메모리 요구량이 지나치게 늘어날 수 있기 때문 => 따라서 ID만 보관
• 메모리 크기를 적정 수준으로 유지하기 위해 캐시 크기에 젷나을 두고 해당 값은 조정 가능하게 함
• 어떤 사용자가 뉴스 피드에 올라온 수천 개의 스토리를 훑을 확률은 적고 최신 스토리를 볼 확률이 높아 캐시 미스가 일어날 확률은 낮음

피드 읽기 흐름 상세 설계

• 미디어 콘텐츠는 CDN에 저장하여 빨리 읽어갈 수 있도록 함
  
  클라이언트가 뉴스 피드를 어떻게 읽는지

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

캐시 구조

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

4단계 마무리

다루면 좋을 추가 문제들

데이터베이스 규모 확장

• 수직적 규모 확장 VS 수평적 규모 확장
• SQL vs NoSQL
• 주/부 다중화
• 복제본에 대한 읽기 연산
• 일관성 모델
• 데이터베이스 샤딩

다른 논의 주제

• 웹 계층 무상태 운영
• 가능한 한 많은 데이터를 캐시할 방법
• 여러 데이터 센터를 지원할 방법
• 메시지 큐를 사용해 컴포넌트 결합도 낮추기
• 핵심 메트릭에 대한 모니터링