ndc14 범용 게임 서버 프레임워크 디자인 및 테크닉

iFunFactory Inc.

GENERIC GAME SERVER FRAMEWORKDESIGN & APPLICABLE TECHNIQUES

아이펀팩토리 문대경 ([email protected])

iFunFactory Inc.

THIS TALK ISMAINLY ABOUT...

1. 시스템 디자인

2. 범용 게임 서버 프레임워크 디자인 연습 & 구현 기술

iFunFactory Inc.

ABOUTYOUR SPEAKER

옛날에 넥슨 서버팀장 (1999-2005)

미국 유학생 및 클라우드 컴퓨팅 스타트업 시니어 엔지니어 (2005-2011)

귀국 후 다시 넥슨의 피고용인 (2011-2013)

끝으로 갓 1년 된 스타트업 대표 (2013-현재)

iFunFactory Inc.

DISCLAIMERNO SHOPPING TOUR

걱정하지 마세요.

오늘 여기서는 물건 팔지 않습니다.

(문의: [email protected])

mailto:[email protected]

iFunFactory Inc.

SYSTEMLOOSE DEFINITIONS

특정 목적을 위한 물리적/논리적 컴포넌트의 집합

핵심 디자인 요소: Interface 와 Architecture

iFunFactory Inc.

SYSTEMINTERFACE

시스템이 무엇을 제공하는가?

(외부에서 바라보는 시스템의 모습)

Photo from ifixit.com

iFunFactory Inc.

SYSTEMARCHITECTURE

어떤 기능이 어디에 배치되는가?

(내부 구조에 대한 문제)

Photo from ifixit.com

iFunFactory Inc.

TRADE-OFFSAS SYSTEM DESIGN PRINCIPLE

만렙 시스템은 없다

리소스 제약 외에도 선택지 간 충돌 때문

Design decisions = Trade-off choices

훈남 외모

두뇌 힘

돈자상함

???

iFunFactory Inc.

TRADE-OFF IN SYSTEM DESIGNEXAMPLE: CAP THEOREM

Consistency, Availability, Partition tolerance

이 3개 중 2개만 가능 (by Prof. Eric Brewer)

Consistency PartitionTolerance

Availability

RDBMS(MySQL)

iFunFactory Inc.

TRADE-OFF IN SYSTEM DESIGNEXAMPLE: CAP THEOREM

Consistency, Availability, Partition tolerance

이 3개 중 2개만 가능 (by Prof. Eric Brewer)

Consistency PartitionTolerance

Availability

RDBMS(MySQL)

CassandraCouchDBDynamo

RedisMongoDB(SAFE=1)

iFunFactory Inc.

TRADE-OFF IN SYSTEM DESIGNEXAMPLE: INTERNET PROTOCOL (IP)Design Goals*

1. 존재하는 네트워크들 연결 (ARPANET & ARPA packet radio net)

2. 장애에서도 통신 가능

3. 다양한 형태의 서비스 지원

4. 다양한 네트워크 기술의 수용

5. 분산 관리

6. 저렴한 가격

7. 호스트의 쉬운 추가

8. 사용자별 자원 사용량 계측

*D. Clark et al, “The Design philosophy of the DARPA internet protocols”, SIGCOMM CCR, 1988

iFunFactory Inc.

Design Goals*





5. 분산 관리

6. 저렴한 가격




Autonomous System (AS)& Interdomain Routing

TRADE-OFF IN SYSTEM DESIGNEXAMPLE: INTERNET PROTOCOL (IP)

iFunFactory Inc.

TRADE-OFF IN SYSTEM DESIGNEXAMPLE: INTERNET PROTOCOL (IP)Design Goals*





5. 분산 관리

6. 저렴한 가격




iFunFactory Inc.

EXPERIENCED SYSTEM DESIGNERKNOW YOUR SYSTEM

목표의 정의

• 어떤 가정 하에 어떤 것들이 필수이고, 어떤 것들을 포기할 수 있는가?

