SlideShare a Scribd company logo

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

NAVER D2
NAVER D2

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

1 of 67
Download to read offline
로살펴보는확장가능한게임서버의구현 
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 패턴 
새로운스토리지기술이필요 
6

Recommended

[2B7]시즌2 멀티쓰레드프로그래밍이 왜 이리 힘드나요
[2B7]시즌2 멀티쓰레드프로그래밍이 왜 이리 힘드나요[2B7]시즌2 멀티쓰레드프로그래밍이 왜 이리 힘드나요
[2B7]시즌2 멀티쓰레드프로그래밍이 왜 이리 힘드나요NAVER D2
 
(2013 DEVIEW) 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
(2013 DEVIEW) 멀티쓰레드 프로그래밍이  왜이리 힘드나요? (2013 DEVIEW) 멀티쓰레드 프로그래밍이  왜이리 힘드나요?
(2013 DEVIEW) 멀티쓰레드 프로그래밍이 왜이리 힘드나요? 내훈 정
 
242 naver-2
242 naver-2242 naver-2
242 naver-2NAVER D2
 
Multithread & shared_ptr
Multithread & shared_ptrMultithread & shared_ptr
Multithread & shared_ptr내훈 정
 
비동기 파일 로딩
비동기 파일 로딩비동기 파일 로딩
비동기 파일 로딩Bongseok Cho
 
Multi-thread : producer - consumer
Multi-thread : producer - consumerMulti-thread : producer - consumer
Multi-thread : producer - consumerChang Yoon Oh
 

More Related Content

What's hot

헤테로지니어스 컴퓨팅 : CPU 에서 GPU 로 옮겨가기
헤테로지니어스 컴퓨팅 :  CPU 에서 GPU 로 옮겨가기헤테로지니어스 컴퓨팅 :  CPU 에서 GPU 로 옮겨가기
헤테로지니어스 컴퓨팅 : CPU 에서 GPU 로 옮겨가기zupet
 
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것흥배 최
 
Concurrency in action - chapter 7
Concurrency in action - chapter 7Concurrency in action - chapter 7
Concurrency in action - chapter 7JinWoo Lee
 
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?내훈 정
 
Concurrency in action - chapter 5
Concurrency in action - chapter 5Concurrency in action - chapter 5
Concurrency in action - chapter 5JinWoo Lee
 
11_웹서비스활용
11_웹서비스활용11_웹서비스활용
11_웹서비스활용noerror
 
안드로이드 멀티스레딩 입문 송형주
안드로이드 멀티스레딩 입문 송형주안드로이드 멀티스레딩 입문 송형주
안드로이드 멀티스레딩 입문 송형주iamhjoo (송형주)
 
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - PerfornanceGCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance상현 조
 
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화sung ki choi
 
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이  왜 이리 힘드나요?  (Lock-free에서 Transactional Memory까지)Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이  왜 이리 힘드나요?  (Lock-free에서 Transactional Memory까지)
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)내훈 정
 
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)khuhacker
 
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing SystemGCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System상현 조
 
[2D4]Python에서의 동시성_병렬성
[2D4]Python에서의 동시성_병렬성[2D4]Python에서의 동시성_병렬성
[2D4]Python에서의 동시성_병렬성NAVER D2
 
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group SystemGCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System상현 조
 
이권일 Sse 를 이용한 최적화와 실제 사용 예
이권일 Sse 를 이용한 최적화와 실제 사용 예이권일 Sse 를 이용한 최적화와 실제 사용 예
이권일 Sse 를 이용한 최적화와 실제 사용 예zupet
 
Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용흥배 최
 
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server SampleGCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample상현 조
 
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with ExceptionGCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception상현 조
 
NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현noerror
 

What's hot (20)

헤테로지니어스 컴퓨팅 : CPU 에서 GPU 로 옮겨가기
헤테로지니어스 컴퓨팅 :  CPU 에서 GPU 로 옮겨가기헤테로지니어스 컴퓨팅 :  CPU 에서 GPU 로 옮겨가기
헤테로지니어스 컴퓨팅 : CPU 에서 GPU 로 옮겨가기
 
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
 
