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

1. iFunFactory Inc.
GENERIC GAME SERVER FRAMEWORK
DESIGN & APPLICABLE TECHNIQUES
아이펀팩토리 문대경 (dkmoon@ifunfactory.com)

2. iFunFactory Inc.
THIS TALK IS
MAINLY ABOUT...
1. 시스템 디자인
2. 범용 게임 서버 프레임워크 디자인 연습 & 구현 기술

3. iFunFactory Inc.
ABOUT
YOUR SPEAKER
 옛날에 넥슨 서버팀장 (1999-2005)
 미국 유학생 및 클라우드 컴퓨팅 스타트업 시니어 엔지니어 (2005-2011)
 귀국 후 다시 넥슨의 피고용인 (2011-2013)
 끝으로 갓 1년 된 스타트업 대표 (2013-현재)

4. iFunFactory Inc.
DISCLAIMER
NO SHOPPING TOUR
걱정하지 마세요.
오늘 여기서는 물건 팔지 않습니다.
(문의: info@ifunfactory.com)

5. iFunFactory Inc.
SYSTEM
LOOSE DEFINITIONS
 특정 목적을 위한 물리적/논리적 컴포넌트의 집합
 핵심 디자인 요소: Interface 와 Architecture

6. iFunFactory Inc.
SYSTEM
INTERFACE
시스템이 무엇을 제공하는가?
(외부에서 바라보는 시스템의 모습)
Photo from ifixit.com

7. iFunFactory Inc.
SYSTEM
ARCHITECTURE
어떤 기능이 어디에 배치되는가?
(내부 구조에 대한 문제)
Photo from ifixit.com

8. iFunFactory Inc.
TRADE-OFFS
AS SYSTEM DESIGN PRINCIPLE
 만렙 시스템은 없다
 리소스 제약 외에도 선택지 간 충돌 때문
 Design decisions = Trade-off choices
훈남 외모
두뇌 힘
돈자상함
???

9. iFunFactory Inc.
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: CAP THEOREM
Consistency, Availability, Partition tolerance
이 3개 중 2개만 가능 (by Prof. Eric Brewer)
Consistency Partition
Tolerance
Availability
RDBMS
(MySQL)

10. iFunFactory Inc.
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: CAP THEOREM
Consistency, Availability, Partition tolerance
이 3개 중 2개만 가능 (by Prof. Eric Brewer)
Consistency Partition
Tolerance
Availability
RDBMS
(MySQL)
Cassandra
CouchDB
Dynamo
Redis
MongoDB
(SAFE=1)

11. iFunFactory Inc.
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: 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

12. iFunFactory Inc.
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
Autonomous System (AS)
& Interdomain Routing
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: INTERNET PROTOCOL (IP)

13. iFunFactory Inc.
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: 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

14. iFunFactory Inc.
TRADE-OFF IN SYSTEM DESIGN
EXAMPLE: 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

15. iFunFactory Inc.
EXPERIENCED SYSTEM DESIGNER
KNOW YOUR SYSTEM
 목표의 정의
• 어떤 가정 하에 어떤 것들이 필수이고, 어떤 것들을 포기할 수 있는가?
 목표를 반영하는 인터페이스/아키텍처 디자인
• 인터페이스와 아키텍처에 따라 시스템이 제공하는 것, 할 수 있는 것, 할 수 없는 것이 결정된다.
 디자인을 현실화
• 어떤 Technology를 쓸 것인가?

16. iFunFactory Inc.
SYSTEM COMPONENT
GRANULARITY
 코드 한 줄
 함수
 모듈
 서비스
 사람(?)
시스템 디자이너의 성장 방향

17. iFunFactory Inc.
SYSTEM DESIGN
RECAP
1. 시스템 디자인에 절대적으로 우월한 답은 없음
2. 시스템 디자인의 핵심은 어떤 가정하에서 무엇이 가능하고 불가능한지 정하는 것
3. 이를 위한 트레이오프 선택과 각각의 의미를 파악
4. 디자인을 구현으로 옮기는 것은 또 다른 기술

