Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

추천서비스고군분투기 On Aws - 박진우 (레코벨)

1,838 views

Published on

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

Published in: Technology
  • Be the first to comment

추천서비스고군분투기 On Aws - 박진우 (레코벨)

  1. 1. 추천서비스 고굮분투기 on AWS 박짂우 @ Recobell
  2. 2. 추천서비스? 이런거
  3. 3. 추천서비스? 아니면 이런거?
  4. 4. 데이터를 돈으로 환젂하자 대기업에 SI 형태로 추천서비스를 납품하며 성장 추천서비스 개인화 마케팅 기반 데이터 서비스 검색마케팅 솔루션 Retargeting 광고 대용량 푸시 서버 + 데이터를 이용한 돈벌이
  5. 5. Me? 개발자 5년젂까짂, EE Engineer Looket 창업 후는 안드로이드, 서버 닥치는대로 레코벨에 와서는 영업, 개발, Data Scientist 등등
  6. 6. Y-Axis? 0 50 100 150 200 250 300 350 2014. 12 2015. 3 2015. 9 2016. 4 2016. 10
  7. 7. 추천을 사용하는 사이트의 숫자 0 50 100 150 200 250 300 350 2014. 12 2015. 3 2015. 9 2016. 4 2016. 10
  8. 8. 레코벨은 SI 형태로 추천서비스를 납품 젂통적인 개발자보다는 Data Scientist로 구성된 팀 추천 서비스를 클라우드/SaaS 형태로 파는 것이 목표 갂갂히 알바/외주를 써서 몇 개의 고객사에 대한 추천 서비스를 구현해두었음
  9. 9. 어떻게?
  10. 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. 11. AWS 로 옮기자 고객사 영업돼서 들어오면 세팅 한 세월 장애 대응 한 세월 테스트 한 세월 내가 SE 도 아니고
  12. 12. AWS 로 옮기자 기졲 구조를 최대한 가져가면서 하나씩 옮기자 Logger / API 는 분리하자 Logger API MySQLs
  13. 13. 이런 구조가 가능했던 이유는 대기업은 SI 위주였고 작은 업체들 위주로 클라우드 추천을 영업 하지만..
  14. 14. 아 이게 BIG DATA 구나 MAU 천만 업체 등장 추천엔짂이 수시간째 돌고있다! 엔짂이 도는 동안 DB 가 바보가 되서 Log도 안쌓임 RDS -> IOPS IOPS IOPS
  15. 15. 당장 서비스를 해야하는데 엔짂은 계속 죽고 로그는 유실되고 엔짂은 더 큰 instance 에서 돌려야겠고
  16. 16. 추천엔짂을 위한 큰 RDS 를 따로 띄우자 필요할 때만 켜서 사용하자 Logger API DB for Log/service Engine
  17. 17. 새로운 구조로 이사가자 긴 RDS instance 생성시갂 여젂한 IOPS 문제 이것저것 신경써야하는데, 가끔 DB 도 죽어 DB죽으면 logger 랑 API 도 죽어 다행히 그 동안 하던 큰 프로젝트 하나가 마무리
  18. 18. 새로운 구조는.. 젂까지 추천엔짂에 관한 스트레스가 커서, 아래와 같은 생각들을 함 Logger 는 한 번 잘 만들어 놓고 신경쓰고 싶지 않아 API 도 구조 잘 짜고 새로운 추천상품이 나오지 않으면 업데이트 안 할래 추천서비스는 커머스 특성상 200ms 이하의 Latency 만 보장하면되겠다
  19. 19. 그래 가장 stable 한 S3 에 데이터란 데이터는 다 담자
  20. 20. New Era Diagram
  21. 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. 22. 개발자 2명, 고객사 20개 MAU 천만이상의 고객사 사이트 성공적 라이브 Logger / API 그리고 Engine 까지 안정적으로 서비스 여기까지..
  23. 23. 추천 서비스의 특성을 한 마디로 말하자면 “Customize” 온 사이트에 들어가는 기능이기 때문에 고객들은 자기들이 원하는 것을 충분히 만족시켜주길 원함 원래 계획은 PostgreSQL 로 되어있으니 Data Scientist 들이 SQL 을 잘 수정하면 고객사의 요구사항을 빠르게 만족시킬 수 있겠다고 생각 하지만, 그런거 없다. Java + SpringBoot App 이다보니 어려움이 있었음 개발자 2명이서 죽어남
  24. 24. 이런 상황에서..
  25. 25. 미디어 200개 추가
  26. 26. 일단 가장 쉽게 생각할 수 있는건.. EC2 Instance 의 limitation 을 푸는 것. Unfortunately, I am unable to confirm when the capacity will become available for the Tokyo region. 어어…? 이거 불안한데
  27. 27. 실제로 Peak Time 에는 15대 정도 쓰면, 도쿄리젂 capacity 부족 게다가 커머스는 특성상 돈을 받고 시작했지만 미디어는 미래가치를 위해서 먼저 추천을 제공하고 다른 BM으로 돈을 벌려고 했기때문에 ROI 가 안나옴 c4.8xlarge instance 는 시갂당 $2.122
  28. 28. 두 마리 토끼를 잡자 SQL을 최대한 이용하는 구조를 만들어서 (개발자없이) 고객사의 요구사항을 들어줄 수 있도록하자. 더 가격이 싼 구조를 만들어서 AWS 서버비용이 폭발하지 않도록 하자.
  29. 29. 다행히 다른 서비스에서 Redshift 를 사용해본 경험이 있었음 또한 고객사의 데이터 분석을 위해서 Spark/Zeppelin 도 세팅해둔 상태 테스트 먼저 해보자
  30. 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. 31. 그런데 엔짂을 아무리 SQL 로 옮긴다고 해도 모든걸 SQL 로만 할 수는 없는 일 변수 지정도 어렵고 for 문도 없고
  32. 32. 예를 들어, S3 에 있는 데이터 30일치를 가져오려면 위 쿼리를 30번 만들어야하는데… 자동화는 또 어떻게하지?
  33. 33. 그래 foreach / tryeach / var / dateformat 등등 지원하는 거 하나 만들자
  34. 34. YPSQL
  35. 35. New Era w/Redshift
  36. 36. 개발자 2명 DataScientist 4명 사이트 220+개 대략 1/6 가격으로 추천엔짂 운용 대부분의 logic 이 SQL 로 이루어져있음 고객사 요구사항에 빠른 대응
  37. 37. 그 후에 좀 더 한 일들
  38. 38. S3 vs Aurora S3 Put Request 돈이 너무 많이 나와서 Aurora 로 젂환을 바람 추천로직 특성상 데이터가 리니어하게 증가하지 않고 배치시갂 마다 거의 모든 데이터가 수정되는 형태 고객사에 아이템이 100만개이면, 100만개씩 배치때마다 PUT
  39. 39. S3 vs Aurora – fail. Aurora 는 IOPS 에 비례해서 과금하는 시스템 배치시갂 이후에 모든 데이터가 업데이트 될 때 마다 과금이 폭발 안정적인 서비스를 위해서 Replica 운영 배치시갂 이후 모든 데이터가 한번에 업데이트 될 때 Replica Lag 증가 현재 레코벨 데이터모델로는 불가능 향후 모델 수정 후 재시도하기로..
  40. 40. 결국, Hashing / Grouping 하여 여러 개 아이템들을 하나의 파일에 넣어 S3 Put request 를 줄임.
  41. 41. 발표시갂이 짧을테니 몇 가지 더
  42. 42. Task Management 현재 사용하고 있는 TaskManagement Tool은 LinkedIn 에서 만든 Azkaban 많은 고객사사이트에 대해서 추천엔짂을 돌리지만 오래걸리는 고객사는 사실 20%에 불과 나머지 고객사들은 빠른 시갂내에 태스크가 끝남 하지만, AWS 는 시갂당 과금 태스크들의 시갂 관리가 중요 Task-Bundler 라는 모듈을 만들어서 각 번들내에 태스크들이 50분 정도의 실행시갂을 가지도록 만듦
  43. 43. 여젂히 개발자 2명 DataSientist 5명 사이트 300+개 추천서비스 지금은, Logger ~xxxx TPS API ~ xxx TPS
  44. 44. JSONPATH on Redshift JSON Key Name = Table Col Name 자동으로 Mapping Redshift 는 CamelCase 지원을 안해.. 아주 귀찮게 JSONPATH 파일을 관리중. Underscore 를 사용하자
  45. 45. 함께 하실 개발자 구합니다. 그래서
  46. 46. Amazon ECR Java8 Maven/Gradle Spring-boot JS(/TypeScript) Bower, Grunt AngularJS Jenkins Git Wiki / Jira Slack 이런것들을 사용하고 있습니다
  47. 47. Welcome! 하루 평균 1억건의 로그와 함께 데이터로 돈을 벌기 위해 노력하고있습니다.
  48. 48. 들어주셔서 감사합니다 Q&A

×