[2D7]레기온즈로 살펴보는 확장 가능한 게임서버의 구현

1. 로살펴보는확장가능한게임서버의구현
2014-09-23
김홍모
㈜드라이어드

2. 목차
스토리지요구사항분석
Dryad Transaction Layer
다중Key Transaction
분산Transaction
복구
적용사례
마무리& QnA
2

3. 도입
발표자소개
레기온즈소개
3

4. 발표자소개
㈜드라이어드
−레기온즈서버개발
KTH
−클라우드서비스를위한스토리지, 검색엔진개발
DAUM
−검색엔진개발
4

5. 레기온즈소개
소셜전략RPG
−영지개발(심시티)
−영웅(카드) 수집및육성(밀리언아서)
−유저간전투및약탈(클래시오브클랜즈)
2014.04 국내서비스오픈
2014.08 글로벌서비스오픈
5

6. 스토리지요구사항분석
NoSQL vs. RDBMS
Couchbase로살펴보는“수평적확장성＂의원리
Why NoSQL?
트랜잭션이없다면?
Why Not NoSQL?
소셜게임에서의IO 패턴
새로운스토리지기술이필요
6

7. NoSQL vs. RDBMS
7
RDBMS
NoSQL
대표제품
MySQL, MSSQL
Couchbase,MongoDB
API
SQL
대부분Key/Value
Transaction지원수준
Database범위
단일Key 수준
수평적확장성
대부분지원하지않음
지원

8. Couchbase로살펴보는“수평적확장성”의원리(1/5)
8
vBucket
−독립된Key/Value Database
vBucket

9. Couchbase로살펴보는“수평적확장성”의원리(2/5)
9
Dynamic Mapping
−KEY vBucket
Hash(KEY)
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket

10. Couchbase로살펴보는“수평적확장성”의원리(3/5)
10
Static Mapping
−vBucketServer
Hash(KEY)
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
Couchbase
Server
Couchbase
Server
Couchbase
Server

11. Couchbase로살펴보는“수평적확장성”의원리(4/5)
11
Update The Static Map
Hash(KEY)
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
vBucket
Couchbase
Server
Couchbase
Server
Couchbase
Server
Couchbase
Server

12. Couchbase로살펴보는“수평적확장성”의원리(5/5)
12
데이터분할(Partitioning)
−Key를미리다수의vBucket으로나누어둠
데이터이동(Migration)
−추가된Server에일부vBucket을복제하고vBucket맵을갱신

13. Why NoSQL?
13
NoSQL은수평적확장성이기능으로구현되어제공됨
−서버개발자가관련기능을구현할필요없음
RDBMS의경우데이터“분할“, “이동“ 과정을직접구현해야함

14. 트랜잭션이없다면?
14
Lord
Hero
Hero
Hero
Quest
데이터모델
Lord1
…
Lord
Hero
Hero
Hero
Quest
Lord2
…

15. 트랜잭션이없다면?
15
Lord
Hero
Hero
Hero
Quest
Player vs. Player 전투의결과
Lord1
…
Lord
Hero
Hero
Hero
Quest
Lord2
…
부상
Hero
포로

16. 트랜잭션이없다면?
16
Lord
Hero
Hero
Hero
Quest
처리중에API Server가내려갔다면?
Lord1
…
Lord
Hero
Hero
Hero
Quest
Lord2
…
Hero
포로

17. 트랜잭션이없다면?
17
예외처리가어려움
서버장애처리가어려움
정기점검처리가어려움

18. Why Not NoSQL?
18
다수Key로구성된데이터에대해정합성유지가어려움
−단일Key로구현?
−중요한데이터는RDBMS로?
−특정시점에서버가죽지않도록기도하기

19. 새로운스토리지기술이필요
19
수평적확장성을제공
트랜잭션을지원

20. Dryad Transaction Layer
Dryad Transaction Layer 소개
Domain이란?
다중Key Transaction 예시
분산Transaction 예시
20

21. Dryad Transaction Layer 소개
Python으로작성됨
Key/Value 모델
−Couchbase의확장성, 성능을활용(현재)
Transaction 기능을제공
21
Couchbase(확장성+ 성능)
Dryad Transaction Layer (트랜잭션)
Game Logic (확장성+성능+생산성)

