지속 가능한 데이터 분석하기
AWS 기반, 지속 가능한 데이터 분석 플랫폼 구축하기
안녕하세요, 지그재그 데이터팀 소성운입니다.
지난 2019년 4월 18일 개최한 AWS Summit Seoul 2019 행사의 커뮤니티 트랙에서 지그재그의 데이터 분석 사례를 공유할 수 있는 자리를 갖게 되었습니다. 짧은 세션이었지만 현재 지그재그에서 사용하고 있는 데이터 분석 서비스와 분석 프로세스를 소개하였습니다.
발표 영상과 자세한 내용을 공유드립니다. 발표 영상과 발표자료는 해당 링크에서 확인 가능합니다.
동일한 내용으로 AWSKRUG #datascience 모임에서 핸즈온을 진행했었습니다. 핸즈온 자료를 따라오시면 아래 소개드린 내용을 실습해보실 수도 있습니다.
안녕하세요. 소 성운입니다. 저는 지그재그에서 데이터팀에 근무하고 있고, AWS 한국 유저 그룹 데이터 사이언스 소모임 운영진으로 활동하고 있습니다.
지그재그는 여성 쇼핑몰들을 모아서 쉽고 빠르게 그리고 개인화된 쇼핑환경을 제공하는 서비스입니다.
오늘 여러분과 나눌 주제는 데이터 분석입니다.
불과 수년 전이지만 과거에는 빅데이터를 분석하는 것을 시도하는 자체가 어려운 일이었습니다. 데이터를 분석해서 의미를 도출해내는 작업 이전에 데이터 만지는데 전전긍긍하고 많은 시간을 쏟았습니다.
많이 들어보셨겠지만 하둡이나 스파크 같은 분산 프레임워크가 등장해서 이런 문제들을 해결해주었지만, 이것들을 셋업하고 운영하기에는 많은 시간과 노력이 필요했습니다. 다행히 Amazon EMR 같은 서비스가 등장하면서 이런 과정들을 간소화하고, 다른 리소스들과의 확장성을 갖춘 관리 형태로 제공하기 때문에 얼마든지 자신의 입맛에 맞는 분석 플랫폼을 구축할 수 있게 되었습니다.
오늘 공유하는 내용은 제가 작년 9월에 지그재그 팀에 합류하여 정립한 데이터 분석 아키텍처와 그 위에서 실제로 데이터 분석 업무들이 어떤 식으로 이루어지는 지에 대한 내용입니다.
지그재그에는 3400개가 넘는 여성 쇼핑몰들이 입점 해 있고, 매일 10,000개가 넘는 신상품이 실시간으로 업데이트되고 있습니다. 우리나라 여성 쇼핑몰 시장을 아시는 분이라면 지그재그의 통합 쇼핑환경과 일관된 사용자 경험을 제공하는데 얼마나 많은 노력을 쏟고 있는지 아실 겁니다. 이를 바탕으로 유저들에게 사랑받는 서비스로 거듭나게 되었고, 유저수가 늘면서 유저들의 서비스 내 활동 로그만 매일 수십 기가 단위의 데이터가 적재되고 있습니다.
이렇게 모이는 데이터들을 이용해서 쇼핑몰과 상품의 인기도를 측정하고, 사용자에게 개인화된 상품을 제안하는 기능에 활용하고 있습니다. 저희는 조직 내부적으로 데이터를 기반으로 한 의사결정을 지향하기 때문에 많은 분석 관련 요청 업무들이 존재합니다. 각 팀에서 필요한 데이터를 쉽고 원하는 형태로 볼 수 있게 하고, 함께 분석을 진행해서 인사이트를 도출하는 것 또한 데이터팀 업무의 일부라고 생각합니다.
다만 문제는 이런 요청들이 다양한 조직으로부터 산발적으로 일어난다는 것입니다. 데이터를 통해 현업에 도움이 되는 요청은 언제나 환영이지만 그 요구들이 정말 다양하고 제각각이기 때문에 이런 요청들을 처리하기 위해서는 탄탄한 데이터 아키텍처를 정립하고 그 아키텍처 위에서 분석업무를 프로세스화 하는 것이 필요하다고 생각했습니다.
이 자리에 오신 분들 중에 아직 데이터 분석 관련 인프라 도입에 대한 고민을 해 보시지 않으셨다면, 다음과 같은 포인트들부터 시작해 보시면 될 것 같습니다. 먼저 자신이 다루는 데이터를 알아야 합니다. 어떤 형태의 데이터이고 얼마나 큰 사이즈인지 그것들이 어떻게 생성이 되고 업데이트 어떤 주기로 되고 있는지 같은 것들을 분명히 해야 합니다.
또한 데이터의 흐림이 정체 없이 처리되기 위해서 어떤 파이프라인을 구성하고, 어떻게 필요한 곳에 전달을 해야 할지에 대한 고민들입니다. 당부드릴 말씀은 데이터 분석은 실행이 중요하기 때문에 인프라나 서비스 도입을 고민하다가 정작 마감기한까지 분석 관련 일은 시작도 못하는 상황을 만들지 말아 달라는 것입니다. 구글 스프레드시트나 데스크톱에 RStudio로 처리가 가능한 분석업무라면 이런 고민 없이 그냥 바로 실행하시면 됩니다.
현재 지그재그에서 사용하고 있는 데이터 분석 아키텍처를 소개드립니다. 가장 먼저 시도한 작업은 지그재그 서비스용 데이터와 분석용 데이터를 분리하는 작업이었습니다. 분석을 위한 쿼리는 복잡하고 로드가 크게 걸릴 수도 있는데, 분석을 위한 쿼리 요청이 실제 서비스에 영향을 주지 않기 위함입니다.
이를 위한 간단한 해결책으로 주기적으로 데이터베이스의 스냅샷을 S3에 적재해두고, 분석을 위한 접근은 서비스용 데이터베이스가 아니라 S3에만 하도록 하였습니다. 필요한 경우에는, 예를 들면 A/B테스트를 진행하고 이 결과를 실시간으로 모니터링해야 한다고 한다면, Kinesis Firehose를 이용하여 데이터를 실시간으로 S3에 적재하여 분석용 데이터의 실시간성을 유지할 수 있습니다.
여러분 가진 데이터를 큰 고민 없이 일단 S3에 적재하는 순간부터 거짓말처럼 앞으로 진행하고자 하는 거의 모든 작업의 수고로움이 사라지게 됩니다. S3는 안정성과 비용 측면에서의 여러 장점을 갖춘 클라우드 스토리지이고 AWS 내부/외부 리소스와의 굉장히 궁합이 좋습니다.
다양한 소스와 각기 다른 포맷으로 존재하는 데이터를 S3에 적재하면, 이 데이터는 AWS Glue 서비스를 통해 카탈로그로 만들 수 있습니다. 이 부분은 제가 제일 좋아하는 부분인데 Glue 크롤러를 통해 S3를 스캔하면 해당 데이터의 스키마가 자동으로 생성이 됩니다.
실제 Glue 크롤러를 통해 생성한 데이터 카탈로그입니다. Location과 Classification 필드를 보시면 S3의 다양한 경로와 포맷이 있는 걸 확인할 수 있습니다. 저는 S3를 사용하는 것을 선호하는데요, Glue가 지원하는 스펙상으로는 RDS나 DynamoDB를 포함한 다양한 형태의 데이터 소스로부터 카탈로그를 만들 수 있습니다.
데이터 카탈로그 상세화면입니다. 아래 스키마는 수동으로 잡아둘 수도 있지만, 이전 슬라이드에서 말씀드렸듯이 크롤러를 통해 자동으로 스키마 생성이 가능합니다. 제일 하단에 보시면 S3의 폴더 트리에서 읽은 파티션 정보도 자동으로 생성된 것을 볼 수 있습니다. 이 파티션 정보를 이용하여 각 쿼리가 스캔하는 데이터의 양을 제한하여 효율적인 쿼리가 가능합니다.
데이터 엔지니어링에 관심이 있으시다면 Datalake라는 말을 들어보셨을 텐데요. 여기까지 오셨다면 이미 아주 간단한 Datalake를 구축하셨습니다. 핵심은 데이터 형태나 포맷에 상관없이 여기저기 흩어져 있는 데이터를 카탈로그화 하고 필요한 곳에서 접근할 수 있도록 통합관리하는 것입니다. 보시는 것처럼 AWS 몇 가지 서비스를 이용해서 이렇게 쉽고 간단하게 분석 인프라를 갖출 수 있습니다.
저희 팀은 분석작업을 위해서는 EMR을 활용하는데요. EMR 상에서 데이터 조회를 위해 S3로 직접 접근도 가능하지만 보시는 것처럼 카탈로그를 통해서도 접근이 가능합니다.
또한 EMR 뿐만 아니라 서버리스 쿼리 서비스인 Athna나 분석 서비스인 Quicksight 서비스에서도 쉽게 데이터에 접근하여 사용이 가능합니다.
여기까지는 "어떻게 사내의 대용량 데이터를 효율적으로 처리하고 관리할 것인가?"에 대한 고민이었다면, 이제부터는 구축 해 놓은 아키텍처 상에서 어떻게 데이터 분석작업을 진행할 것 인가에 대해 이야기해보려 합니다.
실제로 성과분석이나 프로젝트 성으로 데이터팀으로 많은 분석을 요청들이 있고, 그것들에 대한 해답을 드리기 위해서 많은 고민과 방법들을 찾고 있습니다.
다행히 Google Analytics나 Firebase 같은 개발 플랫폼에서도 이미 충분한 데이터 분석과 인사이트를 제공해주고 있어서 이를 살펴보고 잘만 다룰 줄 안다면 많은 문제들을 해결하실 수 있습니다.
하지만 여러분이 알고자 하는 문제가 일반적인 것에서 자신의 비즈니스에 특화된 질문일수록 점점 더 GA나 Firebase활용에 한계에 부딪히게 될 것입니다.
대부분의 경우는 분석을 위해 특별한 데이터나 어려운 분석 스킬이 필요해서가 아니라 분석 서비스에서 제공하는 스펙의 제약사항을 마주하는 경우입니다. 원하는 데이터가 제공되지 않거나 그것을 알기 위해서 굉장히 복잡한 과정을 거쳐야 하고, 조회할 수 있는 데이터의 탐색범위나 형태의 제약이 존재하는 경우가 비일비재합니다. 사업 환경의 변화로 지표의 재정의가 필요한 경우에도 해당 지표를 트래킹 하는 조건이나 기준을 변경하는 것은 불가능해서 결국은 포기하고 이미 정의된 의미를 파악하고 해석하는 정도로 사용하게 됩니다.
이런 제약사항에 부딪히는 경우가 많아질수록 아마도 "데이터를 직접 만지고 내가 원하는 형태의 분석 결과를 내고 싶다."라는 생각이 마음속 깊은 곳으로부터 일렁이기 시작할 것입니다. Apache Zeppelin은 데이터를 가져오고 가공해서 시각화하는 전반의 과정을 노트북으로 관리할 수 있는 좋은 툴입니다.
보시는 것과 같이 S3상의 데이터를 EMR위에 띄워둔 Zeppelin을 통해서 접근하고 처리가 가능합니다. Zeppelin은 하나의 옵션일 뿐이고 여러분들이 익숙한 데이터 분석 환경, 예를 들면 Jupyter Notebook이나 RStuio 환경 같은 선호하는 데이터 분석 환경이 있으면 EMR상에 셋업 하시고 사용하시면 됩니다. 지그재그는 데이터 전처리 및 간단한 분석을 위해 Spark와 Zeppelin의 조합을 사용하고 있습니다.
Zeppelin의 장점은 모든 분석과정을 코드로 관리할 수 있다는 점입니다. 분석의 산출물 또한 작성한 스크립트 코드이기 때문에 재현 가능성을 갖고 있습니다. 다시 말씀드리면 자신이 진행했던 데이터 분석 전 과정을 그대로 다른 사람이 재현할 수 있습니다. PySpark는 Python에 익숙하신 분이라면 많이 사용해보신 Pandas를 포함한 데이터 처리 관련 유용한 라이브러리를 그대로 사용하실 수 있습니다.
반면에 단점도 존재합니다. 업무를 진행하면서 생성되는 노트북을 관리하고, 이름 짓고 유지보수해야 할 필요가 생기는데, 저같이 정리를 못하는 사람은 노트북 관리를 어려워하실 수 있습니다. 노트북을 Git으로도 관리할 수 있지만 스크립트 코드는 일회성으로 작성하는 경우가 많습니다. 분석의 목적에 따라 같은 데이터이더라도 다양한 형태로 처리하기 때문에 아무리 모듈화 하더라도 코드의 재사용성이 낮습니다. 그러다 보니 따로 분리해서 관리하고 있는 중요한 전처리 코드를 제외하고는 관리에 대한 필요성을 느끼지는 못하고 있고, 오히려 코드보다는 데이터의 출처와 스키마를 정리한 문서관리에 더 신경을 쓰고 있습니다.
Spark에서 발생하는 문제도 많이 있지만 Zeppelin 자체가 생각보다 불안정하고 코드 블락 단위의 작업 양이 많아지면 느려지기 일쑤입니다. 현재 Zeppelin 최신 버전은 0.8.1이고 아직 정식 출시가 안된 상태입니다. (2019.04.18 기준) 문제가 발생하면 슬라이드에서 보시는 것처럼 에러 로그를 뿜어대는 형태이기 때문에 아무래도 데이터팀이나 개발팀이 아닌 조직에서 사용하기 낯설고 장애 대응에 어렵습니다.
시각화 관점에서는 우리에게 익숙한 2차원 형태의 테이블, 라인/바/파이 차트들이 제공되어 일반적인 작업을 처리하고 결과를 확인하기에는 충분하지만 아무래도 표현의 한계로 아쉬운 부분들이 존재합니다.
아무리 원하는 데이터를 원하는 형태로 마음대로 주무를 수 있다고는 하지만 결과 한 줄 보기 위해 이런 식으로 노트북과 코드가 작성되고 관리하는 데는 많은 어려움이 존재합니다.
데이터 분석의 어려운 점을 이야기할 때 이런 기술적인 문제 이외에도 회사 내에 조직적인 문제나 담당자들 간의 데이터의 이해정도에 달라서 발생하는 커뮤니케이션 비용과 그로 인한 실패에 대해서도 생각해볼 수 있습니다. 실제로 현업에서 기술적인 부분보다는 기술외적인 부분(분석의 요구사항 분석, 분석 데이터의 적합성, 결과 레포팅과 커뮤니케이션)의 문제로 잘못된 분석 결과를 야기시키는 경우가 더 빈번합니다.
한 가지 해결책은 대시보드라는 하나의 산출물을 바탕으로 담당자와 분석가들이 리뷰와 피드백 과정을 반복해나가면서 대시보드를 함께 고도화시켜가는 것입니다.
단순히 "분석의 결과를 대시보드를 만든다!"라는 관점에서 시작해보면 어떻게 대시보드를 만들고 배포할 것인가?를 생각해볼 수 있습니다. 이를 위해서는 이미 많은 툴이 존재하고 각각마다 장단점이 존재하기 때문에 자신이 필요로 하는 스펙에 맞게 대시보드를 선택하시면 됩니다.
저희는 초창기에 구글 스프레드시트와 Zeppelin을 통해서 이런 업무들을 해왔었지만 고민 끝에 최근에는 태블로(Tableau)라는 툴을 도입하여 운영을 해보고 있습니다. 돈을 주고 쓰는 만큼 보시는 것과 같이 태블로 내에는 다양한 데이터 커넥터를 지원합니다. 파일 형태부터 GoogleSheet, GA, Amazon EMR, Athena, Redshift 같은 것들을 바로 붙여서 사용할 수 있어서 지그재그 내에 거의 모든 데이터 소스를 무리 없이 커버합니다.
태블로는 가장 큰 단점은 비용이지만 Zepplelin과 비교했을 때 더 많은 시각화 요소를 제공하고 다양한 형태의 대시보드를 자유롭게 구성할 수 있십니다. 저희는 Tableau Online을 사용하고 있기 때문에 서버 호스팅에 대한 부담이 없고, 실제로 현재 데이터 엔지니어 없이 프로덕션 레벨에서 무리 없이 팀 내에서 운영하고 있습니다.
저희가 했던 시도는 전처리와 시각화하는 부분을 분리해서 운영하고자 했습니다. 전처리 코드는 Zeppelin을 통해 ETL을 진행하여 S3에 쌓아두고, 그렇게 처리된 데이터를 외부 대시보드 툴인 태블로 이용해서 대시보드를 만들어보았습니다.
이렇게 대시보드와 데이터 소스를 분리를 했기 때문에 경우에 따라서는 대시보드가 해당 데이터에 라이브로 연결할 수도 있고, 스케쥴링된 추출 형태의 잡으로 데이터를 점진적으로 가져다가 사용하는 여러 가지 옵션이 생겼습니다.
아키텍처상에서 다시 이야기해보면 Zeppelin을 통해 전처리를 진행하고, 필요하다면 여러 파이프라인을 거쳐서 최종 완료된 데이터를 S3에 적재 후 카탈로그화 했습니다. 그 정제된 데이터를 태블로에서 카탈로그 정보를 이용하여 접근하여 대시보드를 구성하는 형태입니다. 자연스럽게 이런 데이터 플로우에서 분석업무의 워크플로우를 잡아볼 수가 있었습니다.
보시는 것과 같이 특별한 것 없는 네 가지 단계의 분석과정입니다. 각각 분석을 위한 기획, 데이터 준비, 데이터 분석 그리고 시각화하는 단계입니다.
이것의 핵심은 각각의 단계가 데이터 아키텍처상에서 어떻게 진행되고 데이터가 어떤 산출물 형태로 이어져 나가는지 이해하는 것입니다. 지그재그 사례로 간단히 짚어 보겠습니다. 지그재그 서비스 내에는 상품 검색 기능에 제공하는데 인기 키워드 항목에 대한 분석을 진행을 했었습니다.
분석 기획단계에서는 담당자의 요구사항들을 분석의 목적에 맞게 상세화 시키는 단계입니다. 예를 들면 성과에 대한 측정은 어떤 지표들로 할 것이고, 여러 지표들을 어떻게 점수화하고 그것을 비교할 것 인지에 대한 내용입니다.
데이터 준비 단계에서는 상세화 된 요구사항을 바탕으로 분석을 위한 데이터를 전 처리하고 카탈로그화 하시면 됩니다.
데이터가 없으면 분석이 진행되지 않기 때문에 데이터를 어떻게 생성해야 하는지도 고민이 필요한데요. 지그재그는 유저 로그를 쌓는 것에 정말 많은 노력을 들이고 있습니다. 관련 노하우들은 지그재그 블로그 다른 포스팅에 정리해두었으니 꼭 한번 확인해보시기 바랍니다.
분석 이벤트 로그 점검 & 정리하기 #1
https://career.zigzag.kr/2018/07/23/007/
분석 이벤트 로그 점검 & 정리하기 #2
https://career.zigzag.kr/2018/09/11/008/
이제 정말로 하고 싶었던 데이터 분석과정입니다. 이 단계에서는 분석가 개개인이 익숙한 분석 환경에서 진행하시면 됩니다. 이 단계에서 고민해야 하는 것은 시각화하는 타블로로 전달해야 하는 데이터가 읽어 들이기 쉬운 형태인지, 데이터 크기는 적당한지, 정제한 데이터가 분석에 있어서 확장성이 고려가 되어있는지가 핵심 포인트입니다. 그렇지 못한 경우에 문제가 생기면 부득이하게 데이터를 준비하는 단계부터 다시 시작할 수도 있습니다.
마지막으로 시각화 단계입니다. 처음 분석 기획단계에서의 질문들에 대한 답을 대시보드로 구성해보시면 됩니다. 사실 이 단계가 마지막이 아닌 어찌 보면 시작 단계입니다. 데이터가 눈에 보이기 그것에 대한 해석이 손에 잡히면 이어지는 궁금증들이 쏟아집니다. 대시보드가 완성이 되면 담당자분과 리뷰를 하며 대시보드를 함께 디벨롭하고, 이어지는 추가 분석을 진행하는 과정의 반복이 이어집니다.
인기 키워드 성과 모니터링 대시보드입니다. 현재 서비스에 게시되고 있는 인기 키워드의 성과를 키워드 클릭수, 상품 클릭수, 상품에 발생한 침수를 점수화하여 신호등 관리라고 부르는 좋은/보통/나쁨으로 나타내 보았습니다. 지난 3주간 성과 좋은 키워드들이 도드라져 보일 수 있도록 워드 클라우드를 주차별로 확인할 수 있게 하였습니다. 이어서 일자별로 시간이 지나면서 Top 10 키워드들이 어떻게 바뀌는지 구성했고, 가장 하단에는 일자별 급상승 키워드들을 확인할 수 있도록 하였습니다.
이런 식으로 데이터 분석 아키텍처 위에 자리 잡힌 워크플로우에 익숙해지면 분석의 요구사항 변경이나 대시보드 장애에도 유연하게 대처가 가능합니다. 각각의 문제마다 예상되는 변경점이나 범위들이 쉽게 도출되기 때문입니다.
예를 들면 처음에는 일자별로 데이터가 보고 싶다고 했었는데 주별/월별로 보고 싶을 수가 있습니다. 데이터를 준비하는 단계에서 각각 일별/주별/월별 통계치를 따로 계산하여 적재하는 것도 방법 이겠지만, 시각화하는 툴에서 시간 관련 집계가 가능하다면 일자별 데이터셋으로 주별/월별 데이터의 요구사항을 간단히 조치할 수 있습니다. Zeppelin의 경우에는 이런 시간 집계 관련 기능이 없기 때문에 번거롭지만 별도로 데이터를 전처리를 해야 합니다.
어느 날 갑자기 대시보드 데이터가 업데이트가 되지 않으면 타블로가 바라보는 데이터 소스와 커넥션 문제가 있는지 확인해봅니다. 만약 데이터를 스케쥴링해서 추출해오는 형태라면 해당 스케쥴링 잡이 정상적으로 실행됐고 종료됐는지를 확인합니다. 이 모든 게 정상이라면 실제로 데이터 소스에 어떤 문제로 데이터가 적재되고 있지 않는지 의심해볼 수 있습니다.
급상승 키워드 산정하는 모델의 변경이 필요하다면 새로운 모델을 만들어 적용하고 해당하는 산출물을 다시 S3에 적재하시면 됩니다. 재미있는 부분은 마치 부품을 갈아 끼듯 문제점으로부터 수정된 파트만 조치를 하면 이후에 과정들은 물 흐르듯 데이터가 다시 흐르고 대시보드 상에서 결과를 바로 확인 가능하다는 것입니다.
이런 프로스 세화 하는 과정들이 분석 업무에 있어서 많은 부수적인 노력을 줄여주고, 분석 결과의 꼬리의 꼬리의 꼬리를 무는 분석 업무를 대처하는 방법이라고 생각합니다.
정리하면 지속 가능한 분석을 하기 위해서는
1. 탄탄한 데이터 아키텍처 위에 셋업 한
2. 현업 팀들과 맞는 워크플로우를 갖추고
3. 반복적인 분석과 리뷰 과정을 끊임없이 이어나가는 것이 핵심입니다.
