Background Image
조회 수 49355 추천 수 0 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

무중단 서비스를 위한 DB 서버 이중화 구축
죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다.

 

* 본 게시글은 월간 마이크로소프트웨어 7월호에 게재된 내용입니다.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
오보명 obm@nhn.com | NHN Business Platform 서비스 플랫폼 개발 센터에서 플랫폼 확산 업무 및 오픈소스 라이선스 컨설팅 업무를 담당하고 있다. 4년 전 CUBRID라는 국산 DBMS와 인연을 맺은 이후, CUBRID 의 국내/해외 확산 업무를 담당하고 있으며 CUBRID 글로벌 커뮤니티 사이트(http://cubrid.org)를 운영하면서 전세계 개발자들과 소통하고 있다.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 


2011년 6월 17일(금) 자정 00:00부터 오전 09:30분까지 국내 홈쇼핑 선두 업체의 쇼핑 사이트가 시스템 점검을 이유로 서비스 운영을 일시 중단했다. 해당 업체의 2010년 매출액과 온라인 쇼핑 매출 비율(30%)을 고려할 때, 1시간 당 매출액은 약 2,700만원이고, 9.5시간 동안 올릴 수 있는 매출액은 약 2억 5천만 원에 이른다. 물론, 대부분 고객들이 잠을 자는 시간이어서 실제 손실액은 훨씬 적었을 것이다. 당일 필자는 에어컨 가격을 알아보고 있었는데, 결국 다른 쇼핑 사이트에서 이를 구매했다. 서비스가 죽지 않아야 하는 이유? 바로 매출과 직결되기 때문이다.

 

왜 서비스는 중단되는가?
서비스 중단의 유형은 원인에 따라 크게 두 가지로 구분할 수 있다. 운영자가 예측하지 못한 장애 상황이 발생한 경우, 그리고 운영자가 의도적으로 서비스를 중단하고 시스템 점검과 같은 상시 운영 업무를 처리하는 경우이다. 이때 문제가 되는 것은 전자의 경우이다. 천재지변, 네트워크 단절, 운영 서버 리소스의 과다 사용, 하드웨어 고장 등의 이유로 장애가 발생하는 경우, 운영자가 원인을 판단하고 서비스를 정상 복구하기까지 상당한 시간이 소요되기 마련이다. 후자의 경우는 다행히 작업 시간을 미리 예측할 수 있지만, 사용자 방문이 가장 적은 새벽에 점검 작업을 수행하여야 하므로 운영자는 늘 피곤할 수 밖에 없다. 근본적으로 피곤은 “간” 때문이기는 하지만, 운영자의 피곤을 줄일 수 있는 확실한 방법은 바로 HA(High Availability) 시스템 구축이다.

 

서비스에 적합한 HA 솔루션 선택
서비스 가용성을 높이기 위한 방안으로 DBMS벤더들은 각각 다양한 방식으로 HA 솔루션을 지원한다. 아래 표는 각 제품 별 특징을 요약한 것이다.

table 1.jpg

 

표 1. 제품별 HA 솔루션의 특징 요약

 

Oracle RAC 및 MS-SQL Cluster는 공유 스토리지 기반의 구조를 따르고 있으며, MySQL과 CUBRID는 복제(Replication)을 사용하여 데이터베이스를 여러 대의 서버에 분산하는 구조를 채택하고 있다. 그 외에도 마스터/슬레이브 데이터베이스 간 동기화 방식과 복제 방식, 자동 절체(Auto-Failover) 기능의 유무, Failover 이후 어플리케이션의 자동 연결 여부 등 제품마다 동작 방식, 지원 기능 및 구축 비용이 매우 상이하다. 운영자는 예산, 서비스 규모 및 부하 패턴을 고려하여 적합한 솔루션을 채택할 수 있다.
지금부터는 비용 부담 없이 공개된 매뉴얼만으로 쉽게 고가용성 시스템을 구축할 수 있는 MySQL과 CUBRID에 대해 더욱 상세히 살펴보고자 한다.

 

목표 1. 죽지 말아야 한다.

 

웹 서비스 제공자는 누구나 서비스 가용성이 100%이기를 바랄 것이다. “서비스는 죽지 말아야 한다”는 목표를 달성하기 위해서는 데이터베이스 서버의 죽음을 미리 대비하고, 죽음을 반드시 알려야 한다. 이를 위해 CUBRID HA는 아래와 같은 기능을 제공한다.

• DB 서버 다중화 구성
• 복제 기반의 데이터베이스 동기화
• 장애 감지 및 Failover

 

1) DB 다중화 구성
CUBRID HA는 읽기/쓰기 부하를 담당하는 마스터 노드, 장애 시 마스터 기능을 대체하는 슬레이브 노드, 읽기 부하 분산을 담당할 수 있는 복제 노드를 조합하여 다양하게 구성할 수 있다. 아래는 CUBRID HA 구성의 예이다.

 

