Download - 레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박진우
개발본부장, 레코벨
추천서비스 고군분투기
on AWS
본 강연에서 다룰 내용
이번 강연에서는 빅데이터에 관심있으신 분들에게 도움이 될 내용들을 다룹니다. 레코벨의 추천서비스가 성장해온 과정을 통해서, 기존의 IDC 환경에서 Cloud환경으로 어떻게 옮겨왔는지, Cloud 환경에서의 구조는 어떤식으로 바뀌어왔는지, 그 과정에서 AWS 의 어떤 서비스들을 사용하였는지를 소개드립니다.
데이터가 돈이 된다는 것을 증명하는 사람들
- 추천서비스
- 개인화 마케팅 서비스
- 검색광고 솔루션
- Retargeting 광고
- 대용량 푸시 서버
+ 데이터를 이용한 돈벌이
본 강연에서 다룰 내용
이번 강연에서는 빅데이터에 관심있으신 분들에게 도움이 될 내용들을 다룹니다. 레코벨의 추천서비스가 성장해온 과정을 통해서, 기존의 IDC 환경에서 Cloud환경으로 어떻게 옮겨왔는지, Cloud 환경에서의 Architecture는 어떤식으로 바뀌어왔는지, 그 과정에서 AWS 의 어떤 서비스들을 사용하였는지를 소개드립니다.
추천서비스 IDC -> Cloud
Cloud Architecture AWS Service
레코벨은 대기업에 SI 형태로 추천서비스 제공
Engineer 보다는 Data Scientist 로 구성된 팀
추천서비스를 클라우드 위에 SaaS 형태로 파는 것이 목표
간간히 알바/외주를 써서 몇 개의 고객사에 대한 추천시스템을 IDC 에 구현
Server on IDC
Legacy on IDC
Logger
API
DB Client Site
User Behavior
Result (HTML)
JS SDK
고객사 영업돼서 들어오면 세팅 한 세월
장애 대응 한 세월
테스트 한 세월
내가 SE 도 아니고
새로운 구조를 위한 숙제
Logger 는 한 번 잘 만들어 놓고 신경쓰고 싶지 않아
API 도 구조 잘 짜고 새로운 추천상품이 나오지 않으면 업데이트 안 할래
Engine 의 안정성에 신경쓰고 싶지 않아
추천서비스는 커머스 특성상 200ms 이하의 Latency 만 보장
Simple Storage Service (S3)
• 간편성
• 내구성
• 확장가능
• 보안
• 가용성
• 저렴한비용
• 간편한 데이터 전송
• 통합
• 손쉬운관리
그래 데이터란 데이터는 다 S3 에 넣자
Amazon Kinesis Stream
Real-Time Streaming Data Buffer
• 실시간
• 사용편의성
• 병렬처리
• 탄력성
• 저렴한비용
• 안정성 (~24H)
Engine
좋은데서 빨리 끝내자
기존 SQL 쓰던 것을 이어가자
c4.8xlarge EC2 Instance • vCPU : 36
• ECU : 132
• Mem : 60G
EBS : io2 w/3000 IOPS
Java8 w/SpringBoot
API
"recType": "a002",
"iids": "354427372",
"results”:
[
{
"itemId": "362054013",
"categoryId": "5502167”,
"rank": 1,
"score": 1,
S3 로 부터 데이터를 가져와서, JSON 형태로 내보내는 것
Problem 1
추천 서비스의 특성을 한 마디로 말하자면
“Customize” 온 사이트에 들어가는 기능이기 때문에
고객들은 자기들이 원하는 것을 충분히 만족시켜주길 원함
원래 계획은 PostgreSQL 로 되어있으니
Data Scientist 들이 SQL 을 잘 수정하면
고객사의 요구사항을 빠르게 만족시킬 수 있겠다고 생각
하지만, 그런거 없다. Java + SpringBoot App 이다보니 어려움이 있었음
개발자 2명이서 죽어남
Problem 2
일단 가장 쉽게 생각할 수 있는건..
EC2 Instance 의 limitation 을 푸는 것.
Unfortunately,
I am unable to confirm when the capacity will become available
for the Tokyo region.
어어…? 이거 불안한데
Problem 2+
실제로 Peak Time 에는 15대 정도 쓰면,
도쿄리전 capacity 부족
게다가 커머스는 특성상 돈을 받고 시작했지만
미디어는 미래가치를 위해서 먼저 추천을 제공하고
다른 BM으로 돈을 벌려고 했기때문에
ROI 가 안나옴
c4.8xlarge instance 는 시간당 $2.122
두 마리 토끼를 잡자
SQL을 최대한 이용하는 구조를 만들어서
(개발자없이) 고객사의 요구사항을 들어줄 수 있도록하자.
더 가격이 싼 구조를 만들어서
AWS 서버비용이 폭발하지 않도록 하자.
Spark / Zeppelin
- Spark - MapReduce 와 유사
- 높은 확장성
- 간단한 인터페이스
- In-Memory
- Hadoop 호환
- Zeppelin - Web-based Notebook
- 정말정말 쉬움
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
결과
대략 1/6 가격으로 추천엔진 운용
• 대부분의 logic 이 SQL 로 이루어져있음
고객사 요구사항에 빠른 대응
개발자 2명 / Data Scientist 4명
사이트 220+
비용
100만개의 상품을 가진 고객사라면 PUT 비용이…
한 번 업데이트 하는데,
$0.0047 / 1,000 * 1,000,000 = $4.7
하루에 세 번이면, 한달에..
$4.7 * 3 * 30 = $423
DB 로 옮겨야할까..?
실패
Aurora 는 IOPS 에 비례해서 과금하는 시스템
배치시간 이후에 모든 데이터가 업데이트 될 때 마다 과금이 폭발
안정적인 서비스를 위해서 Replica 운영 필수
배치시간 이후 모든 데이터가 한번에 업데이트 될 때
Replica Lag 증가
현재 레코벨 데이터모델로는 불가능
향후 모델 수정 후 재시도하기로..
Hashing
Hashing 을 하여, 여러개의 결과 파일을 하나의 파일에 압축시켜 놓자.
하나의 ”압축”파일에는 약 20개의 원본파일이 들어가도 괜찮을 것 같다.
PUT 비용 대략 1/20
Task Management
현재 사용하고 있는 TaskManagement Tool은
LinkedIn 에서 만든 Azkaban
많은 고객사사이트에 대해서 추천엔진을 돌리지만
오래걸리는 고객사는 사실 20%에 불과
나머지 고객사들은 빠른 시간내에 태스크가 끝남
하지만, AWS 는 시간당 과금
태스크들의 시간 관리가 중요
Task-Bundler 라는 모듈을 만들어서
각 번들내에 태스크들이
50분 정도의 실행시간을 가지도록 만듦
체크 포인트
- RDS 를 사용할 땐 IOPS 에 주의하자.
- 웬만한 데이터는 S3 에 담자.
- 스트리밍 데이터에는 Kinesis 를 사용하자.
- Aurora 의 요금 체계를 숙지하자.
- Redshift 꼭 쓰자.
We wants You! ([email protected])