뉴스피드 시스템 설계
09 Feb 2022 | System Design
뉴스 피드 시스템 설계
- 뉴스 피드 (news feed) : sns에서 개인 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들
- 시스템 디자인 면접 문제로 아주 많이 나옴
1. 문제 이해 및 설계 범위 확정
문제 이해 방법
- 면접관의 의도 파악을 위해 질문을 해야 함
- 최소한 어떤 기능을 지원해야 할지 반드시 파악이 필요
설계 범위 확정
- 모바일과 웹 둘 다 지원 필요
- 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야 함 (피드 발행)
- 친구들이 올리는 스토리를 볼 수 있어야 함 (뉴스 피드 생성, 피드 읽기)
- 뉴스 피드 순서는 시간 흐름 역순 (토픽 점수, 가까운 친구의 포스트를 좀 더 위 와 같은 방식도 가능하나, 설계의 단순화를 위해 시간 역순 산정)
- 한 명의 사용자는 최대 5000명의 친구 맺기 가능
- 스토리에는 이미지나 비디오 등의 미디어 파일 포함 가능
2. 개략적 설계안 제시 및 동의 구하기
- (1) 피드 발행 (feed publishing)과 (2) 뉴스 피드 생성 (news feed building)으로 개략적 설계 진행
뉴스 피드 API
- 뉴스 피드 API는 클라이언트가 서버와 통신하기 위해 사용하는 수단
- HTTP 프로토콜 기반
- 상태 정보 업데이트, 뉴스 피드 가져오기, 친구 추가 등의 작업 수행
피드 발행 API
- 새 스토리를 포스팅하기 위한 API
- HTTP POST 형태로 요청을 보냄
POST /v1/me/feed- parameter:
- body : 포스팅 내용
- Authorization 헤더 : API 호출을 인증하기 위해 사용
피드 읽기 API
- 뉴스 피드를 가져오는 API
GET /v1/me/feed- parameter
- Authorization 헤더 : API 호출을 인증하기 위해 사용
피드 발행 시스템
- 그림 11-2 참고
- 사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체,
POST /v1/me/feed API를 사용
- 로드밸런서 (load balancer) : 트래픽을 웹 서버들로 분산
- 웹 서버 : HTTP 요청을 내부 서비스로 중계하는 역할
- 포스팅 저장 서비스 (post service) : 새 포스팅을 데이터베이스와 캐시에 저장
- 포스팅 전송 서비스 (fanout service) : 새 포스팅을 친구의 뉴스피드에 push한다. 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.
- 알림 서비스 (notification service) : 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할
뉴스 피드 생성 시스템
- 그림 11-3 참고
- 사용자 : 뉴스 피드를 읽는 주체,
GET /v1/me/feed API를 이용
- 로드 밸런서 : 트래픽을 웹 서버들로 분산
- 뉴스 피드 서비스 (news feed service) : 캐시에서 뉴스 피드를 가져오는 서비스
- 뉴스 피드 캐시 (news feed cache) : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관
3. 상세 설계
피드 발행 흐름 및 상세 설계
- 그림 11-4는 피드 발행 흐름의 상세 설계안
- 웹 서버와 포스팅 전송 서비스 (fanout service)에 초점
- 나머지는 개략적 설계안 정도로 충분
웹 서버
- 클라이언트와 통신
- 인증 기능 : 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 가능
- 처리율 제한 (rate limiter) : 스팸 차단, 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위한 처리율 제한기 필요
포스팅 전송(팬아웃) 서비스
- 팬아웃(fanout) : 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
- 쓰기 시점에 팬아웃 (fanout-on-write or push model)과 읽기 시점에 팬아웃 (fanout-on-read or pull model) 이 있음
fanout-on-write (push) model
- 새로운 포스팅을 기록하는 시점에 뉴스 피드 갱신. 즉, 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록
- 장점
- 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
- 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 (pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아짐
- 단점
- 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있음 (hotkey 문제)
- 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원이 낭비됨
fanout-on-read (pull) model
- 피드를 읽어야 하는 시점에 뉴스 피드를 갱신, 요청 기반 (on-demand) 모델. 사용자가 본인 홈페이지나 타임라인은 로딩하는 시점에 새로운 포스트를 가져오게 됨
- 장점
- 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 이 모델이 유리함. 로그인 전까지는 어떤 컴퓨팅 자원도 소모하지 않아서임
- 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 hotkey 문제도 생기지 않음
- 단점
- 뉴스 피드를 읽는데 많은 시간이 소요될 수 있음
타협안
- 뉴스 피드를 빠르게 가져오는 것은 아주 중요하므로, 대부분의 사용자는 푸시 모델을 사용함
- 친구나 팔로워가 아주 많은 사용자의 경우에는 팔로워로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 풀 모델 사용
- 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제 완화
타협안의 flow
- 그림 11-5 참고
- 그래프 DB에서 친구 ID 목록을 가져옴
- 사용자 정보 캐시에서 친구들의 정보를 가져옴. 사용자 설정에 따라 친구 가운데 일부를 걸러냄 (일부 친구 feed mute 기능 지원 or 스토리를 일부 사용자에게만 공개하는 기능)
- 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
- 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스피드 데이터를 뉴스 피드 캐시에 넣는다. (그림 11-6 참고) - 사용자는 대부분 최신 스토리를 보기 때문에, 캐시의 크기를 한정하여도 캐시 미스가 많이 나지 않는다.
피드 읽기 흐름 상세 설계
- 그림 11-7 참고
설계안 flow
- 사용자가 뉴스 피드를 읽으려는 요청을 보냄 요청은
GET /v1/me/feed
- 로드밸런서가 요청을 웹 서버 가운데 하나로 보낸다.
- 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출
- 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져옴
- 뉴스 피드에서 표시할 사용자 이름, 사용자 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만듦
- 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보내고, 클라이언트는 해당 피드를 렌더링 함
캐시 구조
- 캐시는 뉴스 피드 시스템의 핵심 컴포넌트, 5 계층으로 나눈다.
- 그림 11-8 참고
- 뉴스 피드 : 뉴스 피드의 ID를 보관
- 콘텐츠 : 포스팅 데이터를 보관, 인기 콘텐츠는 따로 보관
- 소셜 그래프 : 사용자 간 관계 정보를 보관
- 행동 (action) : 포스팅에 대한 사용자의 행위에 관한 정보를 보관. (좋아요, 답글 등등)
- 횟수 (counter) : 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보 보관
4. 마무리
- 시스템 설계 면접은 정답이 없으므로, trade-off가 있는지 잘 이해하고 설명할 수 있어야 함
- 설계를 마친 후에도 시간이 남으면, 규모 확장성 이슈를 논의하는 것도 좋음
규모 확장성 이슈
- 데이터베이스 규모 확장
- 수직적 규모 확장 vs 수평적 규모 확장
- SQL vs NoSQL
- master-slave 다중화
- replica 읽기 연산
- 일관성 모델
- 데이터베이스 sharding
- 추가 논의 주제
- 웹 계층을 stateless로 운영하기
- 가능한 한 많은 데이터를 캐시할 방법
- 여러 데이터 센터를 지원할 방법
- 메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
- 핵심 메트릭 (key metric)에 대한 모니터링 (peak QPS, refresh시 지연시간 등)
참고자료
- 알렉스 쉬, 가상 면접 사례로 배우는 대규모 시스템 설계 기초 11장
뉴스 피드 시스템 설계
- 뉴스 피드 (news feed) : sns에서 개인 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들
- 시스템 디자인 면접 문제로 아주 많이 나옴
1. 문제 이해 및 설계 범위 확정
문제 이해 방법
- 면접관의 의도 파악을 위해 질문을 해야 함
- 최소한 어떤 기능을 지원해야 할지 반드시 파악이 필요
설계 범위 확정
- 모바일과 웹 둘 다 지원 필요
- 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야 함 (피드 발행)
- 친구들이 올리는 스토리를 볼 수 있어야 함 (뉴스 피드 생성, 피드 읽기)
- 뉴스 피드 순서는 시간 흐름 역순 (토픽 점수, 가까운 친구의 포스트를 좀 더 위 와 같은 방식도 가능하나, 설계의 단순화를 위해 시간 역순 산정)
- 한 명의 사용자는 최대 5000명의 친구 맺기 가능
- 스토리에는 이미지나 비디오 등의 미디어 파일 포함 가능
2. 개략적 설계안 제시 및 동의 구하기
- (1) 피드 발행 (feed publishing)과 (2) 뉴스 피드 생성 (news feed building)으로 개략적 설계 진행
뉴스 피드 API
- 뉴스 피드 API는 클라이언트가 서버와 통신하기 위해 사용하는 수단
- HTTP 프로토콜 기반
- 상태 정보 업데이트, 뉴스 피드 가져오기, 친구 추가 등의 작업 수행
피드 발행 API
- 새 스토리를 포스팅하기 위한 API
- HTTP POST 형태로 요청을 보냄
POST /v1/me/feed- parameter:
- body : 포스팅 내용
- Authorization 헤더 : API 호출을 인증하기 위해 사용
피드 읽기 API
- 뉴스 피드를 가져오는 API
GET /v1/me/feed- parameter
- Authorization 헤더 : API 호출을 인증하기 위해 사용
피드 발행 시스템
- 그림 11-2 참고
- 사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체,
POST /v1/me/feedAPI를 사용 - 로드밸런서 (load balancer) : 트래픽을 웹 서버들로 분산
- 웹 서버 : HTTP 요청을 내부 서비스로 중계하는 역할
- 포스팅 저장 서비스 (post service) : 새 포스팅을 데이터베이스와 캐시에 저장
- 포스팅 전송 서비스 (fanout service) : 새 포스팅을 친구의 뉴스피드에 push한다. 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.
- 알림 서비스 (notification service) : 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할
뉴스 피드 생성 시스템
- 그림 11-3 참고
- 사용자 : 뉴스 피드를 읽는 주체,
GET /v1/me/feedAPI를 이용 - 로드 밸런서 : 트래픽을 웹 서버들로 분산
- 뉴스 피드 서비스 (news feed service) : 캐시에서 뉴스 피드를 가져오는 서비스
- 뉴스 피드 캐시 (news feed cache) : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관
3. 상세 설계
피드 발행 흐름 및 상세 설계
- 그림 11-4는 피드 발행 흐름의 상세 설계안
- 웹 서버와 포스팅 전송 서비스 (fanout service)에 초점
- 나머지는 개략적 설계안 정도로 충분
웹 서버
- 클라이언트와 통신
- 인증 기능 : 올바른 인증 토큰을 Authorization 헤더에 넣고 API를 호출하는 사용자만 포스팅 가능
- 처리율 제한 (rate limiter) : 스팸 차단, 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위한 처리율 제한기 필요
포스팅 전송(팬아웃) 서비스
- 팬아웃(fanout) : 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
- 쓰기 시점에 팬아웃 (fanout-on-write or push model)과 읽기 시점에 팬아웃 (fanout-on-read or pull model) 이 있음
fanout-on-write (push) model
- 새로운 포스팅을 기록하는 시점에 뉴스 피드 갱신. 즉, 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록
- 장점
- 뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
- 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 (pre-computed) 뉴스 피드를 읽는 데 드는 시간이 짧아짐
- 단점
- 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있음 (hotkey 문제)
- 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원이 낭비됨
fanout-on-read (pull) model
- 피드를 읽어야 하는 시점에 뉴스 피드를 갱신, 요청 기반 (on-demand) 모델. 사용자가 본인 홈페이지나 타임라인은 로딩하는 시점에 새로운 포스트를 가져오게 됨
- 장점
- 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 이 모델이 유리함. 로그인 전까지는 어떤 컴퓨팅 자원도 소모하지 않아서임
- 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 hotkey 문제도 생기지 않음
- 단점
- 뉴스 피드를 읽는데 많은 시간이 소요될 수 있음
타협안
- 뉴스 피드를 빠르게 가져오는 것은 아주 중요하므로, 대부분의 사용자는 푸시 모델을 사용함
- 친구나 팔로워가 아주 많은 사용자의 경우에는 팔로워로 하여금 해당 사용자의 포스팅을 필요할 때 가져가도록 풀 모델 사용
- 안정 해시를 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제 완화
타협안의 flow
- 그림 11-5 참고
- 그래프 DB에서 친구 ID 목록을 가져옴
- 사용자 정보 캐시에서 친구들의 정보를 가져옴. 사용자 설정에 따라 친구 가운데 일부를 걸러냄 (일부 친구 feed mute 기능 지원 or 스토리를 일부 사용자에게만 공개하는 기능)
- 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
- 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스피드 데이터를 뉴스 피드 캐시에 넣는다. (그림 11-6 참고) - 사용자는 대부분 최신 스토리를 보기 때문에, 캐시의 크기를 한정하여도 캐시 미스가 많이 나지 않는다.
피드 읽기 흐름 상세 설계
- 그림 11-7 참고
설계안 flow
- 사용자가 뉴스 피드를 읽으려는 요청을 보냄 요청은
GET /v1/me/feed - 로드밸런서가 요청을 웹 서버 가운데 하나로 보낸다.
- 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스를 호출
- 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져옴
- 뉴스 피드에서 표시할 사용자 이름, 사용자 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만듦
- 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 보내고, 클라이언트는 해당 피드를 렌더링 함
캐시 구조
- 캐시는 뉴스 피드 시스템의 핵심 컴포넌트, 5 계층으로 나눈다.
- 그림 11-8 참고
- 뉴스 피드 : 뉴스 피드의 ID를 보관
- 콘텐츠 : 포스팅 데이터를 보관, 인기 콘텐츠는 따로 보관
- 소셜 그래프 : 사용자 간 관계 정보를 보관
- 행동 (action) : 포스팅에 대한 사용자의 행위에 관한 정보를 보관. (좋아요, 답글 등등)
- 횟수 (counter) : 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보 보관
4. 마무리
- 시스템 설계 면접은 정답이 없으므로, trade-off가 있는지 잘 이해하고 설명할 수 있어야 함
- 설계를 마친 후에도 시간이 남으면, 규모 확장성 이슈를 논의하는 것도 좋음
규모 확장성 이슈
- 데이터베이스 규모 확장
- 수직적 규모 확장 vs 수평적 규모 확장
- SQL vs NoSQL
- master-slave 다중화
- replica 읽기 연산
- 일관성 모델
- 데이터베이스 sharding
- 추가 논의 주제
- 웹 계층을 stateless로 운영하기
- 가능한 한 많은 데이터를 캐시할 방법
- 여러 데이터 센터를 지원할 방법
- 메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
- 핵심 메트릭 (key metric)에 대한 모니터링 (peak QPS, refresh시 지연시간 등)
참고자료
- 알렉스 쉬, 가상 면접 사례로 배우는 대규모 시스템 설계 기초 11장
Comments