게임 데이터베이스는 톡 쏘는 듯하면서도 달콤하고 나름의 묘한 향을 가진 머스터드소스처럼 다양하면서도 미묘한 맛을 내며 게임 속에 녹아들도록 만드는 것이 관건이다. 게임의 데이터베이스는 다른 시스템과 목표치가 좀 다르다. 온라인 게임은 하루 24시간 일주일에 7일 내내 안정적인 서비스를 지원할 수 있는 24×7의 서비스가 요구된다. 온라인 게임에서의 서비스는 곧 돈과 연결되기 때문이다. 또 사용자들의 편의를 위해 빠른 응답속도도 갖춰야 한다.

코드성 데이터에 유연성 부여하기

게임개발은 기획에서부터 시작된다. 만약 개발도중 기획이 변경되면, 데이터베이스설계는 물론 게임서버에 이르기까지 모두 변경되어야 하는 특성을 가지고 있다. 물론, 기획이 누구도 생각지도 못했을 만큼 참신한 것이 아니라면 기본적인 틀은 변경되지 않는다. 게임기획은 프로젝트의 범위에서 간혹 빠지기도 하지만 거의 모든 경우 게임 계발의 시작이 된다. 게임의 개발 단계를 정리해 보면 ‘기획-설계-구현-테스트’로 구성되며 이런 프로세스는 게임을 서비스하는 중에도 발생한다. 대부분의 온라인 게임 시스템은 일반적으로 <그림 1>같은 구조를 가지고 있다.

<그림1>게임 구성도

게임 서버나 데이터베이스 서버는 기능에 따라서나 트랜잭션 처리량에 따라서 스케일 업(Scale-Up)하거나 스케일 아웃(Scale-Out) 할 수 있다. 이때 잊지 말아야 할 중요한 점은 게임은 C.S 환경이 아니라 n-Trie 구조로 이루어진다는 것이다. 게임서버는 클라이언트가 게임을 진행할 수 있도록 코드성 데이터를 가지고 있다. 이러한 코드성 데이터는 엑셀(Excel)에 담고 있거나, 텍스트 파일 형태로 게임 서버에 가지고 있는 경우도 있고, 데이터베이스 서버에 저장할 수도 있다. 이런 코드성 데이터는 어디에 저장되어 있는지에 관계없이 쉽게 별할 수 있는 특성을 가지고 있다.

기획에서 특정 속성이 추가된다면 데이터 또한 많은 부분이 수정되어야 한다. 또한 유지보수 단계에서 변화가 일어난다면 더욱 많은 신경을 써야 한다. 그럼 시도 때도 없이 변해야 하는 코드성 데이터는 어디에 저장하는 것이 좋을까? 이에 대한 답으로 데이터베이스에 저장하는 것이 당연하다고 말한다면, 데이터베이스는 병화에 약하기 때문에 말도 안 되는 답이라고 말하는 사람도 있을 것이다. 하지만 사실을 알고 보면 데이터베이스에 저장된 코드성 데이터라도 어떻게 설계하느냐에 따라 얼마든지 유연성을 부여할 수 있다. 이런 부분들을 감안하면 <그림 2>와 같은 설계를 할 수 있다.

<그림2>아이템 코드 테이블 구조 (아이템코드의 Primary Key는 ItemID)

만약 기획이 변경되어 ‘추가컬럼1’, ‘추가컬럼2’와 같은 컬럼이 테이블에 추가된다고 가정하자. 그럼 ‘아이템기타’ 테이블에는 ItemID의 개수만큼 행(Row)수가 늘어나게 되지만, 테이블의 구조는 절대로 변하지 않는다. 이런 코드를 읽기 위한 SQL은 <리스트 1>과 같을 것이다.

<리스트 1> 코드를 조회하는 SQL

SELECT
A.ItemID
, A.ItemName
, B.추가컬럼1
, B.추가컬럼2
FROM 아이템코드 A 
INNER JOIN (
SELECT
ItemID
, MIN(CASE WHEN CodeName = '추가컬럼1' THEN CodeValue END) 추가컬럼1
, MIN(CASE WHEN CodeName = '추가컬럼2' THEN CodeValue END) 추가컬럼2
FROM 아이템기타
GROUP BY ItemID) B
ON A.ItemID = B.ItemID

