Sangpill Kim's Blog

서버의 확장성

게임 산업은 대체로 문화 산업의 특징을 많이 가지고 있고 특히 게임 개발은 영화 제작과 많은 비슷한 점을 가지고 있습니다. 그 가운데 하나는 오픈해서 서비스하기 전까지는 얼마나 많은 사용자가 있게 될지 예상할 수 없다는 것입니다.

기존의 게임 서버 아키텍쳐에서는 서비스 초기에는 한 서버에서 100개의 존을 서비스하다가 사용자의 증가에 따라 두 대의 서버에서 각각 50개씩의 존을 서비스하고, 또 사용자가 증가하면 네 대의 서버에서 각각 25개씩의 존을 서비스하는 방식으로 서버를 확장하고 있습니다. 게임 서버의 서비스 분할의 최소단위로서 존이 존재하게 되는 것이고, 사용자가 계속 증가하면 한 개의 존을 한 대의 서버에서 서비스하게 되는 모습으로 그래도 사용자가 증가하면 여러 대의 서버를 컴퓨팅 클러스터로 구성하여 서비스를 하게 됩니다. 게임의 서버 모듈들은 이미 존으로 잘게 나뉘어 있고 서버 관리자가 관리 모듈을 통해서 어느 서버는 몇 번부터 몇 번 존까지를 서비스하고 다른 서버는 몇 번 존까지를 서비스할지를 수동으로 관리함으로서 서버가 확장되게 되는 것입니다.

문제는 이러한 확장성있는 구조가 설계, 개발 단계에서부터 고려되어야 한다는 점입니다. 게임성과 관련한 게임 서버를 개발하고, 월드를 만들고, 존을 분할하고, 존 서버간 통신 모듈을 개발하고, 존과 존서버를 관리하기 위한 매니지먼트 프로그램을 개발하는 일은 결코 쉬운 일이 아닙니다. (썬에서는 전체 게임 개발 과정의 약 40%가 게임 서버 개발에 소요된다고 분석하고 있습니다.)

또한 게임의 사용자 수를 정확하게 예측하기가 매우 어렵기 때문에 월드 내 존의 개수, 존 당 최대 서비스 가능 사용자 수 등의 존 분할 정책을 세우는 것도 쉬운 일이 아닙니다. 기존의 게임은 평면 위의 공간 상에서 플레이를 하기 때문에 한 평면에 동시에 존재할 수 있는 최대 사용자 수를 결정하는 것이 가능했지만 지금은 '세컨드 라이프'와 같이 입체적인 공간에서 플레이가 이루어지기 때문에 3차원 공간의 특징상 최대 사용자 수를 결정하는 것조차 어려워지고 있습니다.

이렇게 얼마나 많은 사용자가 몰릴지 알 수 없는 상황에서 복잡한 구성의 게임 서버 아키텍쳐를 개발하는 것은 개발의 위험성을 높이고, 서비스의 수준을 떨어뜨릴 수 있을 뿐만 아니라 많은 비용과 시간의 투자를 요구하게 되어 게임 개발사가 게임성 자체에 집중하지 못하게 하는 요인이 됩니다.


게임 서버 표준화

또 하나의 큰 문제점은 이러한 아키텍쳐가 업계내에서 표준화되어 있지 않고 개발사마다 다를 뿐만 아니라 개발사 내에서도 게임 스튜디오 별로 또는 게임 별로 다르다는 것입니다. 지금의 게임 서버 아키텍쳐는 표준화된 공통 모듈이 없음으로 인해서 마치 홈페이지를 구축하기 위해서 HTML 페이지 뿐만 아니라 웹서버자체까지 함께 개발하여야 하고 또한 매번 게임을 개발할 때마다 이러한 개발 작업을 반복하여야 합니다. 앞서 언급한 대로 개발 실패의 위험이 있을 뿐만 아니라 개발 비용이 증가하고 개발 시간이 증가할 수 밖에 없는 구조입니다.

