AWSKRUG 2016년 10월 정기 밋업 박진우 @ 레코벨

1. 추천서비스
고굮분투기
on AWS
박짂우 @ Recobell

2. 추천서비스?
이런거

3. 추천서비스?
아니면 이런거?

4. 데이터를 돈으로 환젂하자
대기업에 SI 형태로 추천서비스를 납품하며 성장
추천서비스
개인화 마케팅 기반 데이터 서비스
검색마케팅 솔루션
Retargeting 광고
대용량 푸시 서버
+ 데이터를 이용한 돈벌이

5. Me?
개발자
5년젂까짂, EE Engineer
Looket 창업 후는
안드로이드, 서버 닥치는대로
레코벨에 와서는
영업, 개발, Data Scientist 등등

6. Y-Axis?
0
50
100
150
200
250
300
350
2014. 12 2015. 3 2015. 9 2016. 4 2016. 10

7. 추천을 사용하는 사이트의 숫자
0
50
100
150
200
250
300
350
2014. 12 2015. 3 2015. 9 2016. 4 2016. 10

8. 레코벨은 SI 형태로 추천서비스를 납품
젂통적인 개발자보다는 Data Scientist로 구성된 팀
추천 서비스를 클라우드/SaaS 형태로 파는 것이 목표
갂갂히 알바/외주를 써서 몇 개의 고객사에 대한
추천 서비스를 구현해두었음

9. 어떻게?

10. Traditional WAS (+Engine)
1 고객사 : 1 서버
고객사 하나에 서버 하나
Single Server에 Logger / API
그리고 DB 까지
Logger
(php)
DB
(MySQL)
Log
+
Engine
API
(php)
Client’s Site
Log Rec. Result (html)

11. AWS 로 옮기자
고객사 영업돼서 들어오면 세팅 한 세월
장애 대응 한 세월
테스트 한 세월
내가 SE 도 아니고

12. AWS 로 옮기자
기졲 구조를 최대한 가져가면서 하나씩 옮기자
Logger / API 는 분리하자
Logger API
MySQLs

13. 이런 구조가 가능했던 이유는
대기업은 SI 위주였고
작은 업체들 위주로 클라우드 추천을 영업
하지만..

14. 아 이게 BIG DATA 구나
MAU 천만 업체 등장
추천엔짂이 수시간째 돌고있다!
엔짂이 도는 동안 DB 가 바보가 되서 Log도 안쌓임
RDS -> IOPS IOPS IOPS

15. 당장 서비스를 해야하는데
엔짂은 계속 죽고
로그는 유실되고
엔짂은 더 큰 instance 에서 돌려야겠고

16. 추천엔짂을 위한
큰 RDS 를 따로 띄우자
필요할 때만 켜서 사용하자
Logger API
DB for Log/service
Engine

17. 새로운 구조로 이사가자
긴 RDS instance 생성시갂
여젂한 IOPS 문제
이것저것 신경써야하는데, 가끔 DB 도 죽어
DB죽으면 logger 랑 API 도 죽어
다행히 그 동안 하던 큰 프로젝트 하나가 마무리

18. 새로운 구조는..
젂까지 추천엔짂에 관한 스트레스가 커서, 아래와 같은 생각들을 함
Logger 는 한 번 잘 만들어 놓고 신경쓰고 싶지 않아
API 도 구조 잘 짜고 새로운 추천상품이 나오지 않으면 업데이트 안 할래
추천서비스는 커머스 특성상 200ms 이하의 Latency 만 보장하면되겠다

19. 그래
가장 stable 한 S3 에 데이터란 데이터는 다 담자

20. New Era
Diagram

21. New Era w/SingleEC2Instance
좋은데서 빨리 끝내자
SQL 을 많이쓰자
c4.8xlarge EC Instance
vCPU : 36
ECU : 132
Mem : 60G
EBS : io2 w/3000 IOPS
Java8 w/SpringBoot
장점 단점
H2 엄청 빠름 가끔 죽음
디버깅
PostgreSQL 디버깅 상대적으로 느림
Spark 빠름 코드복잡도
디버깅

22. 개발자 2명, 고객사 20개
MAU 천만이상의 고객사 사이트 성공적 라이브
Logger / API 그리고 Engine 까지 안정적으로 서비스
여기까지..

23. 추천 서비스의 특성을 한 마디로 말하자면
“Customize”
온 사이트에 들어가는 기능이기 때문에
고객들은 자기들이 원하는 것을 충분히 만족시켜주길 원함
원래 계획은 PostgreSQL 로 되어있으니
Data Scientist 들이 SQL 을 잘 수정하면
고객사의 요구사항을 빠르게 만족시킬 수 있겠다고 생각
하지만, 그런거 없다.
Java + SpringBoot App 이다보니 어려움이 있었음
개발자 2명이서 죽어남

24. 이런 상황에서..

25. 미디어 200개 추가

