Spotify 시스템 디자인 분석

 

미디움의 기사를 읽고 시스템 디자인 겉햝기를 했다.

이번에 느끼게 된 거지만, SWE와 대화를 하면서 미국 회사 인터뷰는 항상 시스템 디자인이 필수인 것 같다.

게다가 mill/billions of users를 확보한 SaaS product 라면, 시스템이 어떻게 돌아가는지 알아야하는 것은 기본 중의 기본이다.

코더로서 개발을 하는 개발자와, 시스템의 전반적인 프로세스와 소프트웨어의 생명주기 전역에 있어 커버를 해야하는 SWE의 롤은 어떻게 보면 비슷하면서 참.. 다른 것 같다. 뭐가 얕고 깊다고는 말할 수 없지만... 코드 짜는게 좋으면 개발자, 시스템 디자인 및 UI/UX 까지 관여하려면 엔지니어가 좋은 것 같다.

 

이 시스템 디자인에는 4가지의 전제조건이 들어있다.

- 일단 유저는 이미 로그인을 한 상태로 가정했으며,

- 이미 수백만의 유저를 유치하고 있다.

- 디비도 이미 구조가 짜여졌으며,

- 유저가 음악을 재생할 때 시스템 디자인이 어떻게 되어있는지 해보기로 한다. 

 

로드 밸런서는, 운영체제의 OS와 같이 RR와 같은 기법을 사용하여 유저가 수백명인 앱의 경우에도 항시 트래픽이 원할할 수 있도록 유저의 리퀘스트가 발생하면 트래픽이 적은 서버로 유저 리퀘스트를 보내주어, 유저의 리퀘스트가 바로 서버로 가는 것이 아니라 로드 밸런서를 거쳐서 가는 것이다. 이에 따라 UX는 향상된다. 이것은 NGINX로 하게 된다.

 

Pub/Sub은, 매 밀리초마다 유저들의 재생 리퀘스트가 발생할텐데, 우리는 그럴때마다 데이터베이스에서 바로 유저의 리퀘스트대로 음악을 들려주기가 어려울 것이다. 따라서 유저들의 리퀘스트를 스택구조로 쌓아놨다가 순차적으로 처리하는 message queuing system을 사용하게 된다. 유명한 Pub/Sub로는 RabbitMQ, Apache Kafka가 있다.

 

App Server Producer /App Server Consumer는, 각각 생산자와 소비자로써 각각 publish(write), subscribe(read and process)를 한다. 서로 배타적인 관계다. 확장성을 위해 핵심 역할을 하는 애들이다.

 

Data Warehouse는, 데이터가 너무나도 방대할 때 쿼리들을 처리하기 위해 사용하는 것이다. 여러 머신들을 아울러서 task 분배가 가능하고 병렬 프로세싱을 한다. 하둡 Distributed File System이 그 예시다.

 

So... What Happens in the backend?

유저가 재생 버튼을 누르게 되면, 유저 리퀘스트가 로드 밸런서를 거쳐서 널널한 서버로 도착하게 되고, 그 리퀘스트는 스택으로 쌓여 Pub/Sub에서 실시간으로 처리된다. 그리고 다음에 비동기적으로, 두 개의 독립 사건들이 동시에 진행된다.

a.  Pub/Sub에서 데이터가 아티스트에게로 업데이트된다. 그래서 유저가 재생 버튼을 누를때마다(스트리밍을 할 때마다) 아티스트의 대시보드에는 실시간으로 카운트가 올라간다. Data Warehouse에서 계속 데이터를 끌어오는것보다 훨씬 가볍다.

b. 업데이트되는 사항들이 Data Warehouse에 반영된다.

 

 

 

 

from: https://bootcamp.uxdesign.cc/system-design-interview-prep-spotify-real-time-player-47aa5c24ae22