시스템 디자인 공략법

educative 의 시스템 디자인 인터뷰 가이드를 번역한 글 이다.

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

• 질의를 통해 요구사항을 파악한다. 디자인 질문은 정답이 없다.
• 최종 산출물을 선명히 도출해내기 위한 질문에 공을 많이 들이면 인터뷰를 성공적으로 진행할 가능성이 높아진다.
• 따라서 질의를 통해 면접관이 제시한(?) 시스템이 어떤 점에 포커싱 하고 있는지를 명확히 해야한다.

tweet like system

아래와 같은 질문을 할 수 있다.

• 사용자가 트윗을 포스팅 하고 다른 사람을 follow 할 수 있나요?
• 사용자의 타임라인을 생성하고 표시 해 줘야 하나요?
• 트윗에 사진과 비디오가 포함 되어 있나요?
• 백엔드만 개발? 프론트엔드 까지?
• 유저가 트윗을 검색 할 수 있나요?
• 인기 있는 토픽을 표시해 줘야 하나요?

2. 개략적 설계안 제시(Back of the envelop estimation)

• 시스템의 스케일을 간단하게 계산해 본다면 나중에 스케일링, 파티셔닝, 로드밸런싱, 캐싱 할 때 유용하다.
• 시스템에서 예상되는 규모 산정

tweet like system

• 새 트윗의 개수, 트윗 뷰 개수, 초당 타임라인 생성 개수
• 저장소 용량은 얼마나 필요한가? tweet에 이미지, 비디오 포함 여부에 따라 저장소의 종류가 달라진다.
• 예상 Network Bandwidth는 어떻게 되나? 이것은 트래픽 관리와 부하를 조절하는 데 중요하다.

3. 인터페이스 정의

• 시스템에 어떤 api가 필요할까?
• 시스템에서 예상되는 API를 정의합니다. 이렇게 하면 시스템에서 예상되는 정확한 계약이 설정되고 요구 사항이 잘못되지 않았는지 확인할 수 있습니다.

tweet like system

• postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, …)  
  generateTimeline(user_id, current_time, user_location, …)  
  markTweetFavorite(user_id, tweet_id, timestamp, …)  

4. 데이터 모델 정하기

• 데이터 모델을 인터뷰초기에 정하면 데이터가 시스템 컴포넌트 간에 어떻게 전달될 지 명확해 진다.
• 데이터 모델이 정해지면 그것을 토대로 데이터 파티셔닝과 관리를 정하게 된다.
• 다양한 system entity와 서로간에 어떻게 상호작용 하는 지, storage, transportation, encryption 등 data management사이의 다른 면 에 대하여 인지(식별? 원문은 identify) 해야 한다.

tweet like system

User: UserID, Name, Email, DoB, CreationDate, LastLogin, etc.
Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc.
UserFollow: UserID1, UserID2
FavoriteTweets: UserID, TweetID, TimeStamp

어떤 종류의 디비가 적당할까? NoSQL? RDB? 사진이나 비디오를 저장 하기 위해선 어떤 block storage를 사용 하는것이 좋을까?

5. 고차원 디자인

우리 설계안의 각 컴포넌트를 block diagram으로 그려보자. 요청이 왔을 때 부터 응답 할 때 까지 필요한 모든 컴포넌트를 그려넣도록 노력해보자.

tweet like system

• 모든 read/write 요청을 처리 할 부하 분산용 load balancer와 여러 대의 application server가 필요 하다.
• 만약 read traffic이 더 많다고 가정 한다면 이를 위해 서버를 늘리는 방법을 선택할 수 있다.
• 백엔드 에는 모든 트윗을 저장하고 많은 양의 read 연산을 처리할 수 있는 데이터베이스가 필요하다.
• 사진과 비디오 저장을 위한 분산 파일 저장 시스템도 필요하다.

6. 설계 구체화

• 2~3개의 메이저 컴포넌트를 상세 설계 한다. interviewer는 앞서 우리의 대략적인 설계안을 듣고 우리 설계안 중 어느 부분을 설계할 지 정해준다.
• 우리는 여러 접근 법과 그 접근법의 장단점을 제시 하고 그 중 어떤 접근법을 사용 할 지 정해야 한다.
• 여러 가지 정답이 있을 수 있기 때문에 시스템 제약사항을 생각하며 서로 다른 대안의 tradeoff를 고려해야 한다.

tweet like system

• 방대한 양의 데이터를 저장 해야 하기 때문에 우리의 데이터를 어떻게 분산 하여 저장할 것인가 에 대해 생각 해야 한다. 모든 데이터를 한 데이터베이스에 저장 하면 어떤 일이 일어날까?
• follower가 많은 인기 유저 or 트윗을 많이 하는 heavy user 는 어떻게 관리 할 것인가?
• user의 timeline은 최근 (혹은 관련된) 트윗들을 포함할텐데, 이를 위해 최근 트윗의 저장 방식을 최적화 해야 할까?
• 속도를 높이기 위해서 캐시를 얼마나, 어느 계층에 둬야 할까?
• 더 나은 로드밸런싱이 필요한 요소는 무엇일까?

7. bottleneck 구간 확인 하고 해결 하기

• bottleneck이 발생할 만한 구간을 모두 찾아 내고 bottleneck를 완화시킬 만한 서로 다른 솔루션을 내자
• SPOF(Single point of failure)가 있나? 해결하기 위해 어떤 방법을 사용 해야 할까?
• 서버(디비?)가 망가졌을 때 문제 없이 서비스 할 수 있도록 데이터에 대해 충분한 replica가 있나?
• 마찬가지로, 몇 가지 오류로 인해 전체 시스템이 종료되지 않도록 실행 중인 여러 서비스의 복사본이 충분한가?
• 서비스의 퍼포먼스를 어떻게 모니터링하고 있나? 중요한 구성 요소에 장애가 발생하거나 성능이 저하될 때마다 경고를 받고 있나?

결론

• System Design Interview는 준비를 잘 하고 익숙해지는 것이 가장 중요하다.
• 시스템 디자인을 할 떄 위에 설명한 1~7단계를 잘 따르면 주제에 벗어나지 않고 다양한 면을 고려한 설계를 할 수 있을 것이다.