[야생의 땅: 듀랑고] 서버 아키텍처 vol. 2 (자막)

<야생의 땅: 듀랑고>서버 아키텍처 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

그리고 틈틈이오픈소스 활동도 하고 있는데요

https://github.com/what-studio/profiling

https://github.com/sublee/trueskill


https://github.com/sublee




sublee

한 번 제가 만든 프로젝트 중에서별이 100개 이상 찍힌 것만 모아봤습니다.








sublee

혹시 GitHub 하시는 분 계시면 계정 sublee를 팔로우하고제 프로젝트에 별도 찍어주시면 감사하겠습니다.





본격적인 발표에 앞서 저희 프로젝트를 먼저 소개해드릴게요.저희가 만들고 있는 <야생의 땅: 듀랑고>는

공룡이나 코끼리 조상 같은 고생물들이 사는 땅을 개척하면서

거기서의 생활을 즐기는 모바일 MMORPG입니다.

사냥, 채집, 건설 같은 플레이어의 행동 하나하나가듀랑고 세계에 영구적인 변화를 남기게 되는 오픈월드 게임이죠.

A 서버군 B 서버군 단일 서버군

듀랑고 서버 아키텍처에는 마비노기 영웅전처럼서버군 구분이 없습니다.

A 서버군 B 서버군 단일 서버군

게임을 시작하거나 접속할 때자기가 속할 서버군을 고르지 않아도 되는 거죠.

다중 채널

단일 채널

단일 서버군이던 마비노기 영웅전에서 조금 더 나아가저희는 채널도 구분하지 않는데요

그래서 가까운 장소에만 있으면모든 플레이어와 서로 만날 수 있습니다.

무한한 공간

영속적 세계

단일 채널

고 가용성

저희 서버 아키텍처는이런 듀랑고의 게임플레이를 지원하기 위해

무한한 공간

영속적 세계

단일 채널

고 가용성

무한한 공간, 단일 채널, 영속적 세계, 고 가용성같은 목표를 세우고 도전해오고 있습니다.

#1 멀리 보기

#2 들여다보기

#3 돌아보기

오늘 발표에선 듀랑고 서버 아키텍처가저희의 목표를 어떻게 달성해왔고

#1 멀리 보기

#2 들여다보기

#3 돌아보기

또 어떤 결과를 내고 있는지얘기하려고 합니다.

#1 멀리 보기

첫 번째로 저희 서버 구조가 어떻게 짜여져 있는지 멀리서큰 윤곽부터 한 번 그려 볼게요.

SPOFSingle Point of Failure (단일장애지점)

프로젝트 초반부터 지금까지 저희의 목표는SPOF 없는 MMORPG 서버를 만드는 거였습니다.


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-tig

by 디

스이

즈게

임안

정빈

기자

하지만 감사하게도 디스이즈게임 안정빈 기자님께서그때 제 발표를 굉장히 잘 정리해주신 기사가 있습니다.



by 디

스이

즈게

임안

정빈

기자

그러니 관심 있으신 분들은이쪽도 같이 참고해주시면 좋을 것 같습니다.


이처럼 저희는 SPOF를 만들지 않기 위해서모든 서비스 요소를 이중화하는 한편

모든 서버 노드가 유기적으로 협력해서단 하나의 듀랑고 세계를 구축하도록 설계하고 있습니다.

큰 윤곽을 그려봤으니이번엔 이렇게 만들어진 듀랑고의 게임 서버가

듀랑고라는 게임을 어떻게 구현하고 있는지좀 더 자세히 들여다보겠습니다.

#2 들여다보기

부동산 • 신기루 • 전투 공방 합

크게 세 가지 주제를 다룰 건데요그 중 첫 번째 주제는 게임 세계의 부동산입니다.

부동산이라고 해서 건물만 가지고 얘기할 건 아니고요

정적 객체

식물이나 광물, 시설물 같은모든 정적 객체에 대해 다루겠습니다.

듀랑고 세계에서 가장 주요한 게임플레이 무대는자동으로 생성되는 섬입니다.

심리스

이 섬은 플레이어가 중간로딩 없이 심리스하게 이동할 수 있는가장 큰 공간적 단위죠.

단일 대륙

저희가 개발 초기에는모든 플레이어가 함께 사는 단 하나의 거대한 대륙을 기획했었는데

군도

개발을 진행하면서 대륙 처럼 거대한 섬 뿐만 아니라그 밖에도 다양한 섬을 넘나들 수 있는 군도 모델로 선회하게 됐습니다.

안정섬 불안정섬

군도에는 이렇게 안정섬과 불안정섬,두 종류의 섬이 있는데요

자원 ▼

면적 ▲

수명 ∞

안정섬

안정섬의 경우 좋은 자원이 나진 않지만면적이 넓고 시간이 지나도 사라지지 않아서

이렇게 사람들끼리마을을 만들고 정착하기 좋습니다.

자원 ▲

면적 ▼

수명

불안정섬

안정섬과 달리 불안정섬은 면적이 좁고수명에 제한이 있어서 일정한 시간이 지나면 사라집니다.

자원 ▲

면적 ▼

수명

불안정섬

하지만 생태계도 훨씬 다양하고좋은 자원도 구할 수 있어서

