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

뉴스 피드

홈 페이지 중앙에 지속적으로 업데이트 되는 정보들로, 사용자 상태 업데이트, 사진, 비디오, 팔로우하는 사람들과 페이지, 속한 그룹으로 부터 나오는 좋아요를 포함한다.

 

 

뉴스 피드는 피드 발행과 뉴스 피드 생성 두 가지 부분으로 나뉜다.

 

개략적 설계

피드 발행

• 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다.
• 새 포스팅은 친구의 뉴스피드에도 전송된다.
• HTTP 프로토콜 기반
• POST /v1/me/feed
• Authorization 헤더와 포스팅 내용을 담은 Body 를 사용한다.

• 유저 : 모바일 앱이나 웹에서 새 포스팅을 올리는 주체
• 로드 밸런서: 트래픽을 웹 서버들로 분산
• 웹 서버: HTTP 요청을 내부 서비스로 중계하는 역할 담당
• 포스팅 저장 서비스: 새 포스팅을 디비와 캐시에 저장
• 포스팅 전송 서비스: 새 포스팅을 친구의 뉴스 피드에 푸시. 뉴스 피드 데이터는 캐시에 보관해 빠르게 읽어갈 수 있도록 함
• 알림 서비스: 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할

 

뉴스 피드 생성

뉴스 피드는 모든 친구의 포스팅을 시간 흐름의 역순으로 모아서 만들어진다.

HTTP 프로토콜 기반

GET /v1/me/feed

Authorization 헤더를 사용

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

 

피드 발행 흐름 상세 설계

웹 서버와 포스팅 전송 서비스에 초점을 맞추어 설계 진행

 

웹 서버

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

• 올바른 인증 토큰을 Authorization 헤더에 넣고 호출하는 사용자만 포스팅을 할 수 있어야 한다.
• 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해서 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅의 수에 제한을 두어야 한다.

 

포스팅 전송(Fanout) 서비스

팬아웃(Fanout): 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정

 

쓰기 시점에 포스팅을 전송하는 모델(Push 모델)

새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신한다. 즉, 포스팅이 완료되면 해당 사용자의 캐시에 해당 포스팅을 기록

 

장점

• 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송된다.
• 새 포스팅이 기록되는 순간 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는데 드는 시간이 짧아진다.

 

단점

• 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는데 많은 시간 소요 (Hotkey 문제 발생)
• 서비스를 자주 사용하지 않는 사용자의 피드까지 갱신해야 하므로 자원이 낭비됨

 

읽기 시점에 포스팅을 전송하는 모델(Pull 모델)

피드를 읽어야 하는 시점에 뉴스 피드를 갱신한다. 즉, 사용자가 본인 홈페이지나 타임 라인을 로딩하는 시점에 새로운 포스트를 가져오게 된다. -> 요청 기반(on-demand) 모델

 

장점

• 비활성화된 사용자나 거의 로그인 하지 않는 사용자의 경우 자원을 소모하지 않으므로 이 모델이 유리함
• 데이터를 친구 각각에 푸시하지 않으므로 핫키 문제도 발생하지 않음

 

단점

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

 

이번 설계에서는 이 두 가지 방법을 결합해 장점을 취하고 단점은 버리는 전략을 수행한다.

즉, 대부분의 사용자에게 푸시 모델을 사용하고, 친구나 팔로어가 많은 사용자의 경우 팔로어로 하여금 풀 모델을 사용하게 한다. 또한 안정 해시를 사용해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄일 수 있다.

팬아웃 서비스에 관한 부분만 떼어온 그림

1. 그래프 DB에서 친구 ID 목록을 가져온다.

2. 사용자 정보 캐시에서 친구들의 정보를 가져온다.

    이후 사용자 설정에 따라 친구 가운데 일부를 걸러낸다.

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

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

    뉴스 피드 캐시 : [포스팅 ID, 사용자 ID] 의 순서쌍을 보관하는 매핑 테이블

 

 

피드 읽기 흐름 상세 설계

1. 사용자가 뉴스 피드를 읽기 위한 요청을 보낸다.

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

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

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

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

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

 

캐시 구조

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

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

 

추후 논의해볼만한 내용

• DB 규모 확장
• 웹 계층 무상태로 운영
• 최대한 많은 데이터를 캐시할 방법
• 메세지 큐를 사용해 컴포넌트 사이의 결합도 낮추기
• 핵심 메트릭에 대한 모니터링