2006년 1월 경에 중국의 게임 업체를 방문하고 중국의 게임 시장을 탐방할 기회가 있었는데요. '중국시장에서의 지적재산권에 대한 미흡한 보호 등으로 중국에 진출한 한국 게임에 대해서 현지 업체가 유사한 게임을 개발해서 내놓으면 어떻게 되느냐?'는 질문을 했었는데, 현지의 한국 담당자로부터 들은 답변이 무척 재미있었습니다. 대응책이 사실상 없다는 것이었습니다. 법정 분쟁을 하거나하게 되면 중국의 법원 자체도 지적재산권 보호에 대해 적극적이지 않기 때문에 조치가 취해지거나 판결이 내려지기까지는 2~3년의 시간이 지나버리게 되고, 이 때쯤되면 게임의 수명이 이미 지나버려 유리한 판결을 받아도 한국 업체가 득이될 것이 없다는 것입니다.

그만큼 게임은 문화산업으로서 'Time To Market'이 굉장히 중요한 시장인데 많은 게임 업체듈들은 공통된 서버 모듈이 없거나 로그인, 채팅 등 기본 기능 정도에 대해서만  공통 모듈이 적용되어 있거나 또는 소스 코드 수준의 공유 정도에서 그치고 있어 서버 프로그램을 다시 개발하는데 다시 많은 시간과 비용을 들이고 있습니다.


장애 취약성

또한 기존의 게임 서버 아키텍쳐는 장애에 매우 취약한 구조입니다. 특정한 존을 담당하는 서버에 장애가 발생해서 서비스를 할 수 없게 된 경우 보통은 운영체제와 게임 서버 모듈이 설치된 예비의 서버가 대기하고 있다가 장애가 발생한 서버의 IP 주소로 IP 주소를 바꾸고 관리자의 수작업을 통해서 해당 서버가 서비스하고 있던 존들을 대기중이던 서버가 대체해서 서비스하게 되는 방식으로 처리되고 있습니다.

장애발생 여부를 즉시 알게 되었을 경우라해도 운영체제의 부팅 및 네트워크 설정, 게임 서버 설정 등으로 약 5분~10분 정도의 시간 동안은 장애가 발생한 서버에서 담당한 존에 대해서는 서비스 다운 타임이 발생하게 되고 또 관리자의 수작업에 의한 작업이므로 관리자가 있어야만 한다는 문제가 있습니다. 미션 크리티컬한 업무가 많은 금융권이라면 이러한 상황은 로드밸런싱 클러스터나 HA(High Availability) 클러스터를 통해서 장애가 발생하더라도 다른 서버를 통해서 서비스의 가용성에는 지장을 주지 않도록 아키텍쳐가 구성되어 있겠지만, 게임 서버는 보통 그렇게 구성되어 있지는 않은 것 같습니다. 서비스 측에서는 약 5분 이내의 다운타임 정도에 대해서는 그렇게 심각하게 받아들이지 않는 것 같고 또 게임 사용자들 또한 오래 전부터 이러한 상황에 대해 익숙한 탓인지 극소수의 게임 이외에는 짧은 시간의 다운타임이나 서버 리붓 등 재접속해야 하는 상황에 대해서도 어느 정도 관대한 것 같습니다.

관리의 복잡성

한편 존별 서비스 구성 및 매뉴얼 작업에 의한 서버 관리 등으로 인한 관리를 매우 복잡하��� 만들고 이러한 복잡성은 서버 구조의 비표준화로 인하여 더욱 증대됩니다. 이는 복잡한 관리를 위해서 숙련된 서버 관리자가 필요하게 된다는 의미이고, 게임의 서비스가 특정한 관리자에게 종속되게 되는 문제를 발생시킵니다. 야간에 장애가 발생했을 때 관리자가 부재중이거나, 관리자가 퇴사하는 경우 게임의 서비스에까지 문제가 발생될 수 있는 상황이 생길 수 있다는 것입니다.

특히나 최근 게임업체들은 글로벌 런칭을 하는 경우가 관리의 복잡성은 현지에 서버를 두고 서비스를 시작하는데 많은 어려움을 가져옵니다. 실제로 해외의 유명 온라인 게임은 국내에 서버를 두고 서비스를 개시하려고 했지만, 게임 서버 구성의 어려움 때문에 런칭에 실패하고 사업을 철수한 경우도 있습니다.

이러한 게임서버의 문제점을 극복하고 표준화된 확장성 있는 아키텍쳐를 통하여 개발에 걸리는 시간과 서비스 위험을 감소시키고자 하는 것이 바로 Project Darkstar입니다. 다음 포스팅에서 Darkstar의 Architecture에 대해서 이야기해 보도록 하겠습니다.