데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study 이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.

2. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박주홍 데이터 분석 및 인프라 팀장 / 이준호 데이터 분석 및 BI 팀장
데브시스터즈
데브시스터즈 데이터 레이크 구축 이야기 :
Data Lake architecture case study

3. 컨텐츠, 기술, 서비스를 통해
세상을 더욱 더 즐겁게 만들기 위해 도전하는
글로벌 엔터테인먼트 기업
• 2007년 5월 22일 설립
• 2014년 10월 코스닥 상장

4. 대표작 | 쿠키런
쿠키런 for Kakao | 2013년 4월 2일 출시
LINE 쿠키런 | 2014년 1월 29일 출시
쿠키런 OvenBreak | 2016년 10월 28일 출시
쿠키워즈 | 2018년 8월 23일 출시

5. 발표자 및 팀 소개

6. 발표자 및 팀 소개
박주홍
DEVSISTERS | Data Scientist
• KAIST 수리과학과
• Server Engineer
• Data Engineer
• 쿠키런 데이터 연구, CHI LBW 발표
• Data Science & Infrastructure 팀장

7. 데이터 분석 및 인프라 구축
• 데이터 과학자
• 데이터 엔지니어
• 머신러닝 엔지니어
주요 업무
• 데이터 모델링 및 예측
• A/B Test 인프라 설계 및 구축
• 멀티 게임 데이터 분석을 위한 다중 클러스터 구축
• 데이터 레이크 및 데이터 파이프라인 구축
발표자 및 팀 소개
Data Science & Infrastructure

8. Devsisters Data Infra Before

9. Semi-Structure
Indexing
Indexed Log
Devsisters Data Infra Before
2014년 – Data Infra & Application
Raw Log
CS 팀: CS 응대
분석 팀: KPI 추출

10. Devsisters Data Infra Before
Semi Structure Indexing
• JSON 형태의 Game Log
• 유저 번호, 유저 행동, 시간으로 Indexing
• 주로 CS 대응시 고객 게임 기록 조회, KPI 추출

11. Devsisters Data Infra Before
Semi Structure Indexing
• JSON 형태의 Game Log
• 유저 번호, 유저 행동, 시간으로 Indexing
• 주로 CS 대응시 고객 게임 기록 조회, KPI 추출
Game Log
{“id”:1234,
“action”: “play”,
“timestamp”: “1234567890”,
“score”: 300,
”level”: 12,
“coin”: 7}

12. Devsisters Data Infra Before
Semi Structure Indexing
• JSON 형태의 Game Log
• 유저 번호, 유저 행동, 시간으로 Indexing
• 주로 CS 대응시 고객 게임 기록 조회, KPI 추출
Game Log
{“id”:1234,
“action”: “play”,
“timestamp”: “1234567890”,
“score”: 300,
”level”: 12,
“coin”: 7}
Indexing
{“id”:1234,
“action”: “play”,
“timestamp”: “1234567890”,
“score”: 300,
”level”: 12,
“coin”: 7}

13. Devsisters Data Infra Before
Semi Structure Indexing
• JSON 형태의 Game Log
• 유저 번호, 유저 행동, 시간으로 Indexing
• 주로 CS 대응시 고객 게임 기록 조회, KPI 추출
Game Log
{“id”:1234,
“action”: “play”,
“timestamp”: “1234567890”,
“score”: 300,
”level”: 12,
“coin”: 7}
Indexing
{“id”:1234,
“action”: “play”,
“timestamp”: “1234567890”,
“score”: 300,
”level”: 12,
“coin”: 7}
Querying
SELECT * FROM game_log
WHERE id = 1234
SELECT count(*) FROM game_log
WHERE action = “play”

14. Various Data Request

15. Various Data Request
부서마다 다른 데이터 요청
분석팀
Json 단위 데이터 조회
특정 Field 만 조회
EX) COUNT(DISTINCT USER)
CS팀
모든 로그 중에서
필요 로그 조회
전체의 50%만 필요
마케팅팀
요청시마다
해당일 데이터 가공
일별 고객 정보 스냅샷 필요
BI
Spark 로 직접 데이터 추출 후 분석
SQL 문법으로 직접 접근