목표를 반영하는 인터페이스/아키텍처 디자인

• 인터페이스와 아키텍처에 따라 시스템이 제공하는 것, 할 수 있는 것, 할 수 없는 것이 결정된다.

디자인을 현실화

• 어떤 Technology를 쓸 것인가?

iFunFactory Inc.

SYSTEM COMPONENTGRANULARITY

코드 한 줄

함수

모듈

서비스

사람(?)

시스템 디자이너의 성장 방향

iFunFactory Inc.

SYSTEM DESIGNRECAP

1. 시스템 디자인에 절대적으로 우월한 답은 없음

2. 시스템 디자인의 핵심은 어떤 가정하에서 무엇이 가능하고 불가능한지 정하는 것

3. 이를 위한 트레이오프 선택과 각각의 의미를 파악

4. 디자인을 구현으로 옮기는 것은 또 다른 기술

iFunFactory Inc.

LAB SESSION:GENERIC GAME SERVER FRAMEWORK

iFunFactory Inc.

GAME SERVER FRAMEWORKDESIGN REQUIREMENTS

가정

• 우리는 어떤 게임이 올라갈지 모른다.

반드시 달성할 것

• Flexibility: 가급적 임의의 게임을 모두 지원할 수 있어야 한다.

• Scalability: 서버를 추가하는 방식으로 scale-out 할 수 있어야 한다. (vs. scale-up)

희생할 수도 있는 것

• Inefficiency: 임의의 게임을 지원하기 때문에 다소의 비효율성은 감안한다.

iFunFactory Inc.

GAME SERVER FRAMEWORKDESIGN GOALS

1. Flexibility: 임의의 게임을 지원할 수 있어야 한다.

2. Scalability: scale-out 할 수 있어야 한다.

3. Performance: 최소 기준으로 서버당 active session 10,000개를 서비스 해야 한다.

iFunFactory Inc.

GAME SERVICESIMPLIFIED ARCHITECTURE

Game Server

DB Server

Game Client

Game Client

Game Client

BillingServer

AuthenServer

Analytics Server

Dashboard

Data path

Control path

iFunFactory Inc.

WE WILL DESIGN THESE…

Interface

• Data path: client-server message format

• Control path: server management (e.g., dashboard)

Architecture

• Game object design

• Server distribution

iFunFactory Inc.

INTERFACE DESIGN #1CLIENT-SERVER MESSAGE FORMAT

Standard format• HTTP, UDP, JSON, XML, …

• Pros: Usability

• Cons: Inefficiency

Game Server

Game Client

iFunFactory Inc.


Custom format• TLV, 길이를 앞에 넣는 TCP 메시지

• Pros: Efficiency

• Cons: Manageability

Game Server

Game Client

iFunFactory Inc.

추가 고려 사항

• Message format overhead: 포맷 자체의 오버헤드 (예, XML tag, JSON braces, …)

• Traffic profile: 클라이언트-서버간의 트래픽 패턴 (평균, min-max 등).

• Encryption strategy: 메시지 전체를 암호화? 특정 field 만 암호화?

암호화된 binary data 를 전송할 수 있는가?


iFunFactory Inc.


이 가상의 예제에서는…

JSON

• Pros: 어떤 언어/플랫폼에서도 쉽게 구할 수 있는 라이브러리 (iOS, Android, PC, …)

표준 방법이기 때문에 learning curve 가 상대적으로 적음

어떤 게임이든 다룰 수 있는 유연성

상대적으로 적은 포맷 오버헤드 (VS. XML tags)

• Cons: 텍스트 형태이기 때문에 트래픽 오버헤드와 parsing 오버헤드.

(트래픽은 상대적으로 덜 걱정: 게임 트래픽은 수백 바이트의 적은 데이터가 Bursty 하게 발생)

iFunFactory Inc.

INTERFACE DESIGN #2SERVER MANAGEMENT

