레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
- 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) • 보안 • 저렴한비용
- 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
- 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 꼭 쓰자.
- 54. 함께 해주셔서 감사합니다!
- 55. https://www.awssummit.kr AWS Summit 모바일 앱을 통해 지금 세션 평가에 참여하시면, 행사후 기념품을 드립니다. #AWSSummitKR 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 공유될 예정입니다. 여러분의 피드백을 기다립니다!