22. Domain이란?
Domain은Key/Value 모델을지원하는논리적Database
Domain내에서다중Key Transaction(MTX)을지원
Domain간분산Transaction(DTX)을지원
22
Domain
MTX
DTX

23. 다중Key TX 예시
23
Transaction범위

24. 분산TX 예시
24
Transaction범위

25. 다중Key Transaction
Read Copy Update(RCU) 소개
RCU 예시
RCU 정리
다중Key Transaction 구현
업데이트예제
읽기/쓰기분석
정리
25

26. Read Copy Update(RCU) 소개
(Readers-Writers) Lock 효과구현가능
Wait-Free 읽기
−반면쓰기오버헤드있음
리눅스커널등에서사용
26
http://en.wikipedia.org/wiki/File:Tux.svg

27. RCU 예시(1/4)
27
N1
N2
N3
Singlylinked list
Next Ptr.

28. RCU 예시(2/4)
28
N2’
Copy On Write 스타일의업데이트
N1
N2
N3

29. RCU 예시(3/4)
29
N2’
원자적으로N1의next pointer를N2’로교체(Ref. 공개, Publish)
N1
N2
N3

30. RCU 예시(4/4)
30
더이상사용하는Thread가없는N2를제거(회수, Reclamation)
N2’
N1
N3

31. RCU 정리
31
자료구조는Reference로접근(Publish)
−포인터등매핑구조필요
−예제에서는N1에있는next pointer
공개된Reference를원자적으로교체
−리눅스커널의경우CPU H/W 특성(cache line)을이용
자원회수를위한기준필요
−리눅스커널의경우single writer, context switch 제약조건도입

32. 다중Key Transaction구현
32
자료구조는Reference로접근
−각Domain은Virtual Key로구성
−Virtual Key(Reference)를이용해데이터(Physical Key)를접근
공개된Reference를원자적으로교체
−Virtual Key Physical Key Map 정보를하나의Key에저장(Super Block)
−Compare And Swap으로Super Block을교체
자원회수를위한기준필요
−회수Key = (Domain의모든Key) –(Super Block에존재하는Key)

33. Virtual Key, Super Block
33
Virtual Key
−Domain은다수의Virtual Key를저장하는DB
−Game Logic은VirutalKey를이용해자료를접근
Super Block
−Virtual Key Physical Key Map을유지
−Domain에단1개존재
−Compare And Swap으로업데이트
V. Key
Domain
CB
P. Key
Super B.
Game
Logic
DTL

34. 자원회수를위한기준
34
CouchbaseView
−저장된객체에대해색인을생성할수있음
−색인은비동기적으로생성(Eventual Consistency)
특정Domain의모든Physical Key 목록을얻을수있음
−저장된객체의Key에대해Index 생성
−사전순으로리스팅이가능
도메인의모든Physical Key들
Super Block에등록된
사용중인P. Key들

35. 업데이트예제(1/5)
35

36. 업데이트예제(2/5)
36
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
‘hero1' : 'Player1-ABC-hero1',
}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player1-ABC-hero1
-------------------------
{
'name' : '맥루한',
'level' : 30,
'level_max' : 100
}
업데이트전

37. 업데이트예제(3/5)
37
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
‘hero1' : 'Player1-ABC-hero1',
}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player1-ABC-hero1
-------------------------
{
'name' : '맥루한',
'level' : 30,
'level_max' : 100
}
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 300,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Copy On Write 스타일의업데이트준비(COW Update)

38. 업데이트예제(4/5)
38
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABD-lord',
‘hero1' : 'Player1-ABC-hero1',
}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player1-ABC-hero1
-------------------------
{
'name' : '맥루한',
'level' : 30,
'level_max' : 100
}
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 300,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
원자적으로SuperBlock의‘lord’의Physical Key를변경(Publish)
−Compare And Swap 이용

39. 업데이트예제(5/5)
39
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABD-lord',
‘hero1' : 'Player1-ABC-hero1',
}
Player1-ABC-hero1
-------------------------
{
'name' : '맥루한',
'level' : 30,
'level_max' : 100
}
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 300,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
더이상사용하지않는‘Player1-ABC-lord’를제거(자원회수)

40. 읽기/쓰기분석
40
읽기
−Wait-Free 진입
−SuperBlock을추가로가져와야함
•단일도메인이너무많은키를가지는것은부담
쓰기
−Copy On Write 오버헤드
−쓰기가중첩될경우Compare And Swap 실패가능성이있음
•재시도처리

