[기술컬럼] 멀티 플레이게임의 서버 형태와 그 특징에 대해서

최근에는 모바일 게임에서조차 빼놓을 수 없는 것이 멀티플레이 요소인데요, 서로의 랭킹을 확인하는 기초적인 멀티플레이부터 상대방의 캐릭터를 실시간으로 때려 눕히는 대전플레이에 이르기까지 정도의 차이는 있지만 정교한 멀티플레이를 구현하기 위해서 게임 서버의 형태는 계속해서 변화하고 있습니다.

새로운 형태가 나오기도 하고, 이제는 거의 사용하지 않는 형태도 있지만, 현재 많이 사용는 대표적인 게임서버 형태를 게임의 장르적 특성에 따라서 나눠보고 그 특징에 대해서 알아보겠습니다.

  1. 비동기형 멀티플레이 게임

가장 먼저 알아볼 서버의 형태는 웹브라우저 기반의 PC게임이나 초기 모바일게임에서 많이 볼 수 있는 비동기형 게임 서버입니다.

퍼즐 게임이나 팜(Farm)류 게임처럼 플레이어 사이의 직접적인 상호작용이 거의 없거나 상호작용이 있다고 하더라도 실시간으로 플레이어의 상태를 동기화 할 필요가 없는 게임들에서 많이 사용합니다.

예를 들어, 플레이어의 게임 점수나 레벨 등을 기준으로 랭킹을 겨루거나, 다른 플레이어의 농장을 방문해서 도움을 주는 것과 같은 컨텐츠는 분명 멀티플레이 요소이기는 하지만, 상대방과 같은 시점에 동시에 플레이 하지 않아도 되고, 상대방의 데이터 역시 항상 최근의 상태를 반영하지 않아도 상호 작용이 가능한 약한 멀티플레이 요소를 가지고 있다고 볼 수 있겠습니다.

이런 형태의 게임 서버는 웹 서비스와 유사하게 구현하기도 하는데 다음과 같은 특징이 있습니다.

* Request-Reply 기반의 메시지 교환

서버는 클라이언트의 요청을 처리하고, 처리 결과를 클라이언트에 돌려주는 방식으로 구현합니다.

메시지는 클라이언트에서 서버로 단방향으로 이루어지기 때문에 클라이언트는 요청을 보낼 때를 제외하면 서버와의 연결을 유지하지 않습니다.

이러한 특성은 네트워크 연결이 빈번하게 끊기고 데이터 전송 비용이 비싼 이동통신 환경에 적합하고, 설령 서버에 문제가 생기더라도 현재 처리 중인 요청만 실패할 뿐 재연결이나 강제 종료와 같은 문제에서 자유롭습니다.

* Stateless 서버

서버는 사용자의 데이터 상태를 유지하지 않고, 새로운 요청이 들어올 때마다 데이터를 읽어와서 요청을 처리합니다.

이런 특성은 연속적인 요청들을 같은 서버가 아니고, 다른 서버들에서 처리할 수 있다는 이점이 있습니다.

* 서버 확장이 용이함

클라이언트가 서버와의 네트워크 연결을 유지하지 않고 요청이 있을 때마다 연결을 맺고, 이전에 어느 서버에 연결했었는지 상관이 없기 때문에 서버 확장 및 관리가 용이한 면이 있습니다.

로드밸런서(L4)와 같은 네트워크 장비를 게이트웨이로 두면 로드밸런서의 설정을 동적으로 변경하는 것으로 실제 요청을 처리하는 서버로의 접속을 통제할 수 있기 때문에 서버를 증설하거나 축소하는 것이 용이합니다.

* 다양한 개발 언어와 공개 프로젝트 사용가능

웹 서비스 기술은 인터넷 서비스 중 가장 오래됐으며, 가장 많이 사용하는 기술입니다. 그리고, 그 한계를 극복하기 위해서 많은 발전을 거듭 해 왔는데요, 이런 다양한 개발 환경이나 기술을 자신이나 팀의 상황에 맞게 유연하게 적용할 수 있다는 점도 장점이 될 수 있습니다.

결론적으로 웹 서비스를 응용해서 게임서버를 구현하는 방식인데, 구현이 상대적으로 간단하고, 이동이 잦은 모바일 기기의 특성과 잘 맞아서 초기 모바일 게임 서버에서 많이 볼 수 있는 형태입니다.