table 2.jpg

 표 2. CUBRID HA 구성의 예시

 

아래 그림처럼 CUBRID HA 기본 구성을 한 후, 마스터 서버에 장애가 감지되면, 브로커 미들웨어가 등록된 슬레이브 DB 서버의 상태를 확인하여 연결을 수립한 후, 사용자 요청(읽기/쓰기)을 처리한다. 만약, 브로커 서버와 DB 서버를 각각 분리한 구성에서 브로커 서버에 장애가 감지되면, 마찬가지로 인터페이스(JDBC, PHP, CCI 등)에 등록된 2차 브로커 서버의 상태를 확인하고 연결을 수립한다.

  

pic 1.jpg


그림 1. CUBRID HA 구성에서 마스터 장애 시 Failover

 

MySQL 기반의 HA 환경을 무료로 구성하는 대표적인 방법으로는 1) MySQL 복제와 Linux Heartbeat 패키지를 사용, 2) MySQL 복제와 MMM(Master-Master Replication Manager) 솔루션을 사용하는 것이다. 1)은 운영 편의성 측면에서 매우 취약한 구성인데 이유는 마스터 DB 서버에서 장애가 감지되더라도 운영자가 수동으로 Failover를 하고, 슬레이브 DB 서버와 연결되도록 어플리케이션의 연결 정보를 수동으로 갱신하여야 하기 때문이다. 한편, 2)의 경우는 CUBRID와 마찬가지로 자동 Failover 및 어플리케이션 자동 연결 기능이 지원된다.
 

pic 2.jpg


  

그림 2. MySQL 복제+ Linux HB 구성에서 마스터 장애 시 Failover

 

2) 복제 기반의 데이터베이스 동기화
CUBRID와 MySQL는 데이터베이스 동기화를 위해 복제 기법을 사용하지만, 복제의 동작 방식이 서로 다르다. CUBRID는 마스터 노드에서 데이터(row)의 변경 사항을 로깅하여 이를 복제하는 row-based 복제 기법을 사용하고, MySQL은 마스터에서 수행된 SQL 문을 그대로 로깅하여 복제하는 statement-based 복제 기법을 사용한다. Row-based 복제는 마스터의 모든 변경 사항에 대해 복제할 수 있고 보다 적은 LOCK을 사용하게 되어 동시성이 높다는 장점이 있다. 한편, statement-based 복제는 슬레이브로 SQL문만 복제하므로 마스터 서버에 부하를 덜 주지만 마스터와 슬레이브 사이에 데이터베이스 불일치가 발생할 수 있다.
그림 3은 CUBRID HA 구성에서 복제 방식을 나타낸 것이다. 마스터 노드에서 데이터가 변경되면 트랜잭션 로그와 복제 로그가 슬레이브 노드로 복사 및 반영되면서 마스터 및 슬레이브 데이터베이스가 동기화된다.
 

pic 3.jpg


 그림 3. CUBRID Row-based 복제 방식

 

