차세대 mmorpg 서비스 아키텍처

차세대 MMORPG 서비스 아키텍처

Ncsoft , Technical directorLF Team김종원

누구세요 ?• 현재

– NCSoft, LF Team / Technical director• 과거

– 1992 한메한글 for Windows 개발– 1994 윈도우용 아래아한글 3.0b , 한글 96 등 개발– 1999 포바이트 대표– 2000 임베디드 리눅스 기반 PDA ( 모코코 )– 2002 휴대폰 UI 및 스마트폰 개발– 2004 PE Project( 아이폰 같은 게임기 ) / NCsoft

• 컬럼– 마이크로소프트웨어 1994~2002– ZDNet 컬럼 ‘망치와모루’ 2001~2004

KGC2010 Next generation MMORPG service

2010 년 상반기아이폰에서 가장 인기 있었던 게임 ?

?KGC2010 Next generation MMORPG service

이 게임 해 본 사람 손들어보세요 !!


SNS 게임 : We rule• 귀농 게임 ‘두덕리 온라인’ iPhone 버전• 수익 모델은 Mojo 와 게임 내 광고


하지만…

• 뛰어난 그래픽 디자인 및 클라이언트의 높은 완성도– Age of empire 개발자 출신이라는…

• 네트웍 트래픽이 문제– 점점 자신의 다운 받는 데이터가 계속 증가– 친구 왕국 방문 , 주문 알바– 로그인 실패 , 잦은 서버 다운– 주문 불가 상황 발생– 대규모 사용자 이탈



망함 !!

Postmortem• 25 레벨이 끝 , 그 이후는 ? ( 지금은 40 레벨 )

– 만렙 이후가 필요– 용 키워서 다른 왕국으로 쳐들어가면 좋겠다…

• 사용자가 많아지는 것이 두려운 게임– 사용자가 늘어나면 급격히 네트웍 트래픽 증가– Free to play 게임의 한계

• 단일 월드의 시도는 좋았지만– 안정적으로 운영할 수 있는 서비스 구조 필요


잠깐 , 제목과 다른 내용인데 ?


너는 우리의 미래

• We rule 은 미래에 등장할 lightweight MMORPG 의 프로토타입이 아니었을까 ?

• 미래의 MMORPG 의 요구사항– Free to play– 가벼운 클라이언트 ( 모바일 / 플래시 )– 비동기 플레이 & 실시간 플레이 & push 통지– SNS 를 통한 친구 끌어들이기– 거대 월드 ( 하나의 세계 )


2015 년의 MMORPG 는 ?AAA MMORPG

100GB 의 클라이언트 패키지2560 x 1440 화면 해상도

Unreal 5, CryENGINE 5 엔진 장착

VS

Anywhere MMORPG다운로드 없이 바로 플레이

모바일부터 데스크탑까지 n-screen game플랫폼에 맞춘 다양한 엔진


두 영역을모두 공략 ?


으아 ~~


他山之石


Let another's shipwreck be your sea mark

요즘 가장 잘 나가는 놈 !


Big bang game company• Zynga 의 계속 늘어나는 사용자 (2010 년 3

월 )– 6 천 5 백만 사용자 / 일 , 2 억 2 천 5 백만 명 / 월– Farmville 은 5 개월 동안 2 천 5 백만 명 증

가 /DAU– FishVille 은 오픈한 지 1 주일 만에 6 백만 명

DAU


* GDC10 Scaling social games

Zynga 의 서비스 구조도

Flash-basedclient

Web server

MMO serverMMO

serverMMO server

HTTP

TCP DB serverDB

serverDB server

mem-cached server

PHP logic

Java logic My SQL


* GDC10 Scaling social games

Zynga’s scaling• Scale up – 컴퓨터의 성능을 높이는 것• Scale out – 서비스할 컴퓨터를 더 늘리는 것• 징가의 게임은 DB 하나에서 시작

읽기 전용의 DB 복제 복수의 마스터 DB DB 의 sharding – 수평 , 수직

• CDN 과 memcached 활용• MMO 서버의 sharding 및 로드 밸런싱• 용량 증설 계획을 사전에 수립


NCsoft 의 MMORPG 는• 한 월드 당 최대 동시 접속 인원을 제한• 더 많은 사용자를 받기 위해 복제된 월드 추가• 월드간 커뮤니케이션이나 공통 서비스 어려움• DB 의 복제를 통한 단방향 Web 서비스 제공