얼핏 봐도 알 수 있듯이 아주 유연한 설계가 되었다. 이처럼 유연한 설계가 가능한 것은 게임 서버가 서비스를 시작할 때 코드성 데이터를 단 한번만 읽어오기 때문이다. 다시 말해, 게임유저들에게 서비스할 때가 아닌 게임 서버를 서비스할 때이므로 성능에 전혀 영향을 받지 않다는 것이다. 또한 코드성 데이터는 데이터의 양이 많지 않기 때문에 성능에 대한 영향도 거의 없다고 볼 수 있다.

게임 서버가 데이터를 한 번 읽어가서 캐시(Cache) 역할을 한다는 것은 데이터베이스 서버 입장에서는 변화에 강하게 대처할 수 있는 좋은 약과 같다. 게임에는 많은 코드성 데이터가 존재하기 때문에 이러한 코드성 데이터는 매우 유연하게 설계 하도록 해야 한다.

대량의 트랜잭션과 게임 데이터 처리하기

게임 시스템은 성능 즉 빠른 처리속도와 안정성이 매우 중요하다. 특히 온라인 게임에서의 응답시간은 밀리세컨드(ms) 단위를 다툰다. n-Tire이므로 각 Tire별 응답시간도 매우 중요하다. 데이터 레이어(Data Layer)의 응답시간은 특히 중요하다. 우리는 특정 DBMS 제품을 쓰는 것이 때문에 적절한 응답시간을 유지하기 위해서는 DB설계가 매우 중요하다. 또한 어떤 기능을 DB단에서 처리할 것인지 아니면 게임 서버에서 처리할 것인지에 대한 고려해야 한다. 이제 MMORPG 게임의 특징을 살펴보고, 설계가 어떻게 이루어지는지 살펴보도록 하자. MMORPG 게임의 특징은 다음과 같다.

● 매우 짧고 많은 트랜잭션
● 트랜잭션의 복잡도는 ‘0’에 가까움
● 캐릭터 또는 회원ID 단위로 트랜잭션이 발생
● 많은 양의 게임 데이터와 이력 데이터

짧고 단순한 대량의 트랜잭션

매우 짧은 트랜잭션이 대량으로 일어나기 때문에 게임 DB서버 자원 중 CPU의 중요도가 아주 높다. 물론 다른 자원도 중요하지만 CPU가 가장 중요하다고 하겠다. 또한 트랜잭션이 매우 단순하기 때문에 http://tpc.org에서 확인할 수 있는 tpmc(분당 트랜잭션 처리 수)보다 더 많은 트랜잭션을 처리할 수 있음을 감안해야 한다.

캐릭터 또는 회원ID 단위로 트랜잭션이 발생

온라인 게임의 특징 중 하나는 비정규화된 테이블이 많다는 점이다. 게임 DB에서 비정규화가 정당하게 받아들여지는 이유는 대부분의 트랜잭션이 한 개의 행에만 접근하는 포인트 쿼리(Point Query)이기 때문이다. 가장 큰 특징은 바이너리(Binary)형 컬럼의 존재이다. 바이너리형 컬럼에는 아이템에 대한 데이터, 장착 위치 등 많은 의미를 가진 데이터가 담겨 있다. DBMS는 1바이트를 처리하고자 하더라도 DBMS의 최소 입/출력 단위(8KB, 4KB등 DBMS마다 설정마다 다름)에서 처리되기 때문에 비교적 큰 바이너리형 컬럼을 갱신(Update)하는 데에는 무리가 없다. 하나의 행의 크기가 매우 크기 때문에 데이터의 저장소 효율이 떨어지기는 하지만 포인트 쿼리이므로 문제가 되지 않는다.

그러나 데이터의 분석이 매우 어렵다는 단점이 있다. 데이터의 분석이 어려운 탓에 분석 프로그램이 필요하게 되고 이 과정에서 추가적인 비용이 발생한다.

대용량의 데이터에 대해서 바이너리를 파싱하여 분석이 용이한 데이터로 만들 때에도 많은 서버 자원이 필요하게 된다. 이는 데이터 분석에 의한 의사결정업무에 대해서 지연시간을 늘리는 요인이 된다. DBMS는 최소 입출력 단위로 처리가 이루어지므로 바이너리를 고집하지 않아도 목표 응답시간을 낼 수 있다. 그렇기 때문에 모든 데이터를 바이너리 형으로 설계할 필요는 없는 것이다. 다만 분석에 필요한 데이터와 분석에 사용되지 않는 데이터를 분류하고, 필요 없는 데이터는 바이너리 형으로 만들어서 성능을 높일 수는 있다. 이때, 분석이 필요한 데이터만 논 바이너리(Non-Binary)형 데이터로 설계하면 된다.

