대규모시스템설계기초 ch11

대규모 시스템 설계 기초 ch11. 뉴스 피드 시스템 설계

1단계. 문제 이해 및 설계 범위 확정

• 최소한 어떤 기능을 지원해야할지 파악할 것
  • 뉴스 피드는 어떤 순서로 표시됩니까? 토픽 점수 or 시간 흐름 역순?

2단계. 개략적 설계안 제시 및 동의 구하기

1. 피드 발행
   • 사용자가 스토리 포스팅하면 해당 데이터를 캐시와 DB에 기록. 새 포스팅은 친구 뉴스 피드에도 전송
   • 포스팅 저장 서비스 / 포스팅 전송 서비스 / 알림 서비스
2. 뉴스 피드 생성
   • 시간 흐름 역순으로 모아 가정
   • 뉴스 피드 서비스 w. 캐시
     • 뉴스 피드 렌더링할 때 필요한 피드 ID 보관

3단계. 상세 설계

• 포스팅 전송 서비스 팬아웃: 사용자의 새 포스팅을 사용자와 친구 관계에 있는 모든 사용자에게 전달
  1. 쓰기 시점에 팬아웃
     • 장점)
       • 뉴스 피드 실시간 갱신되며 친구 목록에 있는 사용자에게 즉시 전송
       • 새 포스팅이 기록되는 순간 뉴스피드가 갱신되어 Read가 빠름
     • 단점)
       • 친구 목록 가져오고, 그 목록에 있는 사용자 모두의 뉴스 피드 갱신
       • 서비스를 자주 사용하지 않는 사용자까지 피드 갱신 필요
  2. 읽기 시점에 팬아웃
     • 장점)
       • 비활성된 사용자, 서비스에 로그인하지 않는 사용자의 경우에 해당 모델이 유리
       • 데이터를 친구 각각에 푸시하는 작업이 필요 없기에 핫 키 문제도 없음
     • 단점)
       • 뉴스 피드 읽는데 많은 시간 소요

• 두 가지의 장단점 모두 취하기
  1. 그래프 DB에서 친구 ID 목록 가져옴
  2. 사용자 정보 캐시에서 친구 정보 가져옴. 친구 일부를 걸러냄.
     • 새로 포스팅된 스토리가 일부 사용자에게 공유되도록 설정되어도 비슷
  3. 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐
  4. 팬아웃 작업 서버가 메시지 큐에서 데이터 꺼내 뉴스 피드 데이터 뉴스 피드 캐시에 넣음

4단계. 마무리

• 규모 확장성 이슈도 고려해볼것
  • DB 규모 확장
  • 무상태 웹 서비스 유지
  • 데이터 캐시 방식
  • 핵심 메트릭 모니터링 등