16. Data Lake 도입

17. Data Lake 도입
Data Lake 도입 배경
부서별 다양한 데이터 요청 응대
요청 데이터 활용을 위한 다양한 포맷 지원
데이터 계층화를 통한 데이터 활용성 증대

18. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환

19. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

20. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

21. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

22. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

23. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

24. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
WHERE Country = “India”
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

25. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
WHERE Country = “India”
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

26. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
WHERE Country = “India”
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

27. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
WHERE Country = “India”
Table
Country=India
Country=Germany
Country=US
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

28. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
SELECT sum(Sales) FROM Table
WHERE Country = “India”
Table
Country=India
Country=Germany
Country=US
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

29. Data Lake 도입
Parquet 활용
• Columnar Storage Format
• 특정 Field 만 접근 가능
• Partition 지원
• Spark Dataframe 호환
Table
Country=India
Country=Germany
Country=US
SELECT sum(Sales) FROM Table
WHERE Country = “India”
spark.read.parquet(“s3://path/Country=India”)
.agg(sum(“Sales”))
Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html

30. Data Lake 도입
Data 계층화
• 전혀 가공 없는 Raw Data
• Glacier 활용
• Raw Source 백업 용도
Raw
Layer
• 중복 제거, 결함있는 로그 수정 등 전처리
• Log 종류별 Partition
• 실질적으로 활용하는 로그
Analytics
Layer
• 데이터 요청 목적에 맞도록 가공
• 필요한 부서별 접근 권한 관리 및 용량 최적화
• 목적에 맞게 Data Format 및 Indexing
Objective
Layer

31. Data Lake 도입
Data Lake 를 통한 데이터 요청 응대
분석팀
Json 단위 데이터 조회
특정 Field 만 조회
EX) COUNT(DISTINCT USER)
Parquet 도입
Columnar Storage Format
CS팀
모든 로그 중에서
필요 로그 조회
전체의 50%만 필요
필요 데이터 추출 후
Indexing 하여 저장
마케팅팀
요청시마다
해당일 데이터 가공
일별 고객 정보 스냅샷 필요
Parquet 도입
Date 파티션
BI
Spark 로 직접 데이터 추출 후 분석
SQL 문법으로 직접 접근
Parquet 도입
Athena 로 접근

32. Devsisters Data Infra After

33. Semi-Structure
Indexing
Indexed Log
Devsisters Data Infra After
2014년 – Data Infra & Application
Raw Log
CS 팀: CS 응대
분석 팀: KPI 추출

34. Write Parquet Raw Log
(Parquet)
Devsisters Data Infra After
2018년 – Data Lake
Raw Layer

35. Write Parquet Raw Log
(Parquet)
Devsisters Data Infra After
2018년 – Data Lake
Raw Layer
Preprocessing Analytics Log
Date, Action Partition
Analytic
Layer

36. Write Parquet Raw Log
(Parquet)
Devsisters Data Infra After
2018년 – Data Lake
Raw Layer
Preprocessing
Indexed Log
Analytics Log
Date, Action Partition
Data Analysis
Marketing Snapshot
Date Partition
Semi-Structure
Indexing
DW Athena
Analytic
Layer
Objective Layer
CS 팀: CS 응대
분석 팀: KPI 추출
마케팅 팀: 트랜드 분석
BI 팀: BI 분석

37. Write Parquet Raw Log
(Parquet)
Devsisters Data Infra After
2018년 – Data Lake
Raw Layer
Preprocessing
Indexed Log
Analytics Log
Date, Action Partition
Data Analysis
Marketing Snapshot
Date Partition
Semi-Structure
Indexing
DW Athena
Analytic
Layer
Objective Layer
CS 팀: CS 응대
분석 팀: KPI 추출
마케팅 팀: 트랜드 분석
BI 팀: BI 분석

