스타트업, 빅데이터 처리를 어떻게 고려해야 할까.
스타트업을 하기전, 나는 백엔드에서 시작해 풀스택 개발자로 약 5년 정도 지내왔다. 그간 많은 언어와 웹 프레임워크를 다뤄왔고, 특히 데이터에 있어서는 Oracle DB, MySQL, MSSQL, MariaDB, H2 정도를 다뤄봤는데 개인적으로 NoSQL은 별로 좋아하지 않는터라 그렇게나 유행하던 MongoDB는 간단히 접하기만 하고 사용하지는 않았다. 새로운 개념을 익히기도 사실 번거롭고, RDB의 강력한 ACID가 실상 웹에서는 가장 중요한 신뢰의 요소로 작용한다는 것을 수차례의 프로젝트를 통해 경험했기 때문이다.
허나 이번 내가 진행하는 스타트업인 유라임 프로젝트에서는 얘기가 다르다. 간단히 내 프로젝트를 얘기하면, Wearable/IoT/SNS등에서 오는 데이터를 사용자의 플랜과 연계해서 분석해주는 웹 프로그램이다. 백엔드는 Play! Framework/Scala/Slick등을 사용했고 프론트는 AngularJS/NodeJS/Express 정도를 사용했다. DB는 수년간 써와도 개인적으로 만족하는 MySQL 5.6을 사용했고, 이 모든 것들을 Google Cloud에 올렸고, Docker/Kubernetes기반으로 Orchestrization 및 load balancing하게 처리해두었다.
이 과정에서 C.D나 C.I 외에 빠진 것이 무엇일까? 다름아닌 요즘 그렇게나 핫하다는 빅데이터 처리이다. 사실 빅데이터라는게 나랑은 별 상관없는 문제라 생각했는데, 나도 각종 벤더들의 API를 가져오는지라 만약 나같이 다수의 Wearable를 사용하는 유저라면 Plan에 따라 하루에도 자동 취합되는 데이터가 아직 몇개 통합 안했는데도 약 30 rows정도 된다. 얼마 아닌것처럼 보여도 한달이면 1User = 900 rows, 유저가 1000명만 되어도 한달에 90만 rows가 쌓이게 되는 것이다. 데이터도 데이터이지만, 뭔가 인덱싱 기준도 애매해서 나중에 searching에 있어서 얼마나 많은 수의 연산이 일어날지 벌써부터 걱정이 되더라. 예전에는 은행권 데이터 몇백만 유저도 다뤄봤지만, 오라클 DB를 이중화 및 일일백업 해서 사용해서 크게 걱정은 없었는데 (오라클이라는 신뢰 덕분일까..) 내 스타트업에서 처음부터 끝까지 유저의 데이터를 모두 다 다뤄야 하는 입장에서는 솔직히 빅데이터에 대한 어느정도의 대비를 해야겠다고 생각했다. (마침 작년에 하둡 에코시스템도 몇번 다뤄봤겠다...!!)
하둡 생태계 넘나 복잡한것.클라우드에서 빅데이터 처리를 위한 삽질
그래서 살짝 삽질을 해봤다. NoSQL로 가려고, 빅데이터를 분석하려고 뭐 하둡이니 Spark니 이런 것들을 알아보기 시작했다. 내가 딱 원하는 기능은, 1) OpenAPI들에서 데이터 취합 2) 1일 2회 Batch돌며 데이터 분석 후 결과 다른 테이블에 저장. 이 정도이다. 사실 빅데이터 처리라고 하기도 뭐하긴 한데, 어쨌든간에 뭔가 데이터가 막 100만건씩 쌓이고 하면 분석도 힘들지 않을까 라는 생각도 들고, 뭔가 기준을 정해서 맵리듀스로 축소해놓은 데이터가 필요하다는 생각도 들고, 배치도 어떻게든 돌리긴 해야 하니깐 이건 또 어떻게 해야할지 감이 안오고 (그냥 Spark가 정답이구나 라고 처음엔 생각했다.)...
시간도 없고 해서 On-demand가 아닌 클라우드를 생각했다. 내가 주로 구글 클라우드를 사용하기 떄문에 살펴보니, DataProc, DataFlow 와 같은 빅데이터 통합 솔루션 비슷한 것들이 있고, BigTable이라고 NoSQL이 있더라. 처음에 이리저리 삽질해서 오 그래, DataProc라는게 Spark의 master/worker를 쉽게 만들어주는구나.. Big Table이란게 NoSQL이고 노드가 여러개 관리되는구나.. 이런 것들을 열심히 배우던 찰나에 "아, 내가 지금 무얼 하는거지?" 라는 생각이 들었다.
뭔가 이상적(?) 이었던 유라임의 빅데이터 처리 구조빅데이터 처리가 정말로 필요한가?
이런 생각이 든 이유는 단순하다. 첫째는 "돈"이다. 아직 데이터가 당장 있는 것도 아닌데도 불구하고 "노파심" 혹은 서비스가 커질 때를 대비해서 (...) 등등의 오만가지 이유때문에 구태어 돈을 들여서, "분 단위 과금"에 현혹되서 뭔가 싸보여서, 뭔가 fault-tolerance하고 reliable하고, 뭔가 원클릭 만으로 이리저리 쉽게 설치해주는 것 같아서 등등의 이유때문에 GCP에 설치를 하려고 시도했다. 정말 바보같은 짓이다. 예전에도 Docker/Kubernetes에 대한 이해가 제대로 되지도 않은 상태에서 괜히 인스턴스만 만들어 뒀다가 비싸진 않지만 한달 $50을 3개월 정도 날려먹었다. 러닝커브를 위한 교육비로 생각할 수도 있겠지만, 내가 이를 접게 만든 가장 큰 원인은 BigTable이라는 GCP의 제품덕분이다. 시간당 $1.97을 과금한다는데, 1개월 24시간씩 쓴다 하면 뭔 $1,418이 나온다. 응? 분명 홈페이지에는 싸고 빠르고 이렇게 나왔는데.. 회사에 돈이 없는 건 아니지만 저건 러닝커브를 위한 교육비로 쓰기에는 너무나도 비싸기도 하고, BigTable이 정말로 좋은지에 대한 일차적인 테스트 하나 없이 이를 쓰려고 한다는 것은 분명 잘못된 것이라고 생각했다.
Google Cloud Bigtable, HBase기반, 비싸지만 매우 빠르다.두번째로, 내가 너무 하둡, 스파크, 빅데이터.. 이런 뭔가 멋져보이는, 트랜디한 것들에 현혹된 것은 아닐까, 정말 냉정하게 생각을 해보게 되었다. 내가 왜 NoSQL을 사용해야 하는지를 냉정하게 판단해 보았다. 위에서 언급한 90만 rows에 대해, 만약 RDB로 쓴다면 1 rows당 대략 0.1KB정도라 친다면 (내 테이블의 경우) 900,000 이면 87.8MB, 이렇게 1년이 지나면 약 1GB. GCP 에서 정도의 차이는 있겠지만 적당한 서버(n-standard-1) 1대에 MySQL 2nd 에 10GB로 한달 24시간 풀가동을 하면 약 $100 정도가 나온다. 물론 레플리카 넣고 하면 또 fallover서버 추가되고 그러면 배로 늘겠지만, 어쨌든간에 위에보다는 싸다. 그리고 사용 용량에 따라 과금되기 때문에 선점형 금액도 아니니, 훨씬 더 저렴하다. (아래: Google Cloud Platform Pricing Calculator 비교)
그래서 일단 나도 Google Cloud SQL을 실제로 사용중이니, 그냥 그대로 가기로 했다. 결국 굳이 NoSQL을 쓴다는 자체가 예전에 내가 ReactJS에 살짝 현혹되어 쓰려다가 포기한 것처럼, 그저 너도나도 쓰니깐 나도 흐름에 따라 가는 경우나 마찬가지였다. 물론 공부해 두고, 적용하면 얼마나 좋을까. 하지만 요즘에는 JPA나 뭐 스칼라에서는 Slick등이 아주 편안하게 RDB의 함수화(?)를 잘 실현해 주고 있어서 나름대로 잘 쓰고 있다. 사실 얼마전에 문득 본 MongoDB를 다루는 부분을 보니, Collection이나 이런 약간의 개념만 다를 뿐이지, 사용 방법은 여타 내가 JPA등에서 사용한 그것과는 크게 차이가 없는 것 같더라.
내게 맞는 빅데이터 처리에 대한 고민
사실 내 서비스의 몇몇 기본 기능을 끝내고 빅데이터 처리에 대해서 고민한지는 얼마 되지 않았다. 그래서 이리저리 만져보고 있긴 하다. 뭔가 데이터를 수집하는 의미에서 Streaming과 Batch가 있는 것은 알겠고, 내 서비스는 하루 2회 정도 유저의 데이터를 가져오면 되니깐 Batch가 적당하다. 그럼 이제 이 부분만 처리하면 된다. 사실, 어떻게 보면 유저마다 돌면서 데이터 보고 -> 가져오고 -> 비교하고 -> 분석하고 -> 결과를 저장하는 게 다이다. 그리고 나중에 프론트에서 가져다가 쓰는 것일 뿐. 일종의 프로세스는 일단 백엔드에 하드코딩 방식으로 구현해 두긴 했다.
그럼 남은건 이 나만의 빅데이터 처리 방식을 어떻게 배치로 만드느냐는 것이다. 자바로 스레드 써서 대충 12시간마다 돌려서 데몬으로 돌리는게 나을까, 아니면 Node로 간단한 REST만들어다가 백엔드 요청에 따라서 돌아가게 만들까 등등.. 어쨌든 그냥 인스턴스 하나 더 만들어다가, 혹은 Docker 컨테이너 하나 더 만들어다가 일단 돌리면 된다. 이게 돌리다가 만약 유저나 데이터가 너무 많으면, 분산 처리를 하면 되는데 이를 위한 방식은 아주 다양하다. 일단 나는 Docker와 Kubernetes기반으로 만들어 뒀으니 Replica가 이런 부분을 담당할 것이다. 점유율에 따라 확장하는 식으로.. 어차피 백엔드/프론트 모두 죄다 비동기 방식으로 처리해 두었으니 (심지어 JDBC까지도 비동기로....) Docker컨테이너와 Kubernetes를 통해 LoadBalancing IP하나 두고 외부 요청에 따라 비동기로 응답하는 방식으로 처리해도 괜찮을 것 같다. 아니면 아에 Actor모델 적용한 Akka 배치 하나를 만들어다가 (마침 Scala기도 하겠다.) Docker에다 넣어두고 처리해도 상관없겠다. 당연하지만, 어쨌든 빨리, 생각대로, 잘 만들면 되긴 하는거다.
어떻게 되던 간에, 어차피 하둡이나 스파크를 쓰나, 내가 구현을 하나 다 큰 틀은 비슷한 것 같다. 정말, 나만 그러는지는 모르겠지만 스타트업을 운영하면서, 특히 나는 풀스택으로 일을 하기 때문에 (지금은 혼자 개발을 한다.), 이곳 실리콘 벨리에 있다보면 수없이 많은 기술의 늪에 빠져 사는 것 같다. 이전 글(빠른개발vs미래대비 개발) 에서도 논했지만, 그런 기술 하나하나 다 적용하려다 보면 결국 스타트업에 있어서의 빠른 개발도 불가능 할 것이고, 개발이 산으로 갈 수도 있다. 이럴 때일수록 아버지의 명언이 생각난다. "선택과 집중" 그래, 아무리 내가 모르는 영역이라 하더라도, 일단은 내가 생각한 답으로 가는 것이다. 작년 말이면 이미 베타 오픈을 했어야 하는 이미 한참 늦은 시점에서, 나는 더 이상 신기술이나 다른 것들을 고민할 겨를이 없는 것 같다. 결론은, 스스로를 믿고, 오픈하고 보자.
by 메튜장 (matthew.chang@me.com)
