읽을때 마다 새로운 지식을 알게되는 책이지만, 다음 챕터로 넘어 갈수록 너무 어려워져서 손이가지 않는 책으로 최대한 많이 이해하고 완독을 목표로 정리를 하기위해서 글을 작성하게 되었다.
처음에는 2부 부터 읽다가 왜 1을 읽지 않느냐는 질문을 받고 1부를 읽게되었고 1부 부터 읽는게 필수라고 할정도로 난이도 차이가 있다.
잘근잘근 씹어먹듯, 많은 지식을 남길 수 있도록 열심히 정리해보자!
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24
뉴스피드란
사용자의 홈에 지속적으로 업데이트 되는 스토리를 의미. 사용자 상태 업데이트, 사진, 비디오 등의 정보를 포함하고 있습니다.
이해 및 설계
뉴스피드를 구현해 내기 위해 구성해야 하는 부분들은 다음과 같은데, 피드 발행과 뉴스피드 읽기 부분입니다.
뉴스피드 API
클라이언트가 서버와 통신하기 위해 쓰는 수단입니다. 우선 API 구조를 설계해 본다면 다음과 같습니다.
1) 피드 발행 API
POST /v1/feed
HEADER - 인증
BODY {
// 포스팅하는 내용 포함
}2) 피드 읽기 API
GET /v1/feed
HEADER - 인증기본 설계 구조
각각 API 가 호출되었을 때 실행되는 서비스의 구조를 설명합니다.
피드발생 시스템 구조
다음은 피드 발생 API를 통해 피드가 저장되고 각각 친구들에게 해당 피드가 전달되는 서비스 구조를 모식화한 모습입니다.
사용자가 피드를 생성하기위해 웹서버로 요청을 보내고, 피드의 포스팅 정보를 각각 캐시와 DB 에 저장, 피드 아이디를 각각 친구의 캐시에 저장한 후, 알람을 보내어 피드가 생성되었음을 알린는 구조로 구성되어있다.
뉴스피드 시스템 구조
이번 구조는 각각 구성 된 피드를 호출하는 구조를 모식화 한 모습입니다.
사용자 캐시에 저장되어있는 피드ID 정보를 호출하고 해당하는 포스팅 정보를 가져와 피드를 호출합니다.
확장 설계 구조
피드 발생시, 전송서비스 설계
세부적으로 확인해보면 전송서비스는 다음과 같은 구조로 설계할수 있습니다. 다른 부분은 책에서 확인하고, 중점적인 피드를 전송하는 서비스만 확인 해본다면 다음과 같이 표기할수 있습니다.
뉴스피드 서비스 설계
각각 전송 서비스에서 전달받은 피드아이디를 기반으로 사용자가 각 피드를 호출할 수 있는 구조를 나타냅니다. 캐시 서비스를 이용하여 효율적으로 정보를 관리합니다.
포스팅 전송 서비스 / 팬아웃 서비스 (Fan-out)
이벤트가 발생했을때, 해당 이벤트와 관련된 팔로워나 구독자 여러명에게 복제/전달하는 과정을 말한다. 확장설계의 전송서비스 부분에서 각각 친구에게 메세지를 보내는 항목과 동일하게 볼수 있다.
ex) 해당 뉴스 피드 서비스에서 누군가 피드를 만들면 각각 팔로우 한 사람의 타임라인에 피드를 확인할 수 있도록 전송하는것
1. 쓰기 시점에 팬아웃 (Write Time Fan-out / PUSH Model)
사용자가 게시물을 작성할때 모든 팔로워의 피드에 즉시 게시물을 복사하는 방식입니다.
장점: 읽기 성능이 중요한 뉴스피드 시스템에 적합함, 읽기 성능이 매우 빠르다는 장점이 있다.
단점: 저장 공간도 많이 사용하고, 비활성 사용자에게도 불필요하게 데이터를 복사한다는 단점이 존재한다.
2. 읽기 시점에 팬아웃 (Read Time Fan-out / PULL Model)
사용자가 피드를 요청할때, 팔로우하는 사람들의 게시물을 실시간으로 조회하여 합성하는 방식입니다.
장점: 쓰기 시점의 팬아웃의 단점에 대한 장점이라고 할수 있다. 효율적인 저장공간과 미사용자에 대해 불필요한 작업이 없게된다.
단점: 다만, 서버부하가 사용자가 읽을 때 많이 발생하고 팔로우수가 많은 사용자의 경우 피드 생성이 복잡해지는 단점이 존재한다.
실제 대규모 서비스에서는 두가지 방식을 모두 사용하여 하이브리드로 접근합니다. 팔로워 수가 많은 사용자와 일반사용자의 피드 생성을 효율적으로 조회 하는 형식입니다.
캐시 구조의 중요성
뉴스피드 시스템에서는 캐시구조가 엄청 중요하다. 특성상 데이터의 읽기가 빈번하게 진행되고, 빠른 조회시간을 요구하기 때문이다. 각각 설계구조에 캐시 서비스를 구성한것도 다음과 같은 이유입니다.