Case study• MMORPG

– NCsoft’s MMORPG– Bluehole’s Tera– XL games’ ArcheAge

• Zone 분할 방식의 게임 서비스

• NCsoft 통합 메신저– Channel chatting system


NCsoft MMORPG 의 구성

Login server

Game server

TCP

LogD + Log DB

cacheD + Game

DB

World 1World …

World N


1

2

MS-SQL

Arbiter serverArbiter server

Bluehole 의 MMORPG

Login server

LogD + Log DB

World 1 … N

World servers

Game DB

Planet

ConnectionChatting

DB cachecompres-

sion

Instance serversInstance servers


1

2

* Gametech 2010

MS-SQL

XL games 의 MMORPG

Auth server

World server

Game DB

World

AI server Physics server

In-stanece-zone srv

KGC2010 Next generation MMORPG service * Gametech 2010

1

2

Game serverGame server

Zone 분할 월드의 서버 구조

Logine server

Lobby server DB

cache

Game server DB

server


1

2

3

Divided for zones

Ncsoft 통합 메신저

• 100 만 명 동시접속 목표 설계• AION 오픈 시 서버 2 대로 20 만 이상 채널 채팅

Externalserver

Internalserver

DatabaseExternalserver

Configurationserver


Sharding Users

앞의 시스템들의 공통점은 ?


서비스의 확장에 대해 고민하고 있었다

새로운 서비스의 요구

• 거대 단일 월드• 통합 경매장• 통합 인스턴스 던전• 모바일 및 Web 과의 연계• Facebook, twitter 와 연동• 폐쇄된 게임보다는 SNS 와연계된 플레이 유도


난 너의 모든 것을 알고 싶다 !


현재 서비스 구조에서 가능한가 ?• 이제까지의 MMORPG 에서는 준비가 안되었다• 무엇을 준비해야 하는가 ?

– 게임 시스템 설계 단계부터 준비– 게임 기획에서 관련 컨텐츠 구분– 여러 플랫폼의 요구에 대응할 수 있는

서비스 구조– 요구 사항에 맞는 DB 선택


NCsoft MMORPG 의 구성 (again)

Login server

Game server

TCP

LogD + Log DB

cacheD + Game

DB

World 1World …

World N


1

2

MS-SQL

Log/async dataGame data

이런 구조면 어떨까 ?Login server

Game servers

Other services

Web/SNS 서비스



Database 가 문제

MMORPG DB 특징

• MS-SQL 이나 MySQL 은 확장이 어렵다• 게임 특성 상 쓰기 및 업데이트가 대부분

– 로그인 시 읽기 발생• DB 의 병목은 HDD I/O

– DB 처리에 있어 CPU 는 남는 자원– CPU 보다 HDD 추가가 성능 향상– 쓰기가 많아 SSD 는 적합하지 않음

• 게임 서버 와 웹 , 동시 지원이 부담– 읽기 전용의 복제 DB 로 게임 부담 줄임

• 웹에서 게임 DB 변경 불가


설계 단계 부터 준비

• 컨텐츠 속성에 따른 DB 데이터 구분– 동기 데이터 / 비동기 데이터– 속성에 따라 다른 DB 를 사용하는 것은 ?

• 처음부터 웹 서비스를 같이 지원하자• Transaction 처리는 게임 서버나 캐시 서버에서• 통합 로깅 시스템

– 게임 플레이 정보 , 게임 내 SNS 관련 정보 저장


확장을 위한 준비

• 게임 서버용 DB 로 NoSQL 사용– 읽기와 안정성을 위한 DB 복제 및 분산 DB– DB 의 수평적 분할을 해서 쓰기 병목 분산

• 기존의 RDBMS 와 NoSQL 의 혼용– 안정성이 걱정되면 동시 지원– 중요 데이터 및 쓰기가 적은 데이터는

RDBMS 에 넣어도 좋다• NoSQL DB 는 비동기 데이터 쓰기에 적합


질문있습니다 , NoSQL 뭔가요 ?


No SQL != DBMS• ‘Non-relational’ 혹은 ‘ Not only SQL’• DB 가 아닌 structured storage• 테이블 schema 가 없다