많은 양의 게임 데이터와 이력 데이터 처리하기

게임 데이터베이스를 설계할 때 빼 놓을 수 없는 것 중 하나가 바로 각 캐릭터들에 해당하는 ‘이력관리’이다. 이력관리를 게임 데이터베이스 서버에서 할 것이냐 말 것이냐는 성능과 설계를 결정짓는 중요한 요소가 된다. 여기서 이력관리를 한다는 것은 데이터 분석과도 관계가 있다. 예를 들어 ‘레벨 70에서 71로 올리는데 걸린 평균시간은 얼마인가?’라는 요구사항이 존재한다면 각 캐릭터에 대한 레벨이력이 필요하다. 만약 천만 개의 캐릭터가 있고 100까지의 레벨단계가 존재한다면 레벨이력으로 필요한 데이터는 10억 건에 이르는 셈이다. 그러므로 이력관리를 할 때에는 대용량의 데이터에 대해 고려해야한다. <그림 3>은 레벨에 대한 이력을 관리하기 위한 모델의 변형을 보여준다. 왼쪽 모델의 ‘레벨’은 현재의 레벨을 나타내는 것이고, 오른쪽은 레벨은 이력을 관리하는 것이다.

<그림3>레벨과 레벨이력

이렇게 구성을 해 놓으면 앞에서 요구한 사항들을 100% 만족시킬 수 있다. 또한 특정 날짜에 레벨의 분포도 역시 알 수 있다. 물론 ‘종료일시 + 시작일시’로 인덱스가 걸려 있다면 ‘특정일시에 특정 레벨의 캐릭터 수는?’과 같은 요구사항도 간단히 처리할 수 있게 된다.

비정규화로 저장 공간 줄이기

<리스트 2> 이력 조회 SQL

SELECT
레벨
, COUNT(*) LevelCount
FROM 레벨이력
WHERE '20050617' BETWEEN 시작일시 AND 종료일시
GROUP BY 레벨

<그림 3>을 보면 ‘캐릭터명’이라는 속성이 있다. 이 속성 프리머리 키(Primary Key)라고 가정하자. 일반적으로 ‘캐릭터명’ 같은 속성은 가변길이 문자형의 12바이트 정도 된다. 게임에서 ‘캐릭터’는 중심이 되는 개체집합이므로 많은 자식 개체집합을 가질 것이므로 관계를 가질수록 저장소의 공간이 커지게 마련이다. 앞서 설명한대로 <그림 3>의 ‘레벨이력’에서 캐릭터명을 저장하는 공간은 약 11,444MB(12바이트×10억 건)가 된다.

그렇다면 ‘캐릭터명’ 대신할 키(Key)로 INT형 일련번호를 사용하면 어떨까? INT형은 4바이트로 12바이트 문자열보다 크기가 3배나 적다는 장점이 있다. 또, 인덱스의 크기도 상대적으로 줄어들기 때문에 대용량의 게임 DB에서 회원, 캐릭터와 같은 경우는 대리키를 고려해야 한다.

비정규화도 저장 공간을 절약하는 데는 도움이 된다. 예를 들어 ‘하나의 캐릭터는 아이템을 20개까지 가질 수 있다’고 정의되어 있다면 정규화 및 비정규화된 테이블을 구성할 수 있다.

<그림 4>는 캐릭터와 아이템간의 ERD이다. 실제보다 많이 간소화된 ERD이지만 저장 공간에 대한 것이 주제이므로 이에 초점을 맞춰 보기 바란다. <그림 4>에서처럼 정규화된 테이블에서 ‘소유’ 테이블이 없어짐으로 인해 많은 저장 공간을 절약할 수 있다는 장점이 있다.

만약 천만개의 캐릭터가 있다는 가정 하에 소유테이블은 캐릭터일련번호 4바이트, 아이템ID 2바이트라 하면 하나의 행은 6바이트가 된다. 그러므로 ‘소유’ 테이블은 약 1GB(10,000,000×20×6)가 되어 저장 공간을 절약 하는 결과를 얻을 수 있다.

