1. 마비노기 영웅전 자이언트 서버의 사례로 본
다음 세대 크로스플랫폼 MMORPG 아키텍처
넥슨 코리아 신규개발 3본부
양승명

2. 양승명
• 2D MMORPG “다크에덴”
– 서버 프로그래머
• 3D 액션 RPG “마비노기 영웅전”
– 서버 프로그래머
– 개발 매니저
• 현재 미공개 프로젝트 팀
• EMAIL : sequoia@nexon.co.kr
• 트위터 : @sequoiaxp
(사진)

3. 프리퀄
• NDC11
– “마비노기 영웅전 자이언트 서버의 비밀”
• ICON 2011
– “온라인 게임 서버 분산 아키텍처”

4. 안 보셨어도 됩니다.
금방 요약해드림.

5. 목차
Table of Contents
1. 자이언트 서버 분산 처리 아키텍처
2. 자이언트 서버 아키텍처의 장단점
3. 크로스플랫폼 MMORPG 서버의 요구 조건
4. 크로스플랫폼 MMORPG 서버 아키텍처
5. 크로스플랫폼 MMORPG 서버에 응용 가능한 기술

6. 자이언트 서버의 분산 처리 아키텍처

7. 요구 조건

8. 분산 처리?
• “매핑” (map)
– 요청을 어느 서버에서 처리할지 대응시키는 것
– 요청을 분류해서 작업을 물리적 서버에 할당
요청
앞단
(Frontend)
뒷단
(Backend)
뒷단
(Backend)
뒷단
(Backend)
뒷단
(Backend)
매핑

9. 분산 처리 매핑
세로로 자르기
• 유저(또는 캐릭터)별 분산 처리
• 전투 별 분산 처리
• 채널 별 분산 처리
가로로 자르기
• 기능별 분산 처리
• 캐릭터 관련 기능(캐릭터 고유 스탯)
• 아이템 관련 기능
• 스토리 관련 기능

10. 가로로 자르기
• 물리적 서버를 기능 별로 분리
• “서비스 기반 아키텍처”
• 요청의 종류에 따라 처리할 서버를 결정

11. 가로로 자르기
• 한 번의 요청이 여러 요청을 동반할 수도 있음
– 매번 요청이 네트워크를 건너 처리됨
– 응답 시간이 길어진다.

12. 아키텍처 시나리오
앞단 던전 캐릭터 아이템전투 스토리
배 띄우기
전투확인
레벨 제한 확인 및 스탯 쿼리
OK
입장 아이템 확인 및 소모품 쿼리
스토리 드랍 아이템 확인 및 선행 스토리 확인
스토리 드랍 아이템
캐릭터 스탯
보유 아이템 목록
새로 뜬 배 정보

13. 가로로 잘라지지 않는 것
• 실시간(real-time) 동기화가 필요한 작업
– MO 플레이(~100ms)  밸브 소스™ 엔진
– MMO 플레이 (~1s)  영웅전이 특수한 경우

14. 가로로 자르기 : 코드 레벨에서 결정
• 분산 처리 정책을 코딩 시점에 결정
• 로드에 따라 변경 불가능

15. 세로로 자르기
• 같은 기능의 서버를 여러 대 추가
• 개체(entity) 별로 분리
• “엔티티 기반 아키텍처”
• 엔티티의 실제 위치 찾기(locating) 매
커니즘 필요

16. 가로로 잘라지지 않는 것 – 세로로 자르기
• MO 플레이  전투 별로 엔티티 할당
• MMO 플레이  채널 별로 엔티티 할당

17. 세로로 자르기 : 서비스 구동 시 설정
• 각 서비스 별로 몇 개를 구동시킬 지 결정
• 유저 숫자가 늘어날 경우
– 머신 숫자를 늘리고 서비스 개수 증가
• 특정 기능에 로드가 집중될 경우
– 특정 서비스의 숫자만 증가
• 런타임에 바꿀 수 있으면 좋다.
– 영웅전에서는 실패

18. MMO
MO
자이언트 서버 아키텍처 다이어그램
• 가로 세로로 다 자름
• Frontend (앞단) 서버와 Backend(뒷
단) 서버가 동등한 프로토콜로 통신
• 서버를 많이 준비하면 서버 당 수용할
수 있는 동시 접속자 수가 늘어남
• DB는 서버 당 2대 (게임 DB, 로그 DB)
FrontendClient
Character
Item
Quest
Story
Cashshop
Login
MO
Party
MMO
FrontendClient
FrontendClient
FrontendClient
ProudNet connection (TCP/UDP)
TCP Connection
Location

19. 자이언트 서버의 스레딩 모델
• 한 서비스가 하나의 프로세스
• 멀티 코어 서버에서는?
– 한 서버에 여러 개의 프로세스 구동

