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.
Key-Value Store를 사용한 대용량 게임 통계
WoW 경매장 분석 서비스 wowz.kr를 사례로
윤석주(nori)
모빌팩토리
Key-Value Store를 사용한 대용량 게임 통계
주의!
이 발표에서 통계는 게임 서비스를 분석하는 통계가 아닌
게임내의 경매장 데이터를 기반으로 분석하는 통계를 다룹니다
윤석주 ( @noricube )
- 2012:서울
- Zoo Invasion
- 퍼즐 주주
- Project VM 개발중
발표자 소개
서비스 소개
wowz.kr
- 와우 경매장의 데이터를 수집하여 통계를 보여주는 서비스
- 가격, 가격의 추세
- 와우 인벤에서 좋은 반응 (우측 배너 링크)
만들게 된 계기
WoW의 경매장
정보의 부족
- 아이템 가격의 흐름을 알 수 없다
- 싼가? 비싼가?
- 오르고 있나? 내리고 있나?
- 물품이 적은가? 많은가?
- 큰손이 있다는데?
그래서
WoW 경매장 시세를 알 수 있는 서비스를 만들자
- 검색
- 각 아이템 별 history
- 그래프로 보기 쉽도록
물품 검색
물품 검색
아이템별 history + 그래프
어떻게 만들었나요?
데이터 수집
- API로 15분 단위 경매장 snapshot 가져오기
- JSON 포맷
- 물품 1개당 1 ROW
* https://dev.battle.net/
데이터 형식
[{"auc":1347942360,"item":14344,"owner":"Sanctuary","bid":2041
200,"buyout":2268000,"quantity":3},
....]
아이템 ID / 플...
데이터 분석
- Snapshot마다 아이템 ID 별로 묶어서 ( group by itemId )
- 최소 가격
- 평균 가격
- 중간 가격
- 물품 개수
이렇게 정리
시간 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 ...
서비스에서 표현
시간 ItemID 평균
1:15 109218 8.5
1:30 109218 8.4
1:45 109218 8.4
2:00 109218 8.4
이렇게 분석한 결과를
- 처음에는 mongodb에 저장
- JSON포맷을 바로 저장할 수 있어서 유용
- 개발 도중 schema 변경도 간편
왜죠?
생각하지 못했던 것들
- 많은 데이터
- 데이터의 지속적으로 증가
- 하지만 최소의 유지 비용
많은 데이터
3개월치 누적 데이터로 시작
- 15분 주기마다 새 데이터
- 전체 합산하면 약 80MB의 JSON text
=> 96(1일/15분) * 80MB * 90일(3개월) = 691,200MB = 691GB
많은 데이터
691GB의 데이터를 분석 했더니
- 아이템별로 1일에 96 ROW
- 3개월이면 약 8700 ROW
문제는
- 경매장에서 거래되는 아이템이 약 5000개
- 서버는 9개가 존재
 8700 * 5000 * 9 = 391,500,000 ROW = 약 40GB
검색 한번하면 30초정도 소요
데이터의 지속적인 증가
- 지속적으로 새로운 데이터 추가
- 서비스 시작 후 1년이 경과하면 4배의 저장소 사용
- 시작은 4억 ROW, 1년 뒤면 12억 ROW
1년 뒤면 매우 심각해짐
하지만 최소한의 유지비용
- 개인이 운영 하는 서비스
- 관리 비용 최소화
- 큰 Table을 관리하기 힘들다
- 유지 비용 최소화
- Table이 커지면 비용이 늘어난다
해결책
가능하면 분산 DB로
- 단일 노드에 수용하기에는 너무 많은 양
- 성능 문제도 있고
- 관리도 어려움
- 데이터가 늘어나는 것까지 고려
분산 DB 중에
- Key-Value Store(NoSQL) 선택
- 수평 확장이 편리
- 키에 여러 Column을 추가 가능
- 일관성을 보장하지 않음
Key-Value Store 비교
속도는 보통이지만 사용한 만큼 비용을 지불하는 Azure Table Storage 선택
Cassandra Amazon
DynamoDB
Azure Table
Storage
속도 빠름 빠름...
Azure Table Storage의 요금은
40GB를 써도 월 3360원!
Azure Table Storage 서비스 적용
데이터 구성
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....
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_...
병렬 처리
각 Key는 다른 서버에 저장되어 있음
- 1개 Key 조회, 다수 Key 조회의 시간 차가 거의 없음
 많은 데이터를 한꺼번에 조회 하는 것이 유리
 데이터가 늘어도 조회 시간은 비슷
