11장

뉴스피드를 설계해보자

• 뉴스 피드 시스템 설계는 아주 유명한 면접 문제이다

• 페이스북 뉴스 피드 설계, 인스타그램 피드 설계, 트위터 타임라인 설계 등이 예시다.

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

• 앱과 웹을 모두 지원해야 한다

• 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야 하고, 친구들이 올리는 스토리를 볼 수 있어야 한다.

• 뉴스 피드는 단순히 시간 흐름 역순으로 표시된다.

• 한 명의 사용자는 최대 5000명의 친구를 갖는다

• 매일 천만 명이 방문한다.

• 스토리에는 이미지, 비디오 등의 미디어 파일이 포함될 수 있다

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

1. 피드 발행

   1. 사용자가 스토리를 포스팅하면 해당 데이트럴 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송된다.

2. 뉴스 피드 생성

   1. 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다

• 뉴스 피드 API

  • 피드 발행 API

    • POST /v1/me/feed

  • 피드 읽기 API

    • GET /v1/me/feed

Untitled

• 피드 발행 시스템의 개략적 형태는 위와 같다

  • 사용자: 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체다. POST /v1/me/feed API를 사용한다

  • 로드밸런서: 트래픽을 웹 서버들로 분산한다

  • 웹 서버: HTTP 요청을 내부 서비스로 중계하는 역할을 담당한다

  • 포스팅 저장 서비스: 새 포스팅을 데이터베이스와 캐시에 저장한다

  • 포스팅 전송 서비스: 새 포스팅을 친구의 뉴스 피드에 푸시한다.

  • 알림 서비스: 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할을 한다.

• 뉴스 피드 생성

  • 사용자: 뉴스 피드를 읽는 주체다. GET /v1/me/feed API를 이용한다

  • 로드 밸런서: 트래픽을 웹 서버들로 분산한다

  • 웹 서버: 트래픽을 뉴스 피드 서비스로 보낸다

  • 뉴스 피드 서비스: 캐시에서 뉴스 피드를 가져오는 서비스다

  • 뉴스 피드 캐시: 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관한다.

3단계 상세 설계

Untitled

• 웹 서버

• 팬 아웃 서비스

  • 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정이다

  • 쓰기 시점에 팬아웃하는 모델

    • 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신한다.

    • 장점

      • 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송된다.

      • 뉴스 피드가 이미 갱신되므로 (pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아진다.

    • 단점

      • 친구가 많은 사용자의 경우 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있다.

      • 서비스를 자주 사용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원이 낭비된다.

  • 읽기 시점에 팬아웃하는 모델

    • 사용자가 타임라인을 로딩하는 시점에 새로운 포스트를 가져오게 된다.

    • 장점

      • 비활성화된 사용자, 거의 로그인하지 않는 사용자에게 컴퓨팅 자원을 소모하지 않는다.

      • 데이터를 모든 친구에게 각각 푸시하지 않으므로 핫키 문제도 생기지 않는다.

    • 단점

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

결국은 뭘 쓰나? 두 개 결합

• 대부분의 사용자에 대해서는 푸시 모델을 사용한다

• 친구나 팔로워 수가 아주 많은 사용자의 경우에는 팔로어로 하여금 필요할 때 가져가도록 하는 풀 모델을 사용하여 과부하를 방지한다.

팬 아웃 서비스 동작 순서

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

2. 사용자 정보 캐시에서 친구들의 정보를 가져온다. 그리고 일부를 필터링한다.

   1. 예를 들면, 친구 중 누군가의 업데이트를 무시하기로 결정했다면 그 친구의 스토리는 피드에 보이지 않아야 한다.

3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다

4. 팬 아웃 작업 서버가 메시지 큐에서 데이터를 꺼내서 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다.

   1. 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID>의 순서쌍을 보관하는 매핑 테이블

   2. 사용자 정보와 포스팅 정보 전부를 저장하면 메모리 요구량이 너무 늘어난다. ID만 저장하도록 한다.

   3. 어떤 사용자가 뉴스 피드에 올라온 수천 개의 스토리를 전부 훑어보는 일은 드물다. 캐시 크기에 적절한 제한을 둔다.

피드 읽기 흐름 상세 설계

Untitled

1. 사용자가 뉴스 피드를 읽으려는 요청을 보낸다. 요청은 /v1/me/feed로 전송된다

2. 로드 밸런서가 요청을 웹 서버 가운데 하나로 보낸다.

3. 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출한다

4. 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다

5. 뉴스 피드에 표시할 사용자 이름, 사용자 사진, 포스텡 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다

6. 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보낸다. 클라이언트는 해당 피드를 렌더링한다.

4 단계 마무리

• 다룰만한 주제들

  • 데이터베이스 규모 확장

    • 수직적 규모 확장 vs 수평적 규모 확장

    • SQL vs NOSQL

    • master slave 다중화

    • 복제본에 대한 읽기 연산

    • 일관성 모델

    • 데이터베이스 샤딩

  • 그 외

    • 웹 계층을 무상태로 운영하기

    • 가능한 한 많은 데이터를 캐시할 방법

    • 여러 데이터 센터를 지원할 방법

    • 메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기

    • 핵심 메트릭에 대한 모니터링