비정규화된 테이블 구조는 저장 공간을 많이 절약할 수 있다는 장점이 있지만 변화에 대한 대응은 상당히 취약하다는 단점도 함께 가지고 있다. 또한 캐릭터와 관련된 트랜잭션과 아이템 관련 트랜잭션이 하나의 테이블에 몰리게 되므로 이 또한 록(Lock)에 의한 대기를 유발시킬 수 있다. 필자는 요즘은 하드웨어의 성능이 비약적으로 발전하였기 때문에 너무 소프트웨어적인 최적화를 강조하여 유지보수 및 운영비용을 증가시킬 필요는 없다고 생각한다.

<그림4> 캐릭터와 아이템 간 ERD

파티셔닝으로 관리 효율 높이기

하나의 테이블이 10억 건이라면 인덱스의 깊이도 깊어지고, 관리상의 어려움이 있으므로 수평분할을 고려해야 한다. 만약 DBMS에서 분할기능을 지원한다면 이를 적극 이용하면 되겠지만 분할기능이 존재하지 않는다면 분리된 객체의 일부로 관리해야 한다.

<그림3>의 테이블을 자동으로 분류하여 10개의 테이블에서 관리해주면 좋겠지만 그런 기능이 없는 경우는 수동으로 해주어야 한다. 대리키는 숫자이므로 나머지 연산자를 사용하여 ‘대리키/10’의 나머지를 가지고 분할키를 사용하여 분할할 수도 있다. MS-SQL Server 2000의 경우는 ‘파티션된 뷰’라는 것을 제공한다. MS-SQL Server 2005에서는 대용량 데이터베이스를 위한 파티셔닝 기능을 제공하고 있다. 필자가 확인한 바로는 베타1 버전까지 해시(Hash) 키워드가 존재하여 해시분할이 가능했는데 정식버전에는 없어졌다. 어쨌든 분할기능을 제공한다. 적절하게 각각의 테이블로 분산시키려면 MS-SQL에 <리스트 3>과 같은 프로시저를 작성하면 된다.

<리스트 4>는 오라클의 해시 분할 방법이다(옛날 버전은 지원되지 않음).

<리스트 3> 파티셔닝의 저장프로시저 예

CREATE PROC USP_CREATE_Item
@CharacterSeq INT
, @Item INT
AS
BEGIN
IF @CharacterSeq % 3 = 1 
INSERT 소유1 VALUES(@CharacterSeq, @Item)
ELSE IF @CharacterSeq % 3 = 2 
INSERT 소유2 VALUES(@CharacterSeq, @Item)
IF @CharacterSeq % 3 = 0 
INSERT 소유3 VALUES(@CharacterSeq, @Item)
END
GO

<리스트 4> 오라클 해쉬분할 방법

--해쉬분할 방법1
SQL> CREATE TABLE PRODUCT1(
2 ID NUMBER(3),
3 NAME VARCHAR2(30)
4 )
5 PARTITION BY HASH(ID) PARTITIONS 8
6 STORE IN (TBS1, TBS2, TBS3);

--해쉬분할 방법2
SQL> CREATE TABLE PRODUCT2(
2 ID NUMBER(3),
3 NAME VARCHAR2(30)
4 )
5 PARTITION BY HASH(ID)
6 (PARTITION P1 TABLESPACE TBS1,
7 PARTITION P2 TABLESPACE TBS2,
8 PARTITION P3 TABLESPACE TBS3);

DBMS 로그

로그는 DBMS별로 구조가 달라지기는 하지만 데이터의 일관성을 위해 필요한 만큼 트랜잭션이 발생하는 곳이라면 디스크 I/O도 필요하다. 게임 데이터베이스의 특성상 짧은 트랜잭션이 많이 존재하므로 DBMS의 전체 대기유형을 살펴보면 로그 기록(Write)을 위해 대기되는 시간이 많은 비율을 차지하고 있다는 사실을 확인할 수 있다. 그러므로 로그파일이 있는 디스크를 분리하는 것이 좋다. 일반적인 RAID5(redundant array of inexpensive disk 5)는 좋지 않다. 로그의 경우는 거의 쓰이지 않기 때문이다. 그러므로 RAID1이나 RAID1+0의 디스크 배열에 배치하는 것이 더 좋은 성능을 확보하는데 도움이 된다. <리스트 5>의 오라클의 로그와 관련된 사항들을 모니터링 할 수 있는 SQL 문이다.

<리스트 5> Redo Log Latch 경합 모니터링