Concurrency in action - chapter 7
Concurrency in action - chapter 7Concurrency in action - chapter 7
Concurrency in action - chapter 7
 
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
 
Concurrency in action - chapter 5
Concurrency in action - chapter 5Concurrency in action - chapter 5
Concurrency in action - chapter 5
 
11_웹서비스활용
11_웹서비스활용11_웹서비스활용
11_웹서비스활용
 
Thread programming
Thread programmingThread programming
Thread programming
 
안드로이드 멀티스레딩 입문 송형주
안드로이드 멀티스레딩 입문 송형주안드로이드 멀티스레딩 입문 송형주
안드로이드 멀티스레딩 입문 송형주
 
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - PerfornanceGCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance
GCGC- CGCII 서버 엔진에 적용된 기술 (2) - Perfornance
 
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
 
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이  왜 이리 힘드나요?  (Lock-free에서 Transactional Memory까지)Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이  왜 이리 힘드나요?  (Lock-free에서 Transactional Memory까지)
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)
 
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)
2015 제2회 동아리 해커 세미나 - 병렬컴퓨팅 소개 (16기 김정현)
 
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing SystemGCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System
GCGC- CGCII 서버 엔진에 적용된 기술 (4) - Executing System
 
[2D4]Python에서의 동시성_병렬성
[2D4]Python에서의 동시성_병렬성[2D4]Python에서의 동시성_병렬성
[2D4]Python에서의 동시성_병렬성
 
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group SystemGCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System
GCGC- CGCII 서버 엔진에 적용된 기술 (8) - Group System
 
이권일 Sse 를 이용한 최적화와 실제 사용 예
이권일 Sse 를 이용한 최적화와 실제 사용 예이권일 Sse 를 이용한 최적화와 실제 사용 예
이권일 Sse 를 이용한 최적화와 실제 사용 예
 
Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용
 
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server SampleGCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample
GCGC- CGCII 서버 엔진에 적용된 기술 (6) - CGCII Server Sample
 
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with ExceptionGCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception
GCGC- CGCII 서버 엔진에 적용된 기술 (5) - Executor with Exception
 
NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현
 

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

[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버준철 박
 
NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스Sungik Kim
 
Before OTD EDU Assignments
Before OTD EDU AssignmentsBefore OTD EDU Assignments
Before OTD EDU AssignmentsBeom Lee
 
세션1. block chain as a platform
세션1. block chain as a platform세션1. block chain as a platform
세션1. block chain as a platformJay JH Park
 
MySQL_MariaDB로의_전환_기술요소-202212.pptx
MySQL_MariaDB로의_전환_기술요소-202212.pptxMySQL_MariaDB로의_전환_기술요소-202212.pptx
MySQL_MariaDB로의_전환_기술요소-202212.pptxNeoClova
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017Amazon Web Services Korea
 
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbmsNAVER D2
 
데이타베이스 기본튜닝
데이타베이스 기본튜닝 데이타베이스 기본튜닝
데이타베이스 기본튜닝 Jinuk Bhak
 
Boost 라이브리와 C++11
Boost 라이브리와 C++11Boost 라이브리와 C++11
Boost 라이브리와 C++11OnGameServer
 
Tips and experience of DX12 Engine development .
Tips and experience of DX12 Engine development .Tips and experience of DX12 Engine development .
Tips and experience of DX12 Engine development .YEONG-CHEON YOU
 
[0312 조진현] good bye dx9
[0312 조진현] good bye dx9[0312 조진현] good bye dx9
[0312 조진현] good bye dx9진현 조
 
Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Gruter
 
Pgday bdr gt1000
Pgday bdr gt1000Pgday bdr gt1000
Pgday bdr gt1000정대 천
 
Pgday bdr 천정대
Pgday bdr 천정대Pgday bdr 천정대
Pgday bdr 천정대PgDay.Seoul
 
[KGC2014] DX9에서DX11로의이행경험공유
[KGC2014] DX9에서DX11로의이행경험공유[KGC2014] DX9에서DX11로의이행경험공유
[KGC2014] DX9에서DX11로의이행경험공유Hwan Min
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지강 민우
 
Quick & Dirty Tips for x64 hooks
Quick & Dirty Tips for x64 hooksQuick & Dirty Tips for x64 hooks
Quick & Dirty Tips for x64 hooks용환 노
 
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)Esun Kim
 