18. iFunFactory Inc.
LAB SESSION:
GENERIC GAME SERVER FRAMEWORK

19. iFunFactory Inc.
GAME SERVER FRAMEWORK
DESIGN REQUIREMENTS
 가정
• 우리는 어떤 게임이 올라갈지 모른다.
 반드시 달성할 것
• Flexibility: 가급적 임의의 게임을 모두 지원할 수 있어야 한다.
• Scalability: 서버를 추가하는 방식으로 scale-out 할 수 있어야 한다. (vs. scale-up)
 희생할 수도 있는 것
• Inefficiency: 임의의 게임을 지원하기 때문에 다소의 비효율성은 감안한다.

20. iFunFactory Inc.
GAME SERVER FRAMEWORK
DESIGN GOALS
1. Flexibility: 임의의 게임을 지원할 수 있어야 한다.
2. Scalability: scale-out 할 수 있어야 한다.
3. Performance: 최소 기준으로 서버당 active session 10,000개를 서비스 해야 한다.

21. iFunFactory Inc.
GAME SERVICE
SIMPLIFIED ARCHITECTURE
Game
Server
DB
Server
Game
Client
Game
Client
Game
Client
Billing
Server
Authen
Server
Analytics
Server
Dashboard
Data path
Control path

22. 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

23. iFunFactory Inc.
INTERFACE DESIGN #1
CLIENT-SERVER MESSAGE FORMAT
 Standard format
• HTTP, UDP, JSON, XML, …
• Pros: Usability
• Cons: Inefficiency
Game
Server
Game
Client

24. iFunFactory Inc.
INTERFACE DESIGN #1
CLIENT-SERVER MESSAGE FORMAT
 Custom format
• TLV, 길이를 앞에 넣는 TCP 메시지
• Pros: Efficiency
• Cons: Manageability
Game
Server
Game
Client

25. iFunFactory Inc.
 추가 고려 사항
• Message format overhead: 포맷 자체의 오버헤드 (예, XML tag, JSON braces, …)
• Traffic profile: 클라이언트-서버간의 트래픽 패턴 (평균, min-max 등).
• Encryption strategy: 메시지 전체를 암호화? 특정 field 만 암호화?
암호화된 binary data 를 전송할 수 있는가?
INTERFACE DESIGN #1
CLIENT-SERVER MESSAGE FORMAT

26. iFunFactory Inc.
INTERFACE DESIGN #1
CLIENT-SERVER MESSAGE FORMAT
이 가상의 예제에서는…
JSON
• Pros: 어떤 언어/플랫폼에서도 쉽게 구할 수 있는 라이브러리 (iOS, Android, PC, …)
표준 방법이기 때문에 learning curve 가 상대적으로 적음
어떤 게임이든 다룰 수 있는 유연성
상대적으로 적은 포맷 오버헤드 (VS. XML tags)
• Cons: 텍스트 형태이기 때문에 트래픽 오버헤드와 parsing 오버헤드.
(트래픽은 상대적으로 덜 걱정: 게임 트래픽은 수백 바이트의 적은 데이터가 Bursty 하게 발생)

27. iFunFactory Inc.
INTERFACE DESIGN #2
SERVER MANAGEMENT
 Push-based approach
• 서버가 상태 값을 주기적으로 생성 (예: file/DB logging, SNMP)
• 외부 프로세스가 이를 처리하고 별도의 채널로 게임 서버 프로세스를 관리
• Pros: 구현이 간단 (서버는 보내고 잊어버림)
• Cons: 불필요한 데이터 생성
사용하는 측에서 push 된 데이터의 format 을 가공해서 사용
데이터와 콘트롤이 별개의 채널로 존재
Game
Server
Mgmt
subsystem
Data
Push
Control
Invoke