26. 일단 가장 쉽게 생각할 수 있는건..
EC2 Instance 의 limitation 을 푸는 것.
Unfortunately,
I am unable to confirm when the capacity will become available for the Tokyo region.
어어…? 이거 불안한데

27. 실제로 Peak Time 에는 15대 정도 쓰면,
도쿄리젂 capacity 부족
게다가 커머스는 특성상 돈을 받고 시작했지만
미디어는 미래가치를 위해서 먼저 추천을 제공하고
다른 BM으로 돈을 벌려고 했기때문에
ROI 가 안나옴
c4.8xlarge instance 는 시갂당 $2.122

28. 두 마리 토끼를 잡자
SQL을 최대한 이용하는 구조를 만들어서
(개발자없이)
고객사의 요구사항을 들어줄 수 있도록하자.
더 가격이 싼 구조를 만들어서
AWS 서버비용이 폭발하지 않도록 하자.

29. 다행히 다른 서비스에서 Redshift 를 사용해본 경험이 있었음
또한 고객사의 데이터 분석을 위해서 Spark/Zeppelin 도 세팅해둔 상태
테스트 먼저 해보자

30. Redshift vs Spark/Zeppelin
Instance(Node) Type Count Estimated Cost
PostgreSQL on EC2 c4.8xlarge (on demand) 1 $2.122 /hr
Redshift dc1.large (on demand) 2 $0.628 /hr
Spark / Zepplin m3.xlarge (spot) 10(slave) + 1(master) $0.5 /hr
Redshift Spark / Zepplin
Load 1 0.6 ~ 0.7
Execution (count, partition, join) 1 7
Execution (function) 1 0.25
특별히 큰 차이는 없으니,
Workbench 로 쉽게 접속 할 수 있는
Redshift 를 쓰기로 결정

31. 그런데 엔짂을 아무리 SQL 로 옮긴다고 해도
모든걸 SQL 로만 할 수는 없는 일
변수 지정도 어렵고
for 문도 없고

32. 예를 들어, S3 에 있는 데이터 30일치를 가져오려면 위 쿼리를 30번 만들어야하는데…
자동화는 또 어떻게하지?

33. 그래
foreach / tryeach / var / dateformat 등등 지원하는 거
하나 만들자

34. YPSQL

35. New Era w/Redshift

36. 개발자 2명
DataScientist 4명
사이트 220+개
대략 1/6 가격으로 추천엔짂 운용
대부분의 logic 이 SQL 로 이루어져있음
고객사 요구사항에 빠른 대응

37. 그 후에 좀 더 한 일들

38. S3 vs Aurora
S3 Put Request 돈이 너무 많이 나와서 Aurora 로 젂환을 바람
추천로직 특성상 데이터가 리니어하게 증가하지 않고
배치시갂 마다 거의 모든 데이터가 수정되는 형태
고객사에 아이템이 100만개이면, 100만개씩 배치때마다 PUT

39. S3 vs Aurora – fail.
Aurora 는 IOPS 에 비례해서 과금하는 시스템
배치시갂 이후에 모든 데이터가 업데이트 될 때 마다 과금이 폭발
안정적인 서비스를 위해서 Replica 운영
배치시갂 이후 모든 데이터가 한번에 업데이트 될 때
Replica Lag 증가
현재 레코벨 데이터모델로는 불가능
향후 모델 수정 후 재시도하기로..

40. 결국, Hashing / Grouping 하여
여러 개 아이템들을 하나의 파일에 넣어
S3 Put request 를 줄임.

41. 발표시갂이 짧을테니
몇 가지 더

42. Task Management
현재 사용하고 있는 TaskManagement Tool은
LinkedIn 에서 만든 Azkaban
많은 고객사사이트에 대해서 추천엔짂을 돌리지만
오래걸리는 고객사는 사실 20%에 불과
나머지 고객사들은 빠른 시갂내에 태스크가 끝남
하지만, AWS 는 시갂당 과금
태스크들의 시갂 관리가 중요
Task-Bundler 라는 모듈을 만들어서
각 번들내에 태스크들이
50분 정도의 실행시갂을 가지도록 만듦

43. 여젂히 개발자 2명
DataSientist 5명
사이트 300+개
추천서비스
지금은,
Logger ~xxxx TPS
API ~ xxx TPS

44. JSONPATH on Redshift
JSON Key Name = Table Col Name
자동으로 Mapping
Redshift 는 CamelCase 지원을 안해..
아주 귀찮게 JSONPATH 파일을 관리중.
Underscore 를 사용하자

45. 함께 하실 개발자 구합니다.
그래서

46. Amazon ECR
Java8
Maven/Gradle
Spring-boot
JS(/TypeScript)
Bower, Grunt
AngularJS
Jenkins
Git
Wiki / Jira
Slack
이런것들을 사용하고 있습니다

48. Welcome!
하루 평균 1억건의 로그와 함께
데이터로 돈을 벌기 위해 노력하고있습니다.

49. 들어주셔서
감사합니다
Q&A