--Redo Log latch 경합
select 
round(greatest(
(sum(decode(ln.name, 'redo copy', misses,0))
/ greatest(sum(decode(ln.name, 'redo copy', gets,0)),1)),
(sum(decode(ln.name, 'redo allocation', misses,0))
/ greatest(sum(decode(ln.name, 'redo allocation', gets,0)),1)),
(sum(decode(ln.name, 'redo copy', immediate_misses,0))
/ greatest(sum(decode(ln.name, 'redo copy', immediate_gets,0))
+ sum(decode(ln.name, 'redo copy', immediate_misses,0)),1)),
(sum(decode(ln.name, 'redo allocation', immediate_misses,0))
/ greatest(sum(decode(ln.name, 'redo allocation', immediate_gets,0))
+ sum(decode(ln.name, 'redo allocation', immediate_misses,0)),1)))
* 100,2)
from v$latch l, v$latchname ln
where l.latch# = ln.latch#;

--롤백세그먼트 경합률
select round(sum(waits)/sum(gets),2) from v$rollstat;

--롤백세그먼트 현황
select 
n.usn,
n.name,
s.username Name,
s.osuser,
rs.extents,
rs.wraps,
rs.rssize "Size (Bytes)"
from v$rollname n, v$rollstat rs, v$session s, v$transaction t
where t.addr = s.taddr(+)
and rs.usn(+) = n.usn
and t.xidusn(+) = n.usn
and rs.status = ‘ONLINE’
order by n.usn;

MS-SQL Server 2000에서는 DBCC sqlperf(waitstats) 명령을 제공하여 대기유형을 분석할 수 있도록 하고 있다. <리스트 6>은 대기유형을 수집하는 스크립트이다.

<리스트 6> 대기유형을 수집하는 스크립트

-- wait statistics 데이터 지움
DBCC sqlperf(waitstats,clear)

IF OBJECT_ID('waitstats') IS NOT NULL
DROP TABLE waitstats
CREATE TABLE waitstats (Wait_Type VARCHAR(80), 
Requests NUMERIC(18,1),
Wait_Time NUMERIC (18,1),
Signal_Wait_Time NUMERIC(18,1),
timenow DATETIME DEFAULT getdate())
DECLARE @start INT, @finish INT
SELECT @start = 1, @finish = 10
WHILE (@start < @finish)
BEGIN
BEGIN TRANSACTION
INSERT INTO waitstats (Wait_Type, Requests, 
Wait_Time,Signal_Wait_Time)

EXEC (‘DBCC sqlperf(waitstats)’)
COMMIT

SELECT @start = @start + 1
WAITFOR DELAY ‘00:00:05’ -- 5초 간격으로 수행
End

SELECT * FROM WAITSTATS 
ORDER BY wait_time DESC

필자가 게임업체에 입사하기 전에는 게임 데이터베이스에는 뭔가 특별한 영역이 있을 것이라는 기대도 있었다. 하지만 입사한 뒤에는 다른 데이터베이스와 큰 차이가 없음을 실감한다. 어떤 데이터를 설계하든 우리의 목표는 최종사용자가 서비스를 원활히 사용할 수 있도록 한다는 공통 목표를 가지고 있기 때문이다. 게임에서 다른 점이 있다면 서비스의 목표가 3초에서 0.3초로 줄어들었을 뿐이다.

필자가 게임 데이터베이스를 설계할 때 가장 중요하다고 생각하는 것은 전체적은 그림을 잘 그리는 것이다. 게임 운영뿐만 아니라 마케팅, 운영, 고객관계관리, 게임 밸런싱 조정 등 요구사항은 얼마든지 존재한다. 게임이 실행될 수 있는 환경 이외에 뒤에서 고군분투하고 있는 운영자, 영업부서, 지원부서들의 요구사항도 충분히 고려한 데이터베이스를 설계할 수 있도록 노력하자.

무료로 사용할 수 있는 DBMS

세상에 공짜를 싫어할 사람이 있을까? 특히 큰돈이 들어야 하는 일을 공짜로 할 수 있다면 그 보다 좋은 일이 없을 것이다. 게임 업계의 대다수가 경우 리눅스 베이스로 서버를 개발하고 RDBMS를 MySQL로 사용하는 가장 큰 이유가 비용의 문제라는 사실을 부정하기는 어려울 것이다.

실제로 상용 DBMS를 구매하는 비용은 온라인 게임 서비스를 만드는 과정에서 큰 비중을 차지한다. 때문에 게임 개발자들은 상용 RDBMS가 일부 기능을 제한한 상태에서 무료로 제공하거나 상용이었던 RDBMS가 오픈 소스로 풀린 제품을 찾아 사용하게 된다. 지금부터 각 무료 DBMS의 사용에 대한 장단점을 살펴보자.

