2014년 2월 20일 부산 BEXCO에서 개최되었던 스타트업과 개발자를 위한 클라우드 태권 세미나에서 고객사 발표를 맡아주신 Rankwave 김형은팀장님의 발표 자료 입니다. 발표 제목은 Achieving profitability on AWS 입니다.

1. 1
Achieving Profitability On AWS
RANKWAVE Case

2. 2
Introduction of RANKWAVE

3. 3
91

4. 4
어느 날의 명동 거리..
60 12
91
45
5
25
32
15
41
72
29

5. 5
하고 있는 일
Facebook, Twitter 사용자 분석 : 3,793,796 명
분석하는 글의 수
분석하는 댓글의 수
분석하는 Like 수
70,087,840
422,200,064
334,420,160
Facebook 페이지 분석 : 7,361,971

6. 6
Speed
52,691 명 / h
Facebook 페이지 분석
9,800 원 / h
SNS 사용자 분석
102,249 페이지 / h
AWS 요금

7. 7
5 Months Ago….

8. 8
Rankwave 1.0 on AWS
Central Server
On-Demand Instance
CELL #1
분석
400,000
On-Demand Instance
CELL #2
On-Demand Instance
분석
CELL #9
400,000
분석
400,000
….
데이터 수집
데이터 수집
데이터 수집
EBS Volume
EBS Volume
EBS Volume
NoSQL (mongoDB), RDB (mySQL)

9. 9
Traffic & Cost
분석 대상이 급격히 늘고, 그에 따라 AWS 비용 및 운영 업무 증가
4,000,000
12,000,000
3,500,000
10,000,000
3,000,000
8,000,000
2,500,000
2,000,000
6,000,000
1,500,000
4,000,000
1,000,000
2,000,000
500,000
-
-
분석자 수
System Cost
시스템 증설
데이터 에이징

10. 10
Cost per Person
1) 인당 분석 Cost 는 일정한 패턴을 보임.
CELL 증설 시점에 Cost 가 증가했다가, CELL 에 할당된 수가 최대치에 다가가면서 감소.
2) 지속적인 시스템 튜닝으로 1인당 분석 Cost 감소 추세.
9
8
7
인당 평균 Cost  ₩ 6.8
6
5
4
신규 CELL 증설
3
2
1
0
3/1/2013
4/1/2013
5/1/2013
Cost per person
6/1/2013
7/1/2013
8/1/2013
Linear (Cost per person)
9/1/2013

11. 11
I’m still hungry. - Rankwave

12. 12
개선 Point (1/2)
Instance 사용 비용과 EBS Volume 비용을 줄이는 것이 필요.
데이터 에이징과 시스템 증설 운영 업무를 줄이는 것이 필요.
AWS 비용
Load Balancing
0%
운영 인력 리소스
Data Transfer
1%
모니터링
10%
EBS Volume
37%
시스템 증설
30%
EBS 데이터
에이징
50%
On-Demand
Instance
62%
EBS 백업
10%

13. 13
개선 Point (2/2)
사용자 증가에 따라 최대 처리 용량을 늘리기 때문에, 유휴 리소스가 발생.
따라서, 증설 이후 비용 측면에서는 비효율적이됨.
유휴 리소스를 최소화 하기 위해, 실제 필요한 양만큼만 리소스 할당
신규 CELL 증설

14. 14
How to fix it?

15. 15
Instance Type (1/2)
EC2 Spot Instance
EC2 On-Demand Instance
Spot Instance 는 경매 방식으로 Instance 를 획득하여 저렴한 가격으로 사용.
단, 상황에 따라 언제든 Instance 가 중지될 수 있음.
* 미국 동부(버지니아 북부), Linux
On-Demand Instance
Spot Instance
Ratio
m3.xlarge
$ 0.450 / h
$ 0.0575 / h
12.7%
m3.2xlarge
$ 0.900 / h
$ 0.208 / h
23.1%
m1.small
$ 0.060 / h
$ 0.007 / h
11.6%
m1.medium
$ 0.120 / h
$ 0.013 / h
10.8%
m1.large
$ 0.240 / h
$ 0.026 / h
10.8%
m1.xlarge
$ 0.480 / h
$ 0.052 / h
10.8%