반면, 단점이나 주의해야 할 점도 있는데요,

* 클라이언트 요청 없이는 서버의 이벤트를 전달 할 수 없음.

클라이언트는 서버와 연결을 유지하지 않기 때문에 서버 쪽에서 발생한 이벤트를 받을 수 없습니다.
이런 단점을 극복하기 위해서 롱폴링(Long polling)이나 웹소켓(Websocket)같은 기술들을 사용하기도 합니다.

* 게임은 DB 부하가 생각보다 크다.

기본적으로 플레이어 간 상호작용 뿐 아니라, 사용자의 요청을 처리하기 위한 사소한 데이터까지도 DB로부터 가져와야 하기 때문에  다루는 데이터의 크기도 크고, 접근 자체도 빈번한 편입니다.

그렇기 때문에 DB부하를 분산할 수 있는 데이터 캐시 노드가 반드시 필요합니다.

또 게임 서비스의 특성상 일반적인 웹 서비스들에 비해서 DB에 대한 쓰기 요청이 빈번하기 때문에 쓰기 부하를 분산시킬 수 있는 샤딩(Sharding)과 같은 방법을 고려해야 합니다.

* 메시지 크기가 커질 수 있다.

웹 서비스에서 많이 사용하는 것처럼 json이나 xml과 같은 텍스트 기반으로 데이터를 주고 받는 경우에는 데이터 크기가 커질 수 있는 점도 주의해야 합니다.

바이너리로 데이터로 변환해서 송/수신 하거나, 꼭 필요한 데이터만 주고 받도록 신경 써야 할 부분입니다.

1그림 1. 비동기형 멀티플레이 게임의 서버 구조

다음에 설명할 두가지 게임 서버 형태는 클라이언트와 서버 사이에 연결을 유지하는 기본적인 공통점이 있습니다. 언제든지 서버로부터 메시지를 받아서 처리할 수 있기 때문에 플레이어 사이의 상호 작용이나 서버에서 발생하는 이벤트를 즉시 전달 받을 수 있는 특징이 있습니다.

  1. MO형 멀티플레이 게임

비동기형 멀티플레이 게임의 한계를 벗어나 실시간으로 다른 플레이어와 상호작용할 수 있는 게임의 한 형태로 제한적으로 동기형 멀티플레이 요소를 도입한 게임이 나오게 되는데, PC의 디아블로 시리즈, 오버워치, 배틀그라운드나 모바일의 히트 같은 게임들이 여기에 해당합니다.

모바일의 경우, 네트워크 특성 상의 한계로 RPG의 경우에도 동기형 멀티플레이 요소는 배제하는 경우가 많았습니다만, 네트워크 기술이 발전하고 데이터 통신 비용이 내려가면서 동기형 멀티플레이 요소를 접목하기 시작했습니다.

이런 장르의 게임들은 일시적으로 생성/소멸하는 게임 룸을 중심으로 게임을 플레이하고, 이 결과를 반영하여 랭킹을 비교하거나, 플레이어를 성장시켜 나가는 것이 게임의 기본적인 흐름입니다.

* 빈번하게 생성/소멸하는 게임 룸을 중심으로 플레이

MO형 멀티플레이 게임의 가장 큰 특징은 가상의 룸 단위로 게임이 진행되며, 게임 시스템에 의해서 플레이어들이 모여서 게임 룸을 만들어서  만들어서 플레이하고, 게임이 끝나면 다시 흩어진다는 점입니다.

비동기형 멀티 플레이 게임과는 다르게 게임 룸에서는 플레이어 간 실시간 상호작용이 일어나기 때문에 락-스텝(Lock-step)이나 서버 동기화 같은 플레이어 사이의 데이터 동기화에 대해서 고민이 필요합니다.

* 게임 룸 외 기능을 담당하는 서버가 필요

실제 게임에 진입하기 전까지 대기하면서 상태를 관리할 수 있는 로비 서버가 필요합니다.

플레이어는 로비와 게임 룸 사이를 빈번하게 이동하면서 게임을 플레이하게 되며, 로비 서버는 많은 수의 클라이언트를 수용할 수 있도록 하기 위해서 매치메이킹이나 인증, 채팅, 랭킹과 같은 기능은 별도 서버로 분리하거나, 비동기형 멀티플레이에서 설명했던 웹 서비스로 구현하기도 합니다.

