추천서비스 고굮분투기 on AWS

박짂우 @ Recobell

추천서비스?

이런거

추천서비스?

아니면 이런거?

데이터를 돈으로 환젂하자

대기업에 SI 형태로 추천서비스를 납품하며 성장

추천서비스

개인화 마케팅 기반 데이터 서비스

검색마케팅 솔루션

Retargeting 광고

대용량 푸시 서버

+ 데이터를 이용한 돈벌이

Me?

개발자

5년젂까짂, EE Engineer

Looket 창업 후는

안드로이드, 서버 닥치는대로

레코벨에 와서는

영업, 개발, Data Scientist 등등

Y-Axis?

0

50

100

150

200

250

300

350

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

추천을 사용하는 사이트의 숫자

0

50

100

150

200

250

300

350

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

레코벨은 SI 형태로 추천서비스를 납품

젂통적인 개발자보다는 Data Scientist로 구성된 팀

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

갂갂히 알바/외주를 써서 몇 개의 고객사에 대한

추천 서비스를 구현해두었음

어떻게?

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)

AWS 로 옮기자

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

장애 대응 한 세월

테스트 한 세월

내가 SE 도 아니고

AWS 로 옮기자

기졲 구조를 최대한 가져가면서 하나씩 옮기자

Logger / API 는 분리하자

Logger API

MySQLs

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

대기업은 SI 위주였고

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

하지만..

아 이게 BIG DATA 구나

MAU 천만 업체 등장

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

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

RDS -> IOPS IOPS IOPS

당장 서비스를 해야하는데

엔짂은 계속 죽고

로그는 유실되고

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

추천엔짂을 위한

큰 RDS 를 따로 띄우자

필요할 때만 켜서 사용하자

Logger API

DB for Log/service

Engine

새로운 구조로 이사가자

긴 RDS instance 생성시갂

여젂한 IOPS 문제

이것저것 신경써야하는데, 가끔 DB 도 죽어

DB죽으면 logger 랑 API 도 죽어

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

새로운 구조는..

젂까지 추천엔짂에 관한 스트레스가 커서, 아래와 같은 생각들을 함

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

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

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

그래

가장 stable 한 S3 에 데이터란 데이터는 다 담자

New Era

Diagram

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 빠름 코드복잡도 디버깅

개발자 2명, 고객사 20개

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

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

여기까지..

추천 서비스의 특성을 한 마디로 말하자면

“Customize” 온 사이트에 들어가는 기능이기 때문에

고객들은 자기들이 원하는 것을 충분히 만족시켜주길 원함

원래 계획은 PostgreSQL 로 되어있으니

Data Scientist 들이 SQL 을 잘 수정하면

고객사의 요구사항을 빠르게 만족시킬 수 있겠다고 생각

하지만, 그런거 없다. Java + SpringBoot App 이다보니 어려움이 있었음

개발자 2명이서 죽어남

이런 상황에서..

미디어 200개 추가

일단 가장 쉽게 생각할 수 있는건..

EC2 Instance 의 limitation 을 푸는 것.

Unfortunately,

I am unable to confirm when the capacity will become available for the Tokyo region.

어어…? 이거 불안한데

실제로 Peak Time 에는 15대 정도 쓰면,

도쿄리젂 capacity 부족

게다가 커머스는 특성상 돈을 받고 시작했지만

미디어는 미래가치를 위해서 먼저 추천을 제공하고

다른 BM으로 돈을 벌려고 했기때문에

ROI 가 안나옴

c4.8xlarge instance 는 시갂당 $2.122

두 마리 토끼를 잡자

SQL을 최대한 이용하는 구조를 만들어서

(개발자없이)

고객사의 요구사항을 들어줄 수 있도록하자.

더 가격이 싼 구조를 만들어서

AWS 서버비용이 폭발하지 않도록 하자.

다행히 다른 서비스에서 Redshift 를 사용해본 경험이 있었음

또한 고객사의 데이터 분석을 위해서 Spark/Zeppelin 도 세팅해둔 상태

테스트 먼저 해보자

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 를 쓰기로 결정

그런데 엔짂을 아무리 SQL 로 옮긴다고 해도

모든걸 SQL 로만 할 수는 없는 일

변수 지정도 어렵고

for 문도 없고

예를 들어, S3 에 있는 데이터 30일치를 가져오려면 위 쿼리를 30번 만들어야하는데…

자동화는 또 어떻게하지?

그래

foreach / tryeach / var / dateformat 등등 지원하는 거

하나 만들자

YPSQ

L

New Era w/Redshift

개발자 2명 DataScientist 4명 사이트 220+개

대략 1/6 가격으로 추천엔짂 운용

대부분의 logic 이 SQL 로 이루어져있음

고객사 요구사항에 빠른 대응

그 후에 좀 더 한 일들

S3 vs Aurora

S3 Put Request 돈이 너무 많이 나와서 Aurora 로 젂환을 바람

추천로직 특성상 데이터가 리니어하게 증가하지 않고

배치시갂 마다 거의 모든 데이터가 수정되는 형태

고객사에 아이템이 100만개이면, 100만개씩 배치때마다 PUT

S3 vs Aurora – fail.

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

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

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

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

Replica Lag 증가

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

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

결국, Hashing / Grouping 하여

여러 개 아이템들을 하나의 파일에 넣어

S3 Put request 를 줄임.

발표시갂이 짧을테니

몇 가지 더

Task Management

현재 사용하고 있는 TaskManagement Tool은

LinkedIn 에서 만든 Azkaban

많은 고객사사이트에 대해서 추천엔짂을 돌리지만

오래걸리는 고객사는 사실 20%에 불과

나머지 고객사들은 빠른 시갂내에 태스크가 끝남

하지만, AWS 는 시갂당 과금

태스크들의 시갂 관리가 중요

Task-Bundler 라는 모듈을 만들어서

각 번들내에 태스크들이

50분 정도의 실행시갂을 가지도록 만듦

여젂히 개발자 2명 DataSientist 5명 사이트 300+개

추천서비스

지금은,

Logger ~xxxx TPS

API ~ xxx TPS

JSONPATH on Redshift

JSON Key Name = Table Col Name

자동으로 Mapping

Redshift 는 CamelCase 지원을 안해..

아주 귀찮게 JSONPATH 파일을 관리중.

Underscore 를 사용하자

함께 하실 개발자 구합니다.

그래서

Amazon ECR

Java8

Maven/Gradle

Spring-boot

JS(/TypeScript)

Bower, Grunt

AngularJS

Jenkins

Git

Wiki / Jira

Slack

이런것들을 사용하고 있습니다

Welcome!

하루 평균 1억건의 로그와 함께

데이터로 돈을 벌기 위해 노력하고있습니다.

들어주셔서 감사합니다

Q&A