3) 장애 감지 및 Failover
CUBRID는 HA 기능이 구현되었던 초기 버전(2008 R2.1이하 버전)에서는 MySQL HA와 마찬가지로 Linux Heartbeat 패키지를 사용하여 노드 상태를 감지하였으나, NHN 내/외부 서비스에 CUBRID HA 적용 후 Linux Heartbeat 패키지의 불안정한 문제들(예: 부정확한 장애 감지로 인해 원치 않는 failover 발생)과 설정의 어려움이 있어, 이후 버전부터는 자체 구현한 CUBRID Heartbeat을 내장하고 있다.
CUBRID HA로 구성된 모든 노드들은 네트워크를 통해 heartbeat 메시지를 주고 받으며 자신을 제외한 노드의 상태를 감시한다. 만일, 일정 시간 동안 특정 노드로부터 heartbeat 메시지를 수신하지 못하게 되면, 해당 노드에 장애가 발생한 것으로 판단한다.
만약, 마스터 노드에서 장애가 발생하면 즉시 구성 정보와 다른 노드들의 상태 정보를 조합하여 슬레이브 노드 중 마스터가 될 수 있는 후보 노드를 선택하고 이 노드에서 쓰기 연산이 가능하도록 해당 노드의 역할을 변경하기 위한 Failover를 수행한다.

  

pic 4.jpg


그림 4. CUBRID Heartbeat에 의한 장애 감지와 Auto-Failover

 

목표 2. 날리지 말아야 한다.

 

목표 1을 달성했다고 하여 모든 문제가 해결된 것은 아니다. 만약, 장애가 발생한 순간의 트랜잭션이 정상적으로 반영되지 않거나, 마스터 노드와 슬레이브 노드 간 데이터베이스 불일치가 발생한다면 어떻게 될까? 쓰기 연산이 비교적 많은 SNS또는 메신저 사용자라면 누구나 겪었을 경험, 열심히 글을 입력했는데 그 글이 보이지 않는 황당함을 서비스 고객이 겪을 수도 있다.
“날리지 말아야 한다”는 목표를 달성하기 위해 CUBRID HA는 세가지 동기화 모드를 지원하며, 운영자는 서비스 유형에 따라 적절한 모드를 설정할 수 있다.

 

table 3.jpg

 표 3. CUBRID HA의 동기화 모드 비교

 

목표 3. 빨라야 한다.

 

목표 1, 목표 2를 달성했다고 해도 여전히 남은 문제, 바로 HA 성능이다. 장애 발생 시점부터 서비스가 정상화될 때까지의 소요 시간을 최소화하기 위해서는, 1) 복제 지연 최소화, 2) 신속한 장애 감지, 3) 가용한 슬레이브 노드로 Failover 수행, 4) 어플리케이션이 슬레이브 노드로 즉시 연결 등 일련의 과정들이 신속 정확하게 수행되어야 한다. 그래야만 서비스 고객들이 순간의 서비스 중단을 눈치채지 못할 것이다.

 

1) HA 환경에서의 복제 지연 테스트
서비스 가용성과 안정성을 향상시키기 위하여 HA 솔루션을 도입할 때 반드시 고려해야 할 반대 급부가 바로 성능이다. HA 환경에서는 슬레이브 노드로 복제를 수행하므로 마스터 노드에 부하가 증가한다. 또한, 데이터 무결성을 보장하기 위하여 HA 동작 모드를 동기 모드(sync mode)로 설정한 경우, 비동기 모드(async mode)에 비해 마스터 노드에 부하가 증가한다. 문제는 이러한 복제 지연이 “얼마나” 실제 서비스에 영향을 주느냐인데, 이를 검증하기 위하여 간단한 테스트를 수행하였다.
마스터 노드 1개와 슬레이브 노드 1개로 구성된 HA 환경을 구축하고, 테이블 1개에 일정 개수의 레코드가 축적될 때까지 100% INSERT 연산을 수행하는 테스트이다. 일반 환경, HA환경(Async모드), HA 환경(Sync 모드)에서 각각 테스트를 수행하였다.
(CPU: Xeon(R) CPU 3065 @ 2.33GHz, Memory: 4G, OS: Linux CentOS 2.6.18, CUBRID 2008 4.0.0233, MySQL 5.5.11)

 

