굿닥에서 지속 가능한 데이터 분석하기. (1)
굿닥은 데이터 중심과 데이터 기반의 플랫폼을 구축 중입니다.
굿닥은 기존의 병원 광고 플랫폼 위에 사용자의 행위정보와 접수/예약 등의 병원과의 접점, 처방전과 결제 등의 상관관계 등의 분석을 통하여 개인들에게 최대한 의미 있는 의료정보를 효과적으로 제공할 수 있는 서비스로 진화 중에 있습니다.
아직은 광고 플랫폼 위에 데이터를 정비하고, 레거시를 변환시키고 있으며, 기존 데이터들의 정리정돈에 매우 많은 공을 들이고 있습니다. 뿐만 아니라, 개원가에 무료로 제공하고 있는 접수 태블릿과 키오스크 업체들과의 연계, 각종 개원가 차트사와의 연계까지 신규로 만들어야 하는 서비스들이 참 많은 상태입니다.
그런 과정 속에서도 미래의 가치 있는 데이터를 관리하고 유지관리를 하기 위해서 지속 가능한 데이터를 추출하고 분석하기 위해서 여러 가지를 고민했습니다.
다른 기업이나 스타트업도 동일한 고민을 대부분 하실 것입니다. 빅데이터라고 불리는 데이터를 추출하고, 모으는 것도 어려운 일이었으며, 데이터를 분석해서 의미 있는 기업의 행위나 비즈니스 적인 의미를 도출하는 작업들은 시간과 인력 투자가 매우 극심한 일이었습니다.
ELK스택이라고 불리는 서비스가 나오고, 하둡과 스파크와 같은 분산 프레임워크, Amazon의 EMR, Kinesis 등의 관리형 클러스터 플랫폼과 실시간 데이터 처리, AWS Glus와 같은 데이터 카탈로그와 통합 보기 기능과 같은 서비스들이 출중하게 나오면서 데이터를 축적하는 단계는 이제 어느 정도 신경만 쓰면 가능한 시대로 돌입했습니다.
상당히 많은 부분을 간소화하고, 다른 리소스들과의 확장성 등을 갖춘 상태에서 서비스들을 구축할 수 있게 된 것이죠.
제가 굿닥에 오기 전에 제가 사용하던 방식은 작은 규모에서는 ELK 스택, 돈이 좀 있거나 넉넉하면 스파크, 믿을 만한 하둡 엔지니어가 있으면 하둡을 사용했습니다. 물론, 더 작은 규모에서는 DBMS로도 충분했죠.
하지만 현재 다루고 있는 데이터의 규모는 상당합니다.
하루에 추가되는 사용자 행위정보나 ROW숫자를 확인해보면, 극심한 경우에는 100억 건에 해당되는 정보가 하루에 Insert 되기도 합니다. 4월 25일의 숫자가 그러했군요.
그리고, 전체적으로 관리하고 있는 데이터 숫자를 체크해보면 오늘 날짜를 기준으로 25억 ROW를 다루고 있습니다. 이 정도의 숫자를 다루려면 기존의 DBMS로는 말도 안 되는 숫자이고, ELK와 하둡, 스파크 등의 데이터 인프라를 다루려고 하면, 최소 3~5인 이상의 전문적인 개발자들이 투입되어야 합니다.
굿닥은 30개 이상의 미디어 매체, 앱과 각종 서비스에서 발생되는 데이터들, 매일 관리되는 서비스들이 증폭되고 있으며, 2019년 하반기에 접수/예약이 본격적으로 가동되는 상황에서는 200억 개 이상의 ROW를 처리해야 할 것으로 개인적으로 예측하고 있습니다.
굿닥은 개인화된 이벤트 상품 추천부터 후기의 순서, 성과의 형태, 랭킹이나 과정의 진화, 이상 상태 감지 및 사용성 분석, 이벤트 퍼널의 분석과 향후, 의료의 프로토콜과 예약/접수의 흐름과의 관계, 처방전과 심평원과의 데이터 관련 분석 등에 이런 모든 데이터 분석 플랫폼을 가동해야 합니다.
더군다나, 각종 의견과 요구사항, 요청들은 비즈니스 본부에서는 마케팅 관점, 접수/태블릿 사업부에서는 사용성과 관련 의료기관의 데이터 추출과 분석, 전략에서 원하는 방향성까지 매우 다양한 요구사항과 산발적으로 발생되는 현업과의 커뮤니케이션들은 매우 복합적입니다.
이런 복합적인 요구사항에 적합하도록 적절한 데이터 아키텍처와 데이터 마트, 그 아키텍처 위에서 동작하는 분석 업무 프로세스와 서비스와의 연계를 매우 합리적으로 디자인하는 것이 중요했습니다.
특히나, 이 부분에 대해서 경영진들을 설득하고, 리소스를 투입하여 적절한 시점에 운용을 했어야 했는데, 제가 입사 시점에 소프트웨어 개발자가 20명이 안 되는 상황에서는 기존 데이터 플랫폼들을 선택하기에는 매우 무리였습니다.
이런 환경을 커버하려면 기존의 ELK, 하둡, 스파크로는 무리라고 판단한 이유는 간단합니다.
새로운 신규 서비스 개발, 기존 레거시의 운영 업무 등에 개발자들의 리소스를 추가 확대하기도 어려운 상황에서 엄청나게 많은 데이터 커넥터들을 필요로 하고 있었기 때문에 최소의 인원으로 데이터 아키텍처를 구성할 수 있는 방법을 택해야 했기 때문입니다.
https://www.treasuredata.com/integrations/
제가 선택한 설루션은 TRESYRE DATA 서비스를 기반으로 회사에 존재하는 각종 데이터 커넥터들과 모두 연계하기 위한 탁월한 선택이었다고 생각합니다.
2017년도 하반기부터 고민하기 시작해서, 2018년도에 도입된 TD는 각종 데이터들을 통합하기 시작했고, 현시점에서는 회사에 존재하는 모든 데이터들을 통합하는 대부분의 시나리오들이 완성되었습니다.
그것도, 개발자 1명의 리소스를 30~40%만 활용했는데도 말이죠.
고생한 담당자인 카일에게는 정말 감사를...
지속 가능한 데이터 플랫폼을 구성하기 위해서는 복잡한 체크리스트가 필요하지만, 지면상 간단하게 몇가지 정리하겠습니다.
첫째. 기업 내부에서 지속 가능한 데이터 업무에 대한 의지가 확고한가?
둘째. 데이터 플랫폼 개발과 운영등의 유지보수 인력으로 팀을 별도로 구축하거나 개발자 리소스의 투입을 최소 3명이상 사용할 수 있는가?
셋째. 기업의 주요 목표가 되는 서비스의 개발에 있어서 데이터 플랫폼의 하부까지 연계 사용할 정도로 디테일한 개발이 필요한가?
넷째. 별도의 디바이스를 만들거나, 지속가능한 데이터 플랫폼의 유지보수나 운영 비용에 대해서 감내할 수 있는가?
다섯째. 믿을만한 ELK, 하둡, 스파크등의 데이터 엔지니어의 보유가 가능한가?
여섯째. 서비스 개발 파트에서 데이터 커넥터들을 최대한 유연하게 운용가능하도록 기술 개발총괄이 해당 업무에 대해서 이해를 하고 있는가?
이상 6개의 질문에서 4개 이상이 가능하다면, 별도의 팀을 만들고, 데이터 엔지니어를 세팅해서, 내부적으로 데이터 플랫폼을 만들거나, AWS의 서비스들을 활용하는 것들이 가능합니다.
하지만, 전체 개발자가 30명 이하의 경우에는 이런 작업은 그렇게 의미있고 효과적으로 작업하기에 어렵습니다. 이 경우에는 TD를 추천드립니다.
ELK와 하둡, 스파크등을 사용하게 되면, 별도의 플랫폼 개발자가 결론적으로 5~6명 필요하게 됩니다.
제가 선택한 것은 최소의 인원과 빠르게 데이터 플랫폼을 구축할 수 있다고 판단하여, TD를 선택했습니다.
.
.
.
계속 이어집니다.