28. iFunFactory Inc.
INTERFACE DESIGN #2
SERVER MANAGEMENT
 Pull-based approach
• 외부 요청이 있을 때만 서버가 상태 값을 반환
• 예: SOAP, REST, …
• Pros: 불필요한 데이터 생성 적음.
API 를 통한 쉬운 연동.
Data 와 control 이 같은 채널 사용
• Cons: 구현이 복잡 (항상 export 해야되는 data 는 pull 때까지 보관해야함)
Game
Server
Mgmt
subsystem
Data
Push
Control
Invoke

29. iFunFactory Inc.
INTERFACE DESIGN #2
SERVER MANAGEMENT
이 가상의 예제에서는…
Push-based: 중요 유저 행동 로그
• 손실이 생기면 안되고 중간 값들 모두 중요
• 외부 연동보다 내부 기록 (고객 지원) 이 더 중요
Pull-based: 서버 상태 및 통계 데이터
• 불특정 외부 시스템과의 연동 중요
• 몇 번의 손실이 생겨도 상관없으며 중간 값 보다 일정 주기의 결과값이 중요

30. iFunFactory Inc.
ARCHITECTURE DESIGN #1
GAME OBJECTS
 Stock game objects & class hierarchy
• 프레임워크에서 제공하는 게임 오브젝트 & 클래스 계층
• Pros: 특정 목적에 부합한다면 게임 개발자의 작업 최소화 가능
성능 개선이 용이
• Cons: 다양한 게임을 지원하기에는 유연성 부족 (다중 상속이 필요해짐)

31. iFunFactory Inc.
ARCHITECTURE DESIGN #1
GAME OBJECTS
 Custom game objects & class hierarchy
• Pros: 각 게임에 가장 적합한 오브젝트 설계 가능
• Cons: 모든 작업을 게임 개발자가 해야 됨
프레임워크가 게임 오브젝트 구현의 성능 개선을 할 수 없음

32. iFunFactory Inc.
ARCHITECTURE DESIGN #1
GAME OBJECTS
 Hybrid approach: class definition in meta language
• 클래스 정의는 meta 언어로 작성하고 프레임워크가 클래스 코드 생성
• Pros: 게임에 필요한 오브젝트 설계가 어느 정도 가능
• Cons: 여전히 프레임워크가 성능 개선하는데 한계. (특히 locking)

33. iFunFactory Inc.
DEADLOCK
HAPPENS IFF…
 Mutual exclusion
 Hold-and-wait
 No preemption
 Circular wait

34. iFunFactory Inc.
DEADLOCK
RESOLUTION
 Mutual exclusion
 Hold-and-wait 잡고 기다리는 대신 풀고 기다리기
 No preemption 강제로 lock 뺏기
 Circular wait 락 순서가 틀렸다면 다 풀고 새로 잡기

35. iFunFactory Inc.
DEADLOCK
RESOLUTION
 Mutual exclusion
 Hold-and-wait 잡고 기다리는 대신 풀고 기다리기
 No preemption 강제로 lock 뺏기
 Circular wait 락 순서가 틀렸다면 다 풀고 새로 잡기
돌고 있던 작업을 취소해야 함. 즉, rollback이 가능해야 함.

36. iFunFactory Inc.
DEADLOCK RESOLUTION
JOURNALING & ROLLBACK
 진행중인 작업을 취소 시, 일련의 동작들의 atomicity 를 보장할 수 없음
 이 때문에 진행중인 작업을 바로 state 로 반영하는 대신
Per-thread journal 에 기록 후, 작업의 성공적인 완료 시에만 state 로 반영함
 Rollback 은 journal 을 버리는 것만으로 간단하게 구현

37. iFunFactory Inc.
YOU MAY ASK…
Q. 정말 journaling 이 동작하나요?
A. 예

38. iFunFactory Inc.
YOU MAY ASK…
Q. 정말 journaling 이 동작하나요?
A. 예

