모의 설계 인터뷰 - 탑 셀러

inhalin·2022년 5월 30일

Udemy Mastering the System Design Interview 정리

목록 보기

4/5

전체 사이트 기준? 항목별 세분화?
- 항목별로 분할되어야 하고 하위 항목 필요할 수 있음
결과들은 얼마나 최신이어야 하나?
- 평균 하루 한 번 정도
- 유행이나 신제품 출시의 경우 더 자주 반영 -> 하루 n번
- 실시간은 필요 x
해당 내용을 바탕으로 한 설계 방식
- 오프라인 배치 프로세스 도입
  - 주기적으로 실행되며 DB 갱신
  - 품목별로 세분화한 데이터를 웹 서버로 전달
탑 셀러가 된다는 것의 정확한 뜻은?
얼마 동안 시간대를 토대로 탑 셀러를 계산하는지?
- 전체 역사 기준으로 최고 판매량 서적 산출시 해리포터, 성경 등 고전만 나올 것임 -> 고객은 별로 흥미 없음
- 현재 유행, 인기 품목 알기 원함
지난 2주간 최고 판매량 품목 등으로 제한한다면?
- 안 유명한 품목 계산시 2주간 매출 없다면 의미 있는 결과 도출 어려움
품목 개수에 최소한의 임곗값을 부여해서 기간 거슬러 올라가는 방식?
- 현재 유행/인기 품목을 보여줄때, 어제 산거랑 5년전 산거랑 중요성(weight)이 다름 -> 모든 판매 내역에서 시간에 따라 가중치를 조절
어느 정도 규모?
- 초당 수천 번의 트랜잭션
- 각 카테고리 품목 페이지마다 + 홈화면에 표시

시간에 따른 가중치 조절 부분
- 최근 구매 > 과거 구매
- exponential decay 형태 => $e^{\lambda t}$
- t = 구매 이후 경과한 시간
- $\lambda$ = 붕괴율(하이퍼 파라미터)

상품 ID, 카테고리, 구매일자
데이터 웨어하우스 또는 데이터 레이크에 저장
- 바로 쿼리하면 시스템 마비될 수 있음
- 필요한 데이터가 품목 별로 분할 및 저장되는 데이터 레이크
- 대규모 SQL 쿼리 -> Athena, Redshift cluster

항목의 다양성과 방대한 규모로 인해 데이터 분석이 어려움
잘 확장되는 시스템 필요
- 아파치 스파크 -> 다중설계, 프로세스를 전체 클러스터에 걸쳐 분산 가능, 데크 모니터링, 스케줄링 제공
- 지수함수성 붕괴의 경우 단순한 SQL 쿼리로 해결 어려움
- 스파크의 유연성 -> 클러스터 유지 감수할 가치 있음
- 일래스틱 맵리듀스 -> 유지 보수 절감 가능
스파크의 기능
- 모든 구매 내역 추출 - 품목 ID, 품목의 항목, 구매 시점
- 작업 순서: 모든 항목별 분류 - 각 항목별 구매 조회 - 지수함수성 붕괴 적용 - 품목별 점수 집계 - 품목 총점 토대로 항목 분류 - DB에 결과 저장
데이터 저장 방식
- 상위 100개만 각 제품 항목에 저장
- 서버 1개 + 백업용 예비 서버
요청 처리 방식
- 초당 수천건의 request 발생 -> 서버와 DB 사이에 캐싱 서비스 필요(웜 캐시)
- 캐시 처음 시작할 때 접근량 많음 -> scalable힌 서비스 필요
- <key, value> => <category id, to item's ids>의 NoSQL(다이나모DB 등) 사용

하이퍼 파라미터
- 모델링을 위해 설정해주는 값
- 이 값에 의해 동일한 input이 들어와도 output이 달라질 수 있음.
웜 캐시 vs 콜드 캐시
- 콜드 캐시 - 아무 데이터도 저장되어 있지 않은 상태, 캐시 미스로 데이터베이스 직접 접근해야 함
- 웜 캐시 - 데이터가 저장되어 있어서 사용자 요청시 캐싱된 데이터를 바로 사용 가능
아마존 Athena
- 표준 SQL을 사용하는 Amazon S3용 대화식 쿼리 서비스
아마존 Redshift
- 페타 바이트급 데이터 웨어하우스 서비스
- 기존의 웨어하우징 솔루션보다 빠르고 안전하고 저렴(하다고 함)

Amazon Redshift
구조화된 데이터 모델 제공
데이터 저장하기 전에 전처리 필요
- 어떤 데이터를 포함할지 결정 -> 쓰기 스키마(schema on write)
- 전처리 과정이 오래 걸리고, 즉시 데이터 수집이 어려움
사용자: 정기적인 보고에 어떤 데이터가 필요한지 미리 알고 있는 비즈니스 애널리스트와 다른 비즈니스 사용자
고비용