Chapter 11. 뉴스 피드 시스템 설계

[MinJunKweon]

느낀점

• 무난무난하게 읽음. Rate Limiter, Consistent Hash, Notification Service 들어가는 거 보고 이럴 때 쓰는구나 싶었음.
• 앞서 일일 1천만명 사용, 5천명 팔로워 같이 구체적인 숫자를 제시하길래 설계안이 제한에 만족하는지 검증하는 과정이 들어갈 줄 알았는데 없어서 의아했음
• 셀러브리티 문제(핫키 문제)에 대해서 좀 중점적으로 다룰 줄 알았는데 그냥 설계에 더 치중된 것 같아서 좀 더 알아봐야겠음 ㅋ_ㅋ

---

정리

설계 범위 확정

• 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있어야하고, 친구들이 올리는 스토리를 볼 수 있어야함
• 단순히 시간 흐름 역순으로 표시된다고 가정
• 최대 친구는 5000명
• 매일 1천만명이 방문
• 스토리에 이미지나 비디오 등의 미디어 파일 포함 가능

개략적 설계안

• 피드 발행(feed publishing) : 스토리를 포스팅하면 캐시와 디비에 기록함. (친구의 피드에 전송)
• 뉴스 피드 생성(news feed building) : 지면 관계상 모든 친구의 포스팅을 시간 흐름 역산으로 모아서 만드는 과정

뉴스 피드 API

피드 발행 API

POST /v1/me/feed

<Parameters>
Body : 포스팅 내용
Authorization 헤더 : API 호출을 인증하기 위해 사용

피드 읽기 API

GET /v1/me/feed

<Parameters>
Authorization 헤더 : API 호출을 인증하기 위해 사용

피드 발행

• 포스팅 저장 서비스(Post Service) : 새 포스팅을 DB와 캐시에 저장
• 포스팅 전송 서비스(Fanout Service) : 새 포스팅을 친구의 뉴스 피드에 푸시(push)함. 캐시에 저장해서 뉴스피드 데이터를 빠르게 읽어갈 수 있도록 함
• 알림 서비스(Notification Service) : 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할을 담당함

뉴스 피드 생성

• 뉴스 피드 서비스(News feed Service) : 캐시에서 뉴스 피드를 가져오는 서비스
• 뉴스 피드 캐시(News feed Cache) : 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관함

상세 설계

포스팅 전송(Fanout) 서비스 모델 종류와 장단점

• 쓰기 시점에 전송(Fanout-on-write, Push model)
  • (장점1) 뉴스 피드가 실시간으로 갱신되며 친구목록에 있는 사용자에게 즉시 전송
  • (장점2) 새 포스팅이 기록되는 순간에 뉴스피드가 갱신되어 읽기속도 향상
  • (단점1) 친구가 많은 사용자는 뉴스피드 갱신에 시간이 너무 많이 소요됨 (hotkey 문제)
  • (단점2) 서비스를 자주 사용하지 않는 사용자의 피드도 매번 갱신하는 자원 낭비
• 읽기 시점에 전송(Fanout-on-read, Pull model)
  • (장점1) 친구 중에 비활성화된 사용자가 많은 경우 효율적
  • (장점2) 친구 각각에 푸시하는 작업이 없어서 핫키 문제도 없음
  • (단점1) 뉴스피드 읽는 데에 시간이 너무 오래걸림

팬아웃 과정

1. 그래프 DB(Graph DB)에서 친구 ID를 가져옴. (Graph DB는 친구 관계나 추천을 관리하기 적합)
2. 캐시에서 친구들의 정보를 가져옴. ⇒ 이후 공개여부나 사용자 개인의 설정에 따라 피드 업데이트를 무시할 사용자를 걸러냄
3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 발행.
4. 팬아웃 워커가 뮤케엇 데이터를 꺼내서 뉴스피드 캐시에 갱신. ⇒ 메모리 크기를 적절히 제한해서 적당한 데이터만 올려놓음. 오래된 데이터는 캐시 미스로 새로 불러오게끔 설계 (보통 최신의 데이터만 확인하므로 전부 훑어보는 경우는 지극히 낮음)

❗ 뉴스 피드 캐시는 Post ID - User ID 으로 이루어진 키-값 페어 구조로 되어있다.

피드 읽기 흐름 상세 설계

