뉴스 피드 시스템 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초 "뉴스 피드 시스템 설계"을 요약한 내용입니다.

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

• 모바일 앱 및 웹 둘다 지원하는 시스템
• 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴수 있음
• 친구들이 올리는 스토리를 볼 수 있어야 함
• 시간 흐름 역순으로 표시됨
• 한 명의 사용자는 최대 5000명까지 친구를 가질 수 있음
• 매일 천만명이 방문
• 스토리에는 이미지나 비디오 등의 미디어 파일 포함 될 수 있음

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

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

뉴스 피드 API

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

피드 발행

개략적인 설계 [그림 11-2] 참고

• 사용자: 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체
• 로드밸런서: 트래픽을 웹 서버들로 분산
• 웹 서버: HTTP 요청을 내부 서비스로 중계하는 역활
• 포스팅 저장 서비스: 새 포스팅을 데이터베이스와 캐시에 저장
• 포스팅 전송 서비스: 새 포스팅을 친구의 뉴스 피드에 푸시, 캐시에 보고나하여 빠르게 읽어갈 수 있도록 한다
• 알림 서비스: 친구들에게 새 포스팅이 올라왔을을 알리는 역활

뉴스 피드 생성

개략적인 설계 [그림 11-3] 참고

• 사용자: 뉴스 피드를 읽는 주체
• 로드 밸런서: 트래픽을 웹서버들로 분산
• 웹 서버: 트래픽을 뉴스 피드 서비스로 보낸다
• 뉴스 피드 서비스: 캐시에서 뉴스 피드를 가져오는 서비스
• 뉴스 피드 캐시: 뉴스 피드를 랜더링할 때 필요한 피드 ID를 보관

3단계 상세 설계

피드 발행 흐름 상세 설계

• [그림 11-4]는 웹 서버와 포스싵 전송 서비스에 초점을 맞추었다
• 웹 서버
  • 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행
• 포스팅 전송 서비스
  • 팬아웃(fanout)은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
  • 팬아웃은 두가지 모델이 있음
    • 쓰기 시점에 팬아웃(Fanout On Write) - 푸시 모델이라고도 함
      • 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신
      • 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록
      장점
      • 뉴스 피드가 실시간으로 갱시되며 친구 목록에 있는 사용자에게 즉시 전송
      • 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는 데 드는 시간이 짧아진다.
      단점
      • 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 피드를 갱신하는데 많은 시간이 소요될 수 있음
        • 핫키 라고 부르는 문제
      • 서비스를 자주 이용하지 않는 사용자의 피드까지 갱싱해야 함으로 컴퓨팅 자원이 낭비 됨
    • 읽기 시점에 팬아웃(Fanout On Read) - 풀(Pull) 모델이라고 함
      • 피드를 읽어야 하는 시점에 뉴스 피드를 갱신
      • 요청 기반 모델
      • 사용자가 본인 홈페이지나 타임라인을 로딩하는 시점에 새로운 포스팅을 가져오게 된다.
      장점
      • 비활성화된 사용자, 서비스를 잘 사용하지 않는 사용자의 경우에 이 모델이 유리
      • 로그인하기 전까지는 어떤 컴퓨팅 자원도 소모되지 않음
      • 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않음
      단점
      • 뉴스 피드를 읽는데 많은 시간이 소요될 수 있음
• 뉴스 피드를 빠르게 가져오는 것은 아주 중요함으로 대부분의 사용자에 대해서는 푸시 모델을 사용
• 친구나 팔로어가 아주 많은 사용자의 경우 팔로어로 하여금 해당 사용자의 포스팅을 필요할 때 가져오도록 하는 풀 모델을 사용하여 시스템 과부하를 방지
• 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄여볼 것
• 팬아웃 서비스 동작 1.

피드 읽기 흐름 상세 설계

• [그림 11-7]는 뉴스 피드를 읽는 과정의 상세 설계안

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

캐시 구조

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

4단계 마무리

• 좀더 고민하면 좋을 주제

데이터베이스 규모 확장

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

그외

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