1단계 문제 이해 및 설계 범위 확정
뉴스 피드 시스템 설계를 할 때, 가장 먼저 해야할 일은 면접관에게 질문하여 의도를 파악하는 것이다.
지원자: 모바일 앱을 위한 시스템인가요? 아니면 웹? 둘 다 지원해야 합니까?
면접관: 둘 다 지원해야 합니다.
지원자: 중요한 기능으로는 어떤 것이 있을까요?
면접관: 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야 하고, 친구들이 올리는 스토리를 볼 수도 있어야 합니다.
지원자: 뉴스 피드에는 어떤 순서로 스토리가 표시되어야 하나요? 최신 포스트가 위에 오도록 해야 하나요? 아니면 토픽 점수(topic score) 같은 다른 기준이 있습니까? 예를 들어, 가까운 친구의 포스트는 좀 더 위에 배치되어야 한다든가 하는.
면접관: 그냥 단순히 시간 흐름 역순으로 표시된다고 가정합시다.
지원자: 한 명의 사용자는 최대 몇 명의 친구를 가질 수 있습니까?
면접관: 5,000명입니다.
지원자: 트래픽 규모는 어느 정도입니까?
면접관: 매일 천만 명이 방문한다고 가정합시다.(10million DAU)
지원자: 피드에 이미지나 비디오 스토리도 올라올 수 있습니까?
면접관: 스토리에는 이미지나 비디오 등의 미디어 파일이 포함될 수 있습니다.
Plain Text
복사
위 요구사항을 통해 시스템 설계를 해볼 수 있다.
2단계 개략적 설계안 제시 및 동의 구하기
뉴스 피드 시스템의 설계로는 (1) 피드 발행(feed publishing)과 (2) 뉴스 피드 생성(new feed building)의 두 가지 부분으로 나눌 수 있다.
•
피드 발행 : 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 새 포스팅은 친구의 뉴스 피드에도 전송된다.
•
뉴스 피드 생성: 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다.
뉴스 피드 API
뉴스 피드 API를 통해 상태 정보를 업데이트하거나, 뉴스 피드를 가져오거나, 친구를 추가하는 등 다양한 작업을 수행한다. 이 중 가장 중요한 피드 발행 API와 피드 읽기 API 2개를 살펴보자.
피드 발행 API
새 스토리를 포스팅하기 위한 API로, HTTP POST 형태로 요청을 보내면 된다.
POST /v1/me/feed
•
body : 포스팅 내용
•
Authorization 헤더: API 호출을 인증하기 위해 사용
피드 읽기 API
뉴스 피드를 가져오는 API다.
GET /v1/me/feed
•
Authorization 헤더: API 호출을 인증하기 위해 사용
피드 발행
•
사용자 : 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체
•
로드밸런서 : 트래픽을 웹 서버들로 분산
•
웹 서버 : HTTP 요청을 내부 서비스로 중계하는 역할을 담당
•
포스팅 저장 서비스(post service) : 새 포스팅을 데이터베이스와 캐시에 저장
•
포스팅 전송 서비스(fanout service) : 새 포스팅을 친구의 뉴스 피드에 푸시
•
알림 서비스(notification service) : 새 포스팅이 올라왔음을 알리거나 푸시 알림을 보내는 역할을 담당
뉴스 피드 생성
•
사용자 : 뉴스 피드를 읽는 주체
•
로드밸런서 : 트래픽을 웹 서버들로 분선
•
웹 서버 : 트래픽을 뉴스 피드 서비스로 보냄
•
뉴스 피드 서비스 : 캐시에서 뉴스 피드를 가져오는 서비스
•
뉴스 피드 캐시 : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관
3단계 상세 설계
피드 발행 흐름 상세 설계
대부분의 컴포넌트는 위의 개략적 설계안의 내용으로 충분하고, 웹 서버와 포스팅 전송 서비스만 조금 더 알아보자.
웹 서버
웹 서버는 클라이언트와 통신하는 역할 뿐만 아니라, 인증이나 처리율 제한 등의 기능도 수행한다. Authorization 헤더에 올바른 인증 토큰이 있는 사용자만 포스팅을 할 수 있도록 처리하고, 스팸이나 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 한 사용자가 올릴 수 있는 포스팅의 수에 제한을 두어야 한다.
포스팅 전송(fan out) 서비스
포스팅 전송은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정이다. 이러한 팬아웃에는 두 가지 모델이 있다. 하나는 푸시 모델이라고도 불리는 쓰기 시점에 팬아웃(fanout-on-write) 모델이고, 다른 하나는 풀 모델이라고도 불리는 읽기 시점에 팬아웃(fanout-on-read) 모델이다.
fanout-on-write : 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신하는 방식이다. 포스팅이 완료되면 바로 해당 사용자의 캐시에 해당 포스팅을 기록한다.
•
장점
◦
뉴스 피드가 실시간으로 갱신되며 친구 목록에 있는 사용자에게 즉시 전송된다.
◦
새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로(pre-computed), 뉴스 피드를 읽는데 드는 시간이 짧아진다.
•
단점
◦
친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 있는 사용자 모두의 뉴스 피드를 갱신하는데 많은 시간이 요소될 수 있다.(hotkey 문제)
◦
서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야하므로 컴퓨팅 자원이 낭비된다.
fanout-on-read : 피드를 읽어야 하는 시점에 뉴스 피드를 갱신하여, 사용자가 본인 홈페이지나 타임 라인을 로딩하는 시점에 새로운 포스트를 가져온다. 따라서 요청 기반(on-demand) 모델이다.
•
장점
◦
비활성화된 사용자나 서비스에 거의 로그인하지 않는 사용자들의 뉴스 피드를 갱신하지 않아 컴퓨팅 자원을 아끼는데 유리하다.
◦
데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 hotkey 문제도 생기지 않는다.
•
단점
◦
뉴스 피드를 읽는데 많은 시간이 소요될 수 있다.
위 두 가지 방식을 결합하여 장점은 취하고 단점은 버리는 전략을 취할 수 있다. 뉴스 피드를 빠르게 가져올 수 있는 것은 중요하기 때문에, 대부분의 사용자에 대해서는 푸시 모델을 사용한다. 친구나 팔로워가 아주 많은 사용자의 경우에는, 팔로워가 해당 사용자의 포스팅을 필요할 때 가져가도록 하는 풀 모델을 사용하여 시스템 과부하를 방지한다.
추가적으로 안정 해시를 통해 요청과 데이터를 고르게 분산하여 핫키 문제를 줄여볼 수 있다.
팬아웃 서비스의 플로우는 다음과 같다.
1.
그래프 DB에서 친구 ID 목록을 가져온다.
2.
사용자 정보 캐시나 DB에서 친구들의 정보를 가져와, 사용자 설정에 따라 친구 중 무시(mute)하기로 한 친구들을 걸러낸다.
3.
가져온 친구 목록과 새 스토리의 포스팅 ID를 메세지 큐에 넣는다.
4.
팬아웃 작업 서버가 메세지 큐에서 데이터를 꺼내 뉴스 피드 데이터를 캐시에 저장한다. 포스팅 정보를 전부 저장하면 메모리 요구량이 지나치게 늘어날 수 있기 때문에, 아래와 같이 <포스팅 ID, 사용자 ID> 순서쌍으로 매핑해 저장한다.
피드 읽기 흐름 상세 설계
위 그림처럼 이미지나 비디오 같은 미디어 콘텐츠는 CDN에 저장하여 빨리 읽어갈 수 있게 처리한다.
클라이언트가 뉴스 피드를 읽는 플로우는 다음과 같다.
1.
사용자가 뉴스 피드를 읽기 위해 HTTP 요청을 보낸다.
2.
로드밸런서가 요청을 웹 서버 중 하나로 보낸다.
3.
웹 서버에서 피드를 가져오기 위해 뉴스 피드 서비스를 호출한다.
4.
뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다.
5.
뉴스 피드에 표시할 사용자 이름, 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드를 만든다.
6.
생성된 뉴스 피드를 JSON 형태로 클라이언트에 보내고, 클라이언트는 해당 데이터를 통해 렌더링한다.
캐시 구조
뉴스 피드 시스템에서 캐시는 매우 중요한 컴포넌트인데, 위 그림처럼 5개의 계층으로 나뉜다.
•
뉴스 피드 : 뉴스 피드의 ID를 보관
•
콘텐츠 : 포스팅 데이터를 보관, 인기 콘텐츠는 따로 보관
•
소셜 그래프 : 사용자 간 관계 정보를 보관
•
행동 : 포스팅에 대한 사용자의 행위(좋아요, 답글 등) 정보를 보관
•
횟수 : 좋아요 횟수, 답글 수, 팔로워 수, 팔로잉 수 등 정보를 보관
4단계 마무리
뉴스 피드 시스템에서도 정답은 없다. 각 회사의 면접마다 독특한 제약이나 요구조건이 있기 때문에, 그런 점을 잘 고려해 시스템을 설계해야한다. 설계를 진행하고 기술을 선택할 때는 그 배경에 어떤 타협점(trade-off)이 있었는지를 잘 이해하고 설명할 수 있어야한다.
아래는 설계를 마친 후 시간이 조금 남는다면 추가적으로 논의할만한 주제들이다.
•
데이터베이스 규모 확장
◦
수직적 규모 확장 vs 수평적 규모 확장
◦
SQL vs NoSQL
◦
master-slave 다중화
◦
replica에 대한 읽기 연산
◦
일관성 모델
◦
데이터베이스 샤딩
•
웹 계층(web tier)을 무상태로 운영하기
•
가능한 많은 데이터를 캐싱할 방법
•
여러 데이터 센터를 지원할 방법
•
메세지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
•
핵심 메트릭에 대한 모니터링(트래픽이 몰리는 때의 QPS나 뉴스 피드 새로고침 시 지연시간 등)