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
• 로직 작업
– 로직 코드에서 작업을 생성해서 인큐
– 작업량이 많을 때 등
작업 큐?
작업 인큐 대기
디큐한 작업 처리
작업 있음
작업 없음
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);
콜백 등록
27. 자이언트 서버의 장점
• 요구 조건 달성
• 단일 서버군 동시 접속자 5만명
– DB성능이 병목
• 접속자 수에 따라 서버 증설 가능
• 부담이 적은 프로그래밍 모델
28. 자이언트 서버의 단점
• DB가 병목
– DB 분산은 미구현
– DB 서버 비용이 높음
• 만족스럽지 못한 성능
• 런타임 유연성 확보 실패
• 장애 진단 및 운용 툴 미비
– 장애 상황에 대처가 어려움
29. 성능 문제
• 싱글 스레드 멀티 프로세스로 멀티코어 대응
• 프로세스 간 통신은 물리적 위치와 관계없이 TCP
– 내부 TCP 연결이 많아짐 (~10000개)
– 내부 연결 관리에 과도하게 메모리 낭비
• 많은 시나리오에서 여러 종류의 서비스가 관여
– 매 단계마다 시리얼라이즈 오버헤드
– 매 단계마다 네트워크 딜레이
30. 다시 만든다면
• 가로로 자르기는 최소화
• 설계 단계부터 런타임 서버 교체를 고려
– stateless 요청
– 런타임 실패에 대한 폴백 매커니즘 개발
• 모니터링 툴에 좀 더 투자
– 서버 내부 상태를 잘 볼 수 있도록
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 가 어떤 모습이 되든,
– 여러 플랫폼에서 플레이 가능해야 하고,
– 일부라도 웹 인터페이스를 지원할 필요가 있다.
• 두 줄로 요약되는 얘기를 길게 했네요.
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를 통해 웹 인터페이스 제공
58. 미국 스타트업 열풍의 엔진
• 수 많은 고급 기술들이 오픈소스로 공유
• 특히 웹 서비스 특화 기술이 많음
• fork & pull 매커니즘을 통한 자유로운 참여
•다 영어
59. 살펴볼 만한 프로젝트
• node.js
– 고성능 다목적 자바스크립트 서버 플랫폼
– 단일 이벤트루프 + CPS 방식 모델
– 풍부한 미들웨어 생태계
• socket.io
– node.js 미들웨어
– 웹브라우저와 서버 사이에 실시간 통신 지원
– 다단계 폴백(대체) 매커니즘
• memcached / redis
– 메모리 DB 방면에서 경쟁 중
– 성능 뿐 아니라 용도에 따라 선택 가능