[Review] 시스템 디자인 스터디 4주차 후기

안녕하세요!

K-DEVCON (이하 “데브콘”) 그로스 매니저 박종훈입니다.🙋🏻‍♂️

 

이 글에서는 10/2 (목)에 진행된 스터디에서 나눈 이야기를 정리합니다.

 

이번 시간에는 “뉴스피드 설계” 이야기를 나눴습니다.

---

뉴스피드 설계

뉴스피드는 홈 페이지에 지속적으로 업데이트 되는 스토리들입니다. 사용자 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 팔로우, 페이지, 좋아요 등 다양한 정보가 포함됩니다. 뉴스피드 시스템 설계는 유명한 면접 문제 중 하나입니다.

 

뉴스피드 시스템 설계에서는 빠른 응답을 위해 Cache를 적극적으로 사용하는 것이 특징입니다. 실제로 트위터의 경우 Redis를 적극적으로 사용한 것을 발표자료를 통해 엿볼 수 있습니다. (Timelines at Scale)

 

우리는 먼저 책에서 나오는 설계 흐름을 따라가 보고, 그 후로 확장된 영역까지 이야기를 나눠보았습니다. 특히 팬아웃(Pan-out)과 팬인(Pan-in)을 중심으로 이야기를 나눴습니다.

책에서는 최종적으로 아래와 같이 시스템 디자인을 진행하였습니다.

 

쓰기 경로 시스템 디자인은 다음과 같습니다:

 

 

읽기 경로 시스템 디자인은 다음과 같습니다:

 

 

 

팬 아웃(Pan-out)

팬 아웃(Pan-out)은 어떤 사용자의 새 포스팅을 작성하였을 때, 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정입니다.

책에서는 아래의 세 가지 방식에 대해서 설명합니다.

 

• 쓰기 시점에 팬아웃(Pan-out on Write, Push)
  • 쓰기 시점에 모든 팔로워에게 푸시
  • 읽기가 매우 빠름 (Redis 캐시 조회)
  • 일반 사용자 트윗에 적합
  • 쓰기 부하: O(팔로워 수)
• 읽기 시점에 팬아웃(Pan-out on Read, Pull)
  • 읽기 시점에 동적으로 수집
  • 쓰기가 매우 빠름 (한 곳에만 저장)
  • 유명인 트윗에 적합
  • 읽기 부하: O(팔로잉 유명인 수)
  • 보는 관점에 따라 팬 인(Pan-in) 으로 볼 수도 있음. 이후 다시 설명.
• 두가지를 적절히 결합하는 방식 

 

쓰기 시점에 팬아웃

쓰기 시점에 팬아웃 방식에서는 전달된 데이터를 뉴스 피드로 미리 생성해둡니다. 이를 통해 읽기 시 미리 계산된 타임라인을 통해 빠르게 데이터를 반환해줄 수 있습니다.

 

책에서는 아래와 같은 <포스팅 id, 사용자 id> 의 순서쌍을 보관하는 매핑 테이블에 데이터를 넣는다고 되어있습니다.

 

이 테이블은 과연 무엇을 의미하는것일까요? 실제로 Redis 에 이 구조로 보관을 하려면 어떻게 해야하는것일까요?

 

위에서 언급한 Timelines at Scale 를 보면 다음과 같은 내용을 확인해 볼 수 있습니다.

 

 

여기서 각 row는 사용자의 타임라인을 의미하게 됩니다. 그리고 그 뒤로 트윗 정보가 추가되게 됩니다.

 

이 구조를 조금 더 직관적으로 표현하면 아래와 같은 형태입니다.

 다음과 같은 논의를 하였습니다.

• 왜 책에서는 테이블 형태라고 하였을까?
  • 좀 더 이해하기 쉬운 형태로 설명하기 위해 한 유저의 List의 각 row를 세로로 나열한게 아닐까? 

• 각 아이템에는 왜 UserID 가 들어갔을까?
  • 만약 tweet_id 만 포함시켰을 경우 tweet_id 로 tweet을 조회한 후, 작성자 user_id 를 통해 작성자 user 정보를 다시 조회해야하는데 이는 읽기 속도를 낮출 것임. 타임라인을 받아온 후 바로 유저 정보를 조회하기 위해 별도의 데이터로 저장하여, 병렬로 요청할 수 있도록 함.

위 방식은 트위터 초기에는 잘 동작했던것으로 보입니다. 하지만 유저가 늘어나게 되면서 다음과 같은 문제점이 발생되었습니다. 

• 활성화 되지 않은 사용자에게도 캐시를 쌓아두고 있어야 한다.
• 팔로워가 많은 사람이 글을 작성하는 경우에, 쓰기에 많은 리소스를 필요로 한다.

 