20. 이벤트 루프
• “이벤트 루프”
– 이벤트가 일어날 때까지 블록
– 이벤트가 발생하면 작업을 생성해서 처리
• I/O 이벤트 또는 타이머 이벤트 작업
– .net 스레드 풀에서 발생
– 작업 큐에 넣는 것은 thread-safe
• 로직 작업
– 로직 코드에서 작업을 생성해서 인큐
– 작업량이 많을 때 등
작업 큐?
작업 인큐 대기
디큐한 작업 처리
작업 있음
작업 없음

21. 프로그래밍 모델
• 문맥(context) 관리가 핵심
• 누가 문맥을 관리할까?

22. 프로그래밍 모델
(옛날식) 웹 서버의 경우
• 요청 1개 당 프로세스(또는 스레드 1개)
• 문맥을 OS가 관리
– 단순한 프로그래밍 모델
– 성능 오버헤드 높음
#include <stdio.h>
int main(int argc, char** argv)
{
printf(“%s”, getHttpHeader());
printf(“%s”, getHtmlDoc(argc, argv));
return 0;
}

23. 프로그래밍 모델
명시적인 컨텍스트 관리
• State Pattern 등 스테이트 머신 코딩
• 문맥을 모두 개체에 저장해놓고 프로그래머가 관리
– 복잡한 프로그래밍 모델
– 성능 오버헤드 낮음
– 코딩이 귀찮음

24. 프로그래밍 모델
암시적인 컨텍스트 관리
• 단순한 프로그래밍 모델 + 낮은 성능 오버헤드
– microthread(fiber 등)
– coroutine
– CPS (continuation passing style)
• 언어 지원이 필요

25. 자이언트 서버의 프로그래밍 모델
• 암시적인 컨텍스트 관리
– CPS + C# Enumerator 활용
– 스레드 블록 최소화
– 컨텍스트 관리 부담을 언어 지원으로 경감
IEnumerator<object> Run()
{
…
var sync = new OperationSync(
itemConnection,
new QueryInventory());
yield return sync;
if (sync.Result.HasItem(…))
…
}
오퍼레이션이 완료될
때 까지 스레드 양보
Connection itemConnection = service.Connect(localEntity,
characterID, “ItemService”);
Operation queryRequest = new QueryInventory();
queryRequest.Complete += (sender, args) =>
{
SendToClient(queryRequest.Result);
};
itemConnection.Request(queryRequest);
콜백 등록

26. 자이언트 서버 아키텍처의 장단점

27. 자이언트 서버의 장점
• 요구 조건 달성
• 단일 서버군 동시 접속자 5만명
– DB성능이 병목
• 접속자 수에 따라 서버 증설 가능
• 부담이 적은 프로그래밍 모델

28. 자이언트 서버의 단점
• DB가 병목
– DB 분산은 미구현
– DB 서버 비용이 높음
• 만족스럽지 못한 성능
• 런타임 유연성 확보 실패
• 장애 진단 및 운용 툴 미비
– 장애 상황에 대처가 어려움

29. 성능 문제
• 싱글 스레드 멀티 프로세스로 멀티코어 대응
• 프로세스 간 통신은 물리적 위치와 관계없이 TCP
– 내부 TCP 연결이 많아짐 (~10000개)
– 내부 연결 관리에 과도하게 메모리 낭비
• 많은 시나리오에서 여러 종류의 서비스가 관여
– 매 단계마다 시리얼라이즈 오버헤드
– 매 단계마다 네트워크 딜레이

30. 다시 만든다면
• 가로로 자르기는 최소화
• 설계 단계부터 런타임 서버 교체를 고려
– stateless 요청
– 런타임 실패에 대한 폴백 매커니즘 개발
• 모니터링 툴에 좀 더 투자
– 서버 내부 상태를 잘 볼 수 있도록

31. 다음 세대 크로스플랫폼 MMORPG
서버 요구 조건을 중심으로

32. 현 세대 MMORPG?
• 가상의 물리적 공간을 제공
– 실재감을 강조
– “넓은 가상 공간에 많은 사람들이 모여서 즐기는 게임”

33. 현 세대 MMORPG?
• 근 10년간 핵심적인 변화나 혁신은 없었음
• MMORPG간의 차별성
– 그래픽 및 캐릭터
– 컨텐츠 양
– 게임 룰
– 게임 연출
– 스토리
– IP

34. 다음 세대 MMORPG?
• 게임디자인 세션 아닙니다.

35. 걱정은 되시죠?
• PC게임 만들어서 먹고 살 수 있을까?
– 작년에 노트북보다 타블렛이 더 많이 팔렸다는데…
– 모바일게임과 소셜게임이 뜬다는데…
• 최근의 화두
– 포스트 PC
– 모바일
– SNS
– …

