게임 서버의 구조 #

참고> 이 글은 한빛 네트워크 에서 퍼왔음을 알려드립니다.

남재욱
(주)지스퀘어 3D 캐주얼 게임 서버 프로그래머

온라인 게임에서 실질적인 게임을 진행시켜주는 것이 게임 서버이다. 우리는 게임 서버의 구조는 게임의 진행과 시스템의 효율성에 많은 영향을 미치는 부분이다. 물리적으로 한정적인 시스템 자원을 효율적으로 사용하기 위해서 다양한 분산 처리는 필수적인 요소이다. 분산 처리 구조를 익힘으로써 우리는 좀 더 세련되고 뛰어난 성능을 발휘할 수 있는 게임 서버를 만들 수 있다. 온라인 게임 서버 프로그래밍의 핵심인 게임 서버의 구조에 대해 알아 보도록 하자.

일반적인 게임 서버 구조 #

게임 서버는 실질적인 게임을 진행하는 역할을 담당한다. 게임 서버는 유저간의 동기화, NPC 의 인공지능, 아이템 시스템 등 게임 시스템의 총 집합이라 할 수 있다. 게임 진행에 필요한 모든 게임의 요소들을 총괄하여 진행시켜주는 작업을 하기 때문에 가장 많은 일을 담당한다. 게임을 진행하는 요소는 방대하기 때문에 하나의 서버에서 처리하는데는 많은 부담이 된다.

게임 서버를 제작하고 테스트를 하는 과정에서 수십명의 유저를 처리하는 것은 그리 문제가 되지 않는다. 더욱이 하드웨어의 눈부신 발전에 힘입어 게임에서도 고성능 서버를 사용하기 시작하면서 서버쪽의 부담이 덜어져 가는 것도 사실이다. 하지만 접속 유저가 늘어나면서 서버쪽에서 느끼는 부하는 그 수치가 급격하게 증가한다. 그렇기 때문에 서버를 제작하면서 게임 서버의 부하를 분산시키려는 노력이 필요하다.

NPC 서버의 분리 #

구성에 따라 게임 서버에 많은 부하를 줄 수 있는 것이 NPC 의 인공지능 부분이다. 보통 게임에서 NPC 의 인공지능은 상당히 단순하게 느껴진다. 하지만 수많은 NPC 의 인공지능을 구성하는 코드는 상당히 복잡하며 처리량도 만만치가 않다. 따라서 <그림 1> 과 같이 NPC 의 인공지능 부분을 따로 분리하여 게임 서버에서 부하를 줄이게 된다.

<그림 1> NPC 서버의 분리

NPC 서버와 게임 서버가 분리되면 게임 서버에서는 NPC 오브젝트만 생성하게 된다. NPC 서버에서는 게임 서버에서 생성된 NPC 오브젝트의 인공지능을 처리한다. NPC 서버에서는 인공지능 부분만 처리하여 게임 서버에 있는 NPC 오브젝트에게 소켓 통신 등을 이용하여 명령한다. 게임 서버 입장에서는 소켓 통신을 하는 비용은 지불하게 되지만 많은 서버 리소스를 절약하는 효과를 볼 수 있다. 또한 NPC 서버에서는 인공지능 부분을 전담하기 때문에 더욱 복잡하고 똑똑한 인공지능을 만들어 낼 수도 있다. 사실 게임 서버에 인공지능 부분까지 처리하게 되고, 처리할 NPC 의 숫자도 많다면 복잡하고 세련된 인공지능은 서버에 많은 부담을 주게 될 것이다.

온라인 게임을 하다보면 서버가 다운되어 다시 접속을 하였는데 NPC 들이 필드에서 하나도 없는 경우를 몇몇 게임에서 발견할 수 있다. 이러한 상황은 NPC 서버와 게임 서버간의 동기화가 안된 상황에서 클라이언트가 게임 서버에 접속하였을 때 발생하는 현상이다. 이런 경우 잠시만 기다리면 갑자기 NPC 들이 생겨나는 것을 볼 수 있을 것이다.

NPC란? Non-Player Characters 의 약자이다. 게임에서 유저 캐릭터가 아닌 서버에 의해
조종되는 캐릭터를 총칭하는 말이다. 온라인 게임에서는 보통 상점주인, 경비병, 몬스터
등이 이에 속한다.

동기화 서버의 분리 #