읽기 시점에 팬아웃

이러한 문제점을 개선하기 위해 기존의 쓰기 시점의 팬아웃과 읽기 시점에 팬아웃 을 함께 사용하게 됩니다.

읽기 시점에 팬아웃 방식은 사용자가 타임라인을 로딩하는 시점에 새로운 포스트를 가져옵니다.

이를 통해 불필요한 사용자에게 컴퓨터 자원을 소모하지 않게 되었으며, 팔로워가 많은 사람이 글을 작성하더라도 그 부담을 덜 수 있게 되었습니다.

 

책에서는 두가지 방식을 함께 결합하는 방식에 대해서 말로만 설명 되어있는데요. 한 스터디원 분께서 AI를 활용하여 간단하게 이해할 수 있도록 예시 페이지를 제작해주셨습니다.

 

1단계: 사용자가 타임라인을 요청합니다.

2단계: 미리 계산된 일반 사용자의 트윗들을 Redis에서 가져옵니다

 

 

 

3단계: 팔로우 중인 유명인들의 최근 트윗을 실시간으로 조회합니다

 

4단계: Fan-Out과 Fan-In 데이터를 시간순으로 병합합니다

 

5단계: 최종 타임라인을 사용자에게 전달합니다

 

이제 더 나은구조가 되었습니다. 하지만 이러한 방식에서도 한계가 있습니다.

중간에 광고를 넣고 싶다든지, 친구 추천을 넣고 싶다든지, 현재 인기 급상승 트윗을 넣고 싶다든지 새로운 요구들이 있을때, 점점 더 복잡해지며 대응하기가 어려운 구조가 되었습니다.

팬 인(Pan-in)

팬 인(Pan-in)은 작성자 입장에서 생각하는 Pan-out 과 반대로 소비자 입장에서 생각하는 방식입니다.

(앞서 이야기 한 ‘읽기 시점에서 Pan-out’ 과 헷갈리기 좋은 단어입니다. 우선 관점의 차이로 이해했습니다. (작성자 입장과 수신자 입장))

 

트위터는 팬 아웃 에서의 한계를 개선하기 팬 인 방식을 적극적으로 도입하기 시작합니다. 팬 인 사용 예시는 트위터의 발표자료를 통해 엿볼 수 있습니다. (How We Learned to Stop Worrying and Love Fan-In at Twitter)

 

트위터 서비스가 커지게 되면서 다양한 니즈에 따라 다양한 마이크로 서비스들이 존재하게 되었습니다.

그리고 이를 통합하기 위해 Timeline Mixer 가 생기게 되었습니다.

 

최종적으로 다음과 같은 아키텍처로 운영하게 되었다고 합니다.

실제로는 Timeline Mixer 에 굉장히 많은 서비스가 붙으며, 기존의 Timeline service도 별도의 서비스로 운영됩니다

 

 

 

 Timeline Mixer 는 각 서비스에서 보내온 데이터를 우선순위에 따라 처리하여 최종적으로 사용자에게 맞춤형 데이터를 제공해줍니다.

 

스터디 중에는 발표에서 나온 "Timeline Mixer가 탄생되고, 발전하기 까지의 과정" 에 대한 이야기를 나눴지만, 여기서는 너무 긴 이야기가 될 것 같아 이만 줄입니다. 관심이 있다면 한 번 보시는걸 추천드리는 발표자료 입니다. 트위터 팀의 많은 고민을 느껴볼 수 있었습니다.

추천 참고 자료

• ByteByteGo - Design A News Feed System
• Timelines at Scale
• How We Learned to Stop Worrying and Love Fan-In at Twitter

---

 

오늘은 위와같은 이야기를 함께 나누어보았습니다.

 

시스템 디자인을 하면서 배우는 것은 "절대적인 정답은 없다"는 것입니다.
서비스의 성장과 요구사항에 맞춰 유연하게 대응하는 것이 중요합니다.

우리 스터디에서는 이러한 문제들을 실제 사례에서 어떻게 해결해 나갔을까 많은 고민을 해보고 이야기를 나눠보고 있습니다. 이번주도 다들 열심히 참여해주셔서 더 풍성한 스터디가 될 수 있었습니다.

 

 

 

스터디에서 더 많은 이야기를 나눴지만, 오늘은 여기서 마쳐보겠습니다.

✅ 직접 스터디를 개설해보고 싶은 분이 계시다면, K-DEVCON에서 운영을  도와드리겠습니다. 데브콘의 '랩짱'에 도전하여 커뮤니티 성장을 함께 이끌어주세요! 슬랙을 통해 운영진에게 DM 부탁드리겠습니다😉