이렇게 탐험하기에 적합하죠.

만약 안정섬에 플레이어가 너무 적게 있으면적적하고 외로울 겁니다.

가뜩이나 넓은데마치 무인도에 혼자 떨어진 느낌이겠죠.

또 불안정섬의 경우는 사람이 너무 많으면오히려 경쟁이 치열해져서 탐험하기 괴로워질 겁니다.

듀랑고에서의 쾌적하고 재밌는 경험을 위해선섬의 인구밀도가 항상 적절하게 유지돼야 합니다.

하지만 섬 수가 고정 돼있다면 유입되는 플레이어의 수에 따른인구밀도 변화에 대응할 수 없을 겁니다.

사람 ∝ 섬

그래서 저희는 각 섬의 인구밀도를 적절하게 맞추고자플레이어의 수에 맞춰서 섬 수가 자동으로 조절되게 만들었습니다.

사람 ∝ 섬

가령 100명만 플레이할 때는 섬이 서너 개밖에 되지 않지만10,000명이 플레이할 땐 수백 개의 섬도 생길 수 있는 거죠.

7k 836

2차 LBT

지난 2차 LBT 때를 예로 들면 참여자는 약 7천 명 정도였는데요그에 맞춰서 836개의 섬이 자동으로 생성돼서 공급됐었습니다.

이처럼 듀랑고 세계의 공간은잠재적으로 무한하다고 볼 수 있습니다.

게임 서버는 이렇게 얼마나 늘어날지 모르는 공간을모두 지탱해야 하는 거죠.

그럼 지금부터 저희가 어떻게 무한한 공간을 처리하는지그 방법을 살펴보도록 하겠습니다.

플레이어에서 시작해 볼게요.

접속 중…

플레이어가 게임에 접속할 땐우선 게이트웨이에 자신의 아이디를 알려주게 됩니다.

배정

그럼 게이트웨이는 플레이어가 마지막에 있던 위치를 기반으로접속할 프론트엔드를 배정해주죠.

이어서 클라이언트가배정받은 프론트엔드에 접속하면

플레이어 객체가 게임 세계에 나타나게 됩니다.

플레이어는 접속했을 때만 게임 세계에 속하니깐서버는 수동적으로 그저 전달받은 아이디를 DB에서 찾기만 하면 되죠.

반면 식물이나 광물, 시설물 같은 정적 객체들은늘 게임 세계에 속해 있어야 합니다.

그렇다고 플레이어처럼 서버에 스스로 접속하는 건 아니기 때문에서버가 직접 찾아낼 수 있어야 합니다.

아이디 위치

색인 키

그러려면 아이디로 색인되는 플레이어와 달리정적 객체들은 위치로 색인돼야 합니다.

아이디 위치

색인 키

서버에 좌표만 주어져도그곳에 있는 정적 객체를 바로 발견할 수 있어야 하는 건데요

저희가 위치를 다룰 땐몇 가지 간략화된 지리 단위를 이용합니다.

섬의 모양새인 지형은 일종의 타일맵인데한 칸에 한 가지 지질을 담고 있습니다.

타일

여기서의 한 칸을저희는 타일이라고 부릅니다.

타일

타일은 게임 내에서 정적 객체가 점유할 수 있는가장 작은 영역이기도 하죠.

16×16 타일 = 청크

그 다음 단위는가로세로 16타일을 묶은 구역인 청크입니다.

16×16 타일 = 청크

섬이 크건 작건 청크의 면적은 균일하겠죠.

16×16 타일 = 청크

그러면서도 타일처럼 너무 작지도 않고 크기가 적당해서여러가지 용도로 유용하게 쓰고 있습니다.

가령 게임 클라이언트는 서버로부터자기 시야에 들어온 근처의 정보만 스트리밍 받는데

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/chunks-streaming.gif

이 때 정보가 묶이는 단위도 바로 청크입니다.

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/chunks-streaming.gif

{키: 값}

한편, Key-value 스토리지인 Couchbase에서아이디가 아닌 정보로 데이터를 찾는 건 그렇게 간단하지 않습니다.

{키: 값}

Map/Reduce를 지원하긴 하지만 색인 속도가 느려서자주 읽고 써야 되는 작업에는 적합하지 않거든요.

{키: 값}

저희는 Couchbase를 쓰면서도어디에 어느 정적 객체가 있는지 빠르고 정확하게 색인하기 위해

땅문서

땅문서라고 부르는 별도의 문서에정적 객체의 위치를 역정규화시켰습니다.

{타일: 객체}

구조는 단순한데요어느 타일에 어떤 정적 객체가 위치하는지 가리키는 딕셔너리라고 볼 수 있습니다.

만약 섬 전체를 하나의 땅문서로 관리하게 되면다루기는 편하겠죠.

하지만 섬 크기가 클 수록 색인하는 부담도 함께 커질 겁니다.땅문서 하나가 객체 수백만 개를 색인한다고 생각해보세요.

청크마다 땅문서

저희는 섬 크기와 상관 없이색인 성능을 일관되게 보장하기 위해

청크마다 땅문서

땅문서 하나가 딱 하나의 청크만 담당하게 만들었습니다.

노드1

노드2 노드3

