More Related Content Similar to Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로 (20) Key-Value Store를 사용한 대용량 게임 통계: WoW 경매장 분석 서비스 wowz.kr를 사례로2. Key-Value Store를 사용한 대용량 게임 통계
주의!
이 발표에서 통계는 게임 서비스를 분석하는 통계가 아닌
게임내의 경매장 데이터를 기반으로 분석하는 통계를 다룹니다
3. 윤석주 ( @noricube )
- 2012:서울
- Zoo Invasion
- 퍼즐 주주
- Project VM 개발중
발표자 소개
8. 정보의 부족
- 아이템 가격의 흐름을 알 수 없다
- 싼가? 비싼가?
- 오르고 있나? 내리고 있나?
- 물품이 적은가? 많은가?
- 큰손이 있다는데?
15. 데이터 수집
- API로 15분 단위 경매장 snapshot 가져오기
- JSON 포맷
- 물품 1개당 1 ROW
* https://dev.battle.net/
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
20. 이렇게 분석한 결과를
- 처음에는 mongodb에 저장
- JSON포맷을 바로 저장할 수 있어서 유용
- 개발 도중 schema 변경도 간편
25. 많은 데이터
3개월치 누적 데이터로 시작
- 15분 주기마다 새 데이터
- 전체 합산하면 약 80MB의 JSON text
=> 96(1일/15분) * 80MB * 90일(3개월) = 691,200MB = 691GB
27. 문제는
- 경매장에서 거래되는 아이템이 약 5000개
- 서버는 9개가 존재
8700 * 5000 * 9 = 391,500,000 ROW = 약 40GB
검색 한번하면 30초정도 소요
28. 데이터의 지속적인 증가
- 지속적으로 새로운 데이터 추가
- 서비스 시작 후 1년이 경과하면 4배의 저장소 사용
- 시작은 4억 ROW, 1년 뒤면 12억 ROW
1년 뒤면 매우 심각해짐
29. 하지만 최소한의 유지비용
- 개인이 운영 하는 서비스
- 관리 비용 최소화
- 큰 Table을 관리하기 힘들다
- 유지 비용 최소화
- Table이 커지면 비용이 늘어난다
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
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에 시간대별로 가격 정보를 기록
38. 병렬 처리
각 Key는 다른 서버에 저장되어 있음
- 1개 Key 조회, 다수 Key 조회의 시간 차가 거의 없음
많은 데이터를 한꺼번에 조회 하는 것이 유리
데이터가 늘어도 조회 시간은 비슷
39. PaaS
- 사용 해보니 개발에만 집중 가능
- 추가로 웹 서버도 PaaS로 이동
- 분석할 데이터 저장도 azure blob storage 사용
43. 관리
딱히 관리를 하지 않았지만
- 4개월 동안 별 문제 없이 작동
- 새로운 데이터가 생기면 자동으로 반영
46. 추가로
- 이런 서비스를 게임에서 제공 하면 좋지 않을까?
- 게임 내 경제를 분석하는데 도움이 되지 않을까?
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/