38. 발표자 변경

39. 발표자 소개
이준호
DEVSISTERS | Business Intelligence Analyst
• 데이터 분석 업무
• In-Game event 효과 측정 분석
• 마케팅 채널 효율 분석
• A/B Test
• Dashboard 설계 및 구현
• Data Lake 설계 및 구현

40. 기존 분석환경
AWS S3AWS EC2
AWS RDS

41. 기존 분석환경 장점
AWS S3AWS EC2
AWS RDS
Flintrock으로 많은 부분 자동화
1.AWS EC2 서버 셋팅
2.서버에 Spark 및 각종 라이브러리 설치
3.Driver와 Worker 연결
4.추가 기능 : Add & Remove Worker 기능

42. 첫번째 이슈 - 분석환경 셋팅
AWS S3AWS EC2
AWS RDS
On-Premise 환경에 익숙한 BI 분석가에게는
분석을 시작하기 까지 환경설정 시간이 오래 걸림
1. EC2할당 받기까지 대기 시간
2. 할당된 EC2에 spark 및 각종 라이브러리 설치 시간
3. Driver – Worker 설정 시간
3단계가 문제없이 진행된다면 약 7~10분안에 셋팅이
되지만 하나라도 잘 안된다면 retry하는 시간 발생

43. 첫번째 이슈 - 분석환경 셋팅

44. 두번째 이슈 - 데이터 크기
AWS S3AWS EC2
AWS RDS

45. 두번째 이슈 - 데이터 크기
AWS S3
1. 분석 용도로 사용하기 버거운 파일 크기
• Columnar Storage 형식이 아니어서 모든 key값을 읽어야함
• 3개월 치 주요 KPI를 추출한다고 가정하면 r4.2xlarge
클러스터를 약 32대 정도 띄워야 원활하게 작업이 가능함
2. 로그 별 각종 전처리 필요
• Ex 1) 매출정보에서 안드로이드에서 KRW 결제금액은
yyyy-mm-dd 일부터 VAT 제외
• Ex 2) AU 집계시 dummy 유저는 제외
• 분석가 마다 처리하는 로직이 다를 수 있음
• 같은 소스를 가지고 분석하지만 수치가 달라져 end-user
입장에서 혼란이 가중됨

46. 세번째 이슈 – 배치 작업 및 대시보드 생성
AWS S3AWS EC2
AWS RDS

47. 세번째 이슈 – 배치 작업 및 대시보드 생성
1. AWS RDS 데이터 마트
• 적은 비용으로 RDS를 유지하면서 주요 dashboard를 만들 수
있었지만, 분석 용도로 활용하기에는 어려움이 있었음
• Dashboard에 End-user의 추가 요청사항이 발생할 경우,
그에 맞는 테이블을 추가로 구축이 필요
• 관련 코드를 Airflow에 등록
• 데이터가 맞는지 Notebook 분석환경에서 작업한
코드를 그대로 사용하지 못함 (batch 작업에 맞게
변경이 필요)
• Batch 작업이 이상없이 잘 돌아가는지 테스트가 필요
AWS RDS

48. 문제 정의 및 개선방안
1. 오래 걸리는 분석환경 셋팅
2. 분석하기에는 파일 사이즈가 큰
로그 데이터
3. 같은 source지만 분석가 마다 다른
로그 전처리 과정으로 인한 결과물
불일치
• 즉시 접근이 가능한 분석환경
구축
• 표준 SQL 사용
• 각 로그 별 분석에 필요한 key값만
선정하여 column flat하게 저장
• Columnar Storage를 지원하는
파일형식으로 저장
• 1차적인 예외처리를 진행한 뒤에
파일로 저장
Amazon
Athena
문제정의 개선방안 솔루션
4. Batch 작업으로 정리된
RDS table이 다용도로 사용되지 못함
• 다양한 소스의 데이터를 한곳에
저장하여 필요에 따라 꺼내 쓰기
Data Lake

