뉴스 피드 시스템 설계

"가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 읽고 정리한 글입니다 :)

페이스북에서는 뉴스 피드에 대해 다음과 같이 말하고 있다. "뉴스 피드는 여러분의 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들로, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 그리고 여러분이 페이스북에서 팔로우하는 사람들, 페이지, 또는 그룹으로부터 나오는 '좋아요' 등을 포함한다" 이러한 뉴스 피드 시스템 설계는 아주 유명한 면접 문제로써 널리 사용된다.

고려할 요구사항

뉴스 피드 시스템을 설계하기 위해 고려해야할 요구사항은 다음과 같다.

• 웹, 모바일 앱과 같은 타겟 플랫폼
• 뉴스 피드의 정렬 순서
  • 단순히 최신 순서대로 표시할 수 있음
  • 가까운 친구의 포스트를 먼저 표시하는 등의 별도 기준이 있을 수 있음
• 한 명의 사용자가 가질 수 있는 친구 수
• 트래픽 규모
• 피드에 올라오는 데이터의 형식 (이미지나 비디오 등의 미디어 파일, 혹은 Only 텍스트)

개략적 설계안

뉴스 피드 시스템에는 크게 두가지 기능이 있을 것이다. 첫째로 피드를 발행(Feed Publishing)하는 기능과 다음으로 뉴스 피드를 생성(New Feed Building)하는 기능일 것이다.

피드 발행은 사용자가 스토리를 포스팅하는 것을 의미하며, 뉴스 피드 생성은 사용자가 조회할 뉴스 피드를 만드는 것을 의미한다. 피드 발행은 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 DB에 기록하고, 새 포스팅을 친구의 뉴스 피드에 전달해주어야 한다. 뉴스 피드 생성은 본래라면 꽤나 복잡한 알고리즘이 동작하겠지만, 여기서는 간단하게 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정한다.

피드 발행

피드를 발행할 때는 포스팅을 저장하는 서비스와 포스팅을 전송하는 서비스가 필요할 것이다. 포스팅 저장 서비스(Post Service)는 새 포스팅을 DB와 캐시에 저장하는 역할을 맡는다. 포스팅 전송 서비스(Fanout Service)는 새 포스팅을 친구의 뉴스 피드에 푸시(Push)하는 역할을 맞는다. 이 때, 뉴스 피드 데이터는 캐시에 보관하여 빠르게 읽어갈 수 있도록 한다.

이와 별개로 친구들에게 새 포스팅이 올라왔음을 알려줄 알림 서비스도 있으면 더 좋을 것이다.

뉴스 피드 생성

뉴스 피드를 생성할 때는 빠르게 피드 데이터를 가져오는 것이 중요하다. 그렇기에 뉴스 피드 서비스는 캐시에서 뉴스 피드를 가져올 것인데, 이때 포스팅 전송 서비스가 데이터를 저장한 캐시를 사용하면 될 것이다. 해당 뉴스 피드 캐시는 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관하고, 실제 포스팅 데이터는 저장하지 않는다. 이는 메모리를 효율적으로 사용하기 위함이다.

상세 설계

피드 발행

우선 사용자의 요청을 받을 웹 서버가 필요하다. 사용자의 요청을 받은 뒤, 포스팅 저장 서비스와 포스팅 전송 서비스, 알림 서비스 등에 Job을 전파하는 책임을 지닌다. 또한, 웹 서버는 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행한다. 올바르게 인증된 사용자만 포스팅을 할 수 있어야 하며, 유해한 콘텐츠가 자주 올라오는 것을 방지하기 위해 처리율을 제한할 수 있어야 한다.

포스팅 전송, 즉 팬아웃(Fanout)은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 하는 것이다. 팬아웃에는 두 가지 모델이 있는데, 하나는 쓰기 시점에 팬아웃(Fanout-on-Write)하는 모델이고(Push 모델이라고도 함), 다른 하나는 읽기 시점에 팬아웃(Fanout-on-Read)이다.(Pull 모델이라고도 함)

이 두 가지 모델의 장단점은 다음과 같다.
Fanout on Write, Push Model

• 새로운 포스팅을 기록하는 시점에 뉴스 피드를 갱신한다.
• 장점
  • 뉴스 피드가 실시간으로 갱싱되며, 친구 목록에 있는 사용자에게 즉시 전송된다.
  • 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로(Pre-Computed) 뉴스 피드를 읽는데 드는 시간이 줄어든다.
