11장 뉴스 피드 시스템 설계(24-10-22)

문제 이해 및 설계 범위 확정

• 모바일 앱, 웹 둘다 지원해야 함

• 중요 기능
• 사용자가 뉴스 피드에 새로운 스토리 올릴 수 있어야 함
• 친구들이 올리는 스토리를 볼 수 있어야 함

• 뉴스 피드의 스토리 순서 : 단순 시간 흐름 역순

• 한 명의 사용자의 최대 친구 수 : 5000명

• 트래픽 규모 : 매일 천만 명(10million DAU)

• 피드에 이미지나 비디오 스토리도 존재가능함

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

• 피드 발행 : 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록. 새 포스팅은 친구의 뉴스 피드에도 전송됨
• POST /v1/me/feed
• 인자
• 바디(body): 포스트 내용
• Authorization 헤더 : api 호출을 인증하기 위해 사용

• 뉴스 피드 생성 : 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정
• GET /v1/me/feed
• 인자
• Authorization 헤더 : API 호출을 인증하기 위해 사용

피드 발행

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

• 포스팅 저장 서비스(post service) : 새 포스팅을 데이터베이스와 캐시에 저장

• 포스팅 전송 서비스(fanout service) : 새 포스팅을 친구의 뉴스 피드에 푸시한다. 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 함

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

뉴스 피드 생성

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

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

상세 설계

피드 발행 흐름 상세 설계

• 웹 서버 : 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행한다. 올바른 인증 토큰을 Authorization 헤더에 넣고 api를 호출하는 사용자만 포스팅을 할 수 있어야 함 스팸을 막고 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해서 특정 기간 동안 한 사용자가 올릴 수 있는 포스팅의 수에 제한을 두어야 함

• 포스팅 전송(팬아웃) 서비스
팬아웃(fanout)은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
팬 아웃에는 두 가지 모델이 있음
• 쓰기 시점에 팬아웃(fanout-on-write)하는 모델(push 모델이라고도 함)
• 읽기 시점에 팬아웃(fanout-on-read)하는 모델 (pull 모델이라고도 함)

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

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

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

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

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

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

• 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 이 모델이 유리. 어떤 컴퓨팅 자원도 소모하지 않기 때문에

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

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

팬아웃 서비스 동작흐름

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

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

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

4. 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스 피드 데이터를 뉴스 피드 캐시에 넣는다. 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID>의 순서쌍을 보관하는 매핑 테이블임
사용자 정보와 포스팅 정보 전부를 이 테이블에 저장하지 않는 이유는 그렇게 하면 메모리 요구량이 지나치게 늘어날 수 있기 때문.
대부분의 사용자가 보려 하는 것은 최신 스토리기에 캐시 미스가 일어날 확률은 낮음

피드 읽기 흐름 상세 설계

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

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

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

4. 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 id 목록을 가져옴

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

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

캐시 구조

• 뉴스 피드 : 뉴스 피드의 ID를 보관한다

• 콘텐츠 : 포스팅 데이터를 보관함. 인기 컨텐츠는 따로 보관

• 소셜 그래프 : 사용자 간 관계 정보를 보관

• 행동(action) : 포스팅에 대한 사용자의 행위에 관한 정보를 보관. 포스팅에 대한 ‘좋아요’, 답글 등등이 여기에 해당

• 횟수(counter): ‘좋아요’ 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보를 보관