이런 땅문서는 어떤 서버 노드든자유롭게 조회하고 수정할 수 있습니다.

노드1

노드2 노드3

종종 여러 스레드가 동시에같은 땅문서를 건드릴 때도 있겠죠.

노드1

노드2 노드3

그런 경우에도 다른 스레드의 수정사항을 덮어쓰지 않도록트랜잭션 처리로 보호해야 합니다.

낙관적 트랜잭션

개발 초기엔 여기에 낙관적 트랜잭션이라는 기법을 적용했는데요


낙관적 트랜잭션은 ‘경합이 거의 없겠거니’하고낙관적으로 가정하는 트랜잭션 방법 중 하나입니다.


용어는 낙관적 동시성 제어 식 트랜잭션이라고부르는 게 맞지만 편의상 이렇게 줄여서 말할 게요.

v1

낙관적 트랜잭션은 이렇게 동작하는데요DB엔 레코드 별로 버전이 기록돼 있습니다.

v1

v1

애플리케이션이 DB에서 레코드를 조회할 때이 버전도 함께 받습니다.

v1'

v1

그런 다음 레코드를 수정하고 다시 저장할 때도받아 뒀던 버전을 같이 보냅니다.

v1'

v1

그렇게 DB에 있는 버전이기존 버전과 일치하는지 확인하죠.

v1'

v1

두 버전이 여전히 같을 때에만레코드가 성공적으로 저장되게 됩니다.

v1'

v2

만약 그새 다른 스레드에서 이 레코드를 수정했다면버전이 자동으로 바뀌게 되는데

v1'

v2

이땐 DB가 저장 요청을 받아주지 않고 거부합니다.

v1'

v2

그럴 경우 애플리케이션은트랜잭션을 포기하거나 다시 시도할 수 있는데요

v2

v2

트랜잭션을 다시 시도하는 경우엔최신 레코드를 조회해서 새 버전을 받고

v2

v2

똑같은 수정사항을 적용한 다음다시 저장하길 시도합니다.

v2'

v2

이 과정을 반복하다 보면 언젠가는 경합이 끝나서트랜잭션의 성공을 보장할 수 있는 거죠.

v2'

v2

경합이 자주 일어나는 경우에 이 방법을 쓰면이런 재시도 루프가 여러 바퀴 돌 수 있어서 효율적이지 않습니다.

v2'

v2

하지만 경합이 별로 없는 경우에 사용하면대체로 루프가 한 바퀴 밖에 안 돌 테니까 꽤 가볍게 쓸 수 있죠.

Check and Set (CAS)

Couchbase는 CAS라는 이름으로이런 버전 검사 기능을, 기본으로 제공합니다.

Check and Set (CAS)

그래서 쓰기 편하긴 한데딱 한 레코드에 한한 트랜잭션만 보장해주기 때문에

Check and Set (CAS)

거래 처리 같이여러 레코드를 함께 수정하는 경우엔 적합하지 않습니다.


그래서 정적 객체가 한 청크 안에 쏙 들어갈 땐수정할 땅문서도 딱 한 개라서 낙관적 트랜잭션이면 충분하지만


여러 청크에 걸치는 경우는그렇지 않습니다.

BEGIN;UPDATE A;UPDATE B;COMMIT;

Couchbase는 RDB와 다르게여러 레코드를 한 번에 수정하는 트랜잭션은 지원하지 않습니다.

?!

만약 게임 서버가 트랜잭션 처리 없이무턱대고 한 번에 여러 땅문서를 차례대로 수정하려고 하면

?!

예기치 못 한 오류나 다른 스레드와의 경합이 발생했을 때이렇게 불완전한 땅문서가 만들어질 수 있습니다.

?!

저희는 정적 객체가 여러 청크에 걸치는 경우라도안전하게 처리하기 위해서

BASE 트랜잭션

BASE 트랜잭션이라는 기법을 기반으로땅문서의 트랜잭션을 보장할 다른 방법을 고안했습니다.

BASE ACID

트랜잭션

RDBNoSQL

RDB에 ACID 트랜잭션이 있다면NoSQL엔 BASE 트랜잭션이 있습니다.

BASE ACID

트랜잭션

RDBNoSQL

여러 레코드에 대한 트랜잭션을 DB가 아닌애플리케이션에서 보장하는 방법이죠.

Basically AvailableSoft stateEventual consistency

BASE 트랜잭션에서 “BASE”가 이런 뜻이라는데그냥 산성 염기성 말장난하려고 억지로 짜 맞춘 것 같죠?


이중에서 마지막 Eventual consistency가 중요한 것 같습니다.


ACID 트랜잭션과 다르게 BASE 트랜잭션이 진행되는 동안엔DB에서 레코드들 간의 일관성이 깨지게 돼요.


하지만 트랜잭션이 완료됐을 때 결국에는일관성이 맞춰지게 됩니다.


그럼 한 번 BASE 트랜잭션이 어떻게 동작하는지간단하게 짚고 넘어가 볼게요.

여기 수정할 레코드들이 있습니다.

BASE 트랜잭션을 쓸 땐이 레코드들을 바로 수정하는 대신

TX

트랜잭션 문서

먼저 별개의 레코드에작업내용만 기록합니다.