게임 서버에서 제일 기초적인 동작은 캐릭터간의 동기화 작업이다. 동기화 작업은 게임 서버가 시작되고 유저들이 접속하면서 부터 처리하게 된다. 동기화 작업은 제한된 공간에서 유저들의 행동을 상호간에 인지시키게 하기 위한 작업이다. 유저들의 행동을 상호간에 인식시키기 위해서는 모든 캐릭터의 행동을 근처의 모든 캐릭터들에게 알려 주어야 하기 때문에 많은 부하를 발생시킨다. 따라서 동기화 작업만을 전담하는 서버를 분리하여 준다면 게임서버의 퍼포먼스를 향상시킬 수 있다. PC / NPC 간의 동기화 작업은 각각의 오브젝트 단위로 이루어지기 때문에 동기화 서버를 따로 두어 캐릭터들의 동기화 부분만 전담시켜 부하를 분산시키는 구조를 택할 수 있다.

<그림 2> 동기화 서버의 분리

동기화 서버는 NPC 와 PC 의 동기화 작업만 전담한다. 게임 서버에서 클라이언트의 움직임 등의 요청을 받는다면 동기화 서버로 명령을 전달하게 되고 동기화 서버에서는 명령에 따른 결과를 게임 서버에 전달하게 되어 게임 서버에서는 결과를 각색하여 클라이언트로 전달하게 된다. 동기화 서버가 분리되는 방식은 게임 서버가 해야할 일을 물리적으로 다른 서버와 분담하여 처리하는 방식이기 때문에 많은 유저가 접속하였더라도 서버의 성능을 일정하게 유지시켜줄 수 있는 구조이다.

채팅 서버의 분리 #

MMORPG 는 다른 측면에서 보았을 때 커뮤니티의 일종으로서 유저 상호간 액션에 의해 게임이 진행된다. 커뮤니티에서 빠질수 없는 것이 의사 소통이며, 게임에서는 채팅을 통해 상호간의 의사전달을 하게 된다. 따라서 게임 서버에서는 유저들의 많은 양의 채팅 메시지를 처리하게 된다. 또한 채팅 메시지는 유저간의 동기화 문제와도 연관되어 많은 부하를 발생시킬 수도 있기 때문에 채팅 서버만을 따로 두어 게임 서버의 부하를 분산시키기도 한다.

<그림 3> 채팅 서버의 분리

채팅 서버를 분리하게 되면 대부분 클라이언트와 채팅 서버간의 1:1 통신을 하게 된다. 즉, 클라이언트는 게임 서버와 채팅 서버에 각각의 연결을 만들어 통신을 하게 된다는 것이다. 따라서 게임 서버에서 클라이언트의 PC 가 동기화 영역을 움직인다면 채팅 서버에서도 마찬가지로 해당 채팅 동기화 영역으로 움직여 채팅 메세지 동기화를 하게 된다. 게임 서버에서 할 일이 분산되기 때문에 좀 더 안정적인 게임 서버를 만들수 있게 되지만 채팅 서버에서도 캐릭터의 이동에 따른 기본적인 동기화 작업이 필요하기 때문에 채팅 메세지를 게임 서버에서 처리 하는것보다 좀더 많은 작업량이 필요하게 된다.

참고> 서버 기능 분리시 주의사항
서버를 분리하는데에는 많은 사항을 고려해야 한다. 서버의 기능을 나누어 부하를 분산시키는
것은 좋지만 서버를 나누어서 새롭게 생겨날 수 있는 취약점이나 또 다른 부하를 고려해야 하기
때문이다. 예를 들어 NPC 서버가 분리된다면 게임 서버와 NPC 서버간의 동기화, NPC 서버와
게임 서버간의 통신으로 인한 네트워크 오버헤드를 고려해야 한다.
동기화 서버가 분리되면 역시 동기화 서버와 게임 서버간의 통신으로 인한 네트워크 오버헤드와
게임서버와 동기화 서버의 권한을 명확히 해야 한다. 채팅 서버가 분리 된다면 채팅 서버와 게임
서버간의 동기화 문제를 고려해야 한다.

분산 게임 서버의 구조 #

서버 프로그래밍을 하다 보면 분산 서버 또는 클러스터링에 많은 관심을 갖게 된다. 그 이유는 온라인 게임 서버 프로그래머라면 누구라도 기술적 한계를 뛰어넘어 수만에서 수십만명이 하나의 월드에서 자유롭게 게임을 즐기는 환경을 만들어 주는 것을 바라기 때문이다.

현재 국내 온라인 게임을 살펴보면 월드에는 일정한, 내부에서 정하는 유저 제한치가 존재하게 되며 이러한 제한치가 넘어가게 되면 더이상의 유저를 수용하기 보다는 다른 서버군을 오픈하여 유저의 이동을 권하게 하는게 대부분이다.

