11. 뉴스 피드 시스템 설계

문제 이해 및 설계 범위 확정

• 뉴스 피드 시스템을 설계하라고 했을 때 면접관의 의도는 무엇이었는지 질문을 통해 알아내는 것이 첫번째

• 최소한 어떤 기능을 지원해야 하는 지는 반드시 파악해야 한다.

요구사항

• 모바일 및 웹 지원

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

• 단순하게 시간 흐름 역순으로 표시된다고 가정.

• 사용자 당 최대 5,000명의 친구를 가질 수 있음.

• DAU 1000만

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

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

뉴스 피드 API

• 클라이언트가 서버와 통신하기 위해 사용하는 수단, HTTP 프로토콜 기반

• 상태경로 업데이트, 뉴스 피드 업데이트, 친구 추가 등 다양한 작업에 사용

피드 발생 API

• 새 스토리를 포스팅하기 위한 API

• Method: POST

• URL Path: /v1/me/feed

• Params

  • Body: 포스팅 내용

  • Authorization Header: API 호출 인증

피드 읽기 API

• 뉴스 피드를 가져오는 API

• Method: GET

• URL Path: /v1/me/feed

• Params

  • Authorization Header: API 호출 인증

피드 발행(초안)

• 사용자

  • 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체

  • POST /v1/me/feed API 사용

• 로드벨런서

  • 트래픽을 여러 대의 웹 서버로 분산

• 웹 서버

  • HTTP 요청을 내부 서비스로 중계하는 역할

• 포스팅 저장 서비스(Post Service)

  • 새 포스팅을 데이터베이스와 캐시에 저장

• 포스팅 전송 서비스(Fanout Service)

  • 새 포스팅을 친구의 뉴스 피드에 푸시

  • 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.

• 알림 서비스(Notification Service)

  • 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할을 담당

뉴스 피드 생성(초안)

• 사용자

  • 뉴스 피드를 읽는 주체

  • GET /v1/me/feed API 사용

• 로드벨런서

  • 트래픽을 여러 대의 웹 서버로 분산

• 웹 서버

  • 트래픽을 뉴스 피드 서비스로 보냄

• 뉴스 피드 서비스(News feed Service)

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

• 뉴스 피드 캐시(News feed Cache)

  • 뉴스 피드를 랜더링할 때 필요한 피드 ID를 보관

상세 설계

피드 발행 흐름 상세 설계

웹 서버

• 클라이언트와 통신할 뿐만 아니라 인증이나 처리율 제한 등의 기능도 수행

• 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 할 수 있어야 한다.

• 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해서 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅의 수에 제한을 두어야 한다.

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

• 팬아웃

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

  • 쓰기 시점에 팬아웃(Fanout-on-write, Push Model), 읽기 시점에 팬아웃(Fanout-on-read, Pull Model) 두가지가 있음.

• 쓰기 시점에 팬아웃(Fanout-on-write, Push Model)

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

  • 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록

  • 장점

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

    • 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는 시간이 짧아진다.

  • 단점

    • 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있다. -> 핫키(hotkey) 문제

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

• 읽기 시점에 팬아웃(Fanout-on-read, Pull Model)

  • 피드를 읽어야 하는 시점에 뉴스 피드 갱신

  • 요청 기반(on-demend) 모델

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

  • 장점

    • 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 이 모델이 유리함. 활성 사용자만 관리하면 된다.

    • 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제도 생기지 않는다.

  • 단점

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

팬아웃 서비스 개선안

• 뉴스 피드를 빠르게 가져올 수 있도록 하는 것은 중요하기 떄문에 대부분의 사용자에 대해선 푸시 모델 사용

• 친구나 팔로어가 많은 사용자의 경우에는 팔로어로 하여금 해당 사용자의 포스팅을 필요할 때 가져가는 풀 모델을 채택하여 시스템 과부화 방지

• 안정 해시(Consistent Hashing)을 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄임

팬아웃 서비스 개선 동작 방식

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

2. 사용자 정보 캐시에서 친구들의 정보를 가져온다. 이후 사용자 설정에 따라 친구 가운데 일부를 걸러낸다.

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

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

피드 읽기 흐름 상세 설계

1. 사용자가 뉴스 피드를 읽으려는 요청을 보낸다.

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

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

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

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

6. 생성된 뉴스 피드를 JSON 형태로 클라이언트로 보낸다.

7. 클라이언트는 해당 피드를 랜더링한다.

캐시 구조

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

• 뉴스 피드

  • 뉴스 피드 ID 보관

• 콘텐츠

  • 포스팅 데이터를 보관한다.

  • 인기 콘텐츠는 따로 보관한다.

• 소셜 그래프

  • 사용자 간 관계 정보를 보관한다.

• 행동(Action)

  • 포스팅에 대한 사용자의 행위에 관한 정보를 보관한다.

  • 포스팅에 대한 좋아요, 답글 등이 이에 해당된다.

• 횟수(Counter)

  • 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보를 보관

마무리

추가 고려 해볼 것들

• 데이터베이스 규모 확장

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

  • SQL vs NoSQL

  • 주-부(primary-secondary) 다중화

  • 복제본(replica)에 대한 읽기 연산

  • 일관성 모델(Consistency model)

  • 데이터베이스 사딩(Sharding)

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

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

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

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

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

  • 트래픽이 몰리는 시간대의 QPS(Query Per Second)

  • 사용자가 뉴스 피드를 새로고침 할 떄의 지연시간

Reference

캐시 문제 해결 가이드 - DB 과부하 방지 실전 팁Toss_service

캐시 성능 향상기 (Improving Cache Speed at Scale) : NHN Cloud MeetupNHN Cloud Meetup