TX

트랜잭션 문서

레코드를 각각 어떻게 어떻게 바꿔라하는 내용을 저장하는 거죠.

TX

트랜잭션 문서

이 레코드를 트랜잭션 문서라고 부르겠습니다.

TX

트랜잭션 문서

트랜잭션 문서가 성공적으로 등록됐으면

TX

수정할 레코드들은차근차근 수정되게 됩니다.

TX

이 때 보면 레코드 간 일관성이 깨져 있죠.

TX

예를 들면 한쪽에선 돈을 꺼냈는데다른 쪽에는 돈이 안 들어가 있다거나 하는 상황이에요.

하지만 언젠가 모든 레코드에수정사항이 적용되면

일관성도 맞춰지고트랜잭션도 완료되게 됩니다.

만약 중간에 일부 레코드 수정에 실패하더라도

트랜잭션 문서에 적힌 내용을 바탕으로애플리케이션에서 뒤늦게나마 수정사항을 마저 적용할 수 있습니다.

TX

트랜잭션 문서땅문서에 바로

저희가 정적 객체를 땅문서에 기록하는 경우에도BASE 트랜잭션과 마찬가지로

TX


땅문서에 바로 쓰는 대신별개의 트랜잭션 문서에 설치 계획만 먼저 기록해둡니다.

TX


어느어느 타일에 어떤 객체를 올리겠다는 내용이죠.

TX

각 트랜잭션 문서는 이렇게가로세로 4청크 씩을 담당합니다.

TX

패치

이 구역을 저희는 패치라고 부르는데요.

TX

이 패치 내에서 벌어지는 땅문서 변경이모두 해당 트랜잭션 문서에 기록됩니다.

TX

그럼 패치의 경계에 걸치는 경우는 어떻게 처리될까요?

TX

설치 계획을 두 트랜잭션 문서에 나눠서 기록하면여전히 트랜잭션을 보장할 수 없게 될 겁니다.

TXTX

이런 빈틈을 없애기 위해서패치를 이웃한 패치와 1청크 씩 겹치게 만들었습니다.

TXTX

모든 청크 경계가적어도 하나 이상의 패치로는 덮여있는 거죠.

정적 객체가 아무리 커도 한 청크를 넘지는 않기 때문에

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/grid-patches.gif

어느 곳에 위치하더라도단 하나의 패치로 완전히 포갤 수 있습니다.


설치계획은 그 위치를 완전히 포갤 수 있는단 하나의 트랜잭션 문서에 기록하게 됩니다.


롤백 대비

한편 BASE 트랜잭션을 쓸 땐레코드가 롤백되는 상황에도 대비해야 하는데요

TX

가령 첫 번째 레코드는 성공적으로 수정했는데두 번째 레코드에선 실패했을 경우에

TX

애플리케이션이 직접 역함수를 실행해서첫 번째 레코드에 적용했던 수정사항을 다시 되돌려야 하는 거죠.

TX

그런데 역함수를 구현하기 어려운 경우가 있습니다.

TX

수정 로직에 사이드이펙트가 있다거나 하는 경우 같이요.

TX

또 역함수마저 실패하거나애플리케이션이 두 번째 레코드를 며칠 뒤에야 건드려서

TX

첫 번째 레코드를 롤백시켜야한단 사실을 알기까지시간이 오래 걸릴 수도 있습니다.

TX

이렇게 신경 써야 할 예외 상황이 많아서저는 BASE 트랜잭션이 다루기 까다로운 편이라고 생각합니다.

+ 비관적 트랜잭션

저희는 땅문서 트랜잭션을 좀 더 단순하게 만들기 위해서


BASE 트랜잭션에 비관적 트랜잭션이라는 방법을 접목해서롤백 될 가능성을 완전히 없앴습니다.


이것도 원래는 비관적 동시성 제어 식 트랜잭션이라고 불러야 하지만그냥 편의 상 이렇게 부를 게요.

비관적 트랜잭션은 낙관적 트랜잭션과 달리경합이 분명히 발생할 거라고 비관적으로 가정합니다.

그래서 수정할 레코드에 일단 락을 걸고 보죠.

땅문서 트랜잭션을 시작할 때도반드시 청크 별 락을 얻게 해서

트랜잭션을 등록하는 동안은해당 청크의 조건이 절대 바뀌지 않도록 했습니다.

이 락엔 짧은 TTL이 설정돼 있어서 게임 서버 오류로 인해제때 풀리지 않더라도 크게 문제가 되진 않습니다.

지금까지 여러 청크에 걸치는 땅문서 트랜잭션을보장하는 방법을 소개했는데요

이렇게 두 청크에 걸치는 정적 객체를 설치하고자 할 때게임 서버가 땅문서를 어떻게 수정해 나가는지

그 과정을 한 번 나열해 보겠습니다.

1. 청크 잠그기

TX

첫 번째 단계에선 우선 청크들에 락을 걸어서다른 스레드가 해당 청크엔 트랜잭션을 등록하지 못 하게 합니다.

TX

2. 조건 검사

그리고 객체를 설치해도 되는지 조건을 검사해요.설치하려는 자리가 비어 있어야 되는 거죠.

TX

3. 트랜잭션 등록TX

