Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로 #ndc_15 에서 발표한 슬라이드를 공유합니다.

1. Key-Value Store를 사용한 대용량 게임 통계
WoW 경매장 분석 서비스 wowz.kr를 사례로
윤석주(nori)
모빌팩토리

2. Key-Value Store를 사용한 대용량 게임 통계
주의!
이 발표에서 통계는 게임 서비스를 분석하는 통계가 아닌
게임내의 경매장 데이터를 기반으로 분석하는 통계를 다룹니다

3. 윤석주 ( @noricube )
- 2012:서울
- Zoo Invasion
- 퍼즐 주주
- Project VM 개발중
발표자 소개

4. 서비스 소개

5. wowz.kr
- 와우 경매장의 데이터를 수집하여 통계를 보여주는 서비스
- 가격, 가격의 추세
- 와우 인벤에서 좋은 반응 (우측 배너 링크)

6. 만들게 된 계기

7. WoW의 경매장

8. 정보의 부족
- 아이템 가격의 흐름을 알 수 없다
- 싼가? 비싼가?
- 오르고 있나? 내리고 있나?
- 물품이 적은가? 많은가?
- 큰손이 있다는데?

9. 그래서
WoW 경매장 시세를 알 수 있는 서비스를 만들자
- 검색
- 각 아이템 별 history
- 그래프로 보기 쉽도록

11. 물품 검색

12. 물품 검색

13. 아이템별 history + 그래프

14. 어떻게 만들었나요?

15. 데이터 수집
- API로 15분 단위 경매장 snapshot 가져오기
- JSON 포맷
- 물품 1개당 1 ROW
* https://dev.battle.net/

16. 데이터 형식
[{"auc":1347942360,"item":14344,"owner":"Sanctuary","bid":2041
200,"buyout":2268000,"quantity":3},
....]
아이템 ID / 플레이어명 / 물품 입찰 가격 / 즉시구매 가격 / 개수
를 포함

17. 데이터 분석
- Snapshot마다 아이템 ID 별로 묶어서 ( group by itemId )
- 최소 가격
- 평균 가격
- 중간 가격
- 물품 개수

18. 이렇게 정리
시간 ItemID 최소 중간 평균
9:00 72096 4.75 5.0 5.0
9:00 12359 1.08 1.25 1.50
9:00 23446 1.61 4.86 5.0
9:15 72096 3.33 4.72 5.0
9:15 12359 0.97 1.6 1.5
9:15 23446 2.0 3.87 5.0

19. 서비스에서 표현
시간 ItemID 평균
1:15 109218 8.5
1:30 109218 8.4
1:45 109218 8.4
2:00 109218 8.4

20. 이렇게 분석한 결과를
- 처음에는 mongodb에 저장
- JSON포맷을 바로 저장할 수 있어서 유용
- 개발 도중 schema 변경도 간편

23. 왜죠?

24. 생각하지 못했던 것들
- 많은 데이터
- 데이터의 지속적으로 증가
- 하지만 최소의 유지 비용

25. 많은 데이터
3개월치 누적 데이터로 시작
- 15분 주기마다 새 데이터
- 전체 합산하면 약 80MB의 JSON text
=> 96(1일/15분) * 80MB * 90일(3개월) = 691,200MB = 691GB

26. 많은 데이터
691GB의 데이터를 분석 했더니
- 아이템별로 1일에 96 ROW
- 3개월이면 약 8700 ROW

27. 문제는
- 경매장에서 거래되는 아이템이 약 5000개
- 서버는 9개가 존재
 8700 * 5000 * 9 = 391,500,000 ROW = 약 40GB
검색 한번하면 30초정도 소요

28. 데이터의 지속적인 증가
- 지속적으로 새로운 데이터 추가
- 서비스 시작 후 1년이 경과하면 4배의 저장소 사용
- 시작은 4억 ROW, 1년 뒤면 12억 ROW
1년 뒤면 매우 심각해짐

