1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박진우
개발본부장, 레코벨
추천서비스 고군분투기
on AWS

2. Me?
몇 년 전까지만 해도, 반도체하고 싶어한 학생
어쩌다가 창업을 하고,
회사를 팔고,
지금은 레코벨에서 빅데이터를 경험중
AWS 는 사용 6년차

3. 본 강연에서 다룰 내용
이번 강연에서는 빅데이터에 관심있으신 분들에게 도움이
될 내용들을 다룹니다. 레코벨의 추천서비스가 성장해온
과정을 통해서, 기존의 IDC 환경에서 Cloud환경으로
어떻게 옮겨왔는지, Cloud 환경에서의 구조는 어떤식으로
바뀌어왔는지, 그 과정에서 AWS 의 어떤 서비스들을
사용하였는지를 소개드립니다.

5. 데이터가 돈이 된다는 것을 증명하는 사람들
- 추천서비스
- 개인화 마케팅 서비스
- 검색광고 솔루션
- Retargeting 광고
- 대용량 푸시 서버
+ 데이터를 이용한 돈벌이

6. 추천서비스?

7. 추천서비스

8. 추천서비스 사용 사이트 숫자
0
50
100
150
200
250
300
350
2014. 12 2015. 3 2015. 9 2016. 4 2016. 10

9. 본 강연에서 다룰 내용
이번 강연에서는 빅데이터에 관심있으신 분들에게 도움이
될 내용들을 다룹니다. 레코벨의 추천서비스가 성장해온
과정을 통해서, 기존의 IDC 환경에서 Cloud환경으로
어떻게 옮겨왔는지, Cloud 환경에서의 Architecture는
어떤식으로 바뀌어왔는지, 그 과정에서 AWS 의 어떤
서비스들을 사용하였는지를 소개드립니다.
추천서비스 IDC -> Cloud
Cloud Architecture AWS Service

10. 데이터 분석?
Logging Analysis Operation

11. 레코벨은 대기업에 SI 형태로 추천서비스 제공
Engineer 보다는 Data Scientist 로 구성된 팀
추천서비스를 클라우드 위에 SaaS 형태로 파는 것이 목표
간간히 알바/외주를 써서 몇 개의 고객사에 대한 추천시스템을 IDC 에 구현

12. Server on IDC
Legacy on IDC
Logger
API
DB
(+Engine) Client Site
User Behavior
Result (HTML)
JS SDK

13. Server on IDC
Legacy on IDC
Logger
API
DB
Client Site
User Behavior
Result (HTML)
JS SDK
고객사 영업돼서 들어오면 세팅 한 세월
장애 대응 한 세월
테스트 한 세월
내가 SE 도 아니고

14. Server on IDC
To AWS
Logger
API
DB

15. AWS RDS
• 관리용이성
• 뛰어난 확장성
• 가용성 및 내구성
• 빠른속도 (SSD)
• 보안
• 저렴한비용

16. MySQLs
Logger API

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

18. MAU 천만 업체 등장
추천엔진이 수시간째 돌고있다!
엔진이 도는 동안 DB 가 바보가 되서 Log도 안쌓임

19. AWS RDS
• 관리용이성
• 뛰어난 확장성
• 가용성 및 내구성
• 빠른속도 (SSD)
• 보안
• 저렴한비용

20. AWS RDS
• 빠른속도 (SSD)
• 저렴한비용(?)
• SSD $0.138/GB.Month

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

22. Logging & Result
Logger API
Partial Log
Recommendation Result
Recommendation Engine

23. 긴 RDS instance 생성시간
여전한 IOPS 문제
아.. 안정성이여
다행히 그 동안 하던 큰 프로젝트 하나가 마무리

24. 새로운 구조를 위한 숙제
Logger 는 한 번 잘 만들어 놓고 신경쓰고 싶지 않아
API 도 구조 잘 짜고 새로운 추천상품이 나오지 않으면 업데이트 안 할래
Engine 의 안정성에 신경쓰고 싶지 않아
추천서비스는 커머스 특성상 200ms 이하의 Latency 만 보장

