Mais conteúdo relacionado Semelhante a [야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막) (20) [야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)1. <야생의 땅: 듀랑고>
서버 아키텍처 Vol. 2
넥슨 • 왓 스튜디오 • 이흥섭
TOC
#1 멀리 보기
서버 아키텍처 아웃라인
#2 들여다보기
부동산
신기루
전투 공방 합
#3 돌아보기
1, 2차 LBT 회고
2. <야생의 땅: 듀랑고>
서버 아키텍처 Vol. 2
넥슨 • 왓 스튜디오 • 이흥섭
TOC
#1 멀리 보기
서버 아키텍처 아웃라인
#2 들여다보기
부동산
신기루
전투 공방 합
#3 돌아보기
1, 2차 LBT 회고
안녕하세요. 재작년에 이어서 이번에도
<야생의 땅: 듀랑고> 서버 아키텍처를 주제로 발표하는
3. 이흥섭
넥슨 • 왓 스튜디오 • 서비스파트장
넥슨 왓 스튜디오의 서비스 파트장 이흥섭입니다.
반갑습니다.
4. 2011-2013 <카트라이더 대시 & 코인러시>
2013- <야생의 땅: 듀랑고>
저는 NDC가 처음 개방된 2011년에 넥슨에 합류해서
<카트라이더 대시 & 코인러시> 시리즈를 거쳐
9. 본격적인 발표에 앞서 저희 프로젝트를 먼저 소개해드릴게요.
저희가 만들고 있는 <야생의 땅: 듀랑고>는
12. 사냥, 채집, 건설 같은 플레이어의 행동 하나하나가
듀랑고 세계에 영구적인 변화를 남기게 되는 오픈월드 게임이죠.
13. A 서버군 B 서버군 단일 서버군
듀랑고 서버 아키텍처에는 마비노기 영웅전처럼
서버군 구분이 없습니다.
14. A 서버군 B 서버군 단일 서버군
게임을 시작하거나 접속할 때
자기가 속할 서버군을 고르지 않아도 되는 거죠.
18. 무한한 공간
영속적 세계
단일 채널
고 가용성
무한한 공간, 단일 채널, 영속적 세계, 고 가용성
같은 목표를 세우고 도전해오고 있습니다.
19. #1 멀리 보기
#2 들여다보기
#3 돌아보기
오늘 발표에선 듀랑고 서버 아키텍처가
저희의 목표를 어떻게 달성해왔고
20. #1 멀리 보기
#2 들여다보기
#3 돌아보기
또 어떤 결과를 내고 있는지
얘기하려고 합니다.
21. #1 멀리 보기
첫 번째로 저희 서버 구조가 어떻게 짜여져 있는지 멀리서
큰 윤곽부터 한 번 그려 볼게요.
27. 그 서버가 여러 백엔드 서버 중 한 대와 통신한 다음
결과를 내주는 구조입니다.
28. 여기서 백엔드 서버의 경우는 이중화돼있어서
한두 개 죽는다고 서비스에 장애를 초래하진 않습니다.
29. 반면 이중화 돼있지 않은 가운데 중계 서버에 장애가 발생하면
바로 서비스 장애로 이어지게 되죠.
32. 저희 서버는 여러 게임 서버 노드가 서로 통신하면서
유기적으로 협력하며 동작하는데요
35. ZeroMQ는 중계 장치 없이도 RabbitMQ나 Redis의 PUB/SUB같은
메시지큐 기능을 사용할 수 있게 해주는 라이브러리입니다.
36. 중계 장치가 없다 보니 각 노드는
서로가 서로의 주소를 자동으로 알아낼 수 있어야 하는데
38. 저희의 각 노드는 etcd를 통해서 자기 주소를 다른 노드에게 알리고
또 다른 노드의 주소를 모두 알아내서 서로 연결을 맺게 됩니다.
61. 한 노드가 전담하는 모든 객체들의 시야를 더한 영역이
바로 그 노드의 시야가 되는데
72. 모든 서버 노드가 유기적으로 협력해서
단 하나의 듀랑고 세계를 구축하도록 설계하고 있습니다.
75. #2 들여다보기
부동산 • 신기루 • 전투 공방 합
크게 세 가지 주제를 다룰 건데요
그 중 첫 번째 주제는 게임 세계의 부동산입니다.
81. 군도
개발을 진행하면서 대륙 처럼 거대한 섬 뿐만 아니라
그 밖에도 다양한 섬을 넘나들 수 있는 군도 모델로 선회하게 됐습니다.
83. 자원 ▼
면적 ▲
수명 ∞
안정섬
안정섬의 경우 좋은 자원이 나진 않지만
면적이 넓고 시간이 지나도 사라지지 않아서
90. 또 불안정섬의 경우는 사람이 너무 많으면
오히려 경쟁이 치열해져서 탐험하기 괴로워질 겁니다.
92. 하지만 섬 수가 고정 돼있다면 유입되는 플레이어의 수에 따른
인구밀도 변화에 대응할 수 없을 겁니다.
93. 사람 ∝ 섬
그래서 저희는 각 섬의 인구밀도를 적절하게 맞추고자
플레이어의 수에 맞춰서 섬 수가 자동으로 조절되게 만들었습니다.
94. 사람 ∝ 섬
가령 100명만 플레이할 때는 섬이 서너 개밖에 되지 않지만
10,000명이 플레이할 땐 수백 개의 섬도 생길 수 있는 거죠.
95. 7k 836
2차 LBT
지난 2차 LBT 때를 예로 들면 참여자는 약 7천 명 정도였는데요
그에 맞춰서 836개의 섬이 자동으로 생성돼서 공급됐었습니다.
104. 플레이어는 접속했을 때만 게임 세계에 속하니깐
서버는 수동적으로 그저 전달받은 아이디를 DB에서 찾기만 하면 되죠.
113. 16×16 타일 = 청크
그 다음 단위는
가로세로 16타일을 묶은 구역인 청크입니다.
115. 16×16 타일 = 청크
그러면서도 타일처럼 너무 작지도 않고 크기가 적당해서
여러가지 용도로 유용하게 쓰고 있습니다.
123. 만약 섬 전체를 하나의 땅문서로 관리하게 되면
다루기는 편하겠죠.
124. 하지만 섬 크기가 클 수록 색인하는 부담도 함께 커질 겁니다.
땅문서 하나가 객체 수백만 개를 색인한다고 생각해보세요.
146. Check and Set (CAS)
Couchbase는 CAS라는 이름으로
이런 버전 검사 기능을, 기본으로 제공합니다.
147. Check and Set (CAS)
그래서 쓰기 편하긴 한데
딱 한 레코드에 한한 트랜잭션만 보장해주기 때문에
152. ?!
만약 게임 서버가 트랜잭션 처리 없이
무턱대고 한 번에 여러 땅문서를 차례대로 수정하려고 하면
153. ?!
예기치 못 한 오류나 다른 스레드와의 경합이 발생했을 때
이렇게 불완전한 땅문서가 만들어질 수 있습니다.
175. 트랜잭션 문서에 적힌 내용을 바탕으로
애플리케이션에서 뒤늦게나마 수정사항을 마저 적용할 수 있습니다.
183. TX
설치 계획을 두 트랜잭션 문서에 나눠서 기록하면
여전히 트랜잭션을 보장할 수 없게 될 겁니다.
190. TX
가령 첫 번째 레코드는 성공적으로 수정했는데
두 번째 레코드에선 실패했을 경우에
196. TX
이렇게 신경 써야 할 예외 상황이 많아서
저는 BASE 트랜잭션이 다루기 까다로운 편이라고 생각합니다.
199. + 비관적 트랜잭션
이것도 원래는 비관적 동시성 제어 식 트랜잭션이라고 불러야 하지만
그냥 편의 상 이렇게 부를 게요.
204. 이 락엔 짧은 TTL이 설정돼 있어서 게임 서버 오류로 인해
제때 풀리지 않더라도 크게 문제가 되진 않습니다.
206. 이렇게 두 청크에 걸치는 정적 객체를 설치하고자 할 때
게임 서버가 땅문서를 어떻게 수정해 나가는지
208. 1. 청크 잠그기
TX
첫 번째 단계에선 우선 청크들에 락을 걸어서
다른 스레드가 해당 청크엔 트랜잭션을 등록하지 못 하게 합니다.
223. 1. 청크 잠그기
TX
첫 단계에서부터 오류가 나거나
아니면 다른 스레드가 청크 락을 잡고 있어서 잠그는 데 실패해도
232. #2 들여다보기
부동산 • 신기루 • 전투 공방 합
이어서 듀랑고 세계의 객체들이 언제 생성되고
또 언제 서버 메모리에 올라오는지 얘기해보겠습니다.
233. 섬은 그저 공간만 차지하는 게 아니라
수많은 객체들도 포함하고 있습니다.
247. LOD
Level of Detail
그림: http://polygon-reducer.pc-guru.cz/reducing-level-of-detail
컴퓨터 그래픽스 쪽 최적화 기법 중에
LOD라는 게 있습니다.
249. LOD
Level of Detail
그림: http://polygon-reducer.pc-guru.cz/reducing-level-of-detail
여기 판자 위에 있는
스탠포드버니들은 모두 똑같아 보이지만
261. 다시 신기루가 돼서 서버 자원을 아낄 수 있게 해줍니다.
접속자가 없으면 서버도 쉴 수 있도록 말이죠.
263. NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
그렇다고 섬 만들 때 자연물도 같이 만들어서
일일이 DB에 저장한다면
264. NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
NEW NEW NEW NEW NEW NEW
섬 만드는 속도가 느려져서
필요에 따라 섬을 실시간으로 늘리기 어려워질 겁니다.
265. 시설물 같은 경우는 재료에 따라 생김새가 달라져서
신기루에 담아야 되는 정보도 많은 편인데요
266. 78 27 12 63
반면 자연물은 생김새가 판에 박혀있어서
그냥 숫자 하나만으로도 표현할 수 있습니다.
267. 0 12 27
78
63 78 12
27 78
이 점을 활용해서 저희는 섬의 최초 자연물 배치를
단순한 숫자맵 파일로 만들어서 지형 데이터에 포함시켰습니다.
269. 0 12 27
78
63 78 12
27 78
NEW
그런 경우 서버는 땅문서 대신
자연물 배치 파일을 읽어서 신기루 자연물로 보여줍니다.
272. 0 12 27
78
63 78 12
27 78
서버도 그 다음부턴 자연물 배치 파일 대신
DB에 있는 땅문서를 참조하게 됩니다.
275. 동물에는 고수준 AI가 돌아가서 성능을 많이 잡아먹기 때문에
서버에서 특히 효율적으로 관리해야 합니다.
276. 동물에는 아까 보신 <GTA5>의 NPC처럼
플레이어와의 거리에 반응하는 LOD를 적용했습니다.
278. 어디에 어떤 종이 몇 마리 있고
마지막엔 뭘 하고 있었는지 같은 정보가 저장돼있죠.
289. <야생의 땅: 듀랑고>
중앙 서버 없는 게임 로직
최호영 • 14:10 • GBI
오늘 오후 2시 10분에 저희 스튜디오 최호영 님 발표에서
방금 소개해드린 신기루나 부동산을 게임로직에서 실제로 다룬 사례를 소개합니다.
290. <야생의 땅: 듀랑고>
중앙 서버 없는 게임 로직
최호영 • 14:10 • GBI
제가 슥 넘긴 시설물의 신기루도
이쪽에서 자세히 다룰 거고요
291. <야생의 땅: 듀랑고>
중앙 서버 없는 게임 로직
최호영 • 14:10 • GBI
또한 중앙 서버가 없는 환경에서
게임 로직을 만드는 데 있어서 어떤 어려움이 있었고
293. <야생의 땅: 듀랑고>
중앙 서버 없는 게임 로직
최호영 • 14:10 • GBI
저희 서버 아키텍처에 관심 있는 분들께선
이어서 들으시면 좋을 것 같습니다.
302. 저희는 공방 합이 재밌는 전투를 만드는 데 있어서
굉장히 중요한 요소라고 생각했습니다.
316. ①
이렇게 짠 공방 계획을 패킷 하나로 묶어서 클라이언트로 보낸다면
연출에서도 공방 합을 맞출 수 있을 겁니다만
321. ①
②
노드 간 통신 속도가 빠를 땐 별 문제가 생기지 않는데
통신이 느려지거나 동물원에 과부하가 걸리게 되면
324. 규모, 가용성 합의
분산 아키텍처
저희가 설계한 분산 서버 아키텍처로
처리 규모와 가용성을 높일 순 있었지만
325. 규모, 가용성 합의
분산 아키텍처
여러 서버 노드 사이에 합의가 필요한 경우엔
간단한 일이라도 콜로세움 같은 우회책을 마련할 필요가 있었습니다.
326. 규모, 가용성 합의
분산 아키텍처
저희는 이점을 듀랑고 세계를 무한히 넓게 만들기 위한
일종의 트레이드오프로 인식하고 있고요
328. <야생의 땅: 듀랑고>의
거친 환경에서 살아가는 동물 AI
박동일 • 15:20 • GBI
콜로세움 전투를 비롯해 듀랑고의 동물에 관한
더 자세한 이야기는
329. <야생의 땅: 듀랑고>의
거친 환경에서 살아가는 동물 AI
박동일 • 15:20 • GBI
오늘 오후 3시 20분 박동일 님 발표에서 들으실 수 있으니까요
이쪽에도 많은 참관 부탁드립니다.
330. 지금까지 저희 게임 서버가
듀랑고라는 게임을 어떻게 구현하고 있는지 살펴봤습니다.
336. #3 돌아보기
이번엔 그 중 지난 두 차례의 LBT를 진행하면서
저희가 겪은 주요 문제 두 가지를 꼽아봤습니다.
344. 섬 면적이 좁다 보니 플레이어가 한두 명만 돌아다녀도
대부분의 동물이 깨어나게 됩니다.
345. 그러다 보니 동물원 노드에도 부하가 생기고
프론트엔드에도 동기화 부담이 가중됐었습니다.
347. 이번에 저희가 설정한 인구밀도로는
동시 접속자에 비해 동물의 수가 지나치게 많아졌었습니다.
366. 아울러 저희 왓 스튜디오에선
함께 교류할 훌륭한 인재를 찾아다니고 있습니다.
367. 저와 함께 듀랑고의 흥하는 서버를 만들고 싶으신 분이나
아이디어를 주고받고 싶으신 분은