저희 회사의 시스템 구축 목표 중 아주 중요하게 생각하는 항목은 "가능한 모든 DB는
저렴하게 Active - standby를 구현하자"입니다. 결국 "
저렴하게 안정성 향상과 성능 극대화를 추구한다."라는 말인데, 이 문구를 보시면 많은 분들은 "저렴하게"라는 부분만 빼면 가능한 일이라고 생각하실겁니다. 저도 그렇게 생각하구요. 예산만 풍부하다면...
제가 생각하는 아주 좋은 회사는 장비(시스템)와 직원에게 비용을 아끼지 않는 회사입니다.(낭비가 아니라 "아끼지 않는다"입니다. 내가 원하는 기능, 성능 및 안정성을 제공하는 장비나 서비스를 구매하고 이에 비용을 지불하는건 낭비가 아니라고 생각합니다. 물론 사원에게도 마찬가지로 적절한 보수와 특근, 야근 수당을 다 챙겨주는...) 물론 이런 회사에 근무하는건 아주 드문 일이라고 생각합니다. 제가 DW 구축 및 Oracle DB 운영 업무(능력있는 사수님이 계셨었죠. 제가 부사수였습니다. ^^;)를 맡았었던 K사의 모 시스템에서도 비용을 절감하고, 보유한 자원을 최대한 활용하려는 노력은 끊이지 않았었죠. 대한민국 사람이라면 다 아는 큰 회사에서도 비용 절감은 중요한 사항이었죠.
제가 비교적 시스템 자원이 풍부한 곳에서 일을 해왔었던 탓인지 현재 재직중인 회사에 와서 좀 충격을 받았었습니다. 안정성 향상을 위해 Cluster 혹은 Standby 시스템을 구축하는데는 보통 비용이 많이 들기 마련인데, 그 비용에서 타협을 하면 안정성이나 성능도 어느정도 타협을 해야 하는데... 그렇게 생각을 하지 않으니...
암튼 초고속 인터넷이 보편화되어있는 대한민국의 IT 환경에서 안전한 백업보다도 고객들이 원하는건 중단되지 않는 서비스가 아닐까합니다. 그리고 실시간으로 Data 동기화 등의 작업이 이루어지길 원하죠.
경영진으로서는 당연히 직원들이 해결해야할 문제이고, 실무진으로서는 돈도 적게 주면서(예산, 연봉 및 수당을 말합니다.) 품질만 최고를 원한다는 불만을 가지게 됩니다. 아~ 힘들다.
DB Cluster를 구성하려고 여러가지 고민을 해봤습니다.
이번 글에서는 DBMS Cluster에 어떤 것들이 있는지 나열해보고, 제가 근무중인 곳에서 도입한 TAC에 대한 감상을 적어보겠습니다. 다른 DBMS Cluster에 대해서는 다음에 정리해서 올리도록 하겠습니다.
1. Oracle RAC
말이 필요없죠. 좋습니다. 가격이 너무 비싸다는걸 빼면요. 저렴하게 구축하려면, Linux 기반으로해서 공유 스토리지는 Oracle ASM을 이용하는 방법도 있습니다. Oracle 11g 이후 버전에서는 Raw device를 지원하지 않고 ASM을 기본으로 할지도 모른다고 하니까 성능에는 자신이 있는 모양입니다.
당연한 얘기지만 관련 서적도 제법 있습니다. RAC 자체에 대해서는 영문판 책이 대부분이며, 한글판으로는 RAC에서의 성능 문제에 대한 엑셈의 책도 있습니다.
2. IBM DB2 PureScale
메인프레임의 기술을 유닉스에서... Cluster 도입을 고려하던 당시에는 자료가 별로 없어서 제외했습니다.
Oracle RAC에 대항마로서 나온 제품 같습니다.(예전에 DB관련 세미나에 갔더니 고객들이 "RAC~ RAC~"한다고 한 숨을 쉬시더군요.) Oracle RAC처럼 모든 노드를 Active로 사용할 수 있다고 합니다. 단점은 아직까지는 AIX에서만 사용 가능하다는 점입니다.
3. MySQL Cluster
Active-Standby Cluster입니다. Standby DB는 평소에 읽기 전용으로 사용하기를 권장하더군요. 저희쪽에 제안을 들어온 업체의 제안 내용에 따르면, 일반적인 Intel CPU 장비를 제안해놓고는 메모리는 가득 채워서 설치하기를 요구하더군요. 쿼드코어 CPU 두장에 메모리는 128GB이던가... 그것만으로도 가격이 상당히 뛰더군요. 업체측에서는 Active-Active로 궁성을 해도, 거의 실시간으로 모든 노드에 Data 동기화가 이루어져서 Data 정합성이 깨지지 않는다고 하지만... 타 DBMS 업체에서는 이런 구조는 필연적으로 정합성에 문제가 생긴다고 하더군요... 뭐...
좋은 점은 공유 스토리지를 필요로 하지 않아서 SAN 및 공유 Storage 구축 비용이 절감된다는 장점이 있습니다. 그런데 개별 서버에 대용량의 메모리를 설치해야 한다는 점이 조금 걸립니다. 다양한 관련 서적이 있으며, HA관련 서적이 한글판으로도 출판되어 있습니다.
4. MS SQL Server Cluster
Active-Standby Cluster입니다. 일반적으로 얘기하는 HA구성이죠. MS-SQL 라이센스에 Cluster 라이센스를 구매해야하며, 당시엔 이에 대한 사내의 인식과 자료가 좀 부족해서 제외되었었습니다. 또한 MS SQL Server 자체에 대한 책은 많이 출판되어 있으나 HA에 대한 자료는 거의 없습니다.
5. Cubrid Cluster
NHN에서 Open source로 제공하는 Cubrid를 Cluster로 구성하는 방법입니다. Cubrid야 NHN에서 서비스에 사용중이니 안정성 등은 믿음이 가지만, Cluster는 아직 개선의 여지가 많이 필요한거 같아 보입니다. 큐브리드 부설 연구소에서 2008년도에 출판된 책이 한 권 검색되네요. 음... 최근 버전에 관한 내용은
큐브리드 홈페이지에서 찾으시면 됩니다. 그리고
Naver 개발자 센터의 CUBRID프로젝트와
큐브리드 공부하기 카페에서도 관련 정보를 찾으실 수 있습니다.
앞으로의 발전 가능성에 꾸준히 관심을 갖고 지켜보고 있는 제품입니다.
6. Tibero Active Cluster (TAC)
TmaxData의 Tibero RDBMS를 Oracle RAC 형태로 구성한 Cluster입니다. 영진 전문 대학이라는 레퍼런스가 존재했고, 견적을 냈을때 Oracle의 10분의 1에 해당하는 가격이라 이걸로 결정되었었습니다.
혹시 Tibero Active Cluster(이하 TAC)를 도입하려고 검토하시는 업체라면, 아주 신중히 결정하시라고 말씀드리고 싶습니다. TAC는 Tibero라는 DBMS를 Cluster로 구성한거라 Tibero의 약점을 그대로 가지고 있습니다. Oracle과 같은 문법을 제공하기에 기존 개발자가 적응하기 쉽다는 장점이 있지만, Oracle에서 당연히 되던 기능들이 작동을 안 하기도 합니다. 제가 썼던 글을 참조하세요.(
2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능)
그리고 기존의 DB 보안, DB 복제, ETL tool 등이 정상 작동을 하지 않는 부분이 많습니다. 관련 업체의 인증을 받았다지만, 관리 툴이 Tibero에서는 완벽하게 사용할 수 없다던지, 중요 기능이 대용량 Data 환경에서는 정상 작동을 하지 않는다는 문제가 있습니다. 관련 솔루션 테스트 중에 몇 십만건 단위의 Data 처리를 시키니까 DB가 뻗어버리더군요. ㅜㅜ
또 하나의 문제점이라면... Oracle RAC의 경우에 좀 저렴하게 구성하려면 Linux에 Oracle을 올리고, Oracle ASM을 이용하면, Veritas CFS 등의 Cluster filesystem을 구매하지 않아도 Cluster 구성이 가능한데, Tibero에는 자체적으로 제공하는 Cluster filesystem이 없어서 공유 스토리지 구성에 상당한 비용이 소요됩니다. 제 기억엔 TAC 자체 가격과 Veritas CFS 가격이 비슷했던것 같은 기억이...
또한 시중에 출판된 Tibero 혹은 TAC 관련 서적은 없습니다. TmaxData에서 제공하는 Tibero 관련 메뉴얼이 있으며,
테크넷(technet.tmax.co.kr)에서 PDF 파일로 다운로드 가능합니다. 왠만한 명령은 Oracle과 비슷한 문법을 제공해서인지 메뉴얼만으로도 해결이 가능합니다. 사실 이게 최대의 장점이죠.
