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.
로살펴보는확장가능한게임서버의구현 
2014-09-23 
김홍모 
㈜드라이어드
목차 
스토리지요구사항분석 
Dryad Transaction Layer 
다중Key Transaction 
분산Transaction 
복구 
적용사례 
마무리& QnA 
2
도입 
발표자소개 
레기온즈소개 
3
발표자소개 
㈜드라이어드 
−레기온즈서버개발 
KTH 
−클라우드서비스를위한스토리지, 검색엔진개발 
DAUM 
−검색엔진개발 
4
레기온즈소개 
소셜전략RPG 
−영지개발(심시티) 
−영웅(카드) 수집및육성(밀리언아서) 
−유저간전투및약탈(클래시오브클랜즈) 
2014.04 국내서비스오픈 
2014.08 글로벌서비스오픈 
5
스토리지요구사항분석 
NoSQL vs. RDBMS 
Couchbase로살펴보는“수평적확장성"의원리 
Why NoSQL? 
트랜잭션이없다면? 
Why Not NoSQL? 
소셜게임에서의IO 패턴 
새로운스토리...
NoSQL vs. RDBMS 
7 
RDBMS 
NoSQL 
대표제품 
MySQL, MSSQL 
Couchbase,MongoDB 
API 
SQL 
대부분Key/Value 
Transaction지원수준 
Database...
Couchbase로살펴보는“수평적확장성”의원리(1/5) 
8 
vBucket 
−독립된Key/Value Database 
vBucket
Couchbase로살펴보는“수평적확장성”의원리(2/5) 
9 
Dynamic Mapping 
−KEY vBucket 
Hash(KEY) 
vBucket 
vBucket 
vBucket 
vBucket 
vBucket...
Couchbase로살펴보는“수평적확장성”의원리(3/5) 
10 
Static Mapping 
−vBucketServer 
Hash(KEY) 
vBucket 
vBucket 
vBucket 
vBucket 
vBuck...
Couchbase로살펴보는“수평적확장성”의원리(4/5) 
11 
Update The Static Map 
Hash(KEY) 
vBucket 
vBucket 
vBucket 
vBucket 
vBucket 
vBucke...
Couchbase로살펴보는“수평적확장성”의원리(5/5) 
12 
데이터분할(Partitioning) 
−Key를미리다수의vBucket으로나누어둠 
데이터이동(Migration) 
−추가된Server에일부vBucket...
Why NoSQL? 
13 
NoSQL은수평적확장성이기능으로구현되어제공됨 
−서버개발자가관련기능을구현할필요없음 
RDBMS의경우데이터“분할“, “이동“ 과정을직접구현해야함
트랜잭션이없다면? 
14 
Lord 
Hero 
Hero 
Hero 
Quest 
데이터모델 
Lord1 
… 
Lord 
Hero 
Hero 
Hero 
Quest 
Lord2 
…
트랜잭션이없다면? 
15 
Lord 
Hero 
Hero 
Hero 
Quest 
Player vs. Player 전투의결과 
Lord1 
… 
Lord 
Hero 
Hero 
Hero 
Quest 
Lord2 
… ...
트랜잭션이없다면? 
16 
Lord 
Hero 
Hero 
Hero 
Quest 
처리중에API Server가내려갔다면? 
Lord1 
… 
Lord 
Hero 
Hero 
Hero 
Quest 
Lord2 
… 
H...
트랜잭션이없다면? 
17 
예외처리가어려움 
서버장애처리가어려움 
정기점검처리가어려움
Why Not NoSQL? 
18 
다수Key로구성된데이터에대해정합성유지가어려움 
−단일Key로구현? 
−중요한데이터는RDBMS로? 
−특정시점에서버가죽지않도록기도하기
새로운스토리지기술이필요 
19 
수평적확장성을제공 
트랜잭션을지원
Dryad Transaction Layer 
Dryad Transaction Layer 소개 
Domain이란? 
다중Key Transaction 예시 
분산Transaction 예시 
20
Dryad Transaction Layer 소개 
Python으로작성됨 
Key/Value 모델 
−Couchbase의확장성, 성능을활용(현재) 
Transaction 기능을제공 
21 
Couchbase(확장성+...
Domain이란? 
Domain은Key/Value 모델을지원하는논리적Database 
Domain내에서다중Key Transaction(MTX)을지원 
Domain간분산Transaction(DTX)을지원 
22 
D...
다중Key TX 예시 
23 
Transaction범위
분산TX 예시 
24 
Transaction범위
다중Key Transaction 
Read Copy Update(RCU) 소개 
RCU 예시 
RCU 정리 
다중Key Transaction 구현 
업데이트예제 
읽기/쓰기분석 
정리 
25
Read Copy Update(RCU) 소개 
(Readers-Writers) Lock 효과구현가능 
Wait-Free 읽기 
−반면쓰기오버헤드있음 
리눅스커널등에서사용 
26 
http://en.wikipedia...
RCU 예시(1/4) 
27 
N1 
N2 
N3 
Singlylinked list 
Next Ptr.
RCU 예시(2/4) 
28 
N2’ 
Copy On Write 스타일의업데이트 
N1 
N2 
N3
RCU 예시(3/4) 
29 
N2’ 
원자적으로N1의next pointer를N2’로교체(Ref. 공개, Publish) 
N1 
N2 
N3
RCU 예시(4/4) 
30 
더이상사용하는Thread가없는N2를제거(회수, Reclamation) 
N2’ 
N1 
N3
RCU 정리 
31 
자료구조는Reference로접근(Publish) 
−포인터등매핑구조필요 
−예제에서는N1에있는next pointer 
공개된Reference를원자적으로교체 
−리눅스커널의경우CPU H/W 특성(...
다중Key Transaction구현 
32 
자료구조는Reference로접근 
−각Domain은Virtual Key로구성 
−Virtual Key(Reference)를이용해데이터(Physical Key)를접근 
공개...
Virtual Key, Super Block 
33 
Virtual Key 
−Domain은다수의Virtual Key를저장하는DB 
−Game Logic은VirutalKey를이용해자료를접근 
Super Block 
...
자원회수를위한기준 
34 
CouchbaseView 
−저장된객체에대해색인을생성할수있음 
−색인은비동기적으로생성(Eventual Consistency) 
특정Domain의모든Physical Key 목록을얻을수있음 
...
업데이트예제(1/5) 
35
업데이트예제(2/5) 
36 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
‘hero1...
업데이트예제(3/5) 
37 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
‘hero1...
업데이트예제(4/5) 
38 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABD-lord', 
‘hero1...
업데이트예제(5/5) 
39 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABD-lord', 
‘hero1...
읽기/쓰기분석 
40 
읽기 
−Wait-Free 진입 
−SuperBlock을추가로가져와야함 
•단일도메인이너무많은키를가지는것은부담 
쓰기 
−Copy On Write 오버헤드 
−쓰기가중첩될경우Compare An...
정리 
41 
Domain 내에서다중Key에대해Transaction 제공 
Read Copy Update 스타일의구현 
읽기요청은Wait-Free로처리 
쓰기요청은재시도과정이있을수있음 
자원회수는배치작업으로후처리
분산Transaction 
Two Phase Commit 소개 
Two Phase Commit 처리과정 
TX Monitor, Resource Manager 
구현 
DTX 상태 
DTX 후처리 
DTX 상...
Two Phase Commit 소개 
분산트랜잭션처리를위한간단한프로토콜 
−하나의Transaction Monitor 
−다수의Resource Manager가참여 
금융권등에서널리사용됨 
Blocking 모델 
준...
Two Phase Commit 처리과정 
44 
TX 
Monitor 
RM(s) 
준비요청 
준비응답 
Commit 요청 
Commit 응답 
준비단계 
Commit단계
TX Monitor, Resource Manager 
TX Monitor 
−보통별도의서비스가역할을수행(Tuxedo, CICS) 
−분산TX정보(DTX Context)관리 
−TX Commit/Rollback 결정(A...
구현 
TX Monitor 
−별도서비스로존재하지않음(DTL 라이브러리가처리) 
−DTX Context를단일Key로저장 
Resource Manager 
−Domain이역할을수행 
−Super Block에대응정보추가...
DTX Context, Super Block 대응 
DTX Context 
−참여Domain 목록 
−DTX 상태저장(INIT, PENDING, ABORTED, COMMITED) 
−해당키는INIT 상태에서TTL(Ti...
DTX 상태 
INIT 
−DTXContext가생성된상태 
−TTL설정 
PENDING 
−참여하는모든Domain들을해당DTX에편입(Blocking) 
−관련로직을처리 
ABORTED 
−DTX Span 내에서예외...
DTX 후처리 
DTX 처리결과는다음MTX 처리전반영 
ABORT 결과적용 
−DTX Context가“ABORTED” 혹은“만료” 상태의경우 
−Domain 내DTX 관련자료를초기화 
COMMIT 결과적용 
−DT...
DTX 상태도 
50 
INIT 
PENDING 
ABORTED 
COMMITTED 
DTX 준비완료 
진행중예외 
TTL 만료 
성공 
ABORT 
Applied 
COMMT 
Applied 
DTX 후처리 
DT...
업데이트예제(1/7) 
51 
PENDING 
COMMITTED 
INIT
업데이트예제(2/7) 
52 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
‘hero1...
업데이트예제(3/7) 
53 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
‘hero1...
업데이트예제(4/7) 
54 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
…} 
dt...
업데이트예제(5/7) 
55 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
…} 
dt...
업데이트예제(6/7) 
56 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABD-lord', 
…} 
dt...
업데이트예제(7/7) 
57 
SuperBlock-Player1 
------------------------------------- 
VPMap= { 
'lord' : 'Player1-ABC-lord', 
…} 
dt...
정리 
58 
Domain 간분산Transaction 제공 
−참여하는Domain은다중Key Transaction 이용 
Two Phase Commit 스타일의구현 
Blocking 모델 
−PENDING 상태진입...
복구 
59 
Couchbase처리구조 
Key 유실가능성 
성능과안정성(Persistency) 사이의관계 
TX Log
Couchbase처리구조 
60 
비동기처리구조 
−디스크Sync 
−Node간Replication 
동기구조가존재는함 
−Endure 
−Persis_to 
DISK 
CouchbaseNode 
Managed 
C...
Key 유실가능성 
61 
쓰기요청처리와디스크Sync, Node Replication 처리간갭 
−장애시잃어버린Key를알수있을까? 
쓰기요청 
디스크Sync 
Node Replication 
유실가능틈
성능과안정성(Persistency) 사이의관계 
62 
비동기구조는고성능처리의핵심요소 
안정성은기다림을요구 
성능과안정성은아마도trade-off 관계 
완벽한솔루션? 
−초고성능DISK, 초고성능Network?
Undo Log 
63 
Key 유실가능성을받아들임 
−성능은서비스자체의가능성을위협 
Key 유실이발생할경우Domain정합성이깨어질위험이있음 
Undo Log를이용해정합성이깨진Domain을과거로돌림 
Couchba...
적용사례 
64 
선술집에서영웅고용 
레이드전투
선술집에서영웅고용 
65 
참여Domain; 영주 
단일TX로처리 
−진입; 무조건진입(Wait-Free) 
−종료; TX Span이끝날때다른Thread로인해CAS 실패가능성있음 
TX1 
TX2 
TX2 (Retr...
레이드전투 
66 
참여Domain; Legion, LegionPair, 영주(*) 
DTX로처리 
−진입; 모든참여Domain에DTX 정보기록, 이미진행중인DTX가있을경우실패 
−종료; Span이끝날때다른쓰레드로인...
마무리& QnA 
67 
Dryad Transaction Layer를이용해 
−NoSQL의확장성, 성능을바탕으로 
−Transaction이가능한프로그래밍모델을구현 
이를기반으로확장가능한게임서버를구현 
Couchbas...
Upcoming SlideShare
Loading in …5
×

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

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

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

  1. 1. 로살펴보는확장가능한게임서버의구현 2014-09-23 김홍모 ㈜드라이어드
  2. 2. 목차 스토리지요구사항분석 Dryad Transaction Layer 다중Key Transaction 분산Transaction 복구 적용사례 마무리& QnA 2
  3. 3. 도입 발표자소개 레기온즈소개 3
  4. 4. 발표자소개 ㈜드라이어드 −레기온즈서버개발 KTH −클라우드서비스를위한스토리지, 검색엔진개발 DAUM −검색엔진개발 4
  5. 5. 레기온즈소개 소셜전략RPG −영지개발(심시티) −영웅(카드) 수집및육성(밀리언아서) −유저간전투및약탈(클래시오브클랜즈) 2014.04 국내서비스오픈 2014.08 글로벌서비스오픈 5
  6. 6. 스토리지요구사항분석 NoSQL vs. RDBMS Couchbase로살펴보는“수평적확장성"의원리 Why NoSQL? 트랜잭션이없다면? Why Not NoSQL? 소셜게임에서의IO 패턴 새로운스토리지기술이필요 6
  7. 7. NoSQL vs. RDBMS 7 RDBMS NoSQL 대표제품 MySQL, MSSQL Couchbase,MongoDB API SQL 대부분Key/Value Transaction지원수준 Database범위 단일Key 수준 수평적확장성 대부분지원하지않음 지원
  8. 8. Couchbase로살펴보는“수평적확장성”의원리(1/5) 8 vBucket −독립된Key/Value Database vBucket
  9. 9. Couchbase로살펴보는“수평적확장성”의원리(2/5) 9 Dynamic Mapping −KEY vBucket Hash(KEY) vBucket vBucket vBucket vBucket vBucket vBucket vBucket vBucket
  10. 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. 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. 12. Couchbase로살펴보는“수평적확장성”의원리(5/5) 12 데이터분할(Partitioning) −Key를미리다수의vBucket으로나누어둠 데이터이동(Migration) −추가된Server에일부vBucket을복제하고vBucket맵을갱신
  13. 13. Why NoSQL? 13 NoSQL은수평적확장성이기능으로구현되어제공됨 −서버개발자가관련기능을구현할필요없음 RDBMS의경우데이터“분할“, “이동“ 과정을직접구현해야함
  14. 14. 트랜잭션이없다면? 14 Lord Hero Hero Hero Quest 데이터모델 Lord1 … Lord Hero Hero Hero Quest Lord2 …
  15. 15. 트랜잭션이없다면? 15 Lord Hero Hero Hero Quest Player vs. Player 전투의결과 Lord1 … Lord Hero Hero Hero Quest Lord2 … 부상 Hero 포로
  16. 16. 트랜잭션이없다면? 16 Lord Hero Hero Hero Quest 처리중에API Server가내려갔다면? Lord1 … Lord Hero Hero Hero Quest Lord2 … Hero 포로
  17. 17. 트랜잭션이없다면? 17 예외처리가어려움 서버장애처리가어려움 정기점검처리가어려움
  18. 18. Why Not NoSQL? 18 다수Key로구성된데이터에대해정합성유지가어려움 −단일Key로구현? −중요한데이터는RDBMS로? −특정시점에서버가죽지않도록기도하기
  19. 19. 새로운스토리지기술이필요 19 수평적확장성을제공 트랜잭션을지원
  20. 20. Dryad Transaction Layer Dryad Transaction Layer 소개 Domain이란? 다중Key Transaction 예시 분산Transaction 예시 20
  21. 21. Dryad Transaction Layer 소개 Python으로작성됨 Key/Value 모델 −Couchbase의확장성, 성능을활용(현재) Transaction 기능을제공 21 Couchbase(확장성+ 성능) Dryad Transaction Layer (트랜잭션) Game Logic (확장성+성능+생산성)
  22. 22. Domain이란? Domain은Key/Value 모델을지원하는논리적Database Domain내에서다중Key Transaction(MTX)을지원 Domain간분산Transaction(DTX)을지원 22 Domain MTX DTX
  23. 23. 다중Key TX 예시 23 Transaction범위
  24. 24. 분산TX 예시 24 Transaction범위
  25. 25. 다중Key Transaction Read Copy Update(RCU) 소개 RCU 예시 RCU 정리 다중Key Transaction 구현 업데이트예제 읽기/쓰기분석 정리 25
  26. 26. Read Copy Update(RCU) 소개 (Readers-Writers) Lock 효과구현가능 Wait-Free 읽기 −반면쓰기오버헤드있음 리눅스커널등에서사용 26 http://en.wikipedia.org/wiki/File:Tux.svg
  27. 27. RCU 예시(1/4) 27 N1 N2 N3 Singlylinked list Next Ptr.
  28. 28. RCU 예시(2/4) 28 N2’ Copy On Write 스타일의업데이트 N1 N2 N3
  29. 29. RCU 예시(3/4) 29 N2’ 원자적으로N1의next pointer를N2’로교체(Ref. 공개, Publish) N1 N2 N3
  30. 30. RCU 예시(4/4) 30 더이상사용하는Thread가없는N2를제거(회수, Reclamation) N2’ N1 N3
  31. 31. RCU 정리 31 자료구조는Reference로접근(Publish) −포인터등매핑구조필요 −예제에서는N1에있는next pointer 공개된Reference를원자적으로교체 −리눅스커널의경우CPU H/W 특성(cache line)을이용 자원회수를위한기준필요 −리눅스커널의경우single writer, context switch 제약조건도입
  32. 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. 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. 자원회수를위한기준 34 CouchbaseView −저장된객체에대해색인을생성할수있음 −색인은비동기적으로생성(Eventual Consistency) 특정Domain의모든Physical Key 목록을얻을수있음 −저장된객체의Key에대해Index 생성 −사전순으로리스팅이가능 도메인의모든Physical Key들 Super Block에등록된 사용중인P. Key들
  35. 35. 업데이트예제(1/5) 35
  36. 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. 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. 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. 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. 읽기/쓰기분석 40 읽기 −Wait-Free 진입 −SuperBlock을추가로가져와야함 •단일도메인이너무많은키를가지는것은부담 쓰기 −Copy On Write 오버헤드 −쓰기가중첩될경우Compare And Swap 실패가능성이있음 •재시도처리
  41. 41. 정리 41 Domain 내에서다중Key에대해Transaction 제공 Read Copy Update 스타일의구현 읽기요청은Wait-Free로처리 쓰기요청은재시도과정이있을수있음 자원회수는배치작업으로후처리
  42. 42. 분산Transaction Two Phase Commit 소개 Two Phase Commit 처리과정 TX Monitor, Resource Manager 구현 DTX 상태 DTX 후처리 DTX 상태도 예제 정리 42
  43. 43. Two Phase Commit 소개 분산트랜잭션처리를위한간단한프로토콜 −하나의Transaction Monitor −다수의Resource Manager가참여 금융권등에서널리사용됨 Blocking 모델 준비단계와Commit 두단계로진행 43
  44. 44. Two Phase Commit 처리과정 44 TX Monitor RM(s) 준비요청 준비응답 Commit 요청 Commit 응답 준비단계 Commit단계
  45. 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. 46. 구현 TX Monitor −별도서비스로존재하지않음(DTL 라이브러리가처리) −DTX Context를단일Key로저장 Resource Manager −Domain이역할을수행 −Super Block에대응정보추가 46 DTX
  47. 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. 48. DTX 상태 INIT −DTXContext가생성된상태 −TTL설정 PENDING −참여하는모든Domain들을해당DTX에편입(Blocking) −관련로직을처리 ABORTED −DTX Span 내에서예외가발생할경우ABORTED 상태로전환 COMMITTED −모든작업이성공할경우COMMITTED 상태로전환 −TTL 제거 48
  49. 49. DTX 후처리 DTX 처리결과는다음MTX 처리전반영 ABORT 결과적용 −DTX Context가“ABORTED” 혹은“만료” 상태의경우 −Domain 내DTX 관련자료를초기화 COMMIT 결과적용 −DTX Context가“COMMITTED” 상태일경우 −Domain 내존재하는DTX 관련자료를반영 49
  50. 50. DTX 상태도 50 INIT PENDING ABORTED COMMITTED DTX 준비완료 진행중예외 TTL 만료 성공 ABORT Applied COMMT Applied DTX 후처리 DTX 범위내
  51. 51. 업데이트예제(1/7) 51 PENDING COMMITTED INIT
  52. 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. 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. 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. 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. 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. 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. 정리 58 Domain 간분산Transaction 제공 −참여하는Domain은다중Key Transaction 이용 Two Phase Commit 스타일의구현 Blocking 모델 −PENDING 상태진입조건참여Domain에DTX 관련정보기록 −데드락회피 •Domain 준비를사전순으로처리
  59. 59. 복구 59 Couchbase처리구조 Key 유실가능성 성능과안정성(Persistency) 사이의관계 TX Log
  60. 60. Couchbase처리구조 60 비동기처리구조 −디스크Sync −Node간Replication 동기구조가존재는함 −Endure −Persis_to DISK CouchbaseNode Managed Cache Rep. Q Disk Q CouchbaseNode
  61. 61. Key 유실가능성 61 쓰기요청처리와디스크Sync, Node Replication 처리간갭 −장애시잃어버린Key를알수있을까? 쓰기요청 디스크Sync Node Replication 유실가능틈
  62. 62. 성능과안정성(Persistency) 사이의관계 62 비동기구조는고성능처리의핵심요소 안정성은기다림을요구 성능과안정성은아마도trade-off 관계 완벽한솔루션? −초고성능DISK, 초고성능Network?
  63. 63. Undo Log 63 Key 유실가능성을받아들임 −성능은서비스자체의가능성을위협 Key 유실이발생할경우Domain정합성이깨어질위험이있음 Undo Log를이용해정합성이깨진Domain을과거로돌림 Couchbase MySQL Game Logic DTL Undo Log
  64. 64. 적용사례 64 선술집에서영웅고용 레이드전투
  65. 65. 선술집에서영웅고용 65 참여Domain; 영주 단일TX로처리 −진입; 무조건진입(Wait-Free) −종료; TX Span이끝날때다른Thread로인해CAS 실패가능성있음 TX1 TX2 TX2 (Retry)
  66. 66. 레이드전투 66 참여Domain; Legion, LegionPair, 영주(*) DTX로처리 −진입; 모든참여Domain에DTX 정보기록, 이미진행중인DTX가있을경우실패 −종료; Span이끝날때다른쓰레드로인해COMMIT이실패할가능성은낮음 DTX1 DTX2 DTX3
  67. 67. 마무리& QnA 67 Dryad Transaction Layer를이용해 −NoSQL의확장성, 성능을바탕으로 −Transaction이가능한프로그래밍모델을구현 이를기반으로확장가능한게임서버를구현 Couchbase(확장성+ 성능) Dryad Transaction Layer (트랜잭션) Game Logic (확장성+성능+생산성)

×