PaaS
- 사용 해보니 개발에만 집중 가능
- 추가로 웹 서버도 PaaS로 이동
- 분석할 데이터 저장도 azure blob storage 사용
결과
2가지 관점
- 데이터
- 관리
데이터
7개월치 데이터가 쌓였지만
- 이전과 큰 속도 차이 없음
- 10억개의 ROW를 가지고 있지만 DB 가격은 월 1만원 정도
관리
딱히 관리를 하지 않았지만
- 4개월 동안 별 문제 없이 작동
- 새로운 데이터가 생기면 자동으로 반영
총평
- PaaS를 사용함으로써 개발에만 집중함
- 적은 비용으로 많은 데이터를 감당
사용자 반응
추가로
- 이런 서비스를 게임에서 제공 하면 좋지 않을까?
- 게임 내 경제를 분석하는데 도움이 되지 않을까?
감사합니다
sjyun@mobilfactory.co.kr
Reference
• Key-Value Store
• http://bcho.tistory.com/665
• Azure Table Storage
• http://azure.microsoft.com/en-us/documen...
Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로
Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로
Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로
Upcoming SlideShare
Loading in …5
×

Key-Value Store를 사용한 대용량 게임 통계 : WoW 경매장 분석 서비스 wowz.kr를 사례로

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

  • Login to see the comments