16. 16
Instance Type (2/2)
“작업 Queue” 와 “공용 데이터 저장소” 가 필요
①
③
②

17. 17
Volume Type (1/2)
S3 + Free Temporary Volume
EBS Volume
EBS Volume 의 비용은 사용한 Volume 의 크기와 요청한 I/O 의 회수에 따라 정해짐.
빅데이터 분석 시스템의 경우, File I/O 회수가 많을 수 밖에 없기 때문에,
I/O 회수에 따른 과금 이 큰 부담이 됨.
Disk Size
13%
I/O
87%
• 2013.10 분석 데몬의 EBS Volume 비용
• Provisioned storage : $ 289.13
• Provisioned IOPS : $ 1868.97

18. 18
Volume Type (2/2)
AWS 의 EC2 Instance 의 경우, 과금이 되지 않는 임시 Volume 을 제공함. (단, Instance 중지시, 데이터 이용 불가)
따라서, S3 와 같은 저장소에서 데이터를 가져와 임시 Volume 에 저장한 뒤, 연산을 수행하면, I/O 회수에 대한 과금을
피할 수 있음.
Instance
분석 Daemon
S3
Temporary Volume

19. 19
Queue
CELL 단위 Queuing
Global Queuing
Spot Instance 는 언제든 종료될 수 있기 때문에, CELL 단위로 운영하던 작업 Queue 를 공용 Queue 시스템으로
변경하는 것이 필요함.
AWS 에는 SQS 와 같은 Queue 를 제공하고 있으나, 보다 용이한 확장 및 변경을 위해 자체 개발한 Queue 시스템으로
적용.
…

20. 20
Auto Scaling (2/2)
시스템의 부하가 자주 변한다면 Auto Scaling 이 필요함.
AWS Instance Count
①
②
Manual Scaling
Auto Scaling
부하에 대한 대응이 늦는다는 것은, 둘 중 하나 이다.
① “필요한 성능을 내지 못하거나”, ② “AWS Instance 비용을 낭비하거나”

21. 21
Auto Scaling (2/2)
10분 동안 처리해야하는 수, ex) 3,700,000 / 24 / 3 / 6 = 8564
10분 동안 처리한 수, ex) 6000
AWS EC2 SDK
Instance 생성

22. 22
Now…

23. 23
Rankwave 2.0 System on AWS
Queue Manager
데이터 수집 Queue
데이터 분석 Queue
Spot Instance
Spot Instance
데이터 수집 데몬 #1
데이터 수집 데몬 #2
Free Temporary
Volume
Free Temporary
Volume
Spot Instance
AWS S3
분석 데몬 #1
분석 데몬 #2
Free Temporary
Volume
….
Spot Instance
Free Temporary
Volume
….

24. 24
AWS 비용 – Before & After (1/3)
Load
Balancing
0%
Data Transfer
1%
Before
₩3,742,673
Storage 비용
₩2,059,838
EBS Volume
37%
On-Demand
Instance
62%
Load
Balancing
1%
S3
11%
EBS Volume
22%
Spot Instance
7%
Data Transfer
0%
Total
On-Demand
Instance
59%
₩6,195,861
EC2 Instance 비용
기타
After
₩4,221,452
₩72,975
₩74,424
₩10,011,509
₩6,355,713

25. 25
AWS 비용 – Before & After (2/3)
[Before]
인당 평균 Cost : ₩ 6.8
9
8
7
[After]
인당 평균 Cost : ₩ 2.1
6
5
4
3
2
1
0
Cost per person
70% 감소

26. 26
운영 리소스 – Before & After (3/3)
Before
After
모니터링에 의한 수동 Scaling
Auto Scaling
모니터링을 통한 Volume 증설
S3 의 용량 제한은 없음.
데이터 증가에 따른 Volume 증설이 필요 없음
오래된 데이터 에이징 수행
S3 의 LifeCycle 기능을 이용한 자동 에이징
저장소 Volume 에 대한 정기 Backup 수행
No Backup

27. 27
Summary
Spot Instance
S3 with Temporary volume
Queue
Auto Scaling
Achieving Profitability

28. 28
Thank you