49. Data Lake 구축
/login
/billing
/play_trophy
/play_ovenbreak
Json – meta file
f_login
f_billing
f_play_trophy
f_play_ovenbreak
d_country
d_currency
d_card
f_member
f_play_total
Log Data Fact & Dimension Table Summary Table
……

50. 데이터 로드 속도 비교
140.8
10.1
/login f_login
로그인 정보 추출 속도 (단위: Sec)
-93%
• 클러스터 : R4.2xlarge * 9대 (Driver 포함)
• 클러스터당 메모리 : 50GB
기존 분석환경에서 3개월 치 로그인 정보를 로드하는 속도를 비교할 때,
/login 보다 정리된 f_login 테이블에서 데이터를 로드하는 속도가 93% 개선됨

51. SQL query engine 벤치마크
SPECTRUM
벤치마크 대상 솔루션 선정시 고려한 점
1. 빠른 데이터 처리속도를 담보하고
2. 범용성 – Dashboard 제작 및 데이터 분석 모두 함께 사용가능 해야 하며
3. 기존 Infra에서 최소한의 관리 및 코스트로 변경 가능하면서
4. 비용을 optimization 할 수 있는 제품

52. SQL query engine 벤치마크
테스트에 사용된 데이터 및 추출 항목
• 데이터: 3개월 치 로그
• Login, Billing 로그
• 추출 항목: 주요 Daily KPI
• Active User / Paying User / PUR / Revenue / ARPU / ARPPU
벤치마크 측정 항목
• 결과물이 나오기까지 Runtime
• 비용

53. 솔루션 벤치마크 - 상세 설정 내용
Solution Cluster Type # of Machines Cost SQL Engine
AWS EC2
&
Spark
r4.2xlarge
• vCPU : 8
• ECU : 27
• 메모리 : 61GiB
1 - Driver
2 - Workers
1 Driver : 1 * $0.532/h
2 Workers : 2 * $0.13/h
Total : $0.792/h
PySpark
Redshift
dc2.large
• vCPU : 2
• ECU : 7
• 메모리 : 15 GiB
• 스토리지 : 0.16 TB
– SSD
• I/O : 0.60 GB/s
2
2 * $0.25/h
Total : $0.5/h
Postgre
Redshift
Spectrum
The same as Redshift 2 Redshift Cost + $5 per 1TB Postgre
Athena - - $5 per 1TB Presto

54. 솔루션 벤치마크 - 결과
0.0295
0.001
0.0101
0.007
USD
Cost
Spark Redshift Redshift Spectrum Athena
67.6
6.4
25.0
7.5
Sec Runtime (sec)
Spark Redshift Redshift Spectrum Athena
Spark Redshift Redshift Spectrum Athena
걸린시간 (sec) 67.6 6.4 25.0 7.5
걸린시간 (min) 1.13 0.11 0.42 0.13
걸린시간 (hr) 0.019 0.002 0.007 0.002
$ per hour 1.572 0.5 0.5
duration cost (USD) 0.03 0.00 0.00 -
Scan Size (mb) 1,330 1,330
tb로 환산 0.001330 0.001330
computing cost (USD) 0.0067 0.0067
Total Cost (USD) 0.0295 0.0009 0.0101 0.0067

55. 솔루션 벤치마크 - 결과
67.6
41.0
22.4
15.0 12.7
2대 4대 8대 16대 32대
Seconds
Worker 개수별
Spark SQL 처리속도
기존 분석 환경에서는 클러스터를 32대 사용해도
Redshift, Athena 각각 6.4s, 7.5s 보다 약 70~100%정도 느림

56. 솔루션 벤치마크 - 결과
가장 저렴하고 빠른건 Redshift 였지만 몇가지 단점이 있었음
클러스터 설정 및 비용
데이터 Copy
각종 key 설정