25. Simple Storage Service (S3)
• 간편성
• 내구성
• 확장가능
• 보안
• 가용성
• 저렴한비용
• 간편한 데이터 전송
• 통합
• 손쉬운관리
그래 데이터란 데이터는 다 S3 에 넣자

26. Infra on AWS
Candidate
Logger API
Client Site
User Behavior Result (JSON)
Engine

27. Logger
Kinesis
PUT
Producer Consumer
S3
Log Bucket

28. Amazon Kinesis Stream
Real-Time Streaming Data Buffer
• 실시간
• 사용편의성
• 병렬처리
• 탄력성
• 저렴한비용
• 안정성 (~24H)

29. Engine
좋은데서 빨리 끝내자
기존 SQL 쓰던 것을 이어가자
c4.8xlarge EC2 Instance
• vCPU : 36
• ECU : 132
• Mem : 60G
EBS : io2 w/3000 IOPS
Java8 w/SpringBoot

30. Engine – DB선택
장점 단점
H2 엄청 빠름 가끔 죽음..
디버깅..
PostgreSQL 디버깅 상대적으로 느림
Spark 빠름 코드복잡도..
디버깅..

31. API
"recType": "a002",
"iids": "354427372",
"results”:
[
{
"itemId": "362054013",
"categoryId": "5502167”,
"rank": 1,
"score": 1,
S3 로 부터 데이터를 가져와서, JSON 형태로 내보내는 것

32. MAU 천만이상의 고객사 사이트 성공적 라이브
Logger / API 그리고 Engine 까지 안정적으로 서비스
AWS 위에 고객사 20개

33. 사이트 200개 추가

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

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

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

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

38. Redshift
AWS 의 Data Warehouse 서비스
- 신속함
- 저렴함
- 간편성
- 탄력성
- 보안
- 호환성 (Postgresql)

39. Spark / Zeppelin
- Spark
- MapReduce 와 유사
- 높은 확장성
- 간단한 인터페이스
- In-Memory
- Hadoop 호환
- Zeppelin
- Web-based Notebook
- 정말정말 쉬움

40. Redshift vs. Spark/Zeppelin
특별히 크게 차이 나지 않고,
Redshift 를 ReservedNode 로 사용하면 더 싸지고,
상용 Workbench 로 쉽게 접속가능한 Redshift 로 결정
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

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

43. 하지만 방심해선 안되죠..

44. Simple Storage Service (S3)
• 간편성
• 내구성
• 확장가능
• 보안
• 가용성
• 저렴한비용
• 간편한 데이터 전송
• 통합
• 손쉬운관리

45. 비용
100만개의 상품을 가진 고객사라면 PUT 비용이…
한 번 업데이트 하는데,
$0.0047 / 1,000 * 1,000,000 = $4.7
하루에 세 번이면, 한달에..
$4.7 * 3 * 30 = $423
DB 로 옮겨야할까..?

46. Aurora
AWS 의 고성능, 고-확장성 DB
- 고성능
- 뛰어난 보안
- MySQL/PostgreSQL 호환
- 뛰어난 확장성
- 높은 가용성 및 내구성
- 완전 관리형

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

48. Simple Storage Service (S3)
• 간편성
• 내구성
• 확장가능
• 보안
• 가용성
• 저렴한비용
• 간편한 데이터 전송
• 통합
• 손쉬운관리

49. Hashing
Hashing 을 하여, 여러개의 결과 파일을 하나의 파일에
압축시켜 놓자.
하나의 ”압축”파일에는 약 20개의 원본파일이 들어가도
괜찮을 것 같다.
PUT 비용 대략 1/20

50. 한가지만 더

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

52. 체크 포인트
- RDS 를 사용할 땐 IOPS 에 주의하자.
- 웬만한 데이터는 S3 에 담자.
- 스트리밍 데이터에는 Kinesis 를 사용하자.
- Aurora 의 요금 체계를 숙지하자.
- Redshift 꼭 쓰자.

53. We wants You!
(recruit@recobell.com)

54. 함께 해주셔서 감사합니다!

55. https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!