cloud taekwon 2015 - aws를 활용한 로그 분석

스타트업과 개발자들을 위한 AWS 클라우드 태권

AWS를 활용한 로그 분석

VCNC

김명보


발표자 소개

• 김명보

• VCNC에서 비트윈을 개발하고 있는 개발자

• 서버팀과 데이터 팀에서 잡다한 것들을 개발하는 중

• 회사에서 AWS에 돈을 쓰는 것을 담당


비트윈

• 커플들을 위한 모바일 서비스

• 아이폰, 안드로이드 어플리케이션 제공

• 채팅, 기념일, 사진, 메모, 캘린더 기능 제공

• 전 세계에서 1300만+ 다운로드 (as of 2015.08)


비트윈 데이트

• 커플/솔로들을 위한 데이트 코스 추천 서비스

• 아이폰, 안드로이드 어플리케이션 제공

• 지역별 맛집, 구경거리 등에 대한 리뷰 공유

• 한국에서 30만+ 다운로드 (as of 2015.08)


오늘의 발표

• 데이터 분석 시스템 Migration 한 이야기

• 왜 새로운 시스템을 만들 수 밖에 없었나?

• In-house에서 AWS로

• MapReduce로부터 Spark/Zeppelin으로

• 데이터 분석을 통한 Retention 개선 및 개발 방향 설정 경험


과거의 로그 분석 시스템


VCNC의 과거 분석 시스템 – (1)

AWS S3Server

HadoopHDFS + HBase

HadoopMapReduce

MySQL


VCNC의 과거 분석 시스템 – (2)

• 매일 돌리는 주기적인 분석 작업과 On-demand 분석이 요구됨

• 서버가 Json 으로 로그를 남김

• 서버에서 하루에 한 번씩 S3로 업로드

• 회사 내에 데이터 분석용 HDFS + HBase + MapReduce 클러스터 존재

• 아침에 S3로부터 로그를 받아와서 HBase에 쏟아 부음

• 분석을 돌려 결과를 MySQL을 저장함


과거 분석 시스템의 문제점

• 처음엔 1시간 밖에 안 걸리고 좋았음

• 구성후 2년이 지나니 10시간도 넘게 걸림

• 지금부터 유저 수가 2배가 되면????

• 여러 대의 서버와 오픈 소스 스택을 직접 관리해야 함

• 갖가지 난관과 장애의 연속

• 분석 할 때마다 방대한 MapReduce 코드를 작성해야 함



• 잦은 하드 디스크 고장

• 메모리

• Hadoop 2.0.0에 Data Corruption이 퍼지는 버그 존재

• 메모리는 역시 삼성!

• 네트워크 – 1G는 병목, 10G는 비쌈

• 늘어나는 관리비용

• 더 이상 값싼 PC로 분석 클러스터 유지 불가능



• GC timeout

• HDFS/HBase/MapReduce

• 여러 Java stack 사이의 효과적인 메모리 할당의 어려움• YARN은 당시에 퍼포먼스 문제가 있는 초기 단계

• MySQL이 너무 느림

• 분석을 위한 index가 여러 column에 걸쳐서 존재 – gender, age, country, device, …



• 아침에 S3로부터 로그 복사가 너무 오래 걸림

• 사장님 : 오늘 분석 결과 언제 나와요?

• 데이터 팀 : 로그 파일들 아직 바다 건너고 있는데요…

• 사장님 : …


새로운 로그 분석 시스템


새로운 분석 시스템 - Spark

• 메모리를 활용하는 MapReduce

• 훨씬 다양한 API

• distinct, groupByKey, sort, join, …

• 재사용하는 데이터는 cache

• Map같은 연산은 lazy 하게 처리


새로운 분석 시스템 – AWS

Log bucket On-demandSpark Cluster 1

On-demandSpark Cluster 2

Daily AnalysisSpark Cluster

Placement Group

Zeppelin / Dashboard UsersResultbucket


새로운 분석 시스템 – EC2/SPOT

• 필요할 때 cluster 크기를 키우거나 추가적인 cluster를 띄울 수 있다