하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조Logpresso
 

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

[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
 
NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스
 
Before OTD EDU Assignments
Before OTD EDU AssignmentsBefore OTD EDU Assignments
Before OTD EDU Assignments
 
세션1. block chain as a platform
세션1. block chain as a platform세션1. block chain as a platform
세션1. block chain as a platform
 
MySQL_MariaDB로의_전환_기술요소-202212.pptx
MySQL_MariaDB로의_전환_기술요소-202212.pptxMySQL_MariaDB로의_전환_기술요소-202212.pptx
MySQL_MariaDB로의_전환_기술요소-202212.pptx
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
 
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
 
데이타베이스 기본튜닝
데이타베이스 기본튜닝 데이타베이스 기본튜닝
데이타베이스 기본튜닝
 
Processor
ProcessorProcessor
Processor
 
Boost 라이브리와 C++11
Boost 라이브리와 C++11Boost 라이브리와 C++11
Boost 라이브리와 C++11
 
Tips and experience of DX12 Engine development .
Tips and experience of DX12 Engine development .Tips and experience of DX12 Engine development .
Tips and experience of DX12 Engine development .
 
[0312 조진현] good bye dx9
[0312 조진현] good bye dx9[0312 조진현] good bye dx9
[0312 조진현] good bye dx9
 
Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014
 
Pgday bdr gt1000
Pgday bdr gt1000Pgday bdr gt1000
Pgday bdr gt1000
 
Pgday bdr 천정대
Pgday bdr 천정대Pgday bdr 천정대
Pgday bdr 천정대
 
[KGC2014] DX9에서DX11로의이행경험공유
[KGC2014] DX9에서DX11로의이행경험공유[KGC2014] DX9에서DX11로의이행경험공유
[KGC2014] DX9에서DX11로의이행경험공유
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
 
Quick & Dirty Tips for x64 hooks
Quick & Dirty Tips for x64 hooksQuick & Dirty Tips for x64 hooks
Quick & Dirty Tips for x64 hooks
 
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)
Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)
 
하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조하이퍼레저 패브릭 데이터 구조
하이퍼레저 패브릭 데이터 구조
 

More from NAVER D2

[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다NAVER D2
 
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...NAVER D2
 
[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기NAVER D2
 
[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발NAVER D2
 
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈NAVER D2
 
[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&ANAVER D2
 
[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기NAVER D2
 
[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep LearningNAVER D2
 
[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applicationsNAVER D2
 
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingOld version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingNAVER D2
 
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지NAVER D2
 
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기NAVER D2
 
[224]네이버 검색과 개인화
[224]네이버 검색과 개인화[224]네이버 검색과 개인화
[224]네이버 검색과 개인화NAVER D2
 
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)NAVER D2
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기NAVER D2
 
[213] Fashion Visual Search
[213] Fashion Visual Search[213] Fashion Visual Search
[213] Fashion Visual SearchNAVER D2
 
[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화NAVER D2
 
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지NAVER D2
 
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터NAVER D2
 
[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?NAVER D2
 

More from NAVER D2 (20)

[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다
 
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
 
[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기
 
[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발
 
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
 
[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A
 
[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기
 
[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning
 
[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications
 
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingOld version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
 
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
 
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
 
[224]네이버 검색과 개인화
[224]네이버 검색과 개인화[224]네이버 검색과 개인화
[224]네이버 검색과 개인화
 
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
 
[213] Fashion Visual Search
[213] Fashion Visual Search[213] Fashion Visual Search
[213] Fashion Visual Search
 
[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화
 
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
 
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
 
[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?
 

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

  • 2. 목차 스토리지요구사항분석 Dryad Transaction Layer 다중Key Transaction 분산Transaction 복구 적용사례 마무리& QnA 2
  • 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 수준 수평적확장성 대부분지원하지않음 지원
  • 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로? −특정시점에서버가죽지않도록기도하기
  • 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들
  • 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 범위내
  • 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
  • 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 (확장성+성능+생산성)