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

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

• 요구사항
  • 뉴스 피드 페이지에 새로운 스토리 업로드 / 다른 사람이 올리는 스토리 조회
  • 1명의 사용자는 최대 5000명의 친구
  • 스토리에는 미디어 파일 포함 가능

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

1) 피드 발행

• 스토리를 포스팅하면 해당 데이터를 캐시와 DB에 기록
  - 피드 발행 API: 새 스토리 포스팅
  
  • 포스팅 저장 서비스 : 새 포스팅을 DB와 캐시에 저장
  • 포스팅 전송 서비스 : 새 포스팅을 친구 뉴스 피드에 푸시
    • 포스팅 전송(팬아웃) : 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
      1. 쓰기 시점에 팬아웃 (푸시 모델) : 새로운 포스팅 기록 시 뉴스 피드 갱신
         [장점]
         - 뉴스 피드 실시간 갱신, 친구 목록 사용자에게 즉시 전송
         - 새 포스팅 기록되는 순간 뉴스 피드 갱신되므로, 뉴스 피드를 읽는데 드는 시간 감소
         [단점]
         - 핫키 문제 발생
         - 서비스 자주 이용하지 않는 사용자 피드까지 갱신 필요 -> 자원 낭비
         
         
      2. 읽기 시점에 팬아웃 (풀 모델) : 피드 읽는 시점에 뉴스 피드 갱신 (요청 기반 모델)
         [장점]
         - 비활성화된 사용자, 로그인 잘 안하는 사람들에게 유리 (자원 소모X)
         - 핫키 문제 발생X
         [단점]
         - 뉴스 피드 읽는데 많은 시간 소요
  • 알림 서비스 : 새 포스팅이 올라왔음을 알리거나, 푸시 알림 전송

2) 뉴스 피드 생성

• 모든 친구의 포스팅을 시간 흐름 역순으로 모아 보여줌
  - 뉴스 피드 API: 상태 정보 업뎃, 뉴스 피드 가져오기, 친구 추가
  
  • 뉴스 피드 서비스 : 캐시에서 뉴스 피드 가져오기
  • 뉴스 피드 캐시 : 뉴스 피드 렌더링 시 필요한 피드 ID 보관

3단계 : 상세 설계

• 팬아웃 서비스의 동작 원리

1. 그래프 DB에서 친구 ID 목록 가져옴
2. 사용자 정보 캐시에서 친구들 정보 가져옴
3. 친구 목록과 새 스토리 포스팅ID를 메시지 큐에 넣음
4. 팬아웃 작업 서버 (포스팅 전송 작업 서버) 가 메시지 큐에서 데이터 꺼내 뉴스 피드 캐시에 뉴스 피드 데이터를 넣음
   • 뉴스 피드 캐시 : <포스팅 ID, 사용자 ID>

캐시 : 뉴스 피드의 핵심 컴포넌트

1. 뉴스 피드 : 뉴스피드의 ID 보관
2. 콘텐츠 : 포스팅 데이터를 보관하고 인기 콘텐츠는 따로 보관
3. 소셜 그래프 : 사용자 간 관계 정보를 보관 (팔로워, 팔로잉)
4. 행동 : ‘좋아요’나 댓글 같은 사용자 행위에 관한 정보 보관
5. 횟수 : ‘좋아요’ 횟수, 응답 수, 팔로워 수, 팔로잉 수 등의 정보 보관

논의하면 좋을 만한 주제

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

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