Push-based approach

• 서버가 상태 값을 주기적으로 생성 (예: file/DB logging, SNMP)

• 외부 프로세스가 이를 처리하고 별도의 채널로 게임 서버 프로세스를 관리

• Pros: 구현이 간단 (서버는 보내고 잊어버림)

• Cons: 불필요한 데이터 생성

사용하는 측에서 push 된 데이터의 format 을 가공해서 사용

데이터와 콘트롤이 별개의 채널로 존재

Game Server

Mgmtsubsystem

DataPush

ControlInvoke

iFunFactory Inc.


Pull-based approach

• 외부 요청이 있을 때만 서버가 상태 값을 반환

• 예: SOAP, REST, …

• Pros: 불필요한 데이터 생성 적음.

API 를 통한 쉬운 연동.

Data 와 control 이 같은 채널 사용

• Cons: 구현이 복잡 (항상 export 해야되는 data 는 pull 때까지 보관해야함)

Game Server

Mgmtsubsystem

DataPush

ControlInvoke

iFunFactory Inc.



Push-based: 중요 유저 행동 로그

• 손실이 생기면 안되고 중간 값들 모두 중요

• 외부 연동보다 내부 기록 (고객 지원) 이 더 중요

Pull-based: 서버 상태 및 통계 데이터

• 불특정 외부 시스템과의 연동 중요

• 몇 번의 손실이 생겨도 상관없으며 중간 값 보다 일정 주기의 결과값이 중요

iFunFactory Inc.

ARCHITECTURE DESIGN #1GAME OBJECTS

Stock game objects & class hierarchy

• 프레임워크에서 제공하는 게임 오브젝트 & 클래스 계층

• Pros: 특정 목적에 부합한다면 게임 개발자의 작업 최소화 가능

성능 개선이 용이

• Cons: 다양한 게임을 지원하기에는 유연성 부족 (다중 상속이 필요해짐)

iFunFactory Inc.


Custom game objects & class hierarchy

• Pros: 각 게임에 가장 적합한 오브젝트 설계 가능

• Cons: 모든 작업을 게임 개발자가 해야 됨

프레임워크가 게임 오브젝트 구현의 성능 개선을 할 수 없음

iFunFactory Inc.


Hybrid approach: class definition in meta language

• 클래스 정의는 meta 언어로 작성하고 프레임워크가 클래스 코드 생성

• Pros: 게임에 필요한 오브젝트 설계가 어느 정도 가능

• Cons: 여전히 프레임워크가 성능 개선하는데 한계. (특히 locking)

iFunFactory Inc.

DEADLOCKHAPPENS IFF…

Mutual exclusion

Hold-and-wait

No preemption

Circular wait

iFunFactory Inc.

DEADLOCKRESOLUTION

Mutual exclusion

Hold-and-wait 잡고 기다리는 대신 풀고 기다리기

No preemption 강제로 lock 뺏기

Circular wait 락 순서가 틀렸다면 다 풀고 새로 잡기

iFunFactory Inc.

DEADLOCKRESOLUTION

Mutual exclusion

Hold-and-wait 잡고 기다리는 대신 풀고 기다리기

No preemption 강제로 lock 뺏기

Circular wait 락 순서가 틀렸다면 다 풀고 새로 잡기

돌고 있던 작업을 취소해야 함. 즉, rollback이 가능해야 함.

iFunFactory Inc.

DEADLOCK RESOLUTIONJOURNALING & ROLLBACK

진행중인 작업을 취소 시, 일련의 동작들의 atomicity 를 보장할 수 없음

이 때문에 진행중인 작업을 바로 state 로 반영하는 대신

Per-thread journal 에 기록 후, 작업의 성공적인 완료 시에만 state 로 반영함

Rollback 은 journal 을 버리는 것만으로 간단하게 구현

iFunFactory Inc.

YOU MAY ASK…