왜 NoSQL 이 등장하였는가

• Massive data volume– 수 만 대의 DB 를 사용하는 상황 발생

• Extreme query workload– 위 상황에서 RDBMS 에서 사용은 무리

• Schema evolution– Schema 변경도 쉬운 일이 아님

• 여러 NoSQL 시스템의 등장– 안정성 , 관리 효율성 , 보안 등은 검증 단계


여러 NoSQL 등장


Casandra• Google 의 Big table 과 Amazon 의 Dynamo

기반– 서버간 P2P 연결– 중첩된 column (super columns) 저장 방식– Write > Read

• Cassandra Project– 처음엔 Facebook, 지금은 Apache 에서 개발– Java, OpenSource 기반의 분산 DB– 분산 DB 서버간의 실시간 동기화는 안됨– 구조가 간단하여 MySQL 에 비해 수 배 빠름


Case study - Digg


NoSQL 적용 사례 (digg 서비스 )• Digg 가 처했던 어려움

– 고성능의 쓰기 위주에 적합한 DB 구축 필요– 특성 상 DB 에서 데이터 일관성을 포기할 수 있는 상황

• Cassandra 선정– 컬럼 기반 , 구조적 문서 저장 가능 – 모든 노드가 개별적으로 동작 , 데이터가 여러 노드 간에

복제된다– 서버를 추가할 경우 읽기 , 쓰기 성능이 선형적으로 증가


Another NoSQL -• 오픈 소스 , www.mongodb.org• Document-oriented DB

– JSON 과 비슷한 BSON format• 고정된 schemas 없음• 임의의 문서 구조 저장 가능

– 중첩된 문서 구조• Full index 지원• Replication & auto-sharding


MongoDB( 계속 )• Consistency-Availability• Interface :

– C/C++,C#, Java, Python, PHP, Perl, Ruby• Implementation : C++ with boost• Memory size & HDD speed• Support : 10gen.com


MongoDB sample


print(db.student.scores[0].for_course.name);

print(db.student.address.city);

db.students.find({‘name': ‘Jane'})

Cassandra vs MongoDB• Cassandra : SNS, Web, Log-base

– Java 구현 , Garbage collection 부담– 확장 및 분산 좋음 – 세계 규모 웹 서비스– 컬럼을 쉽게 바꾸는 것은 불편

• MongoDB : RDBMS-like– C++ 구현 , Windows 에선 memory mapped file– 빠르고 간단한 DB – 한국 크기 웹 서비스– Cassandra 에 비해 확장성은 낮음– 개발 과정 중 또는 자주 테이블이 변경되는 서비스에

적합


DB 의 확장 (Sharding)• 한 대의 DB 머신 성능으로 처리가 불가능할 때

– 수직적 분할• 테이블마다 다른 DB. 일정 수준 이상의 사용자

증가에는 도움이 안됨– 수평적 분할 (sharding)

• 사용자 id 또는 지역 등으로 DB 를 나누어 넣음 .• 사용자가 늘면 더 잘게 나누면 됨• 나뉘어진 DB 간의 join 이 쉽지 않음• 데이터를 중복하여 기록하여 쿼리를 횟수를 줄임• DB 확장 계획을 미리 세워 분할 규칙을 수립해야 함


확장의 함정• 서비스 상황

– 게임 서버 군 < 웹 /업데이트 서버– 서버 구매 비용 < 서버 운영 비용 (IDC)– 서비스에 사용되는 서버 수 증가– 시스템의 고장율 증가 (MTBF 가 짧아짐 )

• 해결 방향– 이중화 , 다중화

• 하지만 게임 서버 이중화는 어렵다 , 병렬화로 접근하자

– 하지만 DB 캐시 및 DB 의 데이터 다중화 , 중복 가능– 고성능의 서버 사용과 효율화로 서버 증가 억제

• 10 년 내 core 100 이상의 CPU 등장


Baby step

한 걸음씩


Wrap up• 확장을 고려한 시스템 설계• DB 확장 정책 수립• NoSQL 사용 고려• 이중화 , 데이터 복제• 서버의 고성능화 고려


LF Team 은채용 중입니다 !

NCsoft 의 NextMMORPG 개발

Q & A

Twitter @JongwonKimhttp://www.forge.kr

차세대 mmorpg 서비스 아키텍처

Documents