57. 솔루션 벤치마크 - 결과
가장 저렴하고 빠른건 Redshift 였지만 몇가지 단점이 있었음
1. 클러스터를 항상 띄워두거나 사용하고 싶을때만 켜야함
• 현재 온디멘드 쓰는것과 동일한 구조로 불편
2. 태생적으로 idle time에도 클러스터 개수에 따른 비용이 부과됨
3. 그리고 s3 parquet 파일을 Redshift 쪽으로 데이터를 copy 해야하는 작업이 필요함
• 데이터 이동에 따른 비용은 없지만, 설정한 클러스터 스펙에 넘치는 스토리지 용량이 필요할 경우
추가 클러스터를 띄워야 함 (비용 발생)
• copy하는데 시간이 걸림 (걸리는 시간은 미미함)
• 3개월치 정리된 유저 play 기록을 복사하는데 약 11분 걸림 (1.32GB)
4. RDB 처럼 primary_key, foreign_key를 정해줘야하고 추가로
• sort_key (정렬키), dist_type (분산 스타일), dist_key (분산키) 를 정해줘야함
쿼리 성능에 큰 영향을 미침
• Copy로 추가되는 데이터가 sort_key의 정렬을 따르지 않거나 중간에 삭제하는 레코드가 생길 경우
vaccum이라는 작업을 주기적으로 실행해야 쿼리 성능을 유지할 수 있음

58. Athena 시작하기
– Only Two Steps to start Athena
테이블 생성
S3에 저장된 Parquet 파일을 외부스키마로 설정
CREATE EXTERNAL TABLE [table name]
파티션의 데이터를 로드
MSCK REPAIR TABLE [table name]
데이터 쿼리

59. Athena – 테이블 생성
테이블 생성
S3에 저장된 Parquet 파일을 외부스키마로 설정
CREATE EXTERNAL TABLE [table name]
CREATE EXTERNAL TABLE `d_country`(
`country_code` string
, `country` string
, `is_target_country` int)
PARTITIONED BY (date STRING)
STORED AS PARQUET
LOCATION 's3://dw/d_country/’
TBLPROPERTIES ("parquet.compress"="SNAPPY");

60. Athena – 데이터 로드
파티션의 데이터를 로드
MSCK REPAIR TABLE
ALTER TABLE
MSCK REPAIR TABLE [table name]
ALTER TABLE [table name] ADD
PARTITION (dt = '2016-05-14') LOCATION 's3://dw/sub_folder’

61. Athena를 사용하기 위한 관리 포인트 자동화
스키마 설정 파티션 인식
AWS Glue
Crawler

62. 새로운 분석환경
AWS S3AWS EC2
AWS RDS
Athena
Glue

63. 새로운 분석환경의 장점
Hot하게 사용되는 로그는 Column flat하게 정리하여
Data Lake에 저장하고 Athena로 데이터에 직접 접근
데이터 전처리
리소스 절약
빠른
Ad-hoc 분석
빠른
Dashboard 생성

64. 새로운 분석환경의 장점
• 분석가가 달라져도 동일한 source 데이터를 활용하게 되므로
중복으로 발생되는 전처리 리소스를 절약함
• 속도가 빠른 Athena로 s3 파일에 직접 접근하여 쿼리가 가능해짐
• Ad-hoc한 분석할 때 시간 단축
• 새로운 지표 추가할 때 데이터 wrangling 작업을 줄이고, 배치작업
없이 바로 대시보드를 만들 수 있음

65. Write Parquet Raw Log
(Parquet)
Devsisters Data Infra After
2018년 – Data Lake
Raw Layer
Preprocessing
Indexed Log
Analytics Log
Date, Action Partition
Data Analysis
Marketing Snapshot
Date Partition
Semi-Structure
Indexing
DW Athena
Analytic
Layer
Objective Layer
CS 팀: CS 응대
분석 팀: KPI 추출
마케팅 팀: 트랜드 분석
BI 팀: BI 분석

66. Thank you
박주홍/데이터 분석 및 인프라 팀장
J.Park@devsisters.com
이준호/Business Intelligence 팀장
Junho.lee@devsisters.com