Q. 정말 journaling 이 동작하나요?

A. 예

iFunFactory Inc.

RETHINKINGCONCURRENCY-CONTROL

Consistency 를 보장하기 위한 제어

Serializability

• 결과물은 하나의 worker 만이 작업한 것과 같아야 한다.

iFunFactory Inc.

CONCURRENCY CONTROLPESSIMISTIC VS. OPTIMISTIC

Pessimistic concurrency control

“우리는 반드시 충돌할거야.”

• Consistency 를 절대 어기지 않도록 보호. 그러니 취소도 없음.

• 중앙 집중식

iFunFactory Inc.


Optimistic concurrency control

“에이, 설마 충돌 나겠어? 그건 그때 가서 생각하자.”

• 일단 작업하고, consistency 조건을 어겼을 때는 작업 취소 (rollback)

• 분산 처리식

iFunFactory Inc.


어떤 것이 더 좋은가?

(연사가 싫어하는 표현이지만) 케바케

iFunFactory Inc.


Performance(high lock contention)

Performance(low lock contention)

Pessimistic Good Bad

Optimistic Bad Good

iFunFactory Inc.


Performance(high lock contention)

Performance(low lock contention)

Pessimistic Good Bad

Optimistic Bad Good

참고: 많은 게임에서, 설령 두 게임 유저가 동시에 리소스 경쟁을 하더라도 (예: 득템 경쟁),network latency 때문에 게임 서버 입장에서 인지하는 contention rate 은 생각보다 높지 않은 편이다.

iFunFactory Inc.

ARCHITECTURE DESIGN #1OBJECT DESIGN


Hybrid approach

• 게임 개발자는 game object 를 JSON 으로 기술하고 framework 이 class 코드를 생성한다.

• Deadlock 은 Hold-and-wait 을 깨서 해결한다.

• 이 때문에 journal & rollback 을 이용한 optimistic concurrency control 을 한다.

Rollback 가능 시스템의 장점

• 다양한 exception 을 graceful 하게 처리할 수 있음

iFunFactory Inc.

ARCHITECTURE DESIGN #2DISTRIBUTED SERVERS

Partitioned world

• 오브젝트/사용자들을 파티셔닝해서 각 서버가 담당하게 지정

• 다른 서버의 사용자와는 통신이 불가능

• 대부분 “채널” 이라는 이름으로 존재

• Pros: 구현이 간단

• Cons: 게임 사용자들이 게임이 아닌 서버의 구성을 알게 되는 문제

iFunFactory Inc.

ARCHITECTURE DESIGN #2DISTRIBUTED SERVERS

Shared world

• 다른 서버의 사용자와의 통신은 RPC 를 통해서 이루어짐

• 모든 사용자가 하나의 거대한 world 에 포함됨

• Pros: 게임 유저들은 하나의 가상 세계를 공유하게 됨

• Cons: Remote locking 등 구현이 복잡

RPC 를 통하는 경우 유저들은 lag 으로 인식하게 됨 (sync 가 중요할 수록 문제)

iFunFactory Inc.

DISTRIBUTED SERVERSREMOTE OBJECT HANDLING

S1 S2

O2

2) Remote lease request

DirectoryService

Object Server

O2 S2

1) Object lookup

3) Lock O2 for S1

4) Lease grant

iFunFactory Inc.

DISTRIBUTED SERVERSREMOTE OBJECT HANDLING

S1 S2

DirectoryService

6) Object migration request

5) Update O2’s ref count

7) Object release order

8) Object release confirm

9) Update directory entry

10) Migration OK

iFunFactory Inc.

LAB SESSIONRECAP

클라이언트-서버 메시지 포맷 JSON

서버 관리 인터페이스 REST API

게임 오브젝트 지원 JSON 으로부터 코드 생성 + Journaling

분산 서버 RPC 를 통한 Shared World

iFunFactory Inc.

CONTACT

[email protected]

WE ARE HIRING!