2그림2. MO형 멀티플레이 게임 서버 구조

  1. MMO형 멀티플레이 게임

게임 룸 내에서 제한적으로 플레이하는 MO형 멀티플레이 게임과 달리 거대한 월드를 무대로 수많은 플레이어들과의 상호작용을 통해서 게임을 진행하는 게임들이 있는데요, 이런 종류의 게임들의 특징은 플레이어가 게임에 접속해서 화면에 다른 플레이어가 나타나는 순간부터 플레이어 간 상호작용이 일어난다는 점입니다.

바람의 나라를 시작으로 리니지, 월드오브워크래프트(WOW)와 같이 우리들이 익히 알고 있는 많은 게임들이 있습니다.

* 월드 /지역 서버를 중심으로 플레이어들이 상호작용

게임을 구성하는 월드도 광범위하고, 플레이어의 수도 많기 때문에 작은 지역으로 나누고, 각 지역을 담당하는 서버들로 구성합니다.

플레이어는 자신이 위치한 지역 서버에 있는 플레이어를 화면에 표시하는 것만으로도 상호작용이 일어나기 때문에 지역 내 플레이어 데이터 동기화를 위해서 브로드 캐스트 메시지가 매우 많은 것이 특징입니다.

또, 플레이어는 지속적으로 이동하면서 지역 서버들 사이를 이동하기 때문에 플레이어가 지역을 이동할 때 자연스럽게 처리하기 위해서 서버 사이에 플레이어 데이터를 전달하기 위한 방법도 고민해야 합니다.

* Stateful 서버

서버는 플레이어가 게임을 진행 중일 때, 그 데이터를 항상 유지하고 있어야 하기 때문에 Stateful 서버 특성을 갖고 있습니다.
대신, 서버에 문제가 생길 경우 해당 서버에 있던 모든 유저들은 ‘팅김’ 현상을 겪게 됩니다.

* DB 에 대한 부하가 큼

앞서 언급했던 모든 서버 유형을 통틀어서 DB에 대한 부담이 크다고 볼 수 있는데, 서버가 로딩한 플레이어 데이터를 캐싱하고 있다고 하더라도 플레이어 개개인의 행동과 함께 플레이어 사이의 상호작용으로 인한 작은 상태 변화도 저장해야 하기 때문에 쓰기 부하가 상당합니다.

* 플레이어 데이터 관리의 중요성

MMO형 멀티플레이 게임에서 플레이어 데이터의 변화는 하나의 행동이 아니고, 여러 행동의 복합적인 결과로 나타나는 경우가 많은데 이 과정에서 데이터가 유실되거나 정합성이 깨지는 경우가 발생할 수 있습니다.

이럴 경우 아이템 복사를 비롯해서 각종 비정상 행위들이 발생하게 되고, 최악의 경우 서버 데이터를 이전 시점으로 되돌려야하는 결과를 초래할 수도 있습니다.

3그림3. MMO형 멀티플레이 게임 서버 구조

이상으로 게임의 장르적 특성에 따른 서버 구성 방식과 그 특징에 대해서 알아봤습니다.

각 서버 형태의 실제 구현에 대해서는 다른 글을 통해서 찾아 뵐 계획을 가지고 있습니다.

최근의 게임들은 규모가 커지면서 장르적 특성에 대한 경계를 허물고 게임 내 컨텐츠의 특성에 맞게 서버를 구성하는 경우가 많습니다.

예를 들어 MO형 멀티플레이 게임이지만, 모바일의 이동성을 살리기 위해서 로비는 비동기형 멀티플레이 게임의 Stateless 서버로로 구현하고, 매치 또는 전투 부분만 동기형 게임 서버로 구현하거나 MMO형 멀리플레이 게임에서 던전과 같은 특정 지역을 룸처럼 만들어서 필요할 때마다 생성/삭제하는 것처럼 복합적으로 구현하는 경우가 많습니다만, 전체 게임 서버를 기능 별로 나눠 보면 설명 드린 범주에서 크게 벗어나지 않을 것입니다.

 

아이펀팩토리 이재원 테크니컬 디렉터 

 

답글 남기기

댓글을 게시하려면 다음의 방법 중 하나를 사용하여 로그인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중