용량과 메모리 제한이 있지만 장점도 많은 MS SQL 익스프레스

MS SQL 를 RDBMS로 쓸 경우에 기존의 ODBC와 ADO 프로그래밍을 그대로 적용할 수 있다는 장점이 있다. 관리 운영 툴이 부족한 점과 용량과 메모리를 제한하고 있다는 것이 문제지만 윈도우 플랫폼에서 개발자들이 가장 우선적으로 선택할 수 있는 제품이다.

가격 대비 성능이 가장 높은 파이어버드(Firebird)

윈도우를 RDBMS 서버로 사용할 경우 ODBC 드라이버를 별도로 다운받아 사용할 수 있다. 볼랜드 계열에서 파생된 제품이기 때문에 델파이나 C++ 빌더에서 사용해도 통합성이 높다. 리눅스 및 유닉스 계열의 파이어버드일 경우 가격 대비 성능에서 가장 우수한 결과를 얻을 수 있다. 특히 메모리와 저장 용량의 제한은 운영체제와 연관되어 있기 때문에 확장성 또한 우수한 장점도 갖추었다.

온라인 게임 서비스의 해외 서비스나 운영자 중심의 배포를 생각하고 있다면 파이어버드 임베디드 버전으로 게임 서버와 DBMS DLL을 배포하는 방식으로 운영할 수 있다. 이 경우 운영팀이 별도의 DBMS를 설치하거나 설정하는데 대한 부담을 줄일 수 있을 뿐 아니라 재설치 하는 시간도 짧기 때문에 효과적이다. 게임 서버군이 5개에서 20개까지로 확장된다면 확실한 장점을 가졌다고 할 수 있다.

안정성이 좋은 IBM의 DB2 익스프레스-C

IBM의 RDBMS 제품으로 안정성에서 신뢰를 얻고 있는 제품이다. 게임 DBMS로 사용된 레퍼런스가 없다는 점이 아쉽지만 배포되고 다양한 플랫폼에 적용할 수 있다는 점이 장점이다. DB2 익스프레스-C의 경우 SMP(Symmetric Multi Process
ing)를 2CPU까지 지원하고 4GB 메모리를 사용할 수 있기 때문에 MS SQL 익스프레스보다 좀 더 유연한 정책으로 꼽히고 있다.

데이터베이스의 최강자 오라클10g 익스프레스에디션

데이터베이스의 강자인 오라클 무료 버전은 금융권이나 SI쪽 데이터베이스 프로그래머에게 익숙한 DBMS이다. 그렇기 때문에 일부 게임 서버의 경우 시험적으로 오라클로 개발 중인 온라인 게임도 있는 것으로 확인 되었다. 그 동안 DBMS 라이선스 비용이 상당하다는 이유 때문에 망설였지만 소규모 온라인 게임의 경우 오라클10g 익스프레스에디션의 도입이 활발해질 것으로 예상된다. ODBC 드라이버를 이용하면 윈도우 프로그래밍도 할 수 있다.

지금까지 온라인 게임 업계가 사용하고 있는 DBMS에 대해서 알아봤다. 새로운 제품은 누구나 망설인다. 아직 누군가 검증하지 못했기 때문이다. 하지만 여기에 소개된 제품들은 모두 그 안정성이 검증된 상태이기 때문에 게임 게임자로서 매력적으로 접근이 가능할 것이다.

무료 DBMS의 특징

DBMS 특징

파이어버드 ·인터베이스의 무료화 버전
·리눅스 및 윈도우 등의 다양한 플랫폼 지원 
·용량 제한 및 프로세서 수 제한 없음
·트랜잭션 지원 및 스토어드 프로시저 지원
·커넥션 수 제한 없음
·임베디드 DBMS 버전도 지원

오라클10g ·리눅스와 윈도우 버전 지원 익스프레스에디션

·오라클의 안정적인 성능 지원DB2 익스프레스-C
·2GB DBMS 용량 지원
·2 CPU 프로세서 지원
·리눅스와 윈도우 지원

MS SQL 익스프레스
·1 CPU 지원. 듀얼 코어일 경우라도 하나의 CPU 지원
·1GB DBMS 용량 지원
·정식 MS-SQL과 달리 엔터프라이즈 매니저가 없음
·MS 비주얼 스튜디오 2005에 번들링되어 있음