일반적으로 서버군에 따라 각각 물리적으로 분리된 데이터베이스를 사용하게 된다. 때문에 서버군을 이동하게 되면 데이터베이스가 바뀌기 때문에 개발사에 따라 기존의 캐릭터를 그대로 옮겨 갈 수도 있거나 아니면 새로 만들어야 하는 문제가 생기곤 한다. 개발사에서는 새로 오픈하게 되는 서버군에서 캐릭터들의 형평성을 위해 특별한 이유가 없는한 이전에 사용하던 캐릭터를 다른 서버군으로 옮기지 못하게 한다. 대부분의 온라인 게임이 이러한 구조를 택하고 있고, 하나의 캐릭터가 서로 다른 서버군을 옮겨 다니며 게임을 할 수 있게 만든다는 것은 분명 쉬운 일이 아니다.

질문 : 통합된 월드의 게임 서버를 만드는데 가장 문제가 되는 것은 무엇인가?

답 : 첫번째는 통합된 월드내 수많은 유저의 정보를 실시간으로 저장할 수 있는 데이터베이스가 가장 문제가 된다. 서버군의 유저수를 통제하는 것도 데이터베이스의 문제가 주요인이다. 그 이유는 데이터베이스가 실시간으로 동시에 처리할 수 있는 능력은 시스템에 따라 한계치가 있기 때문이다. 두번째는 데이터베이스의 부하를 분산하기 위해 replication 기능을 생각해 볼 수도 있다. 하지만 replication 기능도 상황에 따라 한쪽 데이터베이스에서 오류가 발생할 경우 처리 문제는 상당히 까다롭다. 실시간으로 오류 발생 즉시 다른 한쪽으로 데이터베이스 커넥션을 바꾸어야 하는데 이또한 임시적인 방책이지 해결책은 될 수가 없다. 부하가 심해 오류가 발생되었다고 오류가 없는 데이터베이스로 커넥션을 옮긴다면 한쪽으로 부하가 집중되어 역시 오류가 발생할 문제가 다분해 지기 때문이다. 세번째는 실시간으로 부하를 분산해야 하는 문제가 있다. 갑자기 하나의 지역에 많은 유저가 몰리게 된다면 시스템의 한계에 의해 서버의 처리 속도가 현저하게 느려지거나 심할경우 OS 가 다운이 될 수 있기 때문이다. 부하를 실시간으로 분산시킬 수 있는 것은 상당히 까다로운 문제이다.

replication란? 데이터베이스의 복제 기능이다. 똑같은 정보를 가지고 있는
데이터베이스들끼리 연결되어 한쪽 데이터베이스에 정보가 입력된다면 입력된 데이터를
다른 데이터베이스에도 똑같이 입력되게 하는 데이터베이스 기능이다.

필자의 경우 같은 지역을 여러대의 맵서버가 관리하는 분산 구조를 간단하게 테스트 해본 적이 있다. 구조는 동기화 서버( 1대 ) + 게임 서버( 여러대 ) 의 구조이다.

<그림 4> 게임 서버의 분산 구조

동기화 전문 서버를 한대 두고 그에 여러대의 동일한 맵서버가 연결되어 부하를 분산시켜주는 구조이다. 동기화 서버와 맵 서버간에는 UDP 를 이용하여 데이터를 송수신 한다. 예를 들어 동기화 서버에 2 대의 게임서버 1, 2 를 붙이게 된다면 유저들은 게임 서버 앞단에 있는 로드밸런싱 서버에 의해 적은수의 유저가 있는 게임 서버를 알게하여 게임 서버 1, 2 에 분산되어 접속하고 게임을 하게 되지만 같은 섹터에 있는 캐릭터는 동기화 서버에 의해 동기화가 되는 구조이다.

물리적으로는 분리되어 있는 게임서버 1, 2 이지만 동기화 서버에 의해 논리적으로는 같은 서버에 존재하게 되는 것이다. 동기화 서버는 오직 캐릭터들의 동기화 작업만 수행하기 때문에 디스크 I/O 가 없어 부하를 적게 차지하여 여러대의 동일한 공간의 게임 서버를 동기화 시킬수 있는 구조이기 때문에 많은 유저들을 수용할 수 있다.

서버간의 통신 #

이전에 필자가 구현 했던 MMORPG 의 서버군의 구성은 다음과 같다. <그림 5> 를 보면서 서버간의 통신에 대해 이야기 해보자.

<그림 5> 서버군

<그림 5> 의 서버군은 패치 + 로그인 + 로비 + 맵 + 관리 서버의 구조로 되어 있다. 서버간의 통신은 UDP 프로토콜을 이용하며 관리 서버를 중간에 두어 월드의 모든 접속자 리스트를 가지고 접속자 관리, 전체 메세지 전송, 타 서버에 있는 케릭터에 귀속말 전달 등의 일을 담당한다. 유저가 인증에 성공을 하게되면 최초 인증 서버에서 관리 서버로 유저의 기본 데이터를 송신하여 유저의 연결 리스트에 추가를 하게 된다. 유저가 월드를 선택하고 캐릭터를 선택하여 게임 서버에 접속을 하게 되면 게임 서버에서 관리 서버로 관련 정보를 송신한다. 관리 서버에서는 데이터를 수신하여 연결리스트의 해당 유저 노드를 잘라내어 월드 트리의 해당 서버 브렌치에 노드를 추가하게 된다.