Key-Value Store를 사용한 대용량 게임 통계 : WoW 경매장 분석 서비스 wowz.kr를 사례로

  1. 1. Key-Value Store를 사용한 대용량 게임 통계 WoW 경매장 분석 서비스 wowz.kr를 사례로 윤석주(nori) 모빌팩토리
  2. 2. Key-Value Store를 사용한 대용량 게임 통계 주의! 이 발표에서 통계는 게임 서비스를 분석하는 통계가 아닌 게임내의 경매장 데이터를 기반으로 분석하는 통계를 다룹니다
  3. 3. 윤석주 ( @noricube ) - 2012:서울 - Zoo Invasion - 퍼즐 주주 - Project VM 개발중 발표자 소개
  4. 4. 서비스 소개
  5. 5. wowz.kr - 와우 경매장의 데이터를 수집하여 통계를 보여주는 서비스 - 가격, 가격의 추세 - 와우 인벤에서 좋은 반응 (우측 배너 링크)
  6. 6. 만들게 된 계기
  7. 7. WoW의 경매장
  8. 8. 정보의 부족 - 아이템 가격의 흐름을 알 수 없다 - 싼가? 비싼가? - 오르고 있나? 내리고 있나? - 물품이 적은가? 많은가? - 큰손이 있다는데?
  9. 9. 그래서 WoW 경매장 시세를 알 수 있는 서비스를 만들자 - 검색 - 각 아이템 별 history - 그래프로 보기 쉽도록
  10. 10. 물품 검색
  11. 11. 물품 검색
  12. 12. 아이템별 history + 그래프
  13. 13. 어떻게 만들었나요?
  14. 14. 데이터 수집 - API로 15분 단위 경매장 snapshot 가져오기 - JSON 포맷 - 물품 1개당 1 ROW * https://dev.battle.net/
  15. 15. 데이터 형식 [{"auc":1347942360,"item":14344,"owner":"Sanctuary","bid":2041 200,"buyout":2268000,"quantity":3}, ....] 아이템 ID / 플레이어명 / 물품 입찰 가격 / 즉시구매 가격 / 개수 를 포함
  16. 16. 데이터 분석 - Snapshot마다 아이템 ID 별로 묶어서 ( group by itemId ) - 최소 가격 - 평균 가격 - 중간 가격 - 물품 개수
  17. 17. 이렇게 정리 시간 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
  18. 18. 서비스에서 표현 시간 ItemID 평균 1:15 109218 8.5 1:30 109218 8.4 1:45 109218 8.4 2:00 109218 8.4
  19. 19. 이렇게 분석한 결과를 - 처음에는 mongodb에 저장 - JSON포맷을 바로 저장할 수 있어서 유용 - 개발 도중 schema 변경도 간편
  20. 20. 왜죠?
  21. 21. 생각하지 못했던 것들 - 많은 데이터 - 데이터의 지속적으로 증가 - 하지만 최소의 유지 비용
  22. 22. 많은 데이터 3개월치 누적 데이터로 시작 - 15분 주기마다 새 데이터 - 전체 합산하면 약 80MB의 JSON text => 96(1일/15분) * 80MB * 90일(3개월) = 691,200MB = 691GB
  23. 23. 많은 데이터 691GB의 데이터를 분석 했더니 - 아이템별로 1일에 96 ROW - 3개월이면 약 8700 ROW
  24. 24. 문제는 - 경매장에서 거래되는 아이템이 약 5000개 - 서버는 9개가 존재  8700 * 5000 * 9 = 391,500,000 ROW = 약 40GB 검색 한번하면 30초정도 소요
  25. 25. 데이터의 지속적인 증가 - 지속적으로 새로운 데이터 추가 - 서비스 시작 후 1년이 경과하면 4배의 저장소 사용 - 시작은 4억 ROW, 1년 뒤면 12억 ROW 1년 뒤면 매우 심각해짐
  26. 26. 하지만 최소한의 유지비용 - 개인이 운영 하는 서비스 - 관리 비용 최소화 - 큰 Table을 관리하기 힘들다 - 유지 비용 최소화 - Table이 커지면 비용이 늘어난다
  27. 27. 해결책
  28. 28. 가능하면 분산 DB로 - 단일 노드에 수용하기에는 너무 많은 양 - 성능 문제도 있고 - 관리도 어려움 - 데이터가 늘어나는 것까지 고려
  29. 29. 분산 DB 중에 - Key-Value Store(NoSQL) 선택 - 수평 확장이 편리 - 키에 여러 Column을 추가 가능 - 일관성을 보장하지 않음
  30. 30. Key-Value Store 비교 속도는 보통이지만 사용한 만큼 비용을 지불하는 Azure Table Storage 선택 Cassandra Amazon DynamoDB Azure Table Storage 속도 빠름 빠름 보통 비용 Instance 단위로 비용 발생 쓰기/읽기 예약한 만큼 + 사용량 쓰기/읽기 작업당 + 사용량 관리 필요성 O X X Auto Scaling △(소프트웨어 적 으로 지원하지만 하드웨어 셋팅 필 요) O O
  31. 31. Azure Table Storage의 요금은 40GB를 써도 월 3360원!
  32. 32. Azure Table Storage 서비스 적용
  33. 33. 데이터 구성 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에 시간대별로 가격 정보를 기록
  34. 34. 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 … … … …
  35. 35. 병렬 처리 각 Key는 다른 서버에 저장되어 있음 - 1개 Key 조회, 다수 Key 조회의 시간 차가 거의 없음  많은 데이터를 한꺼번에 조회 하는 것이 유리  데이터가 늘어도 조회 시간은 비슷
  36. 36. PaaS - 사용 해보니 개발에만 집중 가능 - 추가로 웹 서버도 PaaS로 이동 - 분석할 데이터 저장도 azure blob storage 사용
  37. 37. 결과
  38. 38. 2가지 관점 - 데이터 - 관리
  39. 39. 데이터 7개월치 데이터가 쌓였지만 - 이전과 큰 속도 차이 없음 - 10억개의 ROW를 가지고 있지만 DB 가격은 월 1만원 정도
  40. 40. 관리 딱히 관리를 하지 않았지만 - 4개월 동안 별 문제 없이 작동 - 새로운 데이터가 생기면 자동으로 반영
  41. 41. 총평 - PaaS를 사용함으로써 개발에만 집중함 - 적은 비용으로 많은 데이터를 감당
  42. 42. 사용자 반응
  43. 43. 추가로 - 이런 서비스를 게임에서 제공 하면 좋지 않을까? - 게임 내 경제를 분석하는데 도움이 되지 않을까?
  44. 44. 감사합니다 sjyun@mobilfactory.co.kr
  45. 45. 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/

×