39. iFunFactory Inc.
RETHINKING
CONCURRENCY-CONTROL
 Consistency 를 보장하기 위한 제어
 Serializability
• 결과물은 하나의 worker 만이 작업한 것과 같아야 한다.

40. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
 Pessimistic concurrency control
 “우리는 반드시 충돌할거야.”
• Consistency 를 절대 어기지 않도록 보호. 그러니 취소도 없음.
• 중앙 집중식

41. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
 Optimistic concurrency control
 “에이, 설마 충돌 나겠어? 그건 그때 가서 생각하자.”
• 일단 작업하고, consistency 조건을 어겼을 때는 작업 취소 (rollback)
• 분산 처리식

42. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
어떤 것이 더 좋은가?
(연사가 싫어하는 표현이지만) 케바케

43. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
어떤 것이 더 좋은가?
(연사가 싫어하는 표현이지만) 케바케

44. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
Performance
(high lock contention)
Performance
(low lock contention)
Pessimistic Good Bad
Optimistic Bad Good

45. iFunFactory Inc.
CONCURRENCY CONTROL
PESSIMISTIC VS. OPTIMISTIC
Performance
(high lock contention)
Performance
(low lock contention)
Pessimistic Good Bad
Optimistic Bad Good
참고: 많은 게임에서, 설령 두 게임 유저가 동시에 리소스 경쟁을 하더라도 (예: 득템 경쟁),
network latency 때문에 게임 서버 입장에서 인지하는 contention rate 은 생각보다 높지 않은 편이다.

46. iFunFactory Inc.
ARCHITECTURE DESIGN #1
OBJECT DESIGN
이 가상의 예제에서는…
 Hybrid approach
• 게임 개발자는 game object 를 JSON 으로 기술하고 framework 이 class 코드를 생성한다.
• Deadlock 은 Hold-and-wait 을 깨서 해결한다.
• 이 때문에 journal & rollback 을 이용한 optimistic concurrency control 을 한다.
 Rollback 가능 시스템의 장점
• 다양한 exception 을 graceful 하게 처리할 수 있음

47. iFunFactory Inc.
ARCHITECTURE DESIGN #2
DISTRIBUTED SERVERS
 Partitioned world
• 오브젝트/사용자들을 파티셔닝해서 각 서버가 담당하게 지정
• 다른 서버의 사용자와는 통신이 불가능
• 대부분 “채널” 이라는 이름으로 존재
• Pros: 구현이 간단
• Cons: 게임 사용자들이 게임이 아닌 서버의 구성을 알게 되는 문제

48. iFunFactory Inc.
ARCHITECTURE DESIGN #2
DISTRIBUTED SERVERS
 Shared world
• 다른 서버의 사용자와의 통신은 RPC 를 통해서 이루어짐
• 모든 사용자가 하나의 거대한 world 에 포함됨
• Pros: 게임 유저들은 하나의 가상 세계를 공유하게 됨
• Cons: Remote locking 등 구현이 복잡
RPC 를 통하는 경우 유저들은 lag 으로 인식하게 됨 (sync 가 중요할 수록 문제)

49. iFunFactory Inc.
DISTRIBUTED SERVERS
REMOTE OBJECT HANDLING
S1 S2
O2
2) Remote lease request
Directory
Service
Object Server
O2 S2
1) Object lookup
3) Lock O2 for S1
4) Lease grant

50. iFunFactory Inc.
DISTRIBUTED SERVERS
REMOTE OBJECT HANDLING
S1 S2
Directory
Service
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

51. iFunFactory Inc.
LAB SESSION
RECAP
 클라이언트-서버 메시지 포맷 JSON
 서버 관리 인터페이스 REST API
 게임 오브젝트 지원 JSON 으로부터 코드 생성 + Journaling
 분산 서버 RPC 를 통한 Shared World

52. iFunFactory Inc.
CONTACT
DKMOON@IFUNFACTORY.COM
WE ARE HIRING!