각 게임 서버들은 2 개의 네트워크 인터페이스 ( 랜카드 ) 를 사용하여 각각 외부/내부 네트워크 전용으로 사용하였다. 특히 데이터베이스의 경우 외부 네트워크와 차단하여 혹시 있을 수 있는 해킹에 대비하였다. 내부 네트워크와 외부 네트워크로 구분하기 위해 각각의 네트워크 인터페이스 카드 ( 랜카드 ) 하나 ( 랜카드1 ) 에는 공인 IP 를 또 다른 하나 ( 랜카드2 ) 에는 사설 IP 를 부여 하였다. 사설 IP 는 B 클래스 172.16.0.0 - 172.31.255.255 영역을 사용하였다. B 클래스를 쓴 이유는 네트워크당 65000 개의 호스트를 수용하기 때문에 서버가 많이 늘어나도 아이피가 부족할 일이 없기 때문이다. <표 1> 는 내부 네트워크에서 사용하는 클래스의 IP 대역과 네트워크당 수용 가능한 호스트의 수이다.

클래스	IP 대역	네트워크당 수용 호스트 수
A Class	10.0.0.0 ~ 10.255.255.255	16777214 개
B Class	172.16.0.0 ~ 172.31.255.255	65534 개
C Class	192.168.0.0 ~ 192.168.255.255	254 개

<표 1> 클래스 대역폭 및 수용 호스트수

각 서버들의 정보는 데이터베이스에 저장되어 있기 때문에 처음 서버가 구동될 때에는 전체 서버군에 있는 서버들의 정보를 적재 ( load ) 시킨다. 적재된 서버의 정보는 서버 인덱스와 내부 아이피 정보인데, 각각의 서버들은 다른 서버와의 통신을 위해 서버 정보들을 사용한다. 통신이 필요한 서버에 메세지를 송신하고 수신받은 서버에서는 메세지에 따른 처리를 한 후에 다시 응답 메세지를 보내주면 하나의 통신이 완료되는 것이다.

서버간에 전송되는 메세지는 주로 캐릭터가 게임 서버를 이동할 때 사용되는 패킷과 귀속말 패킷이 주로 사용된다. 유저가 게임 서버를 이동할 때에는 캐릭터가 위치하고 있는 포탈 인덱스에서 이동하려는 서버의 인덱스를 알아내어 클라이언트에게는 이동하려는 서버의 아이피, 접속 포트 번호, 인증 키 등을 전송하고, 캐릭터가 현재 위치하고 있는 서버에서는 이동하려는 서버로 인증키 등을 전송한다. 클라이언트에서는 현재 서버로부터 받은 아이피와 포트로 새로운 서버로 접속을 하고 인증키를 통해 인증을 받게 된다. 서버간 통신은 랜카드2 를 통해서만 송/수신 ( 서버간의 패킷은 사설 아이피로 수신된 패킷만 인정하고 공인 아이피로 온 패킷은 무시 ) 하기 때문에 혹시 있을 수 있는 사용자의 해킹을 방지한다. <표 2> 은 IP address 별 사용 용도와 특징을 정리한 내용이다.

	공인 IP	사설 IP
차이점	클라이언트와의 통신	서버간의 통신
차이점	서버간의 통신 사용불가	클라이언트간 통신 사용불가
공통점	서버간의 통신에서 네트워크 대역폭 확보 및 물리적인 보안

<표 2> IP address 사용

외부로 부터의 보안을 위해 서버는 TCPWRAPPER 를 사용하여 관리자 아이피 외의 접근을 막았다. 게임 산업이 발전함에 따라 게임 서버의 보안 문제가 이슈가 된지는 오래이며 유명 게임 서버들의 경우 해커의 공격 목표가 되기도 한다. 해킹에 의해 소스나 데이터베이스가 유출되기도 하기 때문에 개발사들은 보안에 만전을 기해야 한다. 시스템의 해킹은 자칫 큰 문제가 되어 게임의 흥망에도 큰 영향을 미칠수 있기 때문에 중요한 문제이다.

TCPWRAPPER란? Wietse Vanema 에 의해 제작된 TCPwapper 는 호스트 레벨에서 특정
프로토콜과 포트, 네트워크 IP 에 따른 접속허가를 내줄 것인지 거부할 것인지 결정하는
packet dropper 이라고 볼 수 있다.

SubCategoryNetwork