조건에 부합하면 다음 단계로 넘어가서설치 계획을 트랜잭션 문서에 등록하는데

TX

3. 트랜잭션 등록TX

이 단계까지만 성공하면정적 객체의 정상적인 설치가 보장됩니다.

TX

4. 잠금 해제

그 다음으론청크에 걸어둔 락을 풀어주고

TX

5. 땅문서 수정

마지막으로 등록해둔 설치 계획을 처리합니다.땅문서를 실제로 수정하는 거죠.

TX

5. 땅문서 수정

여기까지 성공하면 한 큐에정적 객체 설치가 완료됩니다.

TX

5. 땅문서 수정

이제 각 과정에서 오류가 발생하면 어떻게 되는지역순으로 살펴볼게요.

TX

5. 땅문서 수정

먼저 마지막 단계에서일부 땅문서 수정에 실패하는 경우엔

TX

5. 땅문서 수정

다른 스레드가 해당 땅문서를 읽을 때결국 다시 처리되게 됩니다.

TX

4. 잠금 해제

그 전 단계에서 실패하면청크 락이 제대로 안 풀리겠죠.

TX

4. 잠금 해제

하지만 앞서 소개한 TTL이 있어서금새 자동으로 풀리게 됩니다.

TX

4. 잠금 해제

또 설치계획도 이미 트랜잭션 문서에 등록돼서결국엔 모두 처리되게 되죠.

TX

3. 트랜잭션 등록

아예 트랜잭션 등록에 실패하거나

TX

2. 조건 검사

땅의 상태가 조건에 부합하지 않을 땐즉시 락을 풀고 트랜잭션을 포기합니다.

1. 청크 잠그기

TX

첫 단계에서부터 오류가 나거나아니면 다른 스레드가 청크 락을 잡고 있어서 잠그는 데 실패해도

1. 청크 잠그기

TX

마찬가지로 트랜잭션을 포기하죠.

TX

요약하자면트랜잭션 문서가 등록되는 3단계를 기준으로

TX

여기를 지나면 정적 객체 설치는반드시 성공하고

TX

그 전에 실패할 경우 땅문서엔 이렇게아무런 찌꺼기도 남지 않습니다.

청크

지금까지 듀랑고 서버의부동산 처리에 관해 얘기했는데요

청크

크기가 균일한 청크와

땅문서

청크 별로 저장되는 땅문서로정적 객체를 어떻게 다루는지 살펴봤습니다.

부동산은 듀랑고에서 가장 중요한 자원인 만큼이렇게 안전한 방법으로 관리하고 있습니다.

#2 들여다보기


이어서 듀랑고 세계의 객체들이 언제 생성되고또 언제 서버 메모리에 올라오는지 얘기해보겠습니다.

섬은 그저 공간만 차지하는 게 아니라수많은 객체들도 포함하고 있습니다.

나무나 바위, 시설물 같은 정적 객체도 잔뜩 배치돼있고여기저기엔 동물도 살고 있죠.

300만 10만

2차 LBT

지난 2차 LBT의 경우정적 객체 300만 개와 동물 10만 마리가 동원됐는데요

300만 10만

2차 LBT

이 많은 객체들을항상 서버 메모리에 올려두는 건 불가능할 겁니다.

ⓒ Rockstar Games

제가 한 동안 빠져있었던 <GTA5>라는 게임은방대한 공간을 제공하는 심리스 오픈월드 게임입니다.

ⓒ Rockstar Games

게임의 배경은로스산토스라는 가상의 도시인데요

ⓒ Rockstar Games

여기선 어딜 가든 정교한 NPC를 만나볼 수 있습니다.걸어 다니는 행인부터

ⓒ Rockstar Games

절 잡으러 쫓아오는 경찰이나

ⓒ Rockstar Games

도로를 빽빽이 채우는 자동차들까지

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/gta5-near-cars.gif

ⓒ Rockstar Games

얼마나 많은 NPC랑 정교한 AI가이 로스산토스라는 곳을 채우고 있을지 상상하기 어려웠습니다.


ⓒ Rockstar Games

하지만 이렇게 정교하고 구체적인 NPC는실은 제 근처의 좁은 구역에만 있다는 걸 알 수 있었는데요


ⓒ Rockstar Games

저 멀리 다리 위를 달리는 자동차들은

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/gta5-far-cars.gif

ⓒ Rockstar Games

사실 아무것도 판단하지 않고 그저 정해진 패턴만 반복하는하얗고 붉은 불빛일 뿐이더라고요.


ⓒ Rockstar Games

네모 친 곳을 잘 보면 패턴이 보일 겁니다.불빛들이 간격을 딱딱 맞춰서 다니고 있죠?


LODLevel of Detail

그림: http://polygon-reducer.pc-guru.cz/reducing-level-of-detail

컴퓨터 그래픽스 쪽 최적화 기법 중에LOD라는 게 있습니다.

LODLevel of Detail


카메라에서 먼 객체를 대충 렌더링하는 기법인데요

LODLevel of Detail


여기 판자 위에 있는스탠포드버니들은 모두 똑같아 보이지만

LODLevel of Detail


실은 멀 수록폴리곤을 적게 쓰고 있습니다.

NPC에 LOD