MS SQL과 파이어버드로 온라인 게임 서비스와 확장하기

온라인 게임의 경우 사용자가 늘어날수록 서버도 따라서 증가해야 한다. 이때, 서버뿐 아니라 OS와 RDBMS등을 구매하는 과정에서 적지 않은 비용을 지출해야 한다. 지금까지는 이런 문제를 덜기 위해 리눅스 플랫폼에서 My SQL을 사용하는 것이 일반적이었지만, My SQL이 유료로 전환된 지금에는 새로운 대안을 고려해 볼 필요가 있다.

My SQL을 대체하기 위해 사용할 수 있는 가장 적당한 DBMS는 MS-SQL 익스프레스 버전이다. 익스프레스 버전의 경우 한 개의 CPU와 1GB의 용량 제한과 엔터프라이즈 매니저가 없다는 점을 제외하면 기존의 MS SQL과 거의 똑같이 사용할 수 있다.

한 가지 주의할 점은 1GB로 제한되는 용량이다. 얼마 전 필자가 수행한 프로젝트를 통해 My SQL 시스템을 MS-SQL 익스프레스로 이식하는 방법에 대해 알아보자.

프로젝트를 시작하면서 가장 먼저 해결해야 할 문제는 바로 용량이었다. 기존 DBMS의 용량이 1.4GB이고 앞으로 확장될 부분들을 고려한다면 MS SQL을 구입하는 것 이외에는 방법이 없을 것처럼 보였기 때문이다. 예산 부족으로 DBMS를 구입할 수 있는 입장은 되지 않고 상황은 상용 DBMS를 사는 것 이외엔 방법이 없을 듯하니 난감할 따름이었다.

그래서 여러 가지로 고민하다가 보니 다음과 같이 MS SQL 익스프레스를 사용하면서 별도의 DBMS 비용을 내지 않고 사용하는 방법을 찾아 시스템을 구성할 수 있었다.

MS SQL 익스프레스의 엔진 자체는 MS SQL 2005와 동일하다. 용량 이외에도 지원되지 않는 기능이 몇 가지 있기는 하지만 게임 업계에서 사용할 때에는 거의 지장이 없는 수준이다. MS SQL 2005부터 지원하기 시작하는 스토어드 프로시저(stored procedure)의 경우 MS SQL 익스프레스 버전에서도 지원한다.

구성한 C/S + 웹 시스템은 애플리케이션 서버와 다수의 MS SQL 익스프레스 서버를 두고 MS SQL 익스프레스가 지원하지 않는 밀러링 백업을 위해서 별도의 백업 서버를 구축했다. 백업 서버는 MS SQL 익스프레스와 다른 파이어버드 1.5x 버전을 사용했다. 밀러링 백업은 실시간 백업이 아니라 업무 특성에 따라 야간에 기존 데이터를 비교하여 백업하는 시스템으로 구성했다.

<그림5>MS SQL 익스프레스를 이용한 서비스 구성

MS SQL 익스프레스의 경우 저장 용량 제한이 있어서 위의 방식으로 시스템을 구성할 수 있었다. 요청하는 외주 의뢰사에서 파이어버드보다 인지도가 높은 MS SQL을 더 믿었기 때문에 무료 RDBMS인 MS SQL 익스프레스를 사용한 것이다. 정리하자면 주요 DBMS는 MS SQL을 사용하여 외주 의뢰사의 신뢰를 얻고 사용하지 않는 레거시 데이터나 비정기적인 밀러링 백업용으로는 용량 제한이 없는 인터베이스의 오픈 소스 버전인 파이어버드로 구성한 것이다.

MS SQL 익스프레스에서 제한되는 기능

● 리포팅 서비스 미지원
● OLAP/데이터 마이닝 서비스 미지원
● Analsys 서비스는 미지원
● DTS 미지원
● 데이터베이스 미러링 미지원
● 데이터베이스 4GB까지 사용
● 메모리 1GB까지 사용
● SMP 미지원

이런 아키텍처를 온라인 게임 업계에 적용할 경우 얻을 수 있는 장점은 다음과 같다.

● RDBMS 비용 지출이 없다.
● 기존의 MS SQL 개발자가 별다른 문제없이 개발할 수 있다.
● RDBMS 용량이 제한된 범위를 넘어서면 n대까지 확장하여 용량 증가 효과를 낼 수 있다.
● 비숙련 운영자도 윈도우 시스템에서 쉽게 관리할 수 있다.