• 여러 개의 분석을 필요할 경우 동시에 돌릴 수 있다

• 동시에 돌릴 수 있으면, 가격은 유지하면서 모든 분석이 끝나는 시간을 앞당길 수

있다.

• 같은 작업에 많은 EC2 instance를 사용하더라도 결국 같은 비용

• SPOT의 싼 비용을 활용


새로운 분석 시스템 – S3• 이미 비트윈의 로그가 저장되어 있음

• EC2에서 S3의 접근 속도도 좋음

• r3.8xlarge (10GB NIC) 에서 200~330MBytes/sec 나옴


새로운 분석 시스템 – R3 (X1)

• R3 instances

• 메모리 optimized instance – 244GB

• 320GB SSD x 2

• Shuffle 결과 임시 저장할 때 유리함

• X1 instances (출시 예고)

• 2TB 메모리를 가지는 instance


새로운 분석 시스템 – R3 (X1)


새로운 분석 시스템– Placement Group

• Instance간의 network latency 가 낮아짐

• RTT가 0.3 ms 에서 0.2 ms 로 감소함 ( Tokyo Region 기준 )

• Spakr의 Wide-dependency shuffle operation에서 유리함

• sort, groupBy 등


Migration의 효과

• 과거에는 당일 분석을 중단시키면서 오래 걸리는 분석을 돌리기

어려웠음

• 예) 1년치 로그 전체에 대한 분석

• 현재는 당일 분석과 시간이 오래 걸리는 분석을 동시에 실행 가능


Migration의 효과

• 비트윈의 버그/이슈 추적에 큰 도움이 됨

• 어떤 유저가 앱이 로그아웃 되었다는 데 이유를 모르겠다

• 서버의 버그 + 유저의 3달 전의 행동에 의해서 생긴 문제

• 3달 치의 해당 유저의 행동 로그와 Exception 로그를 비교 분석하여 원인 발견

• 진입 장벽이 낮아져 더 많은 개발 팀원들이 데이터 분석에 관심을

가지기 시작함


SPARK 분석 예시


휴면 계정 보호법 적용

• 1년 이상 사용하지 않은 한국 사용자들의 데이터를 따로 분리 보관해야

함

• 사용자들이 마지막으로 접근한 시점이 DB에 적혀 있지 않았음

• 전체 로그 파일 (압축 해제 시 200TB+) 에 대한 분석이 필요

• 6대의 r3.8xlarge Cluster로 하루 만에 전수 조사 종료


Wake-up push worker

• 비트윈 가입 후 3일간 채팅을 쓰지 않으면 그 후 돌아올 가능성이

낮음을 발견

• 낮은 채팅 사용으로 초기 이탈이 우려되는 유저들에게 채팅 사용을

유도하는 푸쉬 메세지를 전송

• 정확한 효과 측정을 위해서 같은 조건에서 푸쉬를 보내지 않는 10 ~

20%의 대조군 설정


Wake-up push worker - 결과


BetweenDate 데이터 분석

• 새로운 서비스 출시 (2015.06)

• 기존 데이터 분석 시스템에 그대로 적용

• 복잡한 추가 시스템 개발 없이 로그가 쌓이는 S3 bucket과 Zeppelin

notebook만 추가됨


BetweenDate 데이터 분석

• 데이터 분석을 통해서 향후 개발 방향 설정

• 생각보다 많은 유저들이 오직 보기만 하는데 사용

• 참여도에 따라 Retention이 달라짐

• 유저들의 참여를 유도하는 이벤트 진행

• 소셜화(팔로우, 팔로잉) 기능 우선 개발 하기로 결정


결론

• 수개월에 걸쳐 데이터 분석 시스템을 전부 재구성

• 빠르고 효율적이며 범용적인 Apache Spark, Apache Zeppelin을 활용

• AWS를 활용, 최대한 시스템을 간단하게 구성하여 운영 비용을 줄임

• 10배 이상 빠르고 간편한 시스템을 만듦


THANK YOU

cloud taekwon 2015 - aws를 활용한 로그 분석

Technology