- 페이스북의 업데이트와 같은 설계 문제가 있습니다.
1단계 문제 이해 및 설계 범위 확정#
- 대상 : 모바일, 웹
- 중요한 기능
- 뉴스 피드 페이지에서 새로운 스토리를 올릴 수 있어야하며, 친구들이 올리는 스토리를 볼 수도 있음
- 뉴스 피드의 순서
- 한명은 최대 5000명의 친구 가능
- 트래픽은 대략 매일 천만명
- 스토리에는 이미지나 비디오 등의 미디어 파일도 포함 가능
2단계 개략적 설계안 제시 및 동의 구하기#
- 설계는 피드 발행과 뉴스 피드 생성의 두 가지 부분으로 나뉘어 있습니다.
- 피드 발행: 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록합니다.
- 뉴스 피드 생성: 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정합니다.
뉴스 피드 API#
- 뉴스 피드 API는 클라이언트가 서버와 통신하기 위해 사용하는 수단입니다.
- HTTP 프로토콜 기반입니다.
- 피드 API와 피드 읽기 API로 나눌 수 있습니다.
피드 발행#
피드 생성#
3단계 상세 설계#
피드 발행 흐름 상세 설계#
웹 서버#
- 웹 서버는 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행합니다.
포스팅 전송(팬아웃) 서비스#
- 포스틍 전송, 즉 팬아웃은 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정입니다.
- 하나는 쓰기 시점에 팬아웃하는 모델이고 하나는 읽기 시점에 팬아웃 하는 모델이 있습니다.
쓰기 시점에 팬아웃하는 모델#
- 새로운 포스팅을 기록하는 시저멩 뉴스 피드를 갱신하게 됩니다.
- 장점
- 뉴스 피드가 실시간으로 갱신되면 친구 목록에 있는 사용자에게 즉시 전송됩니다.
- 새 포스팅이 기록되는 순간에 뉴스 피드가 이미 갱신되므로 뉴스 피드를 읽는 데 드는 시간이 짧아집니다.
- 단점
- 친구가 많은 사용자의 경우 친구 목록을 가져오고 그 목록에 잇는 사용자 모두의 뉴스 피드를 갱신하는 데 많은 시간이 소요될 수 있습니다. 이를 핫키(hotkey)라고 부릅니다.
- 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨터 자원이 자주 낭비됩니다.
읽기 시점에 팬아웃하는 모델#
- 피드를 읽어야 하는 시점에 뉴스 피드를 갱신합니다. 즉, 요청 기반(on-demand) 모델입니다.
- 장점
- 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에 이 모델이 유리합니다.
- 데이터를 친구 각각에 푸시하는 작업이 필요 없으므로 핫키 문제가 없습니다.
- 단점
- 뉴스 피드를 읽는 데 많은 시간이 소요될 수 있습니다.
피드 읽기 흐름 상세 설계#
캐시 구조#
| | | |
|---|
| 뉴스피드 | 뉴스피드 | | |
| 콘텐츠 | 인기 콘텐츠 | 일반 콘텐츠 | |
| 소셜 그래프 | 팔로어 | 팔로잉 | |
| 행동 | '좋아요' | 답글 | 기타 |
| 횟수 | 좋아요 횟수 | 답글 횟수 | 기타 |
- 뉴스 피드: 뉴스 피드의 ID를 보관합니다.
- 콘텐츠: 포스팅 데이터를 보관합니다. 인기 콘텐츠는 따로 보관합니다.
- 소셜 그래프: 사용자 간 관계 정보를 보관합니다.
- 행동(action: 포스팅에 대한 사용자의 행위에 관한 정보를 보관합니다. 포스팅에 대한 좋아요, 답글 등등이 이에 해당합니다.
- 횟수(counter): 좋아요 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보를 보관합니다.
4단계 마무리#
- 아래의 사항에 대해 추가적으로 더 이야기하면 좋습니다.
- 데이터베이스 규모 확장
- 수직정 규모 확장 vs 수평적 규모 확장
- SQL vs NOSQL
- 주부(master-slave) 다중화
- 복제본(replica) dp eogks dlfrrl dustks
- 일관성 모델(consistency model)
- 데이터베이스 샤딩(sharding)
- 아래의 추가 사항이 있습니다.
- 웹 계층(web tier)을 무상태로 운영
- 가능한 한 많은 데이터를 캐시할 방법
- 여러 데이터 센터를 지원할 방법
- 메시지 큐를 사용하여 컴포넌트 사이의 결합도 낮추기
- 핵심 메트릭에 대한 모니터링