Karen
7k
2017-05-12 12:36:57.0
4
1661

달달 맵싹! 양파의 개발 이야기 - 빅데이터를 하는 기업이 되려면


오랜만에 일 관련 포스팅

빅데이터를 하는 기업이 되려면.



심심하면 빅데이터 빅데이터 어쩌고 하는데 빅데이터 하는 사람으로서 (생색 생색) 불편하기 짝이 없다.

이 말 여러번 했지만

  • 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 가 그 수많은 시스애드민 자리를 잡아 먹은 것처럼 데이터 엔지니어링도 비슷해진다. 내년, 내후년 정도면 평정 될듯.



우리 팀 내년에 공개 서비스로 나갈 듯 합니다. 응원해주세요.




by Yangpa : https://www.facebook.com/londonyangpa/posts/1840417462910399

2
1
  • 댓글 4

  • siva6
    3k
    2017-05-12 14:05:01.0

    만약 올해 내로 data 수집을 시작해야 한다면 어떻게 해야 할까요?
    그냥 내년까지 기다리고 할까요? ^^

    0
  • Karen
    7k
    2017-05-12 14:53:10.0

    siva6님, 안녕하세요.

    OKKY 부운영자 Karen입니다. :)


    혹 칼럼 내용에 관해 궁금한 점이 있으실 경우,

    OKKY 댓글보다는 양파님 페이스북 페이지에서 메시지를 보내시면

    답변 받기가 더 수월하시리라 생각됩니다! ^^


    에디터로서 제가 답변 드릴 수 있는 내용이 아니어서요.

    해당 글 링크와 함께 질문해보시면 좋을 것 같습니다~


    감사합니다.

    0
  • siva6
    3k
    2017-05-12 15:02:36.0 작성 2017-05-12 15:04:54.0 수정됨

    진지한 답변을 원한 것은 아니어서요.
    답변 감사힙니다. 

    링크에 들어가보니 작년 글이었네요. ㅠㅠ

    1
  • 더미
    4k
    2017-05-13 14:28:29.0

    빠른글은 양파님 페이스북가셔서 보시는게..

    여긴 좀 많이 늦더라구요.

    1
  • 로그인을 하시면 댓글을 등록할 수 있습니다.