3. iFunFactory Inc.
ABOUT
YOUR SPEAKER
옛날에 넥슨 서버팀장 (1999-2005)
미국 유학생 및 클라우드 컴퓨팅 스타트업 시니어 엔지니어 (2005-2011)
귀국 후 다시 넥슨의 피고용인 (2011-2013)
끝으로 갓 1년 된 스타트업 대표 (2013-현재)
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를 쓸 것인가?
17. iFunFactory Inc.
SYSTEM DESIGN
RECAP
1. 시스템 디자인에 절대적으로 우월한 답은 없음
2. 시스템 디자인의 핵심은 어떤 가정하에서 무엇이 가능하고 불가능한지 정하는 것
3. 이를 위한 트레이오프 선택과 각각의 의미를 파악
4. 디자인을 구현으로 옮기는 것은 또 다른 기술
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)
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 을 버리는 것만으로 간단하게 구현
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