시스템 디자인 및 디자인
목적 : 기업의 비즈니스 모델에 효율적인 아키텍처를 고안하기 위한 능력 배양
목차
1. 확장 가능한 시스템 설계
2. 알고리즘과 데이터 구조
3. 빅데이터를 활용한 작업
4. 설계 인터뷰 전략
5. 모의 설계 인터뷰
7. 일반적인 기술 인터뷰 팁
ref)
http://media.sundog-soft.com/SystemDesign/SystemDesign.pdf
1. Design a URL shortening service
URL 단축서비스
URL의 길이 제한은 어떻게 되는가?
- 고객 경험으로 , url을 충분히 외울 수 있도록 한다.
- 6글자로 제한하고 A-Z,0-9 (36개) 까지의 문자열을 가지게 한다.
- 6글자 + 각자리수 마다 36개 => 21억 개 정도
URL을 삭제하거나 편집이 가능한가 ?
URL이 영원히 지속되어야 하는가 ?
고민)
어떤 유료화 정책을 가져가야 하는가?
- * URL Report 서비스 ( click counter )
Single server 의 평균적인 SLA은 어떻게 되는가?
DB의 CAP
- MySQL 로 구성 > BTree 인덱스의 성능으로 Read/Write > Shared 이후의 성능
- Mongo Cluster 로 구성 > Shared 필요성 ? > Shared 이후의 성능
SystemDesign 의 SLA
(Scale) 하루에 몇명의 고객이 서비스를 사용하는가 ?
- * 초당 1개의 신규 URL 이 발생한다고 가정 > 년간 31,536,000 개 ( 10년 동안 글자수는 걱정 없다. )
- * 초당 10개의 URL 읽기가 발생한다고 가정
(Latency) SLA을 정의하고 싶은데 스트레스 테스트를 거쳐야 하는가 ?
- 미리 예측을 해볼 순 없나 ..
(Availability) 가용성
- 단일 장애점을 제거 한다. ( WebServer * 2 + DB Replica 구성 )
답안 예시
1.API 에 대한 설계 먼저
- 로그인 시스템도 설계 해야 하는가 ?
- 이미 사용중인 짧은 URL인 경우는
- Base36 인코딩으로 변환하자.
* 0...99...1293...14441 등 id 값이 증가하는데, 36진수로 0-9a-z로 매핑하는 것
* 해시 충돌을 제거할 수 있다.
결과 : 6개 Restfull api : 생성, 재생성, 업데이트, 삭제, 읽기, 리다이렉트
2. 시스템 디자인
- 로드벨런싱 효과가 있는 DNS 사용 하여, Geo(위치)기반 라우팅을 사용한다.
- 확장가능한 DB솔루션으로 NoSQL 종류를 사용
- 한번 지정된 URL은 잘 변경이 안되어 캐시를 db앞단에 둔다.
3. DB Table 스키마
- ID , Short URL, Long URL, UserID
- index : Short URL, Long URL
4. Redirect Cod e
301 : 영구 경로 재지정 ( 브라우저 캐시됨 )
302 : 임시 경로 재지정 ( 브라우저 캐시 X )
ㄴURL 편집 고려, 분석 기능 고려해서 매번 서버에 요청이 더 낫다.
404 : NOT FOUND
Good point
- 단방향 소통이 아닌, 양방향 소통
- 고객 경험을 바탕으로 시스템을 디자인
- 해당 서비스에서는 API 가 운영에 중요 > API 정의로 부터 시작
- 면접관의 피드백,비판을 수용 > 시스템 디자인에 반영
- 보안/가용성/스케일링에 대한 우려
2. Design a reserveration service
고객경험기반 요구사항 정의
- 여러곳의 식당인가?
- 실시간 예약 상황을 중계해야 하는가 ?
- 예약 후 SMS 알림, 취소 변경도 가능 ?
- 고객은 식당과 예약자 둘 모두 , 각 분석 서비스 제공 ?
- 안정성을 중심 ( 수천개의 식당 + 수십만의 고객 )
고민)
테이블
- 고객(일반 유저 ,식당 오너) : userId, userType
- 매장 테이블 : storeId, storeInfo, ownerId
- 예약 테이블 시간대별 캘린더 : datetime, storeId, userId
놓쳤던 포인트
** 고객 시나리오를 먼저 설명하면서, 요구사항을 구체화 및 제약한다.
** 고객 경험 및 니즈을 충분히 반영한 테이블 필드를 구성하고 근거를 설명
** DB > 위치 정보 필드 필요!
** 자주 변경되지 않은 비즈니스 포인트를 찾아, 캐싱 처리
답안 예시
고객 테이블 : SMS을 보낼 연락처, 근처 가까운 위치의 선호하는 식당 검색을 위한 필드
식당 테이블 : 테이블 수 정보, 워크업 홀드백, 영업시간, 주소(위치)
예약 테이블 :
- 타임슬롯 필드 > 식당에 빈 예약시간을 빠르게 검색할 수 있는 알고리즘을 넣을 수 있음
- 파티 사이즈과 식당 테이블 수 고려
수평확장된 NoSQL MongoDB 등을 사용
- 안정성 속도가 중요하다 > CAP 이론에서 어느정도의 일관성을 포기 > 카산드라 로 변경 가능
3. Design a web crawler service
- 수십억개의 웹 페이지를 크롤링
- 매주 업데이트가 되어야 한다. / 업데이트 여부를 판단 해야 함
- 웹페이지의 복사본 HTML 을 저장 / 동적콘텐츠는 아직 고려 X / 목적 : 검색엔진
고민)
- 사이트 맵 저장 > 크롤링 해야할 페이지들 프로듀서 노드
- * 업데이트 여부를 조회하여 필터링
- HTML 리소스를 실제 수집하는 잡을 수행하는 노드들
- 잡 분산을 수행하는 로드 밸런서 노드
놓쳤던 포인트
- ** 수행할 작업(웹)에 대한 모델링 및 알고리즘을 고려하지 못했다.
- ** 의미있는 서비스 단위로 분리하면 좋다.
eg) 크롤링할 URL 큐 서비스는 따로 분리
eg) Paeg donwloader 분산 Job처리는 하이레벨에서 하나의 서비스로 추상화 함
답안 예시
- 웹사이트 + Link 구조 > Graph Model
- Search : BFS로 제한
1.초기 url 입력 : 사이트맵 제출 등
2.큐 : 크롤링할 대상의 url를 큐에서 관리
- 큐는 분산연결리스트 : url크기 밎 양에 대한 예측 어려워 동적 메모리 할당 가능한 구조
3.페이지 다운로더 : HTML 정적리소스를 다운로드하여 스토리지에 저장
4.분산저장소 : S3, Google Storage
5. URL 추출 및 정규화 : 정규화(http/https, url parser)
6. URL filter, stoplist : 악성코드, 금지콘텐츠 등 필터링 + 블랙리스트
7. Content hashes : 다운로드 후 해쉬값 비교로 업데이트 여부 판단
8. URL's processed : 이미 처리된 URL은 또 큐에 넣지 않도록 하기 위한 NoSQL
Q. 클라이언트 사이드 랜더링은 어떻게 처리하는가 ?
URL 추출 및 정규화 컴포넌트에서 담당하도록 한다. 다운로드 받은 URL를 토대로 브라우저에 랜더링 시켜보아 이 과정에서 URL이 생성되는지 확인한다.
Q. 페이지 다운로더에서 너무 많은 페이지를 한번에 읽지 않도록 지연을 주고 싶다면 ?
- 동일한 도메인 하위의 페이지를 동일 스레드에서 실행시켜, 페이지간 수집에 지연시간을 준다.
4. Design a top seller service
질문하기 ( 요구사항 구체화 및 제약 )
다수의 이커스 사이트를 대상으로 하는가 ? - O
카테고리별로 세분화가 되어야 하는가? - O
*카테고리별 구분 및 하위 항목으로도 구분이 필요할 수 있다.
얼마나 빠르게 업데이트 진행되어야 하는가 ?
*실시간 업데이트까지는 필요없다만, 하루에 수차례는 필요
*그렇다면 오프라인 배치 프로세스를 도입할 수 있음.
탑셀러의 기준을 어떻게 잡을것 인가?
*전체 기간을 기준으로 잡으면 성경, 헤리포터 와 같은 고전명작이 탑셀러가 될 것이다.
*그럼 최신의 트랜드를 반영한 지난 2주 동안의 최고 판매량 품목으로 제한
*하지만 2주동안 구매내역이 없는경우가 있다, 그럼 4주동안의 판매량을 보고 낮은 스코어링을 하자.
고민하기
어떤 고객경험을 주기 위함인가?
- * 가격대비 성능이 좋은 제품이며, 사람들의 수요가 있는 제품들을 큐레이션 해준다.
- * 고객이 직접 여러 제품들의 리뷰들을 보고, 비교하며 구매의사결정에 드는 비용을 절감
가정) 웹페이지 마다 제품들의 구매수 미공개, 리뷰수는 공개
- 리뷰 개수의 변화로 , 구매수를 추정해야 한다 ??
- API제공 없이, 페이지를 크롤링해서 리뷰수, 리뷰코멘트를 가져와야 하는가 ??
고객의 니즈 정의 : 새로운 유행을 빠르게 확인하고 싶다.
- 지수 가중치를 주는 수식을 도입, 구매 경과 시간이 작을수록 높은 스코어를 부여
5. Design a videos sharing service
대규모 환경에서 비디오 업로드와 재생을 다뤄야 한다.
- 비용절감측면에서 고민을 해보자.
1. Youtube 설계 같은 모호한 질문 > 특정 서비스를 분리할 수 있는지 판단
2. CDN에 대한 효과적인 비용 통제 방법을 떠올림
3. 메시지 큐, NoSQL, 머신러닝 솔루션 등 고려
6. Design a search engine service
앞에서 크롤러를 만들었다는 가정에서 출발한다. ( 페이지에 대한 분산 데이터 저장소가 이미 있다. )
- 합리적인 검색 결과를 생성하는데 초점을 두자 ( 스케일 측면을 고려 )
알고리즘 생각 TF-IDF 의 문제
- 1. 키워드 갯수로만 문서를 고르기에는 단순하다. 더 정교한 알고리즘이 필요
- 2. 모든 문서를 수집해야 모집단 대비 단어 빈도수를 알 수 있다. -> feasibility check fail
역색인 필요 : 키워드를 입력 --> 여러 정렬된 문서들을 획득
'SystemDesign' 카테고리의 다른 글
[시스템디자인&인터뷰] 6. 일반적인 기술 인터뷰 팁 (0) | 2023.04.16 |
---|---|
프런트엔드 아키텍처 (0) | 2023.04.13 |
[시스템디자인&인터뷰] 4. 설계 인터뷰 전략 (0) | 2023.03.23 |
[시스템디자인&인터뷰] 3. 빅데이터를 활용한 작업 (0) | 2023.03.17 |
[시스템디자인&인터뷰] 2. 알고리즘과 데이터 구조 (0) | 2023.03.16 |