가장 많은 동시 접속자가 발생하는 MMORPG 게임을 기준으로 일반적인 게임 서버의 아키텍쳐를 살펴 보겠습니다. 각각의 게임들은 보통 동일한 게임 서비스를 하는 월드(아시아 서버, 유럽 서버 등..)로 분할되어 있으며, 각각의 월드는 게임 내의 게임 장소에 따라 다시 각각 존으로 나뉘어 있습니다. 사용자는 게임에 접속하면 최초에 자신이 접속할 월드를 선택하여 계정과 비밀번호를 입력한 후 게임을 하면서 존을 넘나들게 되는 것입니다.
- 일반적인 MMORPG 게임의 모습 -
- 일반적인 게임 서버 아키텍처 -
월드
하나의 게임을 한 대의 서버에서 서비스하는 매우 단순한 모델을 생각해 보겠습니다. 서버는 CPU, 메모리 등의 용량으로 인한 연산 능력 및 네트워크 입출력 등에 제약이 있기 때문에 서비스할 수 있는 사용자 수에 제한이 있습니다.
한 서버에서 3천명의 사용자를 수용할 수 있다고 가정을 하겠습니다. 게임의 론칭 이후 수십명의 사용자에서 수백명의 사용자로 사용자가 증가하게 되고 곧이어 3천명의 사용자를 넘어서게 됩니다. 이 때 개발사는 추가적인 서비스를 제공하기 위해 똑같은 서버를 1대 더 설치함으로서 사용자의 분산을 유도합니다. MMORPG 등의 게임에서 아시아 서버, 유럽 서버 등으로 서버가 나뉘는 것이 그 예입니다. 초기의 3천명은 월드 1에서 플레이하고 나중의 3천명은 월드 2에서 플레이하게 되는 것입니다.
| <월드 1> <월드 2> ... <월드 100> |
월드가 분할되어 있는 경우 각각의 월드는 게임상으로 완전히 별개의 월드가 운영되고 있을 뿐 아니라 물리적으로 독립되어 있는 서버에서 구동되기 때문에, 각각의 월드에 있는 사용자끼리 함께 게임을 즐길 수가 없고, 대화 및 사용자 정보의 이동이 불가능합니다.
존
게임 상의 월드는 매우 방대하기 때문에 사실상 하나의 월드를 한 대의 서버에서 서비스하는 것은 거의 불가능한 일입니다. 때문에 실제 서비스는 하나의 월드를 매우 작은 크기의 존으로 나누어 각각의 존들을 매 서버에서 서비스를 하는 식으로 이루어집니다.
한 월드를 100개의 존으로 나누어(하나의 월드를 여러개의 존으로 나누는 것을 Zoning한다고 합니다.) 100대의 서버에서 각자 1개씩의 존을 서비스하면 서버 한대에서 3000명의 사용자를 받아들일 수 있으므로 100개의 존서버를 이용하면 한 월드에서 300,000명의 사용자를 서비스할 수 있도록 되는 것이지요.
따라서 실제 대부분의 게임서버는 다음과 같은 구성을 가지게 됩니다.
| 월드 1 (존 1, 존 2, ..., 존 100) 월드 2 (존 1, 존 2, ..., 존 100) 월드 3 (존 1, 존 2, ..., 존 100) 월드 4 (존 1, 존 2, ..., 존 100) 월드 5 (존 1, 존 2, ..., 존 100) |
- 존 구성 -
사용자들은 게임을 플레이하면서 장소의 이동에 따라 게임 서버 내의 존을 넘나들며 서비스를 받는 물리적인 서버를 넘나들게 되는 것입니다.
존간 이동, 대화, 파티
존으로 구성된 게임을 실제 사용자가 플레이하는 경우 몇가지 이슈가 발생합니다.
사용자가 월드 내에서 게임을 플레이 함에 따라 게임 내 장소를 이동하며 게임을 하기 때문에 A장소에서 B장소로 이동하는 과정에서 존과 존 사이를 이동하게 됩니다. 이렇게 사용자의 존간 이동이 발생할 때는 서버 측에서 사용자에 서비스를 제공하는 존 서버가 바뀌기 때문에 계속적으로 서비스를 제공할 수 있기 위해서는 사용자의 위치 정보, 액션 정보 등의 각종 사용자 정보를 다른 존 서버로 전달해 주어야 합니다. 실제 게임서버 개발 가운데 게임성과 관련한 부분과 함께 가장 큰 부분 중의 하나이죠.
이렇게 사용자 정보를 존 서버 끼리 주고 받는 경우 우선 존과 존 사이에 통신을 해야 하고 사용자와 새로운 존 서버가 접속을 새로 맺어야 하기 때문에 약간의 딜레이가 발생할 수 있는데 이를 어떻게 Seamless하게 빠르게 새로운 접속을 맺을 수 있도록 구성하는가하는 것이 게임 서버 프로그래밍의 큰 기술 가운데 하나입니다.
한편 이러한 존 서버 사이의 이동에 따른 딜레이를 게임 클라이언트 측에서 보완하기도 합니다. 존의 이동을 워프 존이나 게이트 등을 통과하는 이벤트로 만들어서 게임 화면에서 특정한 그래픽 이벤트를 실행하는 동안 존 서버 측의 새로운 접속 설정이 맺어질 수 있도록 하는 것이지요. 게임 클라이언트 엔진 또한 장소의 이동에 따라 새로운 맵 데이터나 그래픽 데이터를 메모리에 로드해야 하기 때문에 약간의 시간이 필요하므로 존 이동에 따라 발생하는 그래픽 이벤트는 서버와 클라이언트 측 모두에 필요한 사항이라고도 할 수 있겠습니다.
존 서버간 이동에 따라 발생할 수 있는 또 다른 큰 문제는 사용자들 사이에 주고받는 정보를 존 서버끼리 공유할 수 없다는 것입니다. 대화 및 파티를 맺는 것이 그 것입니다.
존서버 A에서 사용자 1과 사용자 2가 대화를 나누고 있습니다. 이 때는 아무 문제가 없습니다. 사용자 1, 사용자 2 모두 존서버 A에서 서비스를 받고 있기 때문입니다. 하지만 사용자 2가 존 B로 옮겨감에 따라 문제가 발생합니다. 사용자 1은 존서버 A에서 서비스를 받고 사용자 2는 존서버 B에서 서비스를 받기 때문에 대화는 유지될 수 없습니다. 대화 서비스를 하는 서버가 각각 다르기 때문이죠.
사용자들끼리 무리를 지어 활동하는 파티도 마찬가지입니다. 파티를 맺고 있던 구성원들이 존을 이동하게 되면 파티가 전부 깨어지고 구성원 모두가 존의 이동을 마친 뒤 다시 파티를 맺어야 합니다.
이러한 현상을 막기 위해서 대화, 파티 등의 존서버와는 별도로 서비스가 유지되어야 하는 서비스들은 각각의 서비스를 담당하는 별개의 서버를 두어 관리를 하게 되는데, 이에 따라 보통의 게임들은 모두 다음과 같은 서버 구성을 갖게 됩니다.
| 월드 1 (존 1, 존 2, ..., 존 100) 월드 2 (존 1, 존 2, ..., 존 100) 월드 3 (존 1, 존 2, ..., 존 100) 월드 4 (존 1, 존 2, ..., 존 100) 월드 5 (존 1, 존 2, ..., 존 100) .... .... .... 월드 100 (존 1, 존 2, ..., 존 100) 대화 서버 파티 정보 서버 로그인 서버 데이터 베이스 서버 |
- 일반적인 게임 서버 아키텍쳐 -
일반적인 게임 서버 아키텍쳐의 문제점
위의 아키텍쳐가 대부분의 게임 개발사에서 채택하고 있는 아키텍쳐이고, 한국의 온라인 게임 개발사들이 가장 잘하고 있는 부분입니다. 온라인 게임화가 최대의 화두인 외국의 콘솔 게임이나 아케이드 게임 개발사에서 한국의 개발사에 기술제휴를 타진하는 부분이기도 하구요.
위의 일반적인 게임 서버 아키텍처를 통해서 서버를 구축한다고 해서 게임 서비스가 불가능한 것은 아닙니다. 동시접속자 수가 수만명을 넘는 대규모의 MMORPG 게임들도 위의 아키텍쳐를 통해 실제로 잘 서비스가 되고 있고 있습니다. 하지만 이러한 일반적인 게임 서버 아키텍쳐는 게임 사용자 입장에서는 월드의 분할에 따른 게임 환경 분리, 존 구성에 따른 이동간 딜레이 발생 및 채팅정보 파티정보의 유실, 또한 데이터의 일관성 유지(아이템 분실 및 플레이 정보 분실) 등에 있어서 약점을 가지고 있고, 게임을 서비스하는 입장에서도 게임 사용자 증가에 따른 서버의 확장성 문제, 게임 서버 아키텍쳐의 비표준화로 인한 개발 실패의 위험과 개발 시간의 증가 문제, 장애 취약성의 문제, 게임 서버 관리의 복잡성 문제 등을 가지고 있습니다.
다음 포스팅에서 문제점들을 하나하나 살펴보도록 하겠습니다.
