[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 11장 뉴스 피드 시스템 설계

뉴스 피드

• 홈페이지 중앙에 지속적으로 업데이트되는 스토리들
• 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동 등등

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

• 모바일 앱을 위한 시스템인지, 웹을 위한 시스템인지
  • 둘 다 지원해야 함
• 중요한 기능으론 어떤 것이 있는지
  • 사용자는 뉴스 피드에 새로운 스토리를 올릴 수 있어야 함
  • 친구들이 올리는 스토리를 볼 수도 있어야 함
• 뉴스 피드에는 어떤 순서로 스토리가 표시되어야 하는지?
  • 단순히 시간 흐름 역순으로 표시된다고 가정
• 한 명의 사용자는 최대 몇 명의 친구를 가질 수 있는지?
  • 예시 : 5000명
• 트래픽 규모?
  • 매일 천만 명이 방문한다고 가정
• 피드에 이미지나 비디오 스토리도 올라올 수 있는지?
  • 스토리에는 이미지나 비디오 등의 미디어 파일 포함 가능

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

• 설계안은 피드 발행과 뉴스 피드 생성 두 가지 부분
  • 피드 발행 : 사용자가 스토리를 포스팅하면 캐시와 DB에 기록, 친구의 뉴스 피드에도 전송
  • 뉴스 피드 생성 : 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정

뉴스 피드 API

• 클라이언트가 서버와 통신하기 위해 사용하는 수단
• HTTP 프로토콜 기반
• 상태 정보를 업데이트, 뉴스 피드를 가져오기, 친구 추가 등의 다양한 작업 수행
• 피드 발행 API
  • HTTP POST 형태
  • POST /v1/me/feed
  • 인자 : 바디 (포스팅 내용), Authorization 헤더 (API 호출을 인증하기 위해 사용)
• 뉴스 읽기 API
  • 뉴스 피드를 가져오는 API
  • GET /v1/me/feed
  • 인자 : Authorization 헤더 (API 호출을 인증하기 위해 사용)

피드 발행

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

뉴스 피드 생성

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

3단계 : 상세 설계

피드 발행 흐름 설계

• 웹 서버
  • 클라이언트와 통신할 뿐 아니라 인증, 처리율 제한 등의 기능도 수행
  • 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅
  • 스팸과 유해한 콘텐츠를 막음
  • 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅의 수에 제한
• 포스팅 전송(팬아웃) 서비스
  • 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
• 두 가지 모델
  • 쓰기 시점에 팬아웃하는 모델
  • 읽는 시점에 팬아웃 하는 모델
• 쓰기 시점에 팬아웃하는 모델
  • 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신
  • 포스팅 완료 시 해당 사용자의 캐시에 해당 포스팅을 기록
  • 뉴스 피드가 실시간 갱신, 친구 목록 사용자에게 즉시 전송되는 장점
  • 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는 데 드는 시간이 짧아지는 장점
  • 친구가 많은 경우 사용자 모두의 뉴스 피드를 갱신하는데 많인 시간이 소요될 수 있는 단점 (핫키)
  • 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원 낭비
• 읽기 시점에 팬아웃하는 모델
  • 피드를 읽어야 하는 시점에 뉴스 피드릴 갱신 (요청 기반 모델)
  • 비활성화된 사용자나 서비스에 거의 로그인하지 않는 사용자의 경우엔 이 모델이 유리 (장점)
  • 핫키 문제도 생기지 않는 장점
  • 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있는 단점
• 이 두 가지 방법을 결합하여 장점은 취하고 단점은 버리는 전략
  • 대부분의 사용자에 대해서는 푸시 모델 사용
  • 친구나 팔로어가 아주 많은 사용자의 경우엔 팔로어로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델을 사용 (시스템 과부하 방지)
  • 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제 감소
• 팬아웃 서비스
  • 그래프 데이터베이스에서 친구 ID 목록을 가져옴
  • 사용자 정보 캐시에서 친구들의 정보를 가져오고 사용자 설정에 따라 일부 친구를 걸러냄
  • 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣음
  • 팬아웃 작업 서버가 피드 데이터를 뉴스 피드 캐시에 넣음
  • 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID>의 순서쌍을 보관하는 매핑 테이블
  • 캐시는 크기에 제한을 두며 해당 값은 조정이 가능하도록 함
  • 사용자는 보통 최신 스토리만 보기 때문에 캐시 미스가 일어날 확률을 낮음

피드 읽기 흐름 상세 설계

• 사용자가 뉴스 피드를 읽으려는 요청을 보냄
• 로드밸런서가 요청을 웹 서버 가운데 하나로 보냄
• 웹 서버는 뉴스 피드 서비스를 호출
• 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져옴
• 사용자 캐시와 포스팅 캐시를 통해 완전한 뉴스 피드를 만듦
• 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보냄

캐시 구조

• 캐시는 뉴스 피드 시스템의 핵심 컴포넌트
• 뉴스 피드
  • 뉴스 피드의 ID를 보관
• 콘텐츠
  • 포스팅 데이터를 보관
  • 인기 콘텐츠는 따로 보관
• 소셜 그래프
  • 사용자 간 관계 정보를 보관
• 행동
  • 포스팅에 대한 사용자의 행위에 관한 정보를 보관
  • 포스팅에 대한 좋아요나 답글 등등이 이에 해당
• 횟수
  • 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보를 보관

4단계 : 마무리

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