table.jpg

 

최신 버전의 CUBRID과, MySQL을 적용하여 테스트한 결과, 일반 환경에서는 MySQL의 입력 성능이 평균 20% 더 높지만, HA 환경(Async모드)을 구성했을 때는 CUBRID의 입력 성능이 평균 9% 더 높았다. 또한, HA 환경(Sync모드)을 구성했을 때는 슬레이브 노드에서 트랜잭션이 커밋된 이후에 마스터 노드에서 트랜잭션을 완료 처리하므로 Async일 때보다 약 2배의 시간이 소요되나, 복제 지연은 거의 없는 것으로 확인되었다. 단, 서비스 부하 패턴 및 장애 발생 시점의 복제 데이터 양에 따라 테스트 결과는 상이할 수 있음을 고려하여야 한다.

 

2) Failover 테스트
서비스 운영 중에 자주 발생되는 장애 유형을 6가지로 분류하고, 각 장애 상황에서 CUBRID HA가 성공적으로 Failover를 수행하는지에 관한 테스트이다. 덧글을 입력할 수 있는 게시판 어플리케이션에서 30개의 동시 쓰레드가 QPS 700 수준의 쓰기 및 읽기 연산을 수행하는 도중 장애가 발생하는 시나리오이다. 단, Failover 시간 및 TPS가 정상화되는데 소요되는 총 시간은 서비스 부하 패턴 및 장애 발생 시점의 복제 데이터 양에 따라 상이할 수 있음을 고려하여야 한다.
(CPU: 4 core * Xeon(R) CPU X3350 @ 2.66GHz, Memory: 4G, OS: Linux CentOS 2.6.18, CUBRID R2.2 Patch 9)

 

table 4.jpg

 표 4. CUBRID HA의 Failover 성능 테스트 결과

 

결론. 궂은 날 빛나리라.


지금까지 DB 서버 이중화 구축을 위한 각 제품별 HA 솔루션의 특징을 살펴보고, 비용 고민 없이 도입할 수 있는 오픈소스 제품인 MySQL과 CUBRID의 HA 의 동작 방식과 특징, 그리고 성능을 세가지 목표 관점에서 검토해 보았다.
만약, HA 시스템을 구축할 계획이 있다면 이것만은 명심하자. 걱정 없이 슬레이브 데이터베이스에 실시간 백업(hot backup)을 걸 수 있는 날, 서버 장비가 갑자기 고장 나도 서비스가 중단 없이 운영되는 날, 근무 시간 동안 DB 엔진 버전 업그레이드 작업을 완료하고 퇴근하는 날, 그 날은 온다는 것을.

 

 

참고문헌