41. 정리
41
Domain 내에서다중Key에대해Transaction 제공
Read Copy Update 스타일의구현
읽기요청은Wait-Free로처리
쓰기요청은재시도과정이있을수있음
자원회수는배치작업으로후처리

42. 분산Transaction
Two Phase Commit 소개
Two Phase Commit 처리과정
TX Monitor, Resource Manager
구현
DTX 상태
DTX 후처리
DTX 상태도
예제
정리
42

43. Two Phase Commit 소개
분산트랜잭션처리를위한간단한프로토콜
−하나의Transaction Monitor
−다수의Resource Manager가참여
금융권등에서널리사용됨
Blocking 모델
준비단계와Commit 두단계로진행
43

44. Two Phase Commit 처리과정
44
TX
Monitor
RM(s)
준비요청
준비응답
Commit 요청
Commit 응답
준비단계
Commit단계

45. TX Monitor, Resource Manager
TX Monitor
−보통별도의서비스가역할을수행(Tuxedo, CICS)
−분산TX정보(DTX Context)관리
−TX Commit/Rollback 결정(All or Nothing)
Resource Manager
−보통RDBMS가역할을수행(Oracle, MySQL)
−자체적으로Transaction 처리가능해야함
−TX Commit/Rollback 처리를TX Monitor에게위임
45

46. 구현
TX Monitor
−별도서비스로존재하지않음(DTL 라이브러리가처리)
−DTX Context를단일Key로저장
Resource Manager
−Domain이역할을수행
−Super Block에대응정보추가
46
DTX

47. DTX Context, Super Block 대응
DTX Context
−참여Domain 목록
−DTX 상태저장(INIT, PENDING, ABORTED, COMMITED)
−해당키는INIT 상태에서TTL(Time To Live) 값을가짐
Super Block 대응
−DTX 참여정보추가(DTX_ID)
−DTX에참여할경우TX Span을벗어나서Commit/Rollback 가능하도록
•DTX용VPMap을추가
47

48. DTX 상태
INIT
−DTXContext가생성된상태
−TTL설정
PENDING
−참여하는모든Domain들을해당DTX에편입(Blocking)
−관련로직을처리
ABORTED
−DTX Span 내에서예외가발생할경우ABORTED 상태로전환
COMMITTED
−모든작업이성공할경우COMMITTED 상태로전환
−TTL 제거
48

49. DTX 후처리
DTX 처리결과는다음MTX 처리전반영
ABORT 결과적용
−DTX Context가“ABORTED” 혹은“만료” 상태의경우
−Domain 내DTX 관련자료를초기화
COMMIT 결과적용
−DTX Context가“COMMITTED” 상태일경우
−Domain 내존재하는DTX 관련자료를반영
49

50. DTX 상태도
50
INIT
PENDING
ABORTED
COMMITTED
DTX 준비완료
진행중예외
TTL 만료
성공
ABORT
Applied
COMMT
Applied
DTX 후처리
DTX 범위내

51. 업데이트예제(1/7)
51
PENDING
COMMITTED
INIT

52. 업데이트예제(2/7)
52
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
‘hero1' : 'Player1-ABC-hero1',
}
dtx_id= None
VPMap_dtx= None
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
INIT 상태
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status = 'INIT‘
TTL = DTX_TTL
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABC-lord',
‘hero1' : 'Player2-ABC-hero1',
}
dtx_id= None
VPMap_dtx= None
Player2-ABC-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

53. 업데이트예제(3/7)
53
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
‘hero1' : 'Player1-ABC-hero1',
}
dtx_id= DTX-ABC
VPMap_dtx= {}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
PENDING 시작
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status = ‘PENDING‘
TTL = DTX_TTL
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABC-lord',
‘hero1' : 'Player2-ABC-hero1',
}
dtx_id= DTX-ABC
VPMap_dtx= {}
Player2-ABC-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

54. 업데이트예제(4/7)
54
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
…}
dtx_id= DTX-ABC
VPMap_dtx= {
'lord' : 'Player1-ABD-lord',}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
PENDING 끝
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status = ‘PENDING‘
TTL = DTX_TTL
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABC-lord',
…}
dtx_id= DTX-ABC
VPMap_dtx= {
'lord' : 'Player2-ABD-lord',}
Player2-ABC-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 0,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player2-ABD-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 200,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

