[ 마이 뮤직 테이스트 ] Case Study 4. 데이터 파이프라인 케이스 스터디

 

 

1. 마이 뮤직 테이스트 ?

---

좋아하는 아티스트의 공연을 팬들의 도시에서 직접 말들 수 있는 기회를 제공한다는 아이디어에서 출발한 회사이며,

 

팬들에게는 원하는 아티스트의 콘서트를, 아티스트에게는 다양한 콘서트의 기회를 그리고 프로모터에겐느 안정적인 수익구조와 지속적인 콘서트 기획의 기회를 제공,

 

각 아티스트 별 전 세계 콘서트 수요를 실시간으로 확인할 수 있는 데이터 기반의 콘서트 메이킹 플랫폼이다.

 

 

 

2. 파이프라인 구축 동기

---

• 마뮤테에서 진행하는 공연의 수가 늘어남에 따라 분석해야되는 공연의 수가 크게 증가
• 모델 구축을 위한 연구 개발시간이 줄어, 분석을 제 시간에 하지 못하는 결과 초래
• 데이터 엔지니어 팀은 효율적으로 시간을 활용하여 모델 연구 개발에 매진하고, real-time 으로 판매량 예측 데이터를 쉽고 편리하게 확인할 수 있는 환경을 조성하기 위해

 

 

 

 

3. 파이프라인 구조

---

• 하루에 한 번 설정한 시간에 ‘Cloud Scheduler’ 실행 → ‘Pub/Sub’에 메세지 전송
• ‘Pub/Sub’에 설정된 값을 기반으로 ‘Cloud Functions’ 실행
• ‘Cloud Functions’(서버리스 컴퓨팅 서비스, 구글 lambda와 비슷) 에 설정된 값을 기반으로 ‘Compute Engine’(Analysis Server) 실행
• ‘Compute Engine’(Analysis Server)에서 ‘BigQuery’(Data Source)와 ‘Github(Source Code)’를 기반으로 분석 실행
• 분석이 완료되면 분석 결과 값은 ‘BigQuery’(Analysis Result)로 보내고, ‘Pub/Sub’에 ‘Compute Engine’(Analysis Server)의 정보를 메세지로 보냄
• ‘Pub/Sub’ 설정된 값을 기반으로 ‘Cloud Function’ 실행, ‘Compute Engine’ 종료

 

 

 

4. 기존의 파이프라인 비교시 변경 사항

---

1) composer 를 scheduler 로 변경

마뮤테 파이프라인의 경우 단일 job 만 작동되는 간단한 구조라 job 사이 상호의존성(interdependency) 가 필요한 composer 보다는 scheduler 를 사용하는 것으로 수정함

 

 

2) pub/sub 추가

상세한 로그 기록을 할 수 있고, 안정적으로 데이터를 끌어오는데 특화,

즉 아파치 카프카와 같은 역할을 하는 것으로 생각하면 된다.

 

 

3) stack driver 통한 로그 기록

별도의 소스코드 없이 모니터링 탭을 통해 편리하게 VM 이상작동 탐지 가능, 적은 수의 인원이 쉽고 간편하게 유지보수하기 위해 복잡도가 낮은 인프라 구축 필요해서 선택

 

 

 

 

 

5. 스터디 케이스 연구사항

---

1) 왜 gcp 를 선택했을까?

해당 부분은 아래의 링크를 참고하면 어느정도는 추측할 수 있을 듯 하다.

 

1-1. 분석 및 머신 러닝을 위한 최적화된 옵션 제공

마뮤테의 경우에는 ‘Make’ 라는 공연 수요 파악을 통해 공연을 기획해 티켓 판매하는 비즈니스 모델을 가지고 있다. 사전에 머신러닝으로 콘서트 티켓 판매량을 예측해야되기 때문에 머신러닝에 대한 최적화된 옵션을 제공하는 서비스를 사용하는 것이 좋을 수 있다. Gcp 는 분석 및 머신러닝에 대한 많은 투자를 해오고 있으며, 머신러닝을 위한 최적의 옵션을 제공하고 있다.

 

 

 

1-2. 구축과 관리에 용이하다

Aws 의 경우 매우 광범위한 서비스 때문에 서비스에 대한 파악과 관리가 매우 힘들며, Azure 의 경우에는 신뢰성있는 구현을 위해서는 고급 전문 지식이 필요하다. 반면에 gcp 는 서비스가 광범위하지 않고 쉽게 다룰 수 있기 때문에 적은 인력으로 운영되는 스타트업에서 쉽게 접근할 수가 있는 것 같다,

 

 

 

 

 

2) 파이프라인의 구조에 대해서?

2-1. 파이프라인의 구조가 간단하다

회사의 비즈니스 구조를 생각해보면 의외로 복잡한 파이프라인은 필요가 없을 것 같다. ‘Make’ 라는 공연 수요 파악을 통해 공연을 기획해 티켓 판매하는 것이 회사의 주요 비즈니스 모델이다.

 

각 지역, 나라별 포인트가 일정수준을 넘을 경우에 공연을 제안하는 구조이기 때문에 생각보다 많은 데이터 지표들을 수집하지 않아도 될 듯하다. 그러기 때문에 정기적인 배치 프로세스로 데이터를 수집/적재하고 로그들을 수집하면 되기에 다른 큰 회사들처럼 복잡한 파이프라인은 필요하지 않을 듯하다.

 

 

 

2-2. 해당 파이프라인의 구조는 효율적일까?

글쓴이가 stackdriver 서비스 도입이유를 설명하면서, 아래와 같이 말했다.

“적은 수의 인원이 쉽고, 간편하게 유지보수를 하기 위해서는 복잡도가 낮은 인프라 구축이 필요했고, 이에 따라 Stackdriver를 활용하는 것으로 변경…”

위 워딩을 고려했을 때, 쉬운 관리를 위해서 간편하게 유지보수가 가능하고 복잡도가 낮은 인프라를 구축한 것이 아닐까라는 생각을 한다.

 

 

 

 

6. 참고 링크

---

https://www.bespinglobal.com/stackdriver-gcp-monitoring-20180813/

Stackdriver를 이용한 GCP의 로깅 및 모니터링 소개 - BESPINGLOBAL

https://moondol-ai.tistory.com/184

AWS vs MS Azure vs GCP 장단점 비교!

https://cloud.google.com/functions/docs/concepts/overview?hl=ko 

Cloud Functions 개요  |  Cloud Functions 문서  |  Google Cloud