<GTA5>는 NPC에 이런 LOD를 적용하고 있습니다.

NPC에 LOD

바로 근처의 NPC는 매우 정교하게 동작하지만거리가 멀 수록 단순한 패턴만 반복하는 거죠.

NPC에 LOD

<GTA5> 뿐 아니라 <어쌔신 크리드 유니티>도 그렇고여러 심리스 오픈월드 게임들이 비슷한 방식을 취합니다.

NPC에 LOD

저희도 수많은 객체들을 효율적으로 처리하기 위해객체들에 LOD를 적용하고 있습니다.

상호작용활성화

정적 객체 LOD의 경우거리 대신 상호작용 여부에 반응하게 했는데요

상호작용활성화

얘네는 플레이어가 건드려야만 활성화돼서서버 메모리에 올라가게 됩니다.

신기루 객체

건드리기 전까진 표시하는 데 필요한최소한의 정보로만 땅문서에 기록되는데

신기루 객체

저희는 이 상태를 신기루라고 부릅니다.

신기루 객체

이런 신기루 상태에서도클라이언트에 표시될 수 있고 서버에서도 존재를 인식할 수 있습니다.

플레이어가 건드려서 활성화된 정적 객체는일정 시간 동안 플레이어랑 상호작용해주다가

다시 신기루가 돼서 서버 자원을 아낄 수 있게 해줍니다.접속자가 없으면 서버도 쉴 수 있도록 말이죠.

자연물

정적 객체 중에 나무나 바위 같은 자연물들은섬이 만들어질 때부터 같이 있어야 되는데요

NEW

NEW NEW NEW NEW NEW NEW




그렇다고 섬 만들 때 자연물도 같이 만들어서일일이 DB에 저장한다면

NEW





섬 만드는 속도가 느려져서필요에 따라 섬을 실시간으로 늘리기 어려워질 겁니다.

시설물 같은 경우는 재료에 따라 생김새가 달라져서신기루에 담아야 되는 정보도 많은 편인데요

78 27 12 63

반면 자연물은 생김새가 판에 박혀있어서그냥 숫자 하나만으로도 표현할 수 있습니다.

0 12 27

78

63 78 12

27 78

이 점을 활용해서 저희는 섬의 최초 자연물 배치를단순한 숫자맵 파일로 만들어서 지형 데이터에 포함시켰습니다.

NEW

땅문서의 경우도 역시 섬과 함께 만들어지진 않습니다.섬이 새로 생성된 직후엔 DB에 땅문서가 존재하지 않죠.

0 12 27

78

63 78 12

27 78

NEW

그런 경우 서버는 땅문서 대신자연물 배치 파일을 읽어서 신기루 자연물로 보여줍니다.

DB

NEW

플레이어가 신기루 자연물을 건들면그때야 비로소 객체가 만들어지고 DB에도 저장되죠.

DB

NEW NEW

이때 그 청크의 땅문서도 함께 생성돼서DB에 저장됩니다.

0 12 27

78

63 78 12

27 78

서버도 그 다음부턴 자연물 배치 파일 대신DB에 있는 땅문서를 참조하게 됩니다.

여기까지 정적 객체의 신기루 상태를먼저 살펴봤는데요

이번엔 동물의 신기루 상태를살펴보겠습니다.

동물에는 고수준 AI가 돌아가서 성능을 많이 잡아먹기 때문에서버에서 특히 효율적으로 관리해야 합니다.

동물에는 아까 보신 <GTA5>의 NPC처럼플레이어와의 거리에 반응하는 LOD를 적용했습니다.

섬 여기저기엔동물의 서식지가 기록돼 있는데요

어디에 어떤 종이 몇 마리 있고마지막엔 뭘 하고 있었는지 같은 정보가 저장돼있죠.

플레이어가 섬에 들어오면자기 시야에 들어오는 동물 서식지를 찾습니다.

그리고 거기에 살고 있는 동물들을 깨우죠.

깨어난 동물은 게임 세계에 스폰돼서고수준 AI를 돌리기 시작합니다.

이런 동물의 활동은근처에 관객이 있는 동안에만 지속되고요

관객이 사라지면 동물들도마지막 상태만 DB에 기록하고

모두 사라지게 됩니다.다시 서식지 정보만 남게 되는 거죠.

이처럼 듀랑고에선수많은 객체가 플레이어의 눈앞을 빽빽이 채우고 있지만

대부분은 신기루 상태라서컴퓨팅 자원이나 DB 공간을 거의 소모하지 않습니다.

이렇게 플레이어가 필요로 하는 곳에만자원을 집중하는 것이

듀랑고 서버가잠재적으로 무한한 공간을 지탱하는 방법입니다.

<야생의 땅: 듀랑고>중앙 서버 없는 게임 로직최호영 • 14:10 • GBI

오늘 오후 2시 10분에 저희 스튜디오 최호영 님 발표에서방금 소개해드린 신기루나 부동산을 게임로직에서 실제로 다룬 사례를 소개합니다.


제가 슥 넘긴 시설물의 신기루도이쪽에서 자세히 다룰 거고요


또한 중앙 서버가 없는 환경에서게임 로직을 만드는 데 있어서 어떤 어려움이 있었고