55. 업데이트예제(5/7)
55
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
…}
dtx_id= DTX-ABC
VPMap_dtx= {
'lord' : 'Player1-ABD-lord',}
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
COMMITTED
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status =
‘COMMITTED‘
TTL = None
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABC-lord',
…}
dtx_id= DTX-ABC
VPMap_dtx= {
'lord' : 'Player2-ABD-lord',}
Player2-ABC-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 0,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player2-ABD-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 200,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

56. 업데이트예제(6/7)
56
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABD-lord',
…}
dtx_id= None
VPMap_dtx= None
개별Domain이다음TX 진행시이전DTX 결과반영
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status =
‘COMMITTED‘
TTL = None
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABD-lord',
…}
dtx_id= None
VPMap_dtx= None
Player1-ABD-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 0,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
Player2-ABD-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 200,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

57. 업데이트예제(7/7)
57
SuperBlock-Player1
-------------------------------------
VPMap= {
'lord' : 'Player1-ABC-lord',
…}
dtx_id= None
VPMap_dtx= None
Player1-ABC-lord
------------------------
{
'name' : '홍길동',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}
ABORTED이거나TTL 만료인경우DTX 결과제거
DTX-ABC
------------------------
Domain_ids= [
'Player1',
'Player2'
]
Status =
‘ABORTED‘
TTL = DTX_TTL
SuperBlock-Player2
-------------------------------------
VPMap= {
'lord' : 'Player2-ABC-lord',
…}
dtx_id= None
VPMap_dtx= None
Player2-ABC-lord
------------------------
{
'name' : '홍길순',
'level' : 1,
'gold' : 100,
'food' : 100,
'rune' : 0,
'hero_ids' : ['hero1']
}

58. 정리
58
Domain 간분산Transaction 제공
−참여하는Domain은다중Key Transaction 이용
Two Phase Commit 스타일의구현
Blocking 모델
−PENDING 상태진입조건참여Domain에DTX 관련정보기록
−데드락회피
•Domain 준비를사전순으로처리

59. 복구
59
Couchbase처리구조
Key 유실가능성
성능과안정성(Persistency) 사이의관계
TX Log

60. Couchbase처리구조
60
비동기처리구조
−디스크Sync
−Node간Replication
동기구조가존재는함
−Endure
−Persis_to
DISK
CouchbaseNode
Managed
Cache
Rep. Q
Disk Q
CouchbaseNode

61. Key 유실가능성
61
쓰기요청처리와디스크Sync, Node Replication 처리간갭
−장애시잃어버린Key를알수있을까?
쓰기요청
디스크Sync
Node Replication
유실가능틈

62. 성능과안정성(Persistency) 사이의관계
62
비동기구조는고성능처리의핵심요소
안정성은기다림을요구
성능과안정성은아마도trade-off 관계
완벽한솔루션?
−초고성능DISK, 초고성능Network?

63. Undo Log
63
Key 유실가능성을받아들임
−성능은서비스자체의가능성을위협
Key 유실이발생할경우Domain정합성이깨어질위험이있음
Undo Log를이용해정합성이깨진Domain을과거로돌림
Couchbase
MySQL
Game Logic
DTL
Undo Log

64. 적용사례
64
선술집에서영웅고용
레이드전투

65. 선술집에서영웅고용
65
참여Domain; 영주
단일TX로처리
−진입; 무조건진입(Wait-Free)
−종료; TX Span이끝날때다른Thread로인해CAS 실패가능성있음
TX1
TX2
TX2 (Retry)

66. 레이드전투
66
참여Domain; Legion, LegionPair, 영주(*)
DTX로처리
−진입; 모든참여Domain에DTX 정보기록, 이미진행중인DTX가있을경우실패
−종료; Span이끝날때다른쓰레드로인해COMMIT이실패할가능성은낮음
DTX1
DTX2
DTX3

67. 마무리& QnA
67
Dryad Transaction Layer를이용해
−NoSQL의확장성, 성능을바탕으로
−Transaction이가능한프로그래밍모델을구현
이를기반으로확장가능한게임서버를구현
Couchbase(확장성+ 성능)
Dryad Transaction Layer (트랜잭션)
Game Logic (확장성+성능+생산성)