29. 하지만 최소한의 유지비용
- 개인이 운영 하는 서비스
- 관리 비용 최소화
- 큰 Table을 관리하기 힘들다
- 유지 비용 최소화
- Table이 커지면 비용이 늘어난다

30. 해결책

31. 가능하면 분산 DB로
- 단일 노드에 수용하기에는 너무 많은 양
- 성능 문제도 있고
- 관리도 어려움
- 데이터가 늘어나는 것까지 고려

32. 분산 DB 중에
- Key-Value Store(NoSQL) 선택
- 수평 확장이 편리
- 키에 여러 Column을 추가 가능
- 일관성을 보장하지 않음

33. Key-Value Store 비교
속도는 보통이지만 사용한 만큼 비용을 지불하는 Azure Table Storage 선택
Cassandra Amazon
DynamoDB
Azure Table
Storage
속도 빠름 빠름 보통
비용 Instance 단위로
비용 발생
쓰기/읽기 예약한
만큼 + 사용량
쓰기/읽기 작업당
+ 사용량
관리 필요성 O X X
Auto Scaling △(소프트웨어 적
으로 지원하지만
하드웨어 셋팅 필
요)
O O

34. Azure Table Storage의 요금은
40GB를 써도 월 3360원!

35. Azure Table Storage 서비스 적용

36. 데이터 구성
Key Value
Azshara_2015-05-17_72092
00:00 00:15 00:30
…
{min:3,avg:5,med:4.5} {min:3.5,avg:4,med:4.
2}
{min:4,avg:4.5,med:4
.2}
Azshara_2015-05-18_72092
00:00 00:15 00:30
…{min:4,avg:4.5,med:4} {min:3,avg:5,med:4.5} {min:3.5,avg:4,med:4
.2}
Azshara_2015-05-19_72092
00:00 00:15 00:30
…{min:3.2,avg:4.8,med:4.5} {min:3,avg:5,med:4.5} {min:3,avg:5,med:4.5}
Key는 서버, 시간, 아이템 ID로 만들고
Value에 시간대별로 가격 정보를 기록

37. Key Value
Azshara_2014-12-
02_72092
00:00 00:15 00:30 …
… … …
Azshara_2014-12-
03_72092
00:00 00:15 00:30
…
… … …
Azshara_2015-05-
19_72092
00:00 00:15 00:30
…
… … …

38. 병렬 처리
각 Key는 다른 서버에 저장되어 있음
- 1개 Key 조회, 다수 Key 조회의 시간 차가 거의 없음
 많은 데이터를 한꺼번에 조회 하는 것이 유리
 데이터가 늘어도 조회 시간은 비슷

39. PaaS
- 사용 해보니 개발에만 집중 가능
- 추가로 웹 서버도 PaaS로 이동
- 분석할 데이터 저장도 azure blob storage 사용

40. 결과

41. 2가지 관점
- 데이터
- 관리

42. 데이터
7개월치 데이터가 쌓였지만
- 이전과 큰 속도 차이 없음
- 10억개의 ROW를 가지고 있지만 DB 가격은 월 1만원 정도

43. 관리
딱히 관리를 하지 않았지만
- 4개월 동안 별 문제 없이 작동
- 새로운 데이터가 생기면 자동으로 반영

44. 총평
- PaaS를 사용함으로써 개발에만 집중함
- 적은 비용으로 많은 데이터를 감당

45. 사용자 반응

46. 추가로
- 이런 서비스를 게임에서 제공 하면 좋지 않을까?
- 게임 내 경제를 분석하는데 도움이 되지 않을까?

47. 감사합니다
sjyun@mobilfactory.co.kr

48. Reference
• Key-Value Store
• http://bcho.tistory.com/665
• Azure Table Storage
• http://azure.microsoft.com/en-us/documentation/articles/storage-
dotnet-how-to-use-tables/