36. 크로스 플랫폼 MMORPG
• MMORPG를 만들고는 싶은데,
– PC게임을 만들어서는 유행에 뒤처지는 기분이 듭니다.
• 다른 플랫폼에서도 돌아가는 MMORPG를 만듭시다!
– 웹이라든가
– 타블렛이라든가
– 스마트폰이라든가
– TV라든가
• 유행에 맞춰 페이스북용 MMORPG도…

37. 플랫폼 별 특징 : 모바일 디바이스
• 타블렛PC / 스마트폰
– 터치 인터페이스가 주류
– 넉넉하지 않은 메모리와 스토리지
– PC에 비해 빠르지 않은 CPU
– CPU를 풀로 쓰면 유저 경험이 저하됨
– 웹 브라우저 지원 / 플러그인 미지원
– 유니티3D / 언리얼3 등 주류 게임엔진이 지원
• 두 플랫폼은 화면 사이즈로 차별화
– 게임 만들 때는 정말 큰 차이

38. 플랫폼 별 특징 : 웹 앱
• 플러그인 앱
– 플래시 / 유니티3D
– PC전용
– 기존 PC 클라이언트와 가장 흡사한 플랫폼
• 표준 HTML 앱
– HTML + CSS + Javascript
– PC/모바일 호환
– HTML5 는 상당한 자유도를 제공
– 성능은 아직 의문

39. 크로스 플랫폼 MMORPG?
• 단지 여러 플랫폼에 포팅 된 것이 아니라,
• 여러 플랫폼에서 게임하는 유저가 한 공간에서 즐길 수 있는 MMORPG

40. 크로스 플랫폼 MMORPG 서버
• 서버는 프로토콜에 집중
• 다른 플랫폼은 다 괜찮은데 웹 앱이 문제
– 웹 브라우저가 지원하는 표준 방식으로만 서버와 통신
– Same Origin Policy 문제
• 웹 앱은 한 번 만들어서 여러 플랫폼에서 사용 가능
– GDC 2012 최고 이슈 중 하나 HTML5
– 웬만하면 여러 번 만들고 싶지 않죠?

41. 크로스 플랫폼 MMORPG 서버
• 웹 브라우저  서버 사이의 실시간 쌍방향 통신 필요
– AJAX 롱 폴링
– 플래시 소켓
– HTML5 웹 소켓
– …
• 실제로 웹 소켓을 이용한 MMORPG가 있어요.
– http://browserquest.mozilla.org/
– HTML5 기술데모용 게임
– 스마트폰과 최신 타블렛 PC에서도 원활하게 작동

42. 크로스플랫폼 MMORPG 서버
• 웹 프로토콜은 공개된 표준
– 플랫폼 별 네이티브 앱이나
– 플러그인 앱에서도 접근 가능
• 서버는 웹 프로토콜만 지원해도 되지 않을까?
– HTML5 로 멀티플랫폼 웹 앱을 만든다면 필수
– 네이티브 앱으로 게임을 만들어도 지원 가능
• 페이스북 등 SNS플랫폼에 올라탄다면?
– 부분적으로라도 웹 인터페이스 제공은 필수

43. 크로스플랫폼 MMORPG 서버
• 웹 프로토콜을 지원한다면
– 웹 서버를 이용하면 scalability 확보가 쉽다.
– 로드가 큰 상태에서 서비스 안정성을 위한 노하우가 많음
• 전통적인 게임 서버와는 운용 이슈가 많이 다를 듯
– 지금부터 공부하려니 쉽지 않아요.
– 웹 서비스 업계에서 베테랑들을 빼와야…웹 서비스 하시는 분들 조언 부탁 드립니다.

44. 크로스플랫폼 MMORPG 서버
• 물론 100% 웹 인터페이스일 필요는 없습니다.
– 높은 디테일의 3D 게임은 아직 웹앱으로는 무리
– 게임엔진 지원, 성능 제약 등
– 그렇다고 2D게임만 만들 수도 없고
• 게임의 일부라도 웹 인터페이스로 제공
– 마비노기 영웅전 거래소
– WOW 전투정보실 등
– 조금 더 본격적인 게임플레이도 가능할 듯
• 다른 서비스와의 매시업(혼합) 서비스 가능성도 있다.

45. 결론
• 다음 세대 MMORPG 가 어떤 모습이 되든,
– 여러 플랫폼에서 플레이 가능해야 하고,
– 일부라도 웹 인터페이스를 지원할 필요가 있다.
• 두 줄로 요약되는 얘기를 길게 했네요.

