본문 바로가기

ETC/Server

Multi play game의 server 형태와 그 특징

비동기형 Multi play Game


Web browser 기반의 PC game이나 초창기 mobile game에서 많이 볼수 있는 server로서

Puzzle game이나 farm game 처럼 player사이의 직접적인 상호작용이 거의 없거나 상호작용이 있다고 하더라도

실시간으로 player의 상태를 동기화 할 필요가 없는 game에서 많이 사용된다.


예를들어 상대방과 같은 시점에 동시에 play하지 않아도 되고, 상대방의 data역시 항상 최근의 상태를 반영하지 않아도

상호작용이 가능한 약한 multi play요소를 가지고 있는 게임들



Request-Reply 기반의 message 교환


Server는 client의 request를 처리하고 처리 결과를 client에게 돌려주는 방식으로 구현한다.

Message는 client에서 server로 단방향으로 이루어지기 때문에 client는 request를 보낼때를 제외하면

server와의 연결을 유지하지 않는다.


이러한 특성은 network 연결이 빈번하게 끊기고 data 전송 비용이 비싼 이동통신 환경에 적합하고

Server에 문제가 생기더라도 현재 처리중인 request만 실패할 뿐 Reconnect나 forced shutdown과 같은 문제에서 자유롭다.



Stateless Server

Server는 user의 data state를 유지하지 않고 새로운 request가 들어올 떄마다 data를 read해서 requset를 처리한다.

이러한 특성은 연속적인 request들을 같은 server가 아닌, 다른 server에서 처리할 수 있다는 장점이 존재한다.



Server Expansion(확장)이 용이함


Client가 Server와의 network connection을 유지하지 않고 request가 있을때 마다 연결을 하고, 이전에 어느 server와 연결했는지

상관이 없기 때문에 server expansion와 관리가 용이하다.


Load balancer(L4)와 같은 network 장비를 gateway로 두면 load balancer의 설정을 동적으로 변경하는 것으로

실제 request를 처리하는 server로의 접속을 통제할 수 있기 때문에 server를 expansion하거나 축소하는것이 용이하다.




Load Balancer : Load Balancing을 처리해주는 것, 종류(L2, L3, L4)

Load Balancing(부하분산) : 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는것



단점


Client의 request 없이는 server의 event를 전달할 수 없다.


client는 server와 connection을 유지하지 않기 때문에 server에서 발생한 event를 받을 수 없다.

이것을 극복하기 위해 Long Polling(롱폴링)이나 Wesocket(웹소켓)같은 기술을 사용하기도 한다.


Game DB 부하가 생각보다 크다.


Player간 상호작용뿐만 아니라 user의 request를 처리하기 위한 사소한 data까지도 DB로 가져와야 하기때문에

다루는 data의 크기도 크고 접근자체도 빈번한 편이다.


그렇기 때문에 DB부하를 분산할 수 있는 data cache node가 반드시 필요하다.


또한 Game service의 특성상 일반적인 web service들에 비해서 DB에 대한 write request가 빈번하기 떄문에

write 부하를 분산시킬 수 있는 Sharding과 같은 방법을 고려해야 한다.


Message size가 커질 수 있다.


Web Service에서 사용하는 것처럼 json이나 xml같은 text base로 data를 주고받는 경우에는 data size가 커질수도 있다.

binary data로 변환해서 송/수신하거나 꼭 필요한 data만 주고받도록 신경써야 할 부분이다.


비동기형 muti play game의 server 구조


다음에 설명할 두가지 game server 형태는 client와 server 사이에 connection을 유지하는 기본적인 공통점이 있다.

언제든지 server로부터 message를 받아서 처리할 수 있기 떄문에 player 사이의 상호작용이나 server에서 발생하는

event를 즉시 전달받을 수 있는 특징이 있다.





MO형 Multi Play Game


비동기형 multi play game의 한계를 벗어나 실시간으로 다른 player와 상호작용할 수 있는 game의 한 형태로 제한적으로

동기형 muti play요소를 도입한 game이 나오게 되는데 PC의 디아블로시리즈, 오버워치, 배틀그라운드나 

Mobile game 히트같은 게임들이 여기에 해당된다.


Mobile의 경우 network특성상의 한게로 RPG의 경우에도 동기형 multi play요소는 배제하는 경우가 많았으나

network기술이 발전함에 따라 동기형 multi play 요소를 접목하기 시작했다.


이런 장르의 game들은 일시적으로 생성/소멸하는 game room을 중심으로 game을 play하고 이 결과를 반영하여

랭킹을 비교하거나 player를 성장시켜 나가는 것이 game의 기본적인 흐름이다.



빈번하게 생성/소멸 하는 game room을 중심으로 play


