© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

박진우

개발본부장, 레코벨

추천서비스 고군분투기

on AWS

Me?

몇 년 전까지만 해도, 반도체하고 싶어한 학생

어쩌다가 창업을 하고,

회사를 팔고,

지금은 레코벨에서 빅데이터를 경험중

AWS 는 사용 6년차

본 강연에서 다룰 내용

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

데이터가 돈이 된다는 것을 증명하는 사람들

- 추천서비스

- 개인화 마케팅 서비스

- 검색광고 솔루션

- Retargeting 광고

- 대용량 푸시 서버

+ 데이터를 이용한 돈벌이

추천서비스?

추천서비스

추천서비스 사용 사이트 숫자

0

50

100

150

200

250

300

350

2014. 12 2015. 3 2015. 9 2016. 4 2016. 10

본 강연에서 다룰 내용

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

추천서비스 IDC -> Cloud

Cloud Architecture AWS Service

데이터 분석?

Logging Analysis Operation

레코벨은 대기업에 SI 형태로 추천서비스 제공

Engineer 보다는 Data Scientist 로 구성된 팀

추천서비스를 클라우드 위에 SaaS 형태로 파는 것이 목표

간간히 알바/외주를 써서 몇 개의 고객사에 대한 추천시스템을 IDC 에 구현

Server on IDC

Legacy on IDC

Logger

API

DB

(+Engine) Client Site

User Behavior

Result (HTML)

JS SDK

Server on IDC

Legacy on IDC

Logger

API

DB Client Site

User Behavior

Result (HTML)

JS SDK

고객사 영업돼서 들어오면 세팅 한 세월

장애 대응 한 세월

테스트 한 세월

내가 SE 도 아니고

Server on IDC

To AWS

Logger

API

DB

AWS RDS

• 관리용이성

• 뛰어난 확장성

• 가용성 및 내구성

• 빠른속도 (SSD)

• 보안

• 저렴한비용

MySQLs

Logger API

이런 구조가 가능했던 이유는

대기업은 SI 위주였고

작은 업체들 위주로 클라우드 추천을 영업

하지만..

MAU 천만 업체 등장

추천엔진이 수시간째 돌고있다!

엔진이 도는 동안 DB 가 바보가 되서 Log도 안쌓임

AWS RDS

• 관리용이성

• 뛰어난 확장성

• 가용성 및 내구성

• 빠른속도 (SSD) • 보안

• 저렴한비용

AWS RDS

• 빠른속도 (SSD)

• 저렴한비용(?) • SSD $0.138/GB.Month

당장 서비스를 해야하는데

엔진은 계속 돌고

로그는 유실되고

엔진은 더 큰 instance 에서 돌려야겠고

Logging & Result

Logger API

Partial Log

Recommendation Result

Recommendation Engine

긴 RDS instance 생성시간

여전한 IOPS 문제

아.. 안정성이여

다행히 그 동안 하던 큰 프로젝트 하나가 마무리

새로운 구조를 위한 숙제

Logger 는 한 번 잘 만들어 놓고 신경쓰고 싶지 않아

API 도 구조 잘 짜고 새로운 추천상품이 나오지 않으면 업데이트 안 할래

Engine 의 안정성에 신경쓰고 싶지 않아

추천서비스는 커머스 특성상 200ms 이하의 Latency 만 보장

Simple Storage Service (S3)

• 간편성

• 내구성

• 확장가능

• 보안

• 가용성

• 저렴한비용

• 간편한 데이터 전송

• 통합

• 손쉬운관리

그래 데이터란 데이터는 다 S3 에 넣자

Infra on AWS

Candidate

Logger API

Client Site

User Behavior Result (JSON)

Engine

Logger

Kinesis

PUT

Producer Consumer

S3

Log Bucket

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

Engine – DB선택

장점 단점

H2 엄청 빠름 가끔 죽음..

디버깅..

PostgreSQL 디버깅 상대적으로 느림

Spark 빠름 코드복잡도..

디버깅..

API

"recType": "a002",

"iids": "354427372",

"results”:

[

{

"itemId": "362054013",

"categoryId": "5502167”,

"rank": 1,

"score": 1,

S3 로 부터 데이터를 가져와서, JSON 형태로 내보내는 것

MAU 천만이상의 고객사 사이트 성공적 라이브

Logger / API 그리고 Engine 까지 안정적으로 서비스

AWS 위에 고객사 20개

사이트 200개 추가

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 서버비용이 폭발하지 않도록 하자.

Redshift

AWS 의 Data Warehouse 서비스

- 신속함

- 저렴함

- 간편성

- 탄력성

- 보안

- 호환성 (Postgresql)

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+

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

Simple Storage Service (S3)

• 간편성

• 내구성

• 확장가능

• 보안

• 가용성

•저렴한비용 • 간편한 데이터 전송

• 통합

• 손쉬운관리

비용

100만개의 상품을 가진 고객사라면 PUT 비용이…

한 번 업데이트 하는데,

$0.0047 / 1,000 * 1,000,000 = $4.7

하루에 세 번이면, 한달에..

$4.7 * 3 * 30 = $423

DB 로 옮겨야할까..?

Aurora

AWS 의 고성능, 고-확장성 DB

- 고성능

- 뛰어난 보안

- MySQL/PostgreSQL 호환

- 뛰어난 확장성

- 높은 가용성 및 내구성

- 완전 관리형

실패

Aurora 는 IOPS 에 비례해서 과금하는 시스템

배치시간 이후에 모든 데이터가 업데이트 될 때 마다 과금이 폭발

안정적인 서비스를 위해서 Replica 운영 필수

배치시간 이후 모든 데이터가 한번에 업데이트 될 때

Replica Lag 증가

현재 레코벨 데이터모델로는 불가능

향후 모델 수정 후 재시도하기로..

Simple Storage Service (S3)

• 간편성

• 내구성

• 확장가능

• 보안

• 가용성

•저렴한비용 • 간편한 데이터 전송

• 통합

• 손쉬운관리

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! (recruit@recobell.com)

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

https://www.awssummit.kr

AWS Summit 모바일 앱을 통해 지금 세션 평가에 참여하시면, 행사후 기념품을 드립니다.

#AWSSummitKR 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요.

발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 공유될 예정입니다.

여러분의 피드백을 기다립니다!