또 어떻게 극복했는지 공유하는 자리니까


저희 서버 아키텍처에 관심 있는 분들께선이어서 들으시면 좋을 것 같습니다.

#2 들여다보기


이번엔 주제를 바꿔서듀랑고의 전투에 대해 이야기해보겠습니다.

vs.

개발 초기에 저희가 구현한 전투는프론트엔드와 동물원 노드에 걸쳐서 벌어졌는데요

vs.

양쪽에서 플레이어 객체와 동물 객체가서로 공격을 주거니 받거니 하며 싸우는 거죠.

RPC

그러다 보니 모든 전투 액션이 노드 간 통신으로 이뤄져서리액션이 지연되는 경우가 자주 있었습니다.

가령 플레이어 공격 연출은 이미 나갔는데동물이 제때 맞아주지 않아서

https://github.com/sublee/ndc16-durango-server-architecture-vol2/blob/master/gifs/inconsistent-battle.gif

피격 판정이 늦거나어긋난다거나 하는 식이었죠.


이건 일부러 서버 간 통신을지연시켜놓고 찍은 영상인데요


공방 합이 맞지 않는 것을보실 수 있습니다.


저희는 공방 합이 재밌는 전투를 만드는 데 있어서굉장히 중요한 요소라고 생각했습니다.

콜로세움

그래서 공방합을 맞추기 위해새로운 게임 서버 노드인 콜로세움을 도입했습니다.

콜로세움

앞서 콜로세움은 전투만 담당하는 특별한 노드라고 소개 했었는데요콜로세움이 전투를 어떻게 이끄는지 한 번 보도록 하겠습니다.

vs.

프론트엔드에 있는 플레이어와동물원 노드에 있는 동물 사이에 전투가 벌어지면

vs. vs.

두 노드가 직접 전투를 처리하는 대신임의의 콜로세움에 전투 방을 생성합니다.

vs. vs.

그때부터 전투에 참여한 객체는콜로세움에 동기화되는데요

vs. vs.

콜로세움이 동기화된 객체를 소유하는 건 아니지만대신 제어권을 넘겨받아서 직접 조종할 수 있게 됩니다.

vs. vs.

공방 계획

전투 방에서는 전투 스케줄러라는 게 돌아갑니다.전세를 파악하고 공방 계획을 짜는 역할을 하죠.

vs. vs.

통보

이렇게 세워진 공방 계획은프론트엔드와 동물원 노드에 통보되는데

vs. vs.

통보

통보 받은 쪽에선 그 계획을 무조건 따라야 합니다.

쉽게 말하면 클라이언트 대신 서버가 접속하는인스턴스 던전이라고도 볼 수 있을 것 같아요.

클라이언트에선심리스한 필드 전투로 보이지만 말이죠.

RPC

아까와 달리 콜로세움 노드 하나에서공방 계획이 모두 결정되다 보니까

RPC

노드 간 통신에 의존하지 않아도 돼서판정에서의 공방 합이 맞게 됩니다.

①

이렇게 짠 공방 계획을 패킷 하나로 묶어서 클라이언트로 보낸다면연출에서도 공방 합을 맞출 수 있을 겁니다만

①

아직…

이 계획은 아직 실현하지 못 했습니다.

①

②

그래서 현재 구현은 이런데요

①

②

콜로세움에서 결정된 동물의 행동이 프론트엔드로 바로 전달되지 않고동물원 노드를 거쳐갑니다.

①

②

그래서 플레이어의 행동과 동물의 행동이서로 다른 시점에 클라이언트로 전달되죠.

①

②

노드 간 통신 속도가 빠를 땐 별 문제가 생기지 않는데통신이 느려지거나 동물원에 과부하가 걸리게 되면

①

②

공격 연출과 방어 연출 사이에시간차가 발생하게 됩니다.

①

이 부분은 차후에앞에서 말씀드린 방법으로 개선할 예정입니다.

규모, 가용성 합의

분산 아키텍처

저희가 설계한 분산 서버 아키텍처로처리 규모와 가용성을 높일 순 있었지만


분산 아키텍처

여러 서버 노드 사이에 합의가 필요한 경우엔간단한 일이라도 콜로세움 같은 우회책을 마련할 필요가 있었습니다.


분산 아키텍처

저희는 이점을 듀랑고 세계를 무한히 넓게 만들기 위한일종의 트레이드오프로 인식하고 있고요


분산 아키텍처

좀 더 쉽게 해결할 수 있는방법과 장치를 꾸준히 고민하고 있습니다.

<야생의 땅: 듀랑고>의거친 환경에서 살아가는 동물 AI박동일 • 15:20 • GBI

콜로세움 전투를 비롯해 듀랑고의 동물에 관한더 자세한 이야기는

<야생의 땅: 듀랑고>의거친 환경에서 살아가는 동물 AI박동일 • 15:20 • GBI

오늘 오후 3시 20분 박동일 님 발표에서 들으실 수 있으니까요이쪽에도 많은 참관 부탁드립니다.

지금까지 저희 게임 서버가듀랑고라는 게임을 어떻게 구현하고 있는지 살펴봤습니다.

청크 신기루

청크라는 크기가 균일한 단위와필요한 곳에만 자원을 집중하는 LOD 처리를 이용해서