MO형 multi play game의 가장 큰 특징은  가상의 room 단위로 game이 진행되며 game system에 의해서 player들이 모여

game room을 만들어서 play하고 game이 끝나면 다시 흩어진다는 점이다.


비동기형 multi play game과는 다르게 game room에서는 player간 실시간 상호작용이 일어나기 때문에 Lock-Step algorithm이나 

Server 동기화 같은 player사이의 data 동기화에 대해 고민이 필요하다.


game room 외 기능을 담당하는 server가 필요하다.


실제 game에 진입하기 전까지 대기하면서 상태를 관리할 수 있는 lobby server가 필요하다.

player는 lobby와 game room사이를 빈번하게 이동하면서 game을 play하게 되며, lobby server는 많은 수의 client를 수용할 수 있도록 하기 위해

match making이나 인증, 채팅, 링캥과 같은 기능은 별도로 server로 분리하거나 비동기형 multi play에서 설명했던 web service로 구현하기도 한다.


MO형 multi play game server 구조





MMO형 Multi Play Game


Game room 내에서 제한적으로 play하는 MO형 multi play game과 달리 거대한 월드를 무대로 수많은 player들과의 상호작용을 통해서

game을 진행하는방식, 이런종류의 game들의 특징은 player가 game에 접속해서 화면에 다른 player가 나타나는 순간부터 player간 상호작용이

일어난다는 것 이다.



월드 / 지역 server를 중심으로 player들이 상호작용


Game을 구성하는 world도 광범위 하고 player의 수도 많기 때문에 작은 local로 나누고 각 지역을 담당하는 server들로 구성한다.

player는 자신이 위치한 지역 server에 있는 player를 화면에 표시하는 것 만으로도 상호작용이 일어나기 때문에 

지역에 지역 내 player data 동기화를 위해서 broad cast message가 매우 많은 것이 특징이다.


또한 player는 지속적으로 이동하면서 지역 server들 사이를 이동하기 때문에 player가 지역을 이동할 때 자연스럽게 처리하기 위해서

server 사이에 player data를 전달하기 위한 방법도 고민해야 한다.


Stateful Server


Server는 player가 game을 진행중일때 그 data를 항상 유지하고 있어야 하기 때문에 Stateful server 특성을 갖고 있다.

대신 server에 문제가 생길 경우 해덩 server에 있던 모든 유저들은 튕긴다.


DB에 대한 부하가 크다.


앞에서 언급했던 모든 server유형을 통틀어 DB에 대한 부담이 크다.

Server가 loading한 player data를 caching하고 있다고 하더라도 player 개개인의 해동과 함께 player사이의 상호작용으로

인한 작은 state 변화도 저장해야 하기 때문에 write 부하가 상당하다.


Player Data 관리의 중요성


MMO형 Multi Play Game에서 player data의 변화는 하나의 행동이 아니고 여러 행동의 복합적인 결과로 나타나는 경우가 많은데

이 과정에서 data가 유실되거나 정합성이 깨지는 경우가 발생할 수 있다.


이럴경우 item 복사를 비롯해서 각종 비정상 행위들이 발생하게 되고 최악의 경우 server data를 rollback해야 하는 결과를 초래할 수도 있다.


MMO형 Multi Play Game Server 구조








최근에는 MO형 Multi player game이지만 mobile의 이동성을 살리기 위해서 loby는 비동기형 multi play game의 stateless server로 구현하고

math 또는 전투 부분만 동기형 game server로 구현하거나 MMO형 multi play game에서 던전과 같은 특정 지역을 room처럼 만들어서

필요할 떄 마다 생성/삭제 하는것처럼 복합적으로 구현하는 경우가 많다.









참고


https://blog.ifunfactory.com/2018/05/31/%EA%B8%B0%EC%88%A0%EC%BB%AC%EB%9F%BC-%EB%A9%80%ED%8B%B0-%ED%94%8C%EB%A0%88%EC%9D%B4%EA%B2%8C%EC%9E%84%EC%9D%98-%EC%84%9C%EB%B2%84-%ED%98%95%ED%83%9C%EC%99%80-%EA%B7%B8-%ED%8A%B9%EC%A7%95%EC%97%90/




Load Balance


https://nesoy.github.io/articles/2018-06/Load-Balancer


https://medium.com/@pakss328/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C%EB%9E%80-l4-l7-501fd904cf05


http://blog.naver.com/PostView.nhn?blogId=ethan_jin&logNo=120187279110



'ETC > Server' 카테고리의 다른 글

HTTP / FTP / Socket  (0) 2019.03.11
Dedicated Server / P2P Server / Listen Server  (0) 2019.03.07
Network Transport / RPC  (0) 2019.03.05
IOCP  (0) 2019.03.01
Get방식과 Post방식  (0) 2019.02.26