빅데이터를 하는 기업이 되려면.
2016년 12월 5일
오랜만에 일 관련 포스팅.
심심하면 빅데이터 빅데이터 어쩌고 하는데 빅데이터 하는 사람으로서 (생색 생색) 불편하기 짝이 없다. 이 말 여러 번 했지만
1) 꼭 "빅" 안 붙여도 되고
2) 데이터 엔지니어링 빼고는 사실 이전이랑 크게 변한 거 없고
3) 그냥 작은 데이터도 분석만 잘 하면 된다.
그냥 구글 검색 결과 캡쳐해서 "빅데이터 분석에 따르면 쩜쩜쩜" 이런 거 말고, 진짜 빅데이터 프로젝트 시작하겠다는 기업에서는 뭐뭐 커버하는지 간단 소개.
데이터 마이닝, 분석, 기계학습 모델링 이런 건 사실 다 데이터 유저들이다. 데이터를 누가 뽑아오면 그걸 가지고 인사이트를 발굴하고 우리가 나갈 방향을 제시하고 우주 저 너머 인류의 미래를 찾아내고 뭐 그런 모든 것이 데이터 유저들이고, 이건 이전에도 가능했다. 데이터 대량 처리가 힘들었던 거지, 분석 방법은 있었다. 이젠 분산 처리로 스케일 크게 할 수 있을 뿐인데, 기계학습/모델링 전문가면서 큰 스케일의 분산처리/데이터 엔지니어링 전문가이기도 한 사람 진짜 거의 없다. 그러니까 데이터 유저라고 해서 초보고 데이터 엔지니어링이라고 해서 깊숙이 들어가고 그런 거 전혀 아니다. 그냥 분야가 다르다. 꼭 따지자면 CJ푸드 같은데서 생산 공장 설비 쪽이랑, 시장 분석하고 제품 개발하는 쪽이 다른 그런 식으로 다르다.
그럼 데이터 엔지니어링 쪽을 좀 보자.
데이터 엔지니어링팀의 엔지니어들은 데이터 유저들이 쓰실 데이터를 생성하고 토스하고 캐치하고 다듬고 가지런히 정리해서 전문가님들이 분석할 수 있도록 해야 한다. 그리고 이걸 24/7 돌려야 한다. 이것이 데이터 엔지니어링 움파룸파의 존재 이유다. 보통 빅데이터 코스 이런 거 보면 데이터 구하기와 클리닝 어쩌고 있는데, 이건 시장에서 닭 사와서 다듬기부터 시작하는 거다. 데이터 움파룸파는 닭 키우기, 곧 양계장 설계부터 시작해야 한다.
자, 그럼 먼저 데이터 디자인과 SDK. 어떤 데이터를 어떻게 모을지 생각을 해야죠.
삼성이 사용자 데이터를 모은다고 생각해보자. 모으려면 모아서 보낼 툴이 있어야 하니까 SDK부터 만들어야 한다. 안드로이드 기반 OS에서 데이터 수집하는 표준 SDK를 만들어야겠지? 그러면 안드로이드에서 돌아가는 모든 앱이 쉽게 삼성 데이터 센터에다가 데이터를 보낼 수 있을 테니까. 그 SDK가 이미 쓰였다 가정하고(..라고 하기엔 이것 자체도 엄청난 부서간의 미팅과 조절과 기획을 필요로 하지만 뭐 어쨌든) 어떤 데이터를 언제 보낼 것인지 열심히 고민해야 한다. 물론 많이 많이 보내면 좋겠지만 개인 정보 보호도 고려해야 하고, 핸드폰 배터리도 고려해야 한다. 인터넷 연결 안 좋을 때, 배터리 조금밖에 안 남았을 때 억지로 데이터 다 보내는 것도 좋지 않으니까. 조금만 보낼 수 있다면 어떤 앱 데이터가 제일 중요하고 어떤 건 버려도 되는지도 결정해야 한다. 여러 팀이 있으면 데이터가 겹치기 마련이라서 안 그래도 소중한 데이터 밴드위스 낭비하지 않게 팀 간 조율 많이 해야 한다. 오오오 미팅미팅미팅. 으윽. 하지만 누구에게 언제 전화 걸었다가 중요한가요 어떤 앱을 몇 분 돌렸다 기록이 중요한가요 아님 사진 백업이 중요한가요. 이런 걸 안 정하고 그냥 내보내면 안 되죠.
어쨌든. 데이터를 뭘 언제 어떻게 보낼지 결정했다. 이 부분을 Telemetry design이라고 한다. 그리고 데이터가 다 안 오면 어떡하고 데이터 연결 안 좋은 곳에서 오는 데이터는 훨씬 적을 텐데 그럼 샘플 bias 들어가는 건 어쩌고 하는 어려운 문제는 우선 무시하자. 그냥 내 필요한 데이터는 다 온다고 생각하자. 그래도 데이터 퀄리티 체크는 해야겠죠. 데이터 보내는 중에 전화기 껐을 수도 있고 다시 전화기 켰을 때 데이터 안 보낸 거 한꺼번에 보내면 보낸 시간이 다르게 올 수도 있고, 의외로 시스템 시간이 잘못된 전화기도 많아서 clock skew, 타임스탬프 잘못된 것도 제대로 잡아야 하고... 뭐 어쨌든. Telemetry design했고, 그대로 디바이스에서 데이터 컬렉션하고, 그럭저럭 제대로 보낸다고 하자. 아참, 설마 텍스트로 보낼 생각은 아니었겠지?? 귀하고도 귀한 밴드위스를 설마 제이슨 스트링으로 낭비하는 간 큰 용자는 없으리라 믿고. 우리 팀의 경우는 데이터를 구글식 프로토버퍼 쓰다가 마소 고유 본드로 바꿨습니다 네.
자, 이제부터는 본격적인 데이터 컬렉션 인프라 문제다.
데이터가 왔는데 받을 사람이 없으면 안 되겠죠. 그리고 자리 비워도 안 되겠죠. 데이터 ingestion endpoint가 빵빵 돌아가야겠죠. 그러므로 수십 개 수백 개 수천 개의 서버가 대기하고 있다가 데이터 오면 날름 잡아서 저장해야 하는데 이게 말이 쉽지 초당 몇 천에서 크면 몇 백만의 데이터를 받아서 처리한다는 게, 그리고 그 시스템이 단 1초도 다운되면 안 되고 만약 서버 에러 있으면 어떻게 처리할 거고 복제 문제 생기면 안 되고 등등, 쉽지 않죠. 이 ingestion이 파이프라인의 첫 스텝이고, 그 다음에는 이 데이터 처리. 개인 정보 없애거나 해시하고, clock skew 있음 고치고, Geo info 넣고 (어느 나라에서 온 데이터인지), 혹시라도 데이터 quota 초과했음 throttle하고, 이 전체가 모니터링 되어야 한다.
그 다음부터 downstream. 받아서 기본 처리 된 데이터는 여기저기 갈 데가 많다. raw data로 저장되고 (이 역시 고유 ser-de(serialization, deserialization)를 쓰는 경우가 대부분. 우리 팀도 우리 팀 고유 serde 쓴다) 그 외 streaming data 프로세싱 하는 엔진 몇 군데로 가고, batch job 돌리는 엔진으로도 간다. 이 모든 걸 관장하는 config 시스템도 따로 있다. 사실 컨픽 관리 시스템 이거 하나만 해도 상당히 복잡하다. 유저들이 계속 고치는데, 그 컨픽에 따라서 데이터 처리가 달라지고, 처리하는 컴퓨터는 수천 개고, 그러면 한 번 업데 된 게 쫙 퍼져야 하는데 중간에 에러 나면 어쩔 것이며 etc etc.
뭐 어쨌든. 여기까지 오고 데이터 제대로 다 배달됐음 움파룸파 일은 끝. 여기부터 데이터 유저들이 데이터 픽업해서 뭘 하든지 열심히 하신다. 기계학습 모델을 만들든지, 로그가지고 디버깅을 하든지, 자기네 시스템 모니터링을 하든지 등등.
기계학습의 경우 도착한 데이터를 가지고 모델을 만드는 정적 케이스가 있고, 스트리밍 데이터 가지고 계속 변하는 경우가 있다. 정적인 경우는 한 달에 한 번 모델을 업데할 수도 있고 일 년에 한 번도 할 수 있다. 스트리밍 데이터가지고 복잡한 기계학습 하는 건 상당히 비싸기 때문에 아주 복잡한 건 하지 않는다.
그리고 시스템에 따라서 저 데이터 엔지니어링도 많이 달라진다. 구글이나 빙의 경우는 유저가 타이핑하면 곧바로 뭘 찾고 있는지 때려 맞춰야 하는데 나노 초 단위로 해야 한다. 대신 웹사이트 방문 분석 같은 경우는 리얼 타임까지는 필요 없을 수 있겠다. 리얼 타임이 좋긴 한데, 얼마나 리얼 타임이냐에 따라서 시스템 가격이 천문학적으로 올라간다. 하루 늦어도 괜찮다면 저렴이로 가능하고, 한 시간까지도 그럭저럭 괜찮다. 하지만 주식 시스템같이 밀리세컨드 레벨로 내려가면, 기능은 현저히 적어진다 하여도 엄청나게 비싸진다.
길어져서 여기서 잠깐 정리.
보통 빅데이터 파이프라인을 만드는 기업이라면 - 데이터 디자인하고, 아마도 SDK 만들어서 데이터 보낼 팀들에게 다 배포하고, 데이터 컬렉션 시스템을 만들고, 거기서 데이터 토스 받아서 데이터 가공 시스템도 돌리고, 다운 스트림 여러 가지로 서비스한다. 하둡 돌린다면 아마도 하이브/피그 껴서 배치 시스템. 트위터가 만든 스톰 이런 거면 리얼타임. 로그 뒤지는 거라면 스플렁크나 카프카. 그 외에 리얼타임 엄청 빠른 뭐 어쩌고 하는 거면, 빅데이터를 작은 데이터로 만드는 방법이 사실 정해져 있어서 - 샘플링, aggregate 데이터, 인메모리 DB로 돈지랄 혹은 데이터 기간을 아주 줄여서 가격 조절 및 빠른 쿼리, 그 외에 이 방법을 몇 개 섞은 짬뽕 기법. 어쨌든 기계학습이나 데이터 분석하시는 유저님께서 데이터 찾으실 즈음에는 다 모아서 정리 처리된 상태여야 한다. 여기까지가 데이터 엔지니어링이다(데이터 웨어하우스도 포함될 수도 있긴 한데 그 셋업은 보통 좀 다르니까 여기에서는 넘어가고).
보시다시피 작은 기업에서는 손대기 싫거나 귀찮은 부분 많다. 그래서 내가 데이터 쪽으로 들어가란 말을 안 한다. 우리 팀에서 지금 미는 제품이 바로 이렇게 귀찮은 데이터 파이프라인을 아웃소싱하는 건데, 우리만 이런 거 할 리가 없잖소. 딴 회사들도 비슷한 거 엄청 개발해서 쏟아내고 있다. 작은 회사까지 돌아갈 만한 하둡 엔지니어 / 데이터 파이프라인 만들 엔지니어 숫자가 안 되니까 지금 인력난인데 곧 상용화 솔루션을 해결될 거라는 말. 우린 SDK를 모든 언어/플랫폼으로 뿌리고, 유저는 보내기만 하면 데이터 컬렉션과 처리는 우리가 다 하고 나중에 다운스트림 데이터만 받아서 그걸 가지고 분석을 하든 그냥 저장을 하든 하면 된다. 오오 편해라. 이러면 데이터 관련 법규도 아웃소싱되고 빅데이터 엔지니어링 없이 빅데이터 사용이 가능해진다. 데이터 플랫폼을 서비스로 쉽게 이용할 수 있는 그 순간, 아마존 AWS가 그 수많은 시스애드민 자리를 잡아먹은 것처럼 데이터 엔지니어링도 비슷해진다. 내년, 내후년 정도면 평정될 듯.
우리 팀 내년에 공개 서비스로 나갈 듯합니다. 응원해주세요.