46. 크로스플랫폼 MMORPG 서버 아키텍처

47. 자이언트 서버의 사례
• scalable MMORPG 서버
– 엄밀히 MMORPG는 아니지만
MMO
MO
FrontendClient
Character
Item
Quest
Story
Cashshop
Login
MO
Party
MMO
FrontendClient
FrontendClient
FrontendClient
ProudNet connection (TCP/UDP)
TCP Connection
Location

48. 자이언트 서버의 사례
• 실시간 멀티플레이 서버를 격리
– 상호작용할 클라이언트들을 같은 서버에 접속시킴
• 전통적인 게임서버와 비슷
– 상호작용에 해당하는 로직에만 집중
MMO
MO
FrontendClient
Character
Item
Quest
Story
Cashshop
Login
MO
Party
MMO
FrontendClient
FrontendClient
FrontendClient
ProudNet connection (TCP/UDP)
TCP Connection
Location

49. 자이언트 서버의 사례
• 유저 수에 따라 부하가 가중되는 부분을 다중화
– 유저 1인에 해당되는 로직이 집중
– 상당 비율의 로직이 해당
• 웹 서버와 흡사한 구조
– 요청-응답 형식의 로직
– 다른 서버나 엔티티에 의존하지 않음
MMO
MO
FrontendClient
Character
Item
Quest
Story
Cashshop
Login
MO
Party
MMO
FrontendClient
FrontendClient
FrontendClient
ProudNet connection (TCP/UDP)
TCP Connection
Location

50. 웹 서버와 흡사한 구조?
• 그냥 웹 서버로 만들면 되겠네!
– 안 그래도 웹 인터페이스가 필요하던 참
MMO
MO
Web Server
MO
MMO
Client

51. • MO / MMO 구분은 영웅전 한정이므로 제거
• 크로스 플랫폼으로
MMO
Web Server
MMO
Client
Mobile
Web

52. • MMO에도 웹 접근이 필요하다면
MMO
Web Server
MMO
Client
Mobile
Web
Reverse
Proxy

53. • 웹 인터페이스로 DB부하가 커지면
– DB도 세로로 잘라서 스케일링
– 캐시 서버
MMO
Web Server
MMO
Client
Mobile
Web
Reverse
Proxy
DBCache

54. • 웹MMO간 동기화
– 캐시를 통하면 복잡도가 내려갈 듯
MMO
Web Server
MMO
Client
Mobile
Web
Reverse
Proxy
DBCache

55. 요약하면
• 자이언트 서버에서의 경험
– 게임 로직을 1인 로컬 로직과 상호작용 로직으로 분리해서 분산
– 1인 로컬 로직을 맡은 서버는 웹 서비스와 흡사한 구조
– 상호작용 로직을 맡은 서버는 기존 MMORPG서버와 흡사한 구조
• 크로스플랫폼 MMORPG 아키텍처를 만들기 위해
– 1인 로컬 로직을 완전히 웹 서비스로 분리
– MMO서버는 reverse proxy를 통해 웹 인터페이스 제공

56. 크로스플랫폼 MMORPG에 응용 가능한 기술들

57. 들어 보셨나요?
• https://github.com/
• 버전 컨트롤 시스템 git를 통한 소셜 코딩 서비스

58. 미국 스타트업 열풍의 엔진
• 수 많은 고급 기술들이 오픈소스로 공유
• 특히 웹 서비스 특화 기술이 많음
• fork & pull 매커니즘을 통한 자유로운 참여
•다 영어

59. 살펴볼 만한 프로젝트
• node.js
– 고성능 다목적 자바스크립트 서버 플랫폼
– 단일 이벤트루프 + CPS 방식 모델
– 풍부한 미들웨어 생태계
• socket.io
– node.js 미들웨어
– 웹브라우저와 서버 사이에 실시간 통신 지원
– 다단계 폴백(대체) 매커니즘
• memcached / redis
– 메모리 DB 방면에서 경쟁 중
– 성능 뿐 아니라 용도에 따라 선택 가능

60. 결론

61. 결론
• 자이언트 서버
– 원래 목표는 달성했으나 고품질 서비스에는 실패
– 의외로 미래를 내다본(?) 아키텍처
• 차세대 MMORPG
– 크로스플랫폼 지원 필요
– 서버에서 웹 인터페이스 지원

62. 결론
• 차세대 MMORPG 아키텍처
– 적극적인 웹 관련 기술 도입이 필요
– 유용한 오픈 소스 기술이 다수 있다.
• 오픈 소스 커뮤니티
– 미국 소프트웨어 생태계의 토양
– 한국에, 또는 국내 게임 업계에 이와 같은 기술 공유 인프라가 필요하지 않을까?

63. 끝