1. 유저 클라이언트가 로드밸런서로 GET /v1/me/feed 요청 전송
2. 요청이 웹 서버 중 하나로 로드밸런싱됨
3. 웹 서버는 피드를 가져오기 위해 뉴스피드 서비스를 호출함
4. 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록을 가져옴
5. 뉴스 피드에 표시할 내용을 User Cache와 Post Cache에서 가져옴. (캐시 미스 시, DB Read)
6. 생성된 뉴스 피드를 JSON 형태로 클라이언트에 응답. ⇒ 클라이언트는 결과 피드를 렌더링

논의해볼만한 주제

• DB 스케일 업 vs 스케일 아웃
• SQL vs NoSQL
• DB Master-Slave 다중화
• DB 레플리카에 대한 읽기 연산
• DB 일관성 모델
• DB 샤딩(Sharding)
• 웹 Stateless로 운영하기
• 데이터 캐시를 추가할만한 부분이 더 있는지?
• 다중 IDC를 지원하는 방법
• MQ를 사용해 컴포넌트 간의 결합도(Coupling) 낮추기
• 키 메트릭 모니터링 방법. (ex. 트래픽이 몰리는 시간대에 QPS, 뉴스피드 새로고침 시 지연시간)

[minkukjo]

느낀 점

• 상세 설계 부분에서 시스템 제일 앞 단에 인증과 처리율 제한을 함께 구성하는 모습이 인상 깊었다. 추후 예약이 MSA로 전환되면 제안해볼만한 아이디어인 듯. ( 이렇게 구성되는 컴포넌트의 이름은 뭐라고 불러야할까? 인증 컴포넌트? 처리율 제한기 컴포넌트? )
• Fanout을 두 가지 방법으로 할 수 있다는 점도 인상 깊었다. 포스팅이 작성된 시점에 Fanout을 할 것인지? 유저가 포스팅을 읽는 시점에 Fanout을 할 것인지?
• 포스팅이 작성되는 시점에 Fanout은 친구가 많으면 친구 목록을 읽는 시점에 이슈가 될 수 있다는 점도 신기했다. 이를 Hotkey 문제라 부른다고 한다.
• 책에서는 친구가 아주 많은 유저의 경우에는 Pull Model을, 친구가 적은 유저는 Push Model을 사용한다 하였는데 친구가 아주 많다는 기준은 어느정도로 잡는걸까?
• 캐시의 크기를 효율적으로 관리하기 위해 ID만 저장하는 점도 염두해볼만한 포인트다.
• 결국 이런 뉴스 피드 시스템처럼 트래픽이 큰 시스템에선 캐시 레이어를 어떻게 설계하느냐가 빠른 서빙을 위한 핵심인 듯 하다.

[LOG-INFO]

끄적끄적

• 어차피 서버쪽 설계가 메인인데, 매번 모바일 앱인지 웹인지는 왜 질문하는걸까?
• 이번엔 QPS, 저장용량 같은거 안 구하는군
• 포스팅 생성/뉴스피드 조회 두 부분으로 나누는군
• 포스팅은 보통 최신 데이터를 읽어오니 Write Through로 하면서 TTL 걸거나 LRU 방식 사용하면 좋을 듯
• 포스팅캐시/뉴스피드캐시/사용자캐시 나눈 것 좋은 듯
  • 뉴스피드캐시에는 user_id, post_id만 저장하고, 조회할 때 Application Join한 것도 좋은 듯 (캐시 메모리 효율성)
• 메시지큐 이용해서 '포스팅 전송 서버'/'포스팅 전송 작업 서버' 디커플링한거 굿
  • 이벤트 등으로 급격히 늘어난 부하를 처리할 수 있게 범퍼역할을 해줌
  • publisher/consumer가 서로의 상태를 체크하지 않아도 됨

궁금한 점

• GraphDB 써보신 분 계신가요?
• Hotkey 문제는 어떻게 해결해야 할까?
  • 팔로워가 많은 사용자가 글 쓸 경우 모든 사용자에게 Fan-out하는 방식은 부담
  • 안정해시 사용?
  • 온디맨드 방식?
• 보통 '인증/인가' 어떻게 처리하시나요?
  • 쿠키+세션? 토큰?
  • Gateway에서? 웹서버에서? 각 웹애플리케이션서버에서?
• 각 캐시는 어떤 구현체를 사용하는게 좋을까?
• 뉴스피드캐시에는 (userId, postId)로 여러 데이터를 쌓아야 하나?
  • 특정 user_id로 스캔하면 인덱스 타는건가? (Redis를 잘 모름)
  • 그냥 (userId, List) 하면 안되나?
  • '포스팅 전송 서버'에서 한 번 읽은 후 저장해야 하고, 트랜잭션 신경써야 하는 단점이 있긴 하겠다