청크 신기루

잠재적으로 무한한 공간을 지탱하고

땅문서 콜로세움

여러 서버 노드가 접근해도 안전하게 관리되는 땅문서와콜로세움 같이 특화된 서버 노드로

땅문서 콜로세움

모든 서버 노드가 합의한단 하나의 게임 세계를 만들었습니다.

하지만 아직은서버 아키텍처에 미흡한 부분이 많습니다.

#3 돌아보기

이번엔 그 중 지난 두 차례의 LBT를 진행하면서저희가 겪은 주요 문제 두 가지를 꼽아봤습니다.

하나는 로드밸런싱 문제인데요특히 프론트엔드 부하가 유난히 고르게 분배되지 않던 점입니다.

듀랑고에선 많은 사람들이이렇게 좁은 지역에 마을을 짓고 옹기종기 모여 살게 됩니다.

지금처럼 위치만으로 프론트엔드를 배정해서는특정 프론트엔드에 부하가 몰리게 마련이더라고요

그로 인해 동기화 품질이 떨어지는 걸이번엔 막지 못 했습니다.

프론트엔드를 배정해줄 때 위치 뿐만 아니라부하 상황도 함께 고려하는 방향으로 계획하고 있습니다.

나머지 하나는불안정섬 과잉공급 문제입니다.

불안정섬이 하나만 생겨도그곳엔 동물이 수십 마리는 딸려오는데

섬 면적이 좁다 보니 플레이어가 한두 명만 돌아다녀도대부분의 동물이 깨어나게 됩니다.

그러다 보니 동물원 노드에도 부하가 생기고프론트엔드에도 동기화 부담이 가중됐었습니다.

불안정섬의 인구밀도를 잘 조절하면이런 문제가 발생하지 않을 거라고 생각했지만

이번에 저희가 설정한 인구밀도로는동시 접속자에 비해 동물의 수가 지나치게 많아졌었습니다.

이런 문제를 방지하기 위해 동기화 성능과인구밀도 조절 방법을 함께 개선하려고 합니다.

모든 서버는분명히 죽는다

주요 문제들 말고도 메모리릭이나 게임 로직 오류,미묘한 타이밍 문제 같은 각종 버그도 있었습니다.

모든 서버는분명히 죽는다

개중에는 몇몇 서버 노드를 힘들게 만드는 것도 있었죠.모든 서버는 분명히 죽는 거 아시죠?

증설 감축

재시작

보셨듯이 이번에 저희가 모든 문제를 해결한 상태는 아니었지만그래도 테스트를 성공적으로 마칠 수 있었던 까닭은

증설 감축

재시작

서버 증설과 감축, 그리고 재시작을자유롭게 할 수 있었다는 점에 있는 것 같아요.

노드1

노드2

노드3

각 게임 서버 노드가특정 영역을 독점하지 않는 덕분에

노드1

노드2

노드3

어떤 노드가 문제를 일으킬 때 그걸 종료하기만 하면바로 다른 노드들이 그 역할을 대신할 수 있습니다.

노드1

노드2

노드3

또 서버 부하가 높아졌을 때 노드를 새로 띄우기만 해도부하가 자동으로 분산돼서 서비스를 중단하지 않고도 상황을 회복시킬 수 있죠.

ON

ON

ON

ON

ON

이번 테스트에선몇몇 동물원 노드가 폭주하는 버그가 있었는데요

OFF

ON

ON

ON

ON

해당 노드를 껐다가

ON

ON

ON

ON

ON

다시 켜는 것만으로 점검을 걸지 않고문제를 해결할 수 있었습니다.

꿈: 오토스케일링

저희는 이런 구조와 운영 경험을 바탕으로

꿈: 오토스케일링

나중엔 듀랑고 서버를오토스케일링할 수 있는 MMORPG 서버로 만들고자 합니다.

To be continued…

개인적으로는 지난 두 LBT에서아쉬움이 많이 남았었는데요

To be continued…

하지만 저희 서버 아키텍처의강점과 약점을 파악할 수 있는 굉장히 좋은 기회였다고 생각합니다.

To be continued…

이 경험을 발판 삼아서 다음 번엔 좀 더좋은 서비스를 제공하도록 준비하고 있습니다.

감사합니다.http://j.mp/sub-ndc16

제가 준비한 이야기는 여기까지입니다.끝까지 발표를 들어주셔서 감사하고요


감사합니다.http://j.mp/sub-ndc16

아래 주소에 발표 원고를 올려놨으니제 전달력이 부족해서 이해하기 어려웠던 부분은 이쪽을 참고해주세요.


아울러 저희 왓 스튜디오에선함께 교류할 훌륭한 인재를 찾아다니고 있습니다.

저와 함께 듀랑고의 흥하는 서버를 만들고 싶으신 분이나아이디어를 주고받고 싶으신 분은

이흥섭http://subl.ee/[email protected]

제게 연락주세요.이 QR코드 찍으시면 될 겁니다.

http://subl.ee/

mailto:[email protected]


이상 이흥섭이었습니다.감사합니다.

http://subl.ee/



http://subl.ee/


[야생의 땅: 듀랑고] 서버 아키텍처 vol. 2 (자막)

Software