Skip to main content
<야생의 땅: 듀랑고>
서버 아키텍처 Vol. 2
넥슨 • 왓 스튜디오 • 이흥섭
TOC
#1 멀리 보기
서버 아키텍처 아웃라인
#2 들여다보기
부동산
신기루
전투 공방 합
#3 돌아보기
1, 2차 LBT 회고
<야생의 땅: 듀랑고>
서버 아키텍처 Vol. 2
넥슨 • 왓 스튜디오 • 이흥섭
TOC
#1 멀리 보기
서버 아키텍처 아웃라인
#2 들여다보기
부동산
신기루
전투 공방 합
#3 돌아보기
1, 2차 LBT 회고
안녕하세요. 재작년에 이어서 이번에도
<야생의 땅: 듀랑고> 서버 아키텍처를 주제로 발표하는
이흥섭
넥슨 • 왓 스튜디오 • 서비스파트장
넥슨 왓 스튜디오의 서비스 파트장 이흥섭입니다.
반갑습니다.
2011-2013 <카트라이더 대시 & 코인러시>
2013- <야생의 땅: 듀랑고>
저는 NDC가 처음 개방된 2011년에 넥슨에 합류해서
<카트라이더 대시 & 코인러시> 시리즈를 거쳐
2011-2013 <카트라이더 대시 & 코인러시>
2013- <야생의 땅: 듀랑고>
지금은 <야생의 땅: 듀랑고>의
서버 아키텍처를 담당하고 있습니다.
what-studio/profiling 2,380+
sublee/trueskill 215+
sublee/hangulize 100+
sublee
그리고 틈틈이
오픈소스 활동도 하고 있는데요
what-studio/profiling 2,380+
sublee/trueskill 215+
sublee/hangulize 100+
sublee
한 번 제가 만든 프로젝트 중에서
별이 100개 이상 찍힌 것만 모아봤습니다.
what-studio/profiling 2,380+
sublee/trueskill 215+
sublee/hangulize 100+
sublee
혹시 GitHub 하시는 분 계시면 계정 sublee를 팔로우하고
제 프로젝트에 별도 찍어주시면 감사하겠습니다.
본격적인 발표에 앞서 저희 프로젝트를 먼저 소개해드릴게요.
저희가 만들고 있는 <야생의 땅: 듀랑고>는
공룡이나 코끼리 조상 같은 고생물들이 사는 땅을 개척하면서
거기서의 생활을 즐기는 모바일 MMORPG입니다.
사냥, 채집, 건설 같은 플레이어의 행동 하나하나가
듀랑고 세계에 영구적인 변화를 남기게 되는 오픈월드 게임이죠.
A 서버군 B 서버군 단일 서버군
듀랑고 서버 아키텍처에는 마비노기 영웅전처럼
서버군 구분이 없습니다.
A 서버군 B 서버군 단일 서버군
게임을 시작하거나 접속할 때
자기가 속할 서버군을 고르지 않아도 되는 거죠.
다중 채널
단일 채널
단일 서버군이던 마비노기 영웅전에서 조금 더 나아가
저희는 채널도 구분하지 않는데요
그래서 가까운 장소에만 있으면
모든 플레이어와 서로 만날 수 있습니다.
무한한 공간
영속적 세계
단일 채널
고 가용성
저희 서버 아키텍처는
이런 듀랑고의 게임플레이를 지원하기 위해
무한한 공간
영속적 세계
단일 채널
고 가용성
무한한 공간, 단일 채널, 영속적 세계, 고 가용성
같은 목표를 세우고 도전해오고 있습니다.
#1 멀리 보기
#2 들여다보기
#3 돌아보기
오늘 발표에선 듀랑고 서버 아키텍처가
저희의 목표를 어떻게 달성해왔고
#1 멀리 보기
#2 들여다보기
#3 돌아보기
또 어떤 결과를 내고 있는지
얘기하려고 합니다.
#1 멀리 보기
첫 번째로 저희 서버 구조가 어떻게 짜여져 있는지 멀리서
큰 윤곽부터 한 번 그려 볼게요.
SPOF
Single Point of Failure (단일장애지점)
프로젝트 초반부터 지금까지 저희의 목표는
SPOF 없는 MMORPG 서버를 만드는 거였습니다.
SPOF
Single Point of Failure (단일장애지점)
SPOF는 Single Point of Failure의 약자로
보통 단일장애지점이라고 번역하는데요
SPOF
Single Point of Failure (단일장애지점)
문제가 발생하면 서비스 전체의 장애를 초래하는
한 지점을 얘기합니다.
한 번 이렇게 생긴 가상의 서비스를 상상해 볼게요.
클라이언트가 가운데 있는 서버에 요청을 보내면
그 서버가 여러 백엔드 서버 중 한 대와 통신한 다음
결과를 내주는 구조입니다.
여기서 백엔드 서버의 경우는 이중화돼있어서
한두 개 죽는다고 서비스에 장애를 초래하진 않습니다.
반면 이중화 돼있지 않은 가운데 중계 서버에 장애가 발생하면
바로 서비스 장애로 이어지게 되죠.
SPOF
이렇게 서비스 요소 중에 어떤 곳이라도 이중화돼있지 않은 곳이 있다면
그곳을 SPOF라고 볼 수 있습니다.
이중화
저희는 듀랑고 서버에 단 하나의 SPOF도 만들지 않기 위해서
모든 요소를 빠짐없이 이중화하려고 노력해왔습니다.
저희 서버는 여러 게임 서버 노드가 서로 통신하면서
유기적으로 협력하며 동작하는데요
이때 중앙 서버의 중계가 필요하지 않게 하고 싶었습니다.
그러기 위해 ZeroMQ를 도입했어요.
ZeroMQ는 중계 장치 없이도 RabbitMQ나 Redis의 PUB/SUB같은
메시지큐 기능을 사용할 수 있게 해주는 라이브러리입니다.
중계 장치가 없다 보니 각 노드는
서로가 서로의 주소를 자동으로 알아낼 수 있어야 하는데
이 부분에서 Apache ZooKeeper 같은 컨센서스 코디네이터인
etcd의 도움을 받습니다.
저희의 각 노드는 etcd를 통해서 자기 주소를 다른 노드에게 알리고
또 다른 노드의 주소를 모두 알아내서 서로 연결을 맺게 됩니다.
데이터베이스로는 RDBMS 대신
NoSQL DBMS인 Couchbase를 채택했습니다.
Couchbase는 CAP이론의 C.A.P. 중에서
C.P.를 취하는 DBMS인데요
단순한 Key-value 스토리지이긴 한데
내용을 색인하는 기능도 어느정도는 지원하고 있습니다.
서버 인프라론 손쉽게 서버를 증설하거나 감축하기 위해
AWS를 이용하고 있습니다.
백엔드 서비스 얘기는 이쯤 해두고
이번엔 듀랑고 게임 서버로 넘어가 볼게요.
역할 별 노드
저희는 게임 서버 노드를
몇가지 역할 별로 구분해서 만들고 있습니다.
프론트엔드
프론트엔드는 게임 클라이언트가
직접 접속하는 서버 노드인데요
프론트엔드
플레이어 객체를 관리하고
주변 상황을 클라이언트에 스트리밍하는 역할을 합니다.
게이트웨이
게이트웨이는 RESTful한 웹 서버인데
파일이나 DB에 있는 리소스를 클라이언트에서 읽을 수 있게 해주고
게이트웨이
또 클라이언트가 어느 프론트엔드에 접속할지
배정해주는 역할도 합니다.
동물원
듀랑고의 동물 AI는
이 동물원 노드에서 돌아가는데요
동물원
동물의 행동 중에 전투를 제외한
모든 행동이 여기서 시뮬레이션됩니다.
정원
정원 노드는 식물, 광물, 시설물 같은
정적인 객체를 관리하고요
콜로세움
마지막으로 콜로세움은
전투만 담당하는 조금 특별한 노드인데
콜로세움
콜로세움에 대해선 이따가 좀 더 자세히 다룰 게요.
노드1
노드2
노드3
몇몇 게임 서버 노드는 각자의 역할에 맞춰
게임 세계 곳곳에 흩어져있는 객체를 관리합니다.
노드1
노드2
노드3
자기가 관리하는 객체의
소유권까지 얻어서 전담하게 되죠.
노드1
노드2
노드3
이때 같은 노드가 관리하는 객체라고
꼭 같은 장소에 모여있는 건 아닌데요
노드1
노드2
노드3
노드가 객체를 맡을 때 위치를 참고하긴 하지만
거기에 제한까진 두지 않고 있어요.
플레이어나 동물 같은 객체는
저마다 일정한 영역의 시야를 갖는데요
시야에 들어오는 다른 객체를
각자 인지할 수 있게 되는 거죠.
뿐만 아니라 게임 서버 노드 역시 시야를 갖습니다.
한 노드가 전담하는 모든 객체들의 시야를 더한 영역이
바로 그 노드의 시야가 되는데
만약 게임 서버 노드끼리
이렇게 시야가 겹치게 되면
다른 노드에서 전담하던 객체가 프록시 객체로 만들어져서
이쪽 노드로 동기화됩니다.
이런 방식으로 한 장소를
한 노드가 배타적으로 독점하지 않으면서도
각자가 관리하는 객체 근처의 세계를
인지하고 중계하고 상호작용할 수 있게 됩니다.
http://j.mp/sub-ndc14
저희의 서버 노드 간 통신이나 시야 처리에 대해선
제가 재작년 발표에서 주로 다뤘었는데요
http://j.mp/sub-ndc14
위 주소로 들어가면 당시 슬라이드를 보실 수 있습니다.
http://j.mp/sub-ndc14
근데 제가 슬라이드에 글을 별로 안 적어 놔서
아마 이것만 봐서는 무슨 내용인지 모르실 것 같아요.
http://j.mp/sub-ndc14-tig
by디스이즈게임안정빈기자
하지만 감사하게도 디스이즈게임 안정빈 기자님께서
그때 제 발표를 굉장히 잘 정리해주신 기사가 있습니다.
http://j.mp/sub-ndc14-tig
by디스이즈게임안정빈기자
그러니 관심 있으신 분들은
이쪽도 같이 참고해주시면 좋을 것 같습니다.
이처럼 저희는 SPOF를 만들지 않기 위해서
모든 서비스 요소를 이중화하는 한편
모든 서버 노드가 유기적으로 협력해서
단 하나의 듀랑고 세계를 구축하도록 설계하고 있습니다.
큰 윤곽을 그려봤으니
이번엔 이렇게 만들어진 듀랑고의 게임 서버가
듀랑고라는 게임을 어떻게 구현하고 있는지
좀 더 자세히 들여다보겠습니다.
#2 들여다보기
부동산 • 신기루 • 전투 공방 합
크게 세 가지 주제를 다룰 건데요
그 중 첫 번째 주제는 게임 세계의 부동산입니다.
부동산이라고 해서 건물만 가지고 얘기할 건 아니고요
정적 객체
식물이나 광물, 시설물 같은
모든 정적 객체에 대해 다루겠습니다.
듀랑고 세계에서 가장 주요한 게임플레이 무대는
자동으로 생성되는 섬입니다.
심리스
이 섬은 플레이어가 중간로딩 없이 심리스하게 이동할 수 있는
가장 큰 공간적 단위죠.
단일 대륙
저희가 개발 초기에는
모든 플레이어가 함께 사는 단 하나의 거대한 대륙을 기획했었는데
군도
개발을 진행하면서 대륙 처럼 거대한 섬 뿐만 아니라
그 밖에도 다양한 섬을 넘나들 수 있는 군도 모델로 선회하게 됐습니다.
안정섬 불안정섬
군도에는 이렇게 안정섬과 불안정섬,
두 종류의 섬이 있는데요
자원 ▼
면적 ▲
수명 ∞
안정섬
안정섬의 경우 좋은 자원이 나진 않지만
면적이 넓고 시간이 지나도 사라지지 않아서
이렇게 사람들끼리
마을을 만들고 정착하기 좋습니다.
자원 ▲
면적 ▼
수명
불안정섬
안정섬과 달리 불안정섬은 면적이 좁고
수명에 제한이 있어서 일정한 시간이 지나면 사라집니다.
자원 ▲
면적 ▼
수명
불안정섬
하지만 생태계도 훨씬 다양하고
좋은 자원도 구할 수 있어서
이렇게 탐험하기에 적합하죠.
만약 안정섬에 플레이어가 너무 적게 있으면
적적하고 외로울 겁니다.
가뜩이나 넓은데
마치 무인도에 혼자 떨어진 느낌이겠죠.
또 불안정섬의 경우는 사람이 너무 많으면
오히려 경쟁이 치열해져서 탐험하기 괴로워질 겁니다.
듀랑고에서의 쾌적하고 재밌는 경험을 위해선
섬의 인구밀도가 항상 적절하게 유지돼야 합니다.
하지만 섬 수가 고정 돼있다면 유입되는 플레이어의 수에 따른
인구밀도 변화에 대응할 수 없을 겁니다.
사람 ∝ 섬
그래서 저희는 각 섬의 인구밀도를 적절하게 맞추고자
플레이어의 수에 맞춰서 섬 수가 자동으로 조절되게 만들었습니다.
사람 ∝ 섬
가령 100명만 플레이할 때는 섬이 서너 개밖에 되지 않지만
10,000명이 플레이할 땐 수백 개의 섬도 생길 수 있는 거죠.
7k 836
2차 LBT
지난 2차 LBT 때를 예로 들면 참여자는 약 7천 명 정도였는데요
그에 맞춰서 836개의 섬이 자동으로 생성돼서 공급됐었습니다.
이처럼 듀랑고 세계의 공간은
잠재적으로 무한하다고 볼 수 있습니다.
게임 서버는 이렇게 얼마나 늘어날지 모르는 공간을
모두 지탱해야 하는 거죠.
그럼 지금부터 저희가 어떻게 무한한 공간을 처리하는지
그 방법을 살펴보도록 하겠습니다.
플레이어에서 시작해 볼게요.
접속 중…
플레이어가 게임에 접속할 땐
우선 게이트웨이에 자신의 아이디를 알려주게 됩니다.