의뢰한 업체의 신뢰도를 얻기 위해 궁여지책으로 찾은 방법이었지만 처음 예상했던 것 보다 장점이 많은 시스템이었다. 보통 파이어버드는 개발에 관련된 자료 찾기가 힘든 것이 단점이지만, My SQL에 버금갈 정도로 빠른 속도와 스토어드 프로시저의 사용, 다양한 운영체제의 지원 등 장점이 많은 제품이다.

윈도우 버전의 파이어버드 슈퍼 서버의 SMP도 곧 출시될 파이어버드 3.0에서 기능이 확장될 것이니 저렴하게 게임 DBMS를 구축해보고 싶은 개발자라면 고려해 볼 만한 제품이다(리눅스 버전에서는 SMP가 지원된다).

이 말은 돈을 받고 서비스를 하거나 소스가 공개되어 있지 않은 애플리케이션의 경우 상용 DB를 구매해야 한다는 의미이다. 모 게임 업체의 경우 무료 DBMS인줄 알고 My SQL을 사용했다가 라이선스 취득 권고를 받고 가격 및 조건을 따지다가 MS SQL로 자사 DB를 이식한 경우도 있다.

My SQL은 무료 DBMS가 아니다.

My SQL이 나왔을 때 참 많은 개발자들이 기뻐했다. 필자 역시 아파치, PHP와 함께 무료라는 점으로 트랜잭션조차 지원하지 않는 My SQL로 웹 페이지와 소규모 게임 포털을 만들 때여서 더욱 기뻤다. 당시만 해도 트랜잭션을 해결하기 위해 느리디 느린 InnoDB라는 익스텐션까지 사용하던 시기였다.

다음은 My SQL 벤더인 테라텍이 밝히는 My SQL 구매 조건과 사유이다.

● My SQL을 포함하고 있는 소프트웨어를 고객에게 팔아 그 소프트웨어를 고객이 소유한 장비에 설치하는 경우
● 고객이 소유한 장비에 My SQL을 설치해야하는 소프트웨어를 파는 경우
● My SQL을 포함하고 있는 하드웨어 시스템을 고객에게 팔아서 고객이 있는 곳에 설치하는 경우

자세히 :
● My SQL 서버에 GPL라이선스나 그에 상응하는 라이선스를 가지고 있지 않은(비오픈 소스가 아닌 경우) 애플리케이션을 포함하려면, My SQL 서버용으로 상업용 라이선스가 필요합니다.

● 상업용 애플리케이션을 개발하고 배포하거나 그 애플리케이션을 잘 활용하고자 고객이 반드시 My SQL의 카피를 다운로드 받아야 한다면, 각각의 파생된 작업용으로 사용자(또는 경우에 따라서 고객)는 My SQL 서버용이나 MySQL 클라이언트용 상업용 라이선스가 필요합니다.

● 사용자의 애플리케이션이 하나 또는 여러 개의 My SQL 드라이버를 포함하고 있다면(그래서 사용자가 소유한 애플리케이션이 My SQL과 함께 실행된다면), 해당 드라이버용으로 상업용 라이선스가 필요합니다. 현재 My SQL 드라이버 제품군은 ODBC 드라이버, JDBC 드라이버 그리고 C언어 라이브러리를 포함하고 있습니다.

● My SQL 소프트웨어를 사용자 조직 내에서 배포하려면, 상업용 라이선스를 구입해야 합니다.

● GPL 유저는 My SQL AB와 직접적으로 어떠한 법적인 관계도 가지고 있지 않습니다. 반면 커머셜 라이선스는 My SQL AB 자체 라이선스이며 My SQL AB와 직접적으로 법적인 관계를 제공합니다.

상업용 non-GPL My SQL 서버 라이선스를 가지고 있는 경우, 데이터베이스 서버 당 하나의 라이선스가 필요합니다.(설치된 한 카피의 My SQL 바이너리에 대해) 하나의 My SQL 데이터베이스 서버는 접속 수(연결 수), CPU수량, 메모리 또는 디스크 수 등에 제한을 받지 않습니다. MaxDB서버는 CPU나 유저 당 라이선스입니다.

출처 : 마이크로소프트웨어[2006년 6월호]

http://blog.naver.com/zzanggoosoft?Redirect=Log&logNo=30006159619