[1] High Availability, http://en.wikipedia.org/wiki/High_availability, Wikipedia
[2] Failover, http://en.wikipedia.org/wiki/Failover, Wikipedia
[3] Shared Nothing Architecture, http://en.wikipedia.org/wiki/Shared_nothing_architecture, Wikipedia
[4] Oracle Database High Availability, http://www.oracle.com/technetwork/database/features/availability/index.html
[5] Database Mirroring in SQL Server 2005, http://technet.microsoft.com/en-us/library/cc917680.aspx
[6] MySQL HA/Scalability, http://dev.mysql.com/doc/mysql-ha-scalability/en/index.html
[7] CUBRID 4.0 매뉴얼, http://www.cubrid.com/manual/840/index.htm


 


  1. 죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다.

    무중단 서비스를 위한 DB 서버 이중화 구축 죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다. * 본 게시글은 월간 마이크로소프트웨어 7월호에 게재된 내용입니다. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 오보명 obm@nhn.com | NHN Business Platform 서비스 플랫폼 개발 센터에서 플랫폼 확산 업무 및 오픈소스 라이선스 컨설팅 업무를 담당하고 있다. 4년 전 CUBRID라는 국산 DBMS와 인연을 맺은 이후, CUBRID 의 국내/해외 확산 업무를 담당하고 있으며 CUBRID 글로벌 커뮤니티 사이트(http://cubrid.org)를 운영하면서 전세계 개발자들과 소통하고 있다. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2011년 6월 17일(금) 자정 00:00부터 오전 09:30분까지 국내 홈쇼핑 선두 업체의 쇼핑 사이트가 시스템 점검을 이유로 서비스 운영을 일시 중단했다. 해당 업체의 2010년 매출액과 ...
    Date2011.08.03 Category제품 여행 Byadmin Views49355
    Read More
  2. CUBRID BI 변경 뒷이야기

    CUBRID 2008 R4.0 Beta 출시에 맞춰 CUBRID BI (Brand Identity)가 변경되었습니다. BI를 변경하게 되었던 배경은 1) 글로벌 진출에 따른 차별화된 아이덴티티 확립, 2) 오픈소스의 친근한 이미지와 기업 솔루션의 전문적 이미지를 함께 추구할 수 있는 아이덴티티 확립, 3) 별도의 심볼을 제작하여 홈페이지, 사용자 커뮤니티, 제품 아이콘 등으로 아이덴티티를 확장 활용할 수 있는 필요성 3가지로 정리할 수 있습니다. 금년 2월부터 브랜드 디자인 컨셉에 대한 세부적인 논의가 시작되었고, CUBRID가 추구하는 컨셉을 “성능, 안정성, 기능 향상을 위해 끊임없이 진화하는 오픈소스 DBMS”로 정하고, 이를 위해 브랜드 심볼은 “도전, 진화, 성장, 혁신, 친근, 신선함”의 이미지를 제공하는 것으로 정리를 했습니다. 4월 초에 1차 작업으로 총 9개의 시안이 나왔으며, 이중 3개가 선별되어 한국/중국/루마니아로 구성된 CUBRID 커뮤니티 멤버들을 대상으로 선호도 조사가 진행되었습니다. 첫번째 로고는 “큐브(Cube)”와 “구조(Structure)”, 두번째는 “큐브(Cube, Data)”와 “연결(Bridge, Connect), 세번째는 “기하학(Geometry)”과 “무한(Infinite)”이라는 모티브를 기반으로 디...
    Date2011.05.20 Category알려요~ By정병주 Views48365
    Read More
  3. NHN은 CUBRID를 얼마만큼 사용하고 있을까?

    지난 주 목요일 전자신문 정보통신면(7면) 좌상단에 “NHN, DBMS 국산 ‘큐브리드’로”라는 제목으로 기사가 크게 게재되었습니다(관련 기사 참조). 국내 최대 규모의 데이터베이스를 보유하고 있는 NHN이 네이버 서비스와 사내 인프라에 적용되는 데이터베이스관리시스템(DBMS)을 모두 CUBRID로 교체한다는 내용으로 as-is와 to-be에 대해서 기술되어 있습니다. 기사 내용을 정리해 보면 아래와 같습니다. As-is - NHN은 3년 전부터 CUBRID DBMS를 적용하기 시작 -> 오픈소스 DBMS로 전환하기 전인 CUBRID 7.x 버전부터 사용 - 현재 네이버에서 제공하는 80여개의 서비스에 적용했음(NHN 전체 서비스의 30% 수준) - DB 서버 수 기준으로 NHN 전체 서버 중 5~6%에 해당 - 적용 분야도 카페 덧글, 블로그 덧글 등 대용량 서비스를 포함한 핵심 분야 To-be - DB 서버 수 기준으로 2011년 말까지 NHN 전체 서버의 약 30%에 CUBRID가 적용될 전망 - CUBRID DBMS 적용 서비스를 지속적으로 확대해 향후 2~3년 안에 가능한 모든 DBMS를 CUBRID로 전환할 계획 2008년 11월 CUBRID가 오픈소스 DBMS로 전환되고 2년 3개월이 조금 넘은 시점인데 NHN의 주류 DBMS로 자리매김을 했으며, 향후 ...
    Date2011.03.15 Category고객 적용사례 By정병주 Views29364
    Read More
  4. CUBRID vs. Oracle 총소유비용(TCO) 비교

    작년 말 CIO BIZ+ 기사를 통해 오라클이 서버용 SW 라이선스 정책을 수정했다는 내용을 확인하게 되었습니다. 내년부터 HP서버용 오라클 SW 가격 ‘2배’...썬은 50%↓ 기사 내용의 요지는 스팍 프로세서의 라이선스 팩터(코어에 대한 라이선스 가중치)를 0.75에서 0.5로 내리고, HP 아이테니엄 프로세서(팩터 0.5)와 IBM 파워 프로세서(팩터 0.75)에 대한 팩터는 1로 조정을 함으로써 HP/IBM 서버 기반으로 Oracle DBMS를 구축할 경우 라이선스 비용이 증가하게 되었다는 것입니다(Oracle for HP는 100%, Oracle for IBM은 33% 가격 인상 효과). 반대로 SUN 서버 + Oracle 조합으로 구매하는 사용자는 DBMS 라이선스에 대한 비용을 절감할 수 있고요. IBM이야 자체적으로 DBMS 제품(DB2)을 보유하고 있기 때문에 상대적으로 영향을 덜 받겠지만, HP는 상황이 달라지는 것 같습니다. 최근 코리아크레딧뷰로(KCB)가 유닉스 서버 가상화 및 통합 사업을 진행하면서 기존 HP 서버를 IBM 서버로 전면 교체하기로 결정을 했다고 합니다(관련 기사: HP 유닉스서버, 오라클 가격인상 직격탄 맞다). 반면 MS와의 협력을 강화하여 어플라이언스 4종을 발표하는 행보를 보이고 있고요(관련 ...
    Date2011.01.29 Category라이선스 고찰 By정병주 Views42591
    Read More
  5. CUBRID vs MySQL vs PstgreSQL 제품릴리스 시기 비교

    얼마 전 큐브리드가 제품 다운로드 10만건을 돌파했다는 소식을 전하면서 지인으로부터 많은 격려와 축하를 받았다. 큐브리드가 한 일이라기 보다는 큐브리드를 사용하고 있는 사용자들이 축하를 받아야 하겠지만 어찌됐던 기쁜 일이 아닐 수 없다. 생각해 보면, 국산 소프트웨어로서 그것도 오픈소스 소프트웨어로서 일반 애플리케이션이나 솔루션이 아닌 DBMS라는 조금은 어렵고 제한적인 소프트웨어를 10만건씩 다운로드 했다는 것은 이례적인 일이 아닐 수 없다. 이러한 결과가 가능할 수 있었던 것은 로그인없이 어느 누구나 제품을 다운로드 할 수 있도록 한 정책덕분도 있겠지만, 큐브리드를 기반으로 한 다양한 오픈소스 소프트웨어와의 연동으로 더 많은 사용자를 확보한 덕분이라고 할 수 있다. 뿐만 아니라, 무료로 진행하는 큐브리드 교육뿐 아니라 실시간으로 제품에 대한 궁금증을 8시간안에 해결해 주는 온라인 기술지원도 있었기에 가능했을 것이다. 그러나 무엇보다 지속적인이고 주기적인 제품 업데이트가 없었다면 가능했을까? 이러한 주기적인 업데이트를 하기 위해 이미 해외를 중심으로 추후 버전에 포함되었으면 하는 기능과 성능에 대한 의견을 적극적...
    Date2010.12.22 By멜라니 Views29819
    Read More
  6. CUBRID 서비스 계약에 대한 이해 – 독립 소프트웨어 벤더(ISV)

    지난 달에 최종사용자(End-user)를 위한 CUBRID 서비스 계약에 대해 간략하게 살펴보았습니다. 금번에는 독립 소프트웨어 벤더(ISV: Independent Software Vendor)들이 CUBRID 기반으로 응용 소프트웨어(애플리케이션)를 개발/포팅하여 판매하는 경우에 대해서 설명을 드리도록 하겠습니다. 우선, CUBRID는 오픈소스 DBMS이고, DBMS 엔진은 GPL v2 or higher, 인터페이스는 “BSD 라이선스”를 적용하고 있다는 것은 잘 알고 계실 것입니다. 여기서 인터페이스 함은 JDBC, PHP, ODBC, OLEDB, CCI (C Client Interface) 등을 의미하며, 일반적으로 DBMS 기반의 애플리케이션을 개발할 때 주로 사용합니다. 따라서, CUBRID는 ISV들이 애플리케이션 개발/포팅을 완료한 후 최종사용자를 대상으로 비즈니스를 전개할 때 애플리케이션 소스코드를 공개할 필요가 없으며, 이와 관련된 상세한 내용은 “차별화된 라이선스 정책, 큐브리드 OSS 라이선스 가이드”를 참고하시기 바랍니다. 첫번째 모델은 ISV가 큐브리드사 기술지원 서비스 계약 없이 자체적으로 애플리케이션을 개발하여 판매하는 방식입니다. 주로 소규모의 애플리케이션에 적합하며, 최종사용자에 대한 CUBRID 기술지원까...
    Date2010.11.16 Category라이선스 고찰 By정병주 Views32880
    Read More
  7. 오픈소스 소프트웨어 기반의 성공적인 비즈니스 모델

    11월 2일 지식경제부가 주최하고 정보통신산업진흥원, 한국공개SW활성화포럼, 한국공개소프트웨어협회에서 주관한 제2회 공개SW Day 행사에 참석을 했었습니다. 행사의 주요 일정으로 개발자 대회 시상식과 트레이닝 캠프가 진행되었으며, 오전에 카네기멜론대 실리콘밸리 캠퍼스에서 소프트웨어 매니지먼트 프랙티스를 가르치고 있는 Tony Wasserman 교수가 “Building a Business on Open Source Software”라는 주제로 해외초청 강연을 해 주셨습니다. Wasserman 교수는 강연을 시작하기 전 본인의 노트북과 LCD 프로젝터 간 연결이 매끄럽지 못해 잠시 난관에 부딪쳤는데, 그 와중에 “오픈소스 소프트웨어 행사에서 윈도우 기반의 노트북으로 발표를 하는 것이 맞느냐?”라는 질문을 던져 청중들에게 웃음을 선사했습니다(Wasserman 교수는 리눅스 OS를 사용함). 총 11개의 비즈니스 모델에 대해서 발표를 해 주셨고, 대부분 일반적인 내용들이라 새로움 또는 신선함에 대한 욕구 충족은 되지 않았지만, 전반적으로 핵심 내용만 잘 기술되어 있어서 발표자료의 일부를 발췌해 보았습니다(영어 단어가 평이하여 번역하지 않음). Subscription Model - User downloads software ...
    Date2010.11.13 Category오픈소스 이야기 By정병주 Views42355
    Read More
  8. CUBRID 서비스 계약에 대한 이해 – 최종사용자

    CUBRID는 오픈소스 라이선스를 채택하고 있습니다. DBMS 엔진은 GPL v2 or higher, 인터페이스는 BSD 라이선스를 적용하고 있으며, 소프트웨어 사용에 아무런 제약조건이 없습니다. 따라서 상용 소프트웨어와 같이 소프트웨어 라이선스(사용권)를 얻기 위해 비용을 지불할 필요가 없습니다. (참고: CUBRID 라이선스 및 서비스 정책에 대한 고찰) CUBRID는 별도의 라이선스 비용 없이 서비스 비용만 지불하면 되며, 고객들을 만날 때 자주 질문 받는 내용 중 하나인 서비스 정책과 계약 방법에 대해 살펴 보도록 하겠습니다. CUBRID의 서비스 정책은 크게 프로페셔널 서비스와 서포트 서비스로 나뉘어집니다. 프로페셔널 서비스는 개발 단계에서 제공되는 서비스로서 DB 설계 지원, 스키마 리뷰, 질의 리뷰, 데이터 변환 및 성능 튜닝 서비스 등이 포함되어 있습니다. 비용은 시간당 9만원(VAT 별도)이며, 지원 받고자 하는 시간만큼 계약을 체결하고 서비스를 제공 받으시면 됩니다. 응용 개발이 끝나면 일반적으로 운영 단계로 넘어갑니다. 운영 단계에서는 정기적인 예방점검(PM: Preventive Maintenance)을 통해 문제 발생을 선제적으로 방지하고, 각종 온라인 지원 및 트러...
    Date2010.10.12 Category라이선스 고찰 By정병주 Views35456
    Read More
  9. 함께이기에 더욱 보람된 오픈소스 소프트웨어 확산! XE와 함께하는 큐브리드

    지난 SW업계에 있으면서 늘 들어왔던 사용자들의 소프트웨어에 대한 인식 재고에 대해 절감을 하는 게 아마도 가장 최근이 아닐까 싶습니다. IT환경속에서 무형의 자산인 소프트웨어의 활성화가 하드웨어만큼 발전하지 못한 것도 어찌보면 이 이유에서지 않을까 싶은데요… 국내에서 몇 되지 않은 오픈소스 소프트웨어 업체로서 어찌 보면 쉽지 않은 도전을 하고 있는 큐브리드에게는 더욱 더 실감하는 부분이 아닐까 싶습니다. 예전 외국의 오픈소스 사용현황 및 참여도 현황 자료를 보니 외국의 경우, 여기서 말하는 외국이라 하면 대부분이 선진국을 말하지만 이웃 중국이나 태국의 경우에도 오픈소스 소프트웨어에 대한 관심과 참여도가 우리나라 보다 높게 나타나고 있었습니다. 그만큼 국내에서 오픈소스 소프트웨어라는 분야에 있다는 것이 쉽지 않은 게임이라고 할 수 있겠죠. 더욱이 소프트웨어 중에서도 어렵다는 데이터베이스쪽에서의 오픈소스는 외부에서 프로젝트에 참여할 개발자를 발굴하고 같이 성장하는 것이 더욱더 어려워 보입니다. * 출처: 레드햇과 조지아 공과대학교가 공동으로 전세계 75개국의 오픈소스 환경을 비교, 분석한 ‘오픈소스 인덱스’ 보고서....
    Date2010.07.22 By멜라니 Views43487
    Read More
  10. 기획연재[6] CUBRID 제품 분석 – 클릭카운터

    이번 제품 분석에서는 클릭카운터 기능에 대해서 알아보도록 한다. 인터넷 서비스 중 접속자의 관심도 등을 알아 볼 수 있는 방법으로 조회수를 확인한다. 현재 많은 인터넷 서비스에서 조회수를 이용한 관심도 및 서비스 이용량 정도를 파악하고 있다. 이를 위하여 CUBRID에서는 클릭카운터 함수를 지원한다. 클릭카운터란 인터넷 서비스 중 조회수 증가를 위한 select/update작업을 한번에 처리해 주는 기능을 말한다. 이는 사용자 정의 트랜잭션과 별도로 시스템 내부에서 사용되는 top operation이 적용되어 트랜잭션의 commit/rollback과 상관없이 데이터베이스에 자동으로 적용된다. 클릭카운터 기능을 사용하기 위해 사용하는 함수로는 INCR/DECR함수가 있다. INCR는 1씩 증가, DECR는 1씩 감소하는 함수이다. 각 함수는 select문의 최상위 구문에서만 적용되어 사용되며 sub select문에서는 지원하지 않는다. select절에 INCR 함수를 명시한 경우, COUNTER 값을 1 증가하고 질의 결과는 증가하기 전의 값으로 출력한다. 그리고, INCR 함수는 질의 처리 과정에서 참여한 행(tuple)이 아니라 최종 결과에 참여한 행에 대해서만 값을 증가시킨다. 아래는 incr함수의 사용 ...
    Date2010.06.07 Category제품 여행 Bycubebridge Views38258
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 Next
/ 9

Contact Cubrid

Tel. 070-4077-2110 / Email. contact_at_cubrid.com
Contact Sales