Cover Story 2 데이터베이스계의머스터드소스 MMORPG 게임데이터베이스설계 게임데이터베이스는톡쏘는듯하면서도달콤하고나름의묘한향을가진머스터드소스처럼다양하면서도미묘한맛을내며게임 database 속에녹아들도록만드는것이관건이다. 게임의데이터베이스는다른시스템과목표치가좀다르다. 온라인게임은하루 24 시간 일주일에 7 일내내안정적인서비스를지원할수있는 24 7 의서비스가요구된다. 온라인게임에서의서비스는곧돈과연결되 기때문이다. 또사용자들의편의를위해빠른응답속도도갖춰야한다. 3 부에서는 MMORPG 게임을중심으로대용량게임데이 티베이스에서고려해야할사항들에대해서살펴본다. 코드성데이터에유연성부여하기게임개발은기획에서부터시작된다. 만약개발도중기획이변경되면, 데이터베이스설계는물론게임서버에이르기까지모두변경되어야하는특성을가지고있다. 물론, 기획이누구도생각지도못했을만큼참신한것이아니라면기본적인틀은변경되지않는다. 게임기획은프로젝트의범위에서간혹빠지기도하지만거의모든경우게임계발의시작이된다. 게임의개발단계를정리해보면 기획-설계-구현-테스트 로구성되며이런프로세스는게임을서비스하는중에도발생한다. 대부분의온라인게임시스템은일반적으로 < 그림 1> 같은구조를가지고있다. 클라이언트게임서버 DB 서버 < 그림 1> 게임구성도 김호광 testcode@naver.com B2B로게임외주사업을하다가얼마전부터자사의게임서비스를준비중이다. 외주사업을통해모아둔돈을매일매일개발비로불태우다보니, 어떻게하면재미있으면서도비용은적게드는게임을만들수있을지가최대관심사이다. 이재학 admin@databaser.net 현재웹젠의 DBA (Database Administrator) 로근무하고있다. 데이터베이스정보를제공하는 www.databaser.net의운영자이기도하다. 게임서버나데이터베이스서버는기능에따라서나트랜잭션처리량에따라서스케일업 (Scale-Up) 하거나스케일아웃 (Scale-Out) 할수있다. 이때잊지말아야할중요한점은게임은 C.S 환경이아니라 n-trie 구조로이루어진다는것이다. 게임서버는클라이언트가게임을진행할수있도록코드성데이터를 micro software 2006+6
가지고있다. 이러한코드성데이터는엑셀 (Excel) 에담고있거나, 텍스트파일형태로게임서버에가지고있는경우도있고, 데이터베이스서버에저장할수도있다. 이런코드성데이터는어디에저장되어있는지에관계없이쉽게별할수있는특성을가지고있다. 기획에서특정속성이추가된다면데이터또한많은부분이수정되어야한다. 또한유지보수단계에서변화가일어난다면더욱많은신경을써야한다. 그럼시도때도없이변해야하는코드성데이터는어디에저장하는것이좋을까? 이에대한답으로데이터베이스에저장하는것이당연하다고말한다면, 데이터베이스는병화에약하기때문에말도안되는답이라고말하는사람도있을것이다. 하지만사실을알고보면데이터베이스에저장된코드성데이터라도어떻게설계하느냐에따라얼마든지유연성을부여할수있다. 이런부분들을감안하면 < 그림 2> 와같은설 아이템코드 ItemID ItemName 아이템기타 ItemID CodeName < 그림 2> 아이템코드테이블구조 ( 아이템코드의 Primary Key 는 ItemID) 계를할수있다. 만약기획이변경되어 추가컬럼1, 추가컬럼2 와같은컬럼이테이블에추가된다고가정하자. 그럼 아이템기타 테이블에는 ItemID의개수만큼행 (Row) 수가늘어나게되지만, 테이블의구조는절대로변하지않는다. 이런코드를읽기위한 SQL은 < 리스트 1> 과같을것이다. 얼핏봐도알수있듯이아주유연한설계가되었다. 이처럼유 < 리스트 1> 코드를조회하는 SQL CodeValue 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에서비정규화가정당하게받아들여지는이유는대부분의트랜잭션이한개의행에만접근하는포인트쿼리 micro software 2006+6
cover story 2 _ MMORPG 게임데이터베이스설계 (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) 가되어저장공간을절약하는결과를얻을수있다. 비정규화된테이블구조는저장공간을많이절약할수있다는 micro software 2006+6
정규화 캐릭터캐릭터일련번호캐릭터명 소유캐릭터일련번호아이템ID 비정규화 캐릭터캐릭터일련번호 아이템1 아이템2 아이템아이템ID 캐릭터명 아이템명 아이템1 아이템2 아이템20 아이템20 아이템아이템ID 아이템명 < 리스트 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> 캐릭터와아이템간 ERD < 리스트 4> 오라클해쉬분할방법 장점이있지만변화에대한대응은상당히취약하다는단점도함께가지고있다. 또한캐릭터와관련된트랜잭션과아이템관련트랜잭션이하나의테이블에몰리게되므로이또한록 (Lock) 에의한대기를유발시킬수있다. 필자는요즘은하드웨어의성능이비약적으로발전하였기때문에너무소프트웨어적인최적화를강조하여유지보수및운영비용을증가시킬필요는없다고생각한다. 파티셔닝으로관리효율높이기하나의테이블이 10억건이라면인덱스의깊이도깊어지고, 관리상의어려움이있으므로수평분할을고려해야한다. 만약 DBMS에서분할기능을지원한다면이를적극이용하면되겠지만분할기능이존재하지않는다면분리된객체의일부로관리해야한다. < 그림3> 의테이블을자동으로분류하여 10개의테이블에서관리해주면좋겠지만그런기능이없는경우는수동으로해주어야한다. 대리키는숫자이므로나머지연산자를사용하여 대리키 /10 의나머지를가지고분할키를사용하여분할할수도있다. MS-SQL Server 2000의경우는 파티션된뷰 라는것을제공한다. MS-SQL Server 2005에서는대용량데이터베이스를위한파티셔닝기능을제공하고있다. 필자가확인한바로는베타1 버전까지해시 (Hash) 키워드가존재하여해시분할이가능했는데정식버전에는없어졌다. 어쨌든분할기능을제공한다. 적절하게각각의테이블로분산시키려면 MS-SQL에 < 리스트 3> 과같은프로시저를작성하면된다. < 리스트 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 문이다. micro software 2006+6
cover story 2 _ MMORPG 게임데이터베이스설계 < 리스트 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#; 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) End COMMIT EXEC ( DBCC sqlperf(waitstats) ) SELECT @start = @start + 1 WAITFOR DELAY 00:00:05 SELECT * FROM WAITSTATS ORDER BY wait_time DESC -- 5 초간격으로수행 -- 롤백세그먼트경합률 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; 필자가게임업체에입사하기전에는게임데이터베이스에는뭔가특별한영역이있을것이라는기대도있었다. 하지만입사한뒤에는다른데이터베이스와큰차이가없음을실감한다. 어떤데이터를설계하든우리의목표는최종사용자가서비스를원활히사용할수있도록한다는공통목표를가지고있기때문이다. 게임에서다른점이있다면서비스의목표가 3초에서 0.3초로줄어들었을뿐이다. 필자가게임데이터베이스를설계할때가장중요하다고생각하는것은전체적은그림을잘그리는것이다. 게임운영뿐만아니라마케팅, 운영, 고객관계관리, 게임밸런싱조정등요구사항은얼마든지존재한다. 게임이실행될수있는환경이외에뒤에서고군분투하고있는운영자, 영업부서, 지원부서들의요구사항도충분히고려한데이터베이스를설계할수있도록노력하자. MS-SQL Server 2000에서는 DBCC sqlperf(waitstats) 명령을제공하여대기유형을분석할수있도록하고있다. < 리스트 6> 은대기유형을수집하는스크립트이다. < 리스트 6> 대기유형을수집하는스크립트 -- wait statistics 데이터지움 DBCC sqlperf(waitstats,clear) 무료로사용할수있는 DBMS 세상에공짜를싫어할사람이있을까? 특히큰돈이들어야하는일을공짜로할수있다면그보다좋은일이없을것이다. 게임업계의대다수가경우리눅스베이스로서버를개발하고 RDBMS를 MySQL로사용하는가장큰이유가비용의문제라는사실을부정하기는어려울것이다. 실제로상용 DBMS를구매하는비용은온라인게임서비스를만드는과정에서큰비중을 micro software 2006+6
차지한다. 때문에게임개발자들은상용 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 의특징 사실게임에서게임이 1GB 이상의데이터베이스용량을가지거나 5 커넥션을넘지않는것이일반적이다. 이런관점에서본다면무료 DBMS 를사용해서게임서버를구축하는것도고려해볼만하다. 특히, 우리나라와같이 MS SQL과 My SQL 일색인게임환경의경우, 보안관련이슈가많은두 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이유료로전환된지금에는새로운대안을고려해볼필요가있다. micro software 2006+6
cover story 2 _ MMORPG 게임데이터베이스설계 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 익스프레스에서제한되는기능 리포팅서비스미지원 OLAP/ 데이터마이닝서비스미지원 Analsys 서비스는미지원 DTS 미지원 데이터베이스미러링미지원 데이터베이스 4GB까지사용 메모리 1GB까지사용 SMP 미지원방식으로시스템을구성할수있었다. 요청하는외주의뢰사에서파이어버드보다인지도가높은 MS SQL을더믿었기때문에무료 RDBMS인 MS SQL 익스프레스를사용한것이다. 정리하자면주요 DBMS는 MS SQL을사용하여외주의뢰사의신뢰를얻고사용하지않는레거시데이터나비정기적인밀러링백업용으로는용량제한이없는인터베이스의오픈소스버전인파이어버드로구성한것이다. 이런아키텍처를온라인게임업계에적용할경우얻을수있는장점은다음과같다. User App Server MS SQL Express 밀러링 Firebird DBMS RDBMS 비용지출이없다. 기존의 MS SQL 개발자가별다른문제없이개발할수있다. MS SQL Express 밀러링 App RDBMS 용량이제한된범위를넘어서면 n대까지확장하여용량증가효과를낼수있다. 비숙련운영자도윈도우시스템에서쉽게관리할수있다. User Web Server < 그림 5> MS SQL 익스프레스를이용한서비스구성 MS SQL 익스프레스의엔진자체는 MS SQL 2005와동일하다. 용량이외에도지원되지않는기능이몇가지있기는하지만게임업계에서사용할때에는거의지장이없는수준이다. MS SQL 2005부터지원하기시작하는스토어드프로시저 (stored procedure) 의경우 MS SQL 익스프레스버전에서도지원한다. 구성한 C/S + 웹시스템은애플리케이션서버와다수의 MS SQL 익스프레스서버를두고 MS SQL 익스프레스가지원하지않는밀러링백업을위해서별도의백업서버를구축했다. 백업서버는 MS SQL 익스프레스와다른파이어버드 1.5x 버전을사용했다. 밀러링백업은실시간백업이아니라업무특성에따라야간에기존데이터를비교하여백업하는시스템으로구성했다. MS SQL 익스프레스의경우저장용량제한이있어서위의 의뢰한업체의신뢰도를얻기위해궁여지책으로찾은방법이었지만처음예상했던것보다장점이많은시스템이었다. 보통파이어버드는개발에관련된자료찾기가힘든것이단점이지만, My SQL에버금갈정도로빠른속도와스토어드프로시저의사용, 다양한운영체제의지원등장점이많은제품이다. 윈도우버전의파이어버드슈퍼서버의 SMP도곧출시될파이어버드 3.0 에서기능이확장될것이니저렴하게게임 DBMS를구축해보고싶은개발자라면고려해볼만한제품이다 ( 리눅스버전에서는 SMP가지원된다 ). 이말은돈을받고서비스를하거나소스가공개되어있지않은애플리케이션의경우상용 DB를구매해야한다는의미이다. 모게임업체의경우무료 DBMS인줄알고 My SQL을사용했다가라이선스취득권고를받고가격및조건을따지다가 MS SQL로자사 DB 를이식한경우도있다. micro software 2006+6
My SQL 은무료 DBMS 가아니다 My SQL이나왔을때참많은개발자들이기뻐했다. 필자역시아파치, PHP와함께무료라는점으로트랜잭션조차지원하지않는 My SQL로웹페이지와소규모게임포털을만들때여서더욱기뻤다. 당시만해도트랜잭션을해결하기위해느리디느린 InnoDB라는익스텐션까지사용하던시기였다. 그런데어느순간부터 My SQL이무료가아니라는이야기가들려오기시작했다. 한국에서도영업을한다는말이들려왔고일부기업의경우어쩔수 없이사용료를지불했다는소문도들렸다. 게임업계에서는 My SQL이 MS SQL과함께다수를차지하는 DB이기때문에그충격은적지않았다. CD만제공되는버전의가격이 892,500(VAT 제외 ) 원이며매년같은비용을지불해야한다. My SQL을몇년간사용한다면상용 DBMS를구입하는것과금액상으로도별차이가없을지경이다. 다음은 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나유저당라이선스입니다. < 월간 > 마소는개발자의일기장이기도합니다. I T 테크비즈니스정보지 1980 년대 GW - BASIC 을배우던경험을소중하게생각하는어느개발자가있습니다. 그가 < 마소 > 기자를보고이렇게말했습니다. 개발자로 10 년, 20 년이지날때마다곁에있어준 < 마소 > 가나의개발일기장이되었습니다 요즘 IT 세상은어떻습니까? 리눅스, 자바, 닷넷, 오픈소스등의플랫폼이넘쳐납니다. 그래도 80 년대, 90 년대에그랬던것처럼 < 월간 > 마소는개발자의가려운곳을먼저긁어주는개발자의길동무가되겠습니다. 서울시서초구잠원동 42-2 은정빌딩 3F TEL : 02-540-3070 FAX : 02-540-3090 www.imaso.co.kr micro software 2006+6