• 단점
  • 친구가 많은 사용자의 경우, 친구들의 뉴스 피드를 갱신하는데 많은 시간이 소요될 수 있다. 핫키(Hotkey)라고 부르는 문제이다.
  • 서비스를 자주 이용하지 않는 사용자의 피드까지 계산해야 하므로 컴퓨팅 자원이 낭비된다.

Fanout on Read, Pull Model

• 피드를 읽는 시점에 뉴스 피드를 갱신한다.
• 장점
  • 서비스를 거의 사용하지 않는 사용자의 경우 컴퓨팅 자원을 거의 소모하지 않는다.
  • 데이터를 친구 각각에 푸시하는 작업이 필요없으므로 핫키 문제도 생기지 않는다.
• 단점
  • 뉴스 피드를 읽는데 많은 시간이 소요될 수 있다.

두 모델 모두 각각의 장단점이 있다. 이 책에서는 두 가지 방법을 결합하여 장점은 취하고 단점은 버리는 전략을 취한다. 뉴스 피드를 빠르게 가져오는 것은 중요하므로 대부분의 사용자에 대해서는 푸시 모델을 사용한다. 단 친구나 팔로워가 아주 많은 사용자의 경우에는 팔로워로 하여금 해당 사용자에 대해 풀 모델을 사용하도록 한다. 아울러 안정 해시(Consistent Hashing)을 통해 요청과 데이터를 보다 고르게 분산하여 핫키 문제를 줄이려고 시도한다.

이제 팬아웃 서비스가 동작하는 과정을 설명하자면,

1. 그래프 DB에서 친구 ID 목록을 가져온다.
   • 그래프 DB는 친구 관계나 친구 추천을 관리하기 적합하다.
2. 사용자 정보 캐시에서 친구 정보를 가져온다.
   • 사용자가 설정한 정보에 따라 필터링을 수행해야 한다.
   • 예를들어, 친구가 내 피드 업데이트를 무시 설정 했다면, 해당 친구를 제외해야 한다.
3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 넣는다.
   • 메시지 큐를 사용하는 이유는 이전 단계를 수행하는 서비스와 다음 단계를 수행하는 서비스의 의존관계를 분리하기 위함이다.
   • 만약 이전, 이후 단계를 모두 같은 서비스 혹은 서버에서 수행할 것이라면 굳이 메시지 큐가 필요없을 것이다.
4. 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스 피드 캐시에 넣는다.
   • 뉴스 피드 캐시는 <포스팅 ID, 사용자 ID> 순서쌍을 보관하는 매핑 테이블로 설계하는 것이 일반적이다.
   • 사용자 정보와 포스팅 정보 전부를 저장하지 않는 이유는 메모리 요구량을 줄이기 위함이다.

뉴스 피드 읽기 (뉴스 피드 생성)

뉴스 피드 서비스는 비교적 간단하게 설계할 수 있다. 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져온다. 이후 뉴스 피드에 표시할 사용자 이름, 사용자 사진, 포스팅 콘텐츠 등을 캐시 및 DB에서 가져와 완전한 뉴스 피드를 만든다.

여기서 이미지나 비디오와 같은 미디어 콘텐츠는 CDN을 통해 제공함으로써 성능을 조금 더 높일 수 있을 것이다.

캐시 구조

캐시는 뉴스 피드 시스템의 핵심 컴포넌트이다. 캐시를 어떻게 설계하냐는 다양한 방법이 있겠지만, 해당 책에서는 다음과 같이 5계층으로 설계하였다.

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

총총

다른 설계 문제와 마찬가지로, 이번 문제에도 정답은 없다. 각 상황마다 독특한 제약이나 요구조건이 있을 것이기에, 시스템을 설계할 때는 그런 점들을 고려해야 한다. 설계를 진행하고 기술을 선택할 때는 그 배경에 어떤 Trade-Off들이 있는지 잘 이해하고 설명할 수 있어야 한다.

더 고민해보면 좋을 것들은 다음과 같다.

• 데이터베이스 규모 확장
  • 수직적 규모 확장 vs 수평적 규모 확장
  • SQL vs NoSQL
  • Master-Slave 다중화
  • 일관성 모델(Consistency Model)
  • 데이터베이스 샤딩(Sharding)
• Stateless Web Tier
• 가능한 많은 데이터를 캐싱할 방법
• 여러 데이터 센터를 지원할 방법
• 메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
• 모니터링

이것들을 짧은 시간내에 고려하고 설계하는 것은 불가능할 것이다. 차근차근 하나씩 고민해보면 좋을 것이다.