Background Image
조회 수 62 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
가끔 퇴근길에 서점에 들르곤 한다. 직업이 직업이라 그런진 몰라도 항상 IT코너에 머물러 어떤 새로운 책들이 출간되었나 보게 된다. 
그러다보면 최근 유행하는 컨셉이나 아키텍쳐, 프로그래밍 언어나 개발방법론 등에 대해 트렌드가 뭔지 관찰하려고 안해도 자연히 접하게 되는 것 같다. 
그 중 최근 유행처럼 사람들 입에 오르내리기도 하고 책으로 소개되기도 하는 개념들 중 MSA(Micro Service Architecture)라는 것이 있다.
뭔가 하고 들여다보니 MSA 개념에서 다루고 있는 '독립적으로 수행되는 최소단위의 서비스' 그리고 그 서비스들의 집합으로서의 시스템과 시스템의 분할에 관한 관점 및 해석은 십수년전 주목받던 SOA(Service Oriented Architecture)가 지향하는 서비스를 구성하는 기능별 시스템의 분할과 크게 다르지 않다. 

이 글은 MSA와 SOA가 얼마나 비슷한 사상으로 소개된 개념인지를 이야기하고자 함이 아니다. 예전에도 의미있게 다뤄졌고 지금도 의미있게 받아들여지는 이러한 개념들이 시스템의 관점에서 더 좁게는 DBMS라는 시스템 소프트웨어적 관점에서 어떻게 해석될 수 있는가를 간단하게 짚어보고자 함이다. 

MSA의 개념이 제대로 구현되기 위해서는 시스템이 제공하는 서비스들간 그리고 서비스와 서비스의 수요자간의 추상화된 관계가 명확하게 정의되어야 하며 이는 분산시스템의 확장성측면에서 매우 중요한 고려사항이 된다. 매우 중요한 고려사항이 된다는 이야기는 해당 분산 시스템의 아키텍쳐를 결정하는 요소가 된다는 의미이다.

서두가 길었지만 '확장성'말고도 분산시스템의 아키텍쳐를 결정하는데 영향을 미치는 요소는 '성능(performance)', '사용성(usability)', '편의성(user convenience)', '모니터링의 용이성(monitoring)', '기능성(functionality)', '가용성(availability)' 등 여러가지가 있다.

예를들어 흔히 이중화라고 하는 replication의 경우 HA(High Availability)를 충족시키기 위한 아키텍쳐이다. RAID라는 용어를 들어보았을 것이다. data redundancy를 제공해 media(disk) 차원에서의 MTTF를 최소화하려는 아주 오래된 컨셉이다. HA라는 것은 시스템이 제공하는 서비스 총체적인 차원에서의 MTTF를 최소화하려는 redundant한 시스템 아키텍쳐이다. 
이러한 목적으로 구현된 replication은 그 구현을 위한 기술요소가 분산인 것이지 분산시스템으로서 갖고 있는 목적 자체는 HA인 것이다. 시스템 소프트웨어 개발자들이 흔히 하는 실수는 HA를 목적으로 만들어진 replication을 갖고 다른 분산시스템 예를 들어 흔히 생각해볼 수 있는 cluster(active-active가 되는)도 만들고 cdc(changed data capture)도 만들고 sharding(단순한 table partitioning이 아니라  볼륨의 증감에 따라 re-sharding이 되는 sharding을 말한다)도 만들고 그럼 된다고 생각하는 것이다. 
하지만 그런 안일한 생각이 수개월 혹은 수년의 개발기간을 거쳐 만든 분산 기능자체를 버그 덩어리 내지는 수년간 repository에서 숙성기간을 거치면서 수많은 개발자들에 의해 더럽혀지다가 결국엔 제대로 써보지도 못한채 방치되거나 버려지는 몹쓸 코드덩어리를 만들어낸다.

모두 분산을 위한 기술요소를 갖고 있음에는 틀림이 없다. 하지만 아키텍쳐는 해당 시스템의 목적에 따라 달라져야 한다. 그리고 가능한 기존 시스템에 안좋은 영향을 주지않도록 설계되어야 한다. 위에 열거한 모든 요소들을 하나의 시스템 소프트웨어에서 만족시키는 아키텍쳐를 구현하기란 쉽지 않은 일이다. 

그래서 최근의 시스템 아키텍팅의 트렌드는 단일 목적에 특화된 여러 시스템들의 정합성을 고려하여 커다란 시스템으로 엮는 것이다. 그리고 그러한 트렌드에 맞춰 손쉽게 오케스트레이션을 할 수 있도록 해주는 쿠버네티스같은 플랫폼들이 인기를 끌고 있다.  

하지만 하나의 시스템이 만약 해당 서비스에 필요한 대부분의 요소들을 모두 제공한다면? 굳이 여러 시스템을 엮어 쓸 이유가 없다. 여러 시스템을 엮는다는 것은 그만큼의 비용(데이터 처리 비용)이 증가한다. 데이터가 시스템에 들어와 사용자에게 전달될 때까지 지나치는 경로가 길어질수록 비용은 증가한다. cpu core를 예로 들어보자. data와 instruction이 전달되는 경로를 bus라고 한다. 그 bus의 길이를 보다 짧게 하려고 cache도 두고 locality를 증가시키기 위한 무수한 노력을 한다. 그러다가 하나로 안되니 두개를 붙이고 4개를 붙이고 6개를 붙이고 core수를 늘리다가 결국 특수 목적의 연산유닛이었던 GPU도 붙이고 그런다. GPU를 그냥 옆에 쓸수있게 붙여놓기만 했던 시절에는 GPU에서 처리한 데이터를 다시 cpu에서 받아 처리하는데 필요한 데이터 복제 (메모리간)비용이 상당했고 그걸 처리하기 위한 고민과 기술들이 필요했다. 그러나 지금은 하나의 칩에서 대부분의 작업을 거뜬히 해낼 수 있게 되었다. 

분산시스템도 마찬가지다. 10년전만 해도 하둡하둡하면서 하둡만이 살길인양 분산시스템을 구축하는 프로젝트에서는 너도나도 하둡개발자를 찾았지만 이젠 하둡도 쓸까말까를 고민한다. 

하나의 시스템 혹은 플랫폼이 등장할 때마다 그것을 이용한 보다 나은 조합들이 나오고 정말 최고의 조합이어서든 자본에 의해서든 적어도 2~3년은 이쪽 업계 사람들의 입에 오르내릴만한 조합들이 나오곤 한다. 그러나 분산 시스템을 이해하는 개발자 관점에서 아쉽게 느껴지는 것들이 참 많다. 그중 하나는 브랜드파워 내지는 거대자본의 투입(대대적인 글로벌 컨퍼런스의 개최라든지 프로모션과 같은 것들)이 가능한 시장의 leading company에 의해 그들이 제공하는 조합 내지는 그들의 플랫폼, 그들의 제품을 사용하지 않으면 뒤떨어질 것 같은 인식이 확산되는 경향이 최근들어 빈번하게 발생하고 있다는 것이다. 한번 이러한 인식이 형성되기 시작하면 다른 조합은 이미 고려대상이 아니게 될 뿐 아니라 서비스 차원에서 시스템을 아키텍팅하는 엔지니어들 조차 소위 '대세' 시스템 아키텍쳐를 공부하고 모방하며 뒤질세라 자신의 세미나를 발표하면서 시스템의 획일화에 기여한다. 

그러나 사실은 아니 진실은 '누구나 그렇게 해야만 할 것같은 그런 분위기'가 아니다. 위에 열거한 서로 다른 요소들이 어떤 우선순위와 가중치를 갖고 시스템에서 제공되어야 하는가에 대한 고려가 우선되어야 한다. 조합 가능한 서로 다른 시스템들의 가짓수가 늘어날수록 솔루션으로서의 분산시스템 아키텍쳐 구성의 가짓수또한 증가한다. 

그런 와중에도 대부분의 분산 아키텍쳐에 중요한 고려사항으로써 항상 포함되는 건 데이터베이스이고 데이터베이스를 관리하는 시스템이다. 스트림처리를 통해 저장할 필요없이 사용 후 바로 제거되어도 되는 데이터들을 제외한 모든 데이터들은 데이터베이스를 한번씩은 거치기 마련이기 때문이다. 

DBMS는 이러한 데이터베이스를 관리하기 위한 시스템이고 많은 진화를 거듭하면서 보다 완전한 시스템이 되어가는 중이다. 아직도 가야할 길이 많지만 적어도 30년전 oracle을 생각하면 지금의 oracle은 거의 천상계가 아닌가.

혹자는 '빅데이터 시대'가 도래하고 부터는 DBMS는 퇴물이고 이제 곧 그 자리를 다른 시스템들이 대체하게 될거라는 말들을 하곤 한다. 미안한 말이지만 당신 앞에서 이런 이야기를 던지는 사람이 시스템 컨설턴트라면 그들이 제안하는 시스템 아키텍쳐를 신뢰하지 말라고 충고하고 싶다.

'빅데이터'는 이를 처리하는 단일 시스템에 보다 효율적인 처리를 위해 새로운 처리방식 혹은 새로운 데이터 모델링을 요구하거나 해당 시스템의 처리량을 넘어선 데이터 공급량으로 인해 보다 효율적인 처리방식을 고려하도록 하는 변화된 데이터환경 자체를 비즈니스적으로 표현한 말이고 시스템적 관점에서 '사실상의 대용량(때때로 실시간의 처리가 요구되는)'을 달리 표현한 말에 지나지 않는다. ('빅데이터'라는 용어가 확산되기 시작했던 2010년대 초반 필자가 국내학회지에 기고했던 글을 참조해보면 이 문장의 의미가 더 잘 이해해될 수도 있다. 참조 문서: 데이터 환경의 변화와 분산 데이터베이스 시스템)

그러나 사실 DBMS는 사실상의 대용량 데이터를 처리하기 위한 시스템이다.
DBMS가 오래전부터 맞닥드린 데이터 환경이 바로 '대용량'이고 이 '대용량'의 기준은 점점 높아져 왔을 뿐이다. 따라서 DBMS의 고민은 다름이 아니라 애초부터 대용량이었다. 1970년대 등장한 RDBMS의 시조새격인 ingres 도 이 대용량(당시의)을 처리하기 위해 만들어졌다. 

대용량 데이터의 처리는 DBMS의 숙명과도 같은 것이다. 

'대용량'이라는 키워드와 더불어 DBMS가 항상 안고 가는 숙제가 하나 있다. 바로 '실시간'이다.
'실시간'은 시스템, 즉 DBMS의 성능과 밀접한 관련이 있다. 뭘 실시간으로 제공하느냐에 따라 아키텍쳐는 달라진다. 저장관점에서의 쓰기연산이 실시간으로 이루어져야 하는지, 아니면 검색관점에서의 읽기연산이 실시간으로 이루어져야 하는지, 아니면 읽고쓰는 대부분의 연산에서 실시간이 보장되어야 하는지, 서비스에 따라 실시간의 허용범위는 어느정도인지 등 서비스 환경에 따라 다양하다.
DBMS는 이러한 저장 데이터베이스에 대해 수행되는 읽고쓰기 연산의 결과를 상위 시스템 혹은 클라이언트로 전달하는 주체로써 실시간성을 중요하게 고려한다. 

이렇듯 DBMS는 실시간과 이전에 설명한 대용량에 대한 처리를 고민하면서 분산 DBMS로 발전한다. 

하나의 통합 서비스에서 처리해야 하는 데이터의 양이 DBMS가 처리할 수 있는 수준범위 내에 있다면 다른 시스템은 필요가 없다. 그저 데이터를 받아 DBMS로 전달하는 일만 하면 된다. 그러나 그 데이터들을 DBMS가 다 처리를 못한다. 그래서 중간에 여러 DBMS들에 실시간으로 데이터들을 분산시켜 던져주는 미들웨어 시스템을 두고 DBMS마다 처리하는 속도가 달라 처리된 시점에 필요한 놈이 가져가게 하기 위한 message queue를 둔다. message큐가 처리할 수 있는 용량에도 한계가 있고 가용 저장장치에도 한계가 있기 때문에 저장용 cache를 따로 둔다. 그리고 데이터를 소비한 후 visualization을 따로 해줘야 하는 경우 처리를 위한 시스템을 별도로 엮기도 한다. 이건 하나의 예에 불과하다. 

결국 쉽게 말하면 DBMS가 못따라가는 데이터처리를 다른 시스템들을 붙여 어떻게든 그래도 효율적으로 처리해보려는 것이다. 

그래서 DBMS는 나날이 커져만 가는 대용량에 대응할 수 있는 시스템으로 진화해야 한다. '나날이 커져만가는 대용량에 대응'하기 위한 요소가 바로 '확장성'이다. 하나의 처리 노드에서 감당할 수준을 넘어선 데이터량 때문이다. 이러한 확장성을 갖춘 DBMS는 분산 feature를 장착한 분산 DBMS라고 할 수 있다. 하지만 아직 다양한 서비스 환경에서 실시간 처리에 대한 요구를 만족시켜주는 단일 분산 DBMS는 찾아보기 힘들다. 분산 DBMS로 가야할 길은 아직 멀고 험하다. 어쩌면 일개 시스템소프트웨어 개발자에게는 영원히 끝이 보이지 않는 길일 확률이 아주 높다. 그럼에도 불구하고 DBMS의 숙명과도 같은 '대용량의 데이터를 실시간으로 처리'하기 위해 DBMS는 진화하고 또 진화해간다. 

시스템 소프트웨어 불모지인 대한민국의 국산 DBMS로서 이미 그 효용성을 입증한 큐브리드가 그렇게 진화해가길 진심으로 바란다.


  1. No Image

    분산 시스템으로서의 DBMS, 그리고 큐브리드

    가끔 퇴근길에 서점에 들르곤 한다. 직업이 직업이라 그런진 몰라도 항상 IT코너에 머물러 어떤 새로운 책들이 출간되었나 보게 된다. 그러다보면 최근 유행하는 컨셉이나 아키텍쳐, 프로그래밍 언어나 개발방법론 등에 대해 트렌드가 뭔지 관찰하려고 안해도 자연히 접하게 되는 것 같다. 그 중 최근 유행처럼 사람들 입에 오르내리기도 하고 책으로 소개되기도 하는 개념들 중 MSA(Micro Service Architecture)라는 것이 있다. 뭔가 하고 들여다보니 MSA 개념에서 다루고 있는 '독립적으로 수행되는 최소단위의 서비스' 그리고 그 서비스들의 집합으로서의 시스템과 시스템의 분할에 관한 관점 및 해석은 십수년전 주목받던 SOA(Service Oriented Architecture)가 지향하는 서비스를 구성하는 기능별 시스템의 분할과 크게 다르지 않다. 이 글은 MSA와 SOA가 얼마나 비슷한 사상으로 소개된 개념인지를 이야기하고자 함이 아니다. 예전에도 의미있게 다뤄졌고 지금도 의미있게 받아들여지는 이러한 개념들이 시스템의 관점에서 더 좁게는 DBMS라는 시스템 소프트웨어적 관점에서 어떻게 해석될 수 있는가를 간단하게 짚어보고자 함이다. MSA의 개념이 제대로 구현되기 위해서...
    Date2019.03.29 Category나머지... By조성룡 Views62
    Read More
  2. [CUBRID 유틸리티] restoreslave에 대하여 알아보자.

    CUBRID는 10.1 version 이상부터 restoreslave란 명령어를 제공한다. CUBRID 9.3.x version 까지는 온라인 재구성을 위해 자체적으로 제공되는 shell script를 사용하였으나, 10.1 version 이상부터는 restoreslave 명령을 통해 보다 편하게 작업을 할 수있다. 해당 명령어를 통해 master의 구동 상태와는 상관 없이, slave를 재구축 할 수 있으며, 시나리오는 아래와 같다. 1. HA 서비스 중, 이중화가 깨졌을때. (1) 필요 환경 : master - slave의 이중화 환경. (2) 필요 파일 : master 서버의 backup file (3) 시나리오 - DB의 이중화가 깨지는 것을 재연하기 위해 slave의 db_ha_apply_info의 데이터를 삭제한다. - slave의 heartbeat를 종료한다. slave) $> csql -S -u dba --sysadm demodb sysadm> delete from db_ha_apply_info; - 위의 이중화 로그를 삭제하였을 경우, 동기화는 더이상 이루어지지 않는다. - 위의 행위로 인하여 DB 이중화가 깨졌다고 판단하고 이중화복구를 진행하여보자. - master에서 backup 받은 backup file은 slave에 옮겨놓은 상태이다. slave) $> cubrid service stop -- cubrid sevice 종료 $> ps -ef | grep cubrid -- CUBRID process가 모두...
    Date2019.03.29 Category제품 여행 By박동윤 Views49
    Read More
  3. CUBRID 커버링 인덱스(covering index) 이야기

    CUBRID 2008 R4.0 버전 이상부터는 커버링 인덱스를 지원합니다, 커버링 인덱스는 “A covering index is a special case where the index itself contains the required data field(s) and can return the data.”라고 하는데 원문을 해석하면 커버링 인덱스는 인덱스 자체에 필수 데이터 필드가 들어 있고 데이터를 반환할 수 있는 특별한 인덱스라고 해석됩니다, 다시 정리하면 하나의 질의 내에 특정 인덱스를 구성하는 컬럼만 사용하는 경우를 커버링 인덱스를 사용하게 됩니다. 아래 예제-1)에서 SELECT 질의의 WHERE 조건에 사용된 컬럼 i와, SELECT 리스트로 주어진 컬럼 j는 모두 인덱스 idx를 구성하는 컬럼입니다. 이와 같은 경우에 CUBRID는 SELECT 질의를 수행할 때 커버링 인덱스를 스캔 하게 됩니다, 이는 하나의 인덱스가 SELECT 문이 요구하는 조건과 결과를 모두 포함하고 있기 때문에 가능한 일입니다. 예제-1) CREATE TABLE tbl (i INT, j INT); CREATE INDEX idx ON tbl(i, j); SELECT j FROM tbl WHERE i > 0; 그렇다면 왜 커버링 인덱스라는 개념이 필요할까?, 우선 설명에 앞서 우선 CUBRID의 인덱스 구조에 대해 간단하게 설명하겠습니다. CUBRID는 B+T...
    Date2019.02.28 Category제품 여행 By정만영 Views125
    Read More
  4. CM을 통해 SQL을 분석해보자.

    SQL을 수행하다 보면 SLOW SQL이 많이 발생합니다. 이럴때, 해당 SQL의 실행계획을 확인 함으로써, 지연을 발생시키는 부분을 쉽게 찾을 수 있습니다. 1. SQL 서식화. - 보통 SQL을 LOG에서 copy 할경우 가시적으로 보기 힘든경우 사용합니다. 2. 질의 실행 계획보기. - 질의편집기에 SQL을 작성 후, 질의 실행계획보기를 통하여 해당 SQL의 실행계획을 확인 할 수 있습니다. 2.1 질의실행계획보기 --계속 - 질의 실행 계획보기를 실행 시, 질의 계획의 원본, 트리출력, 그래픽출력 등으로 쉽게 확인이 가능합니다. - 이글에서 주로 다룰 내용은 트리출력이며, 보다 사용자가 보기 편리한 구조로 이루어져 있습니다. - 해당 내용을 분석하면, olympic 테이블과 record 테이블은 서로 inner join으로 조인이 이루어 집니다. - olympic 테이블은 FULL SCAN이 일어났으며, 모두 디스크 io가 발생하였습니다. - record 테이블은 primary key(host_year)을 사용하여 인덱스 범위검색을 하였습니다. - 이때, olympic 테이블에서 추출한 레코드는 총 25개 이며, record 테이블에서는 2000개의 레코드를 추출하였습니다. - olympic 테이블에서의 전체 row는 25건이며, 페이지로는 1게 ...
    Date2019.01.01 Category제품 여행 By박동윤 Views165
    Read More
  5. No Image

    실패하지 않는 마이그레이션을 위해서 고려해야 될 사항

    실패하지 않는 마이그레이션을 위해서 고려해야 될 사항 클라우드 전환에 따라 기존 유지보수 비용이 높은 UNIX 체계에서 Linux 체계로 전환하면서 오픈소스 유형의 SW로 전환하는 사례가 많아졌다. 도입단가, 비용문제로 고객과 SW밴더간의 이견을 좁히지 못해서 대체 SW로 전환하는 사례도 있다. 그 이외에도 노후장비 교체시기에 SW까지 함께 교체하는 경우도 있는데 OS 및 WAS, 그리고 Database System과 같은 기업 서비스의 근간이 되는 Package SW들이 주 대상이 된다. 위 3가지 중에 대체 SW로 변환하는데 있어 어려움이 발생하는 영역으로 WAS 및 Database System 부분이 될 수 있는데 그 중에서도 Database System이 난위도가 높으며 성공여부를 가늠하는 핵심적인 부분이기도 하다. 다른 대체 SW로 전환하는 작업을 Win-Back 마이그레이션이라는 용어를 사용하기도 하는데 성공적으로 수행하기 위해서 꼼꼼하게 대비해야하는 사항들이 있다. 다수의 DBMS 전환작업을 해오면서 성공과 실패를 통해 경험한 내용을 기반으로 Win-Back 마이그레이션 프로젝트를 수행하는데 고려되어야 할 사항들에 대해서 공유하고자 한다. 1. 제품선정(RDB) DBA또는 그에 준하는 역할을...
    Date2018.12.31 Category나머지... By김창휘 Views215
    Read More
  6. CMT(CUBRID Migration Tool) 활용

    CMT를 이용하여 데이터 마이그레이션 작업하면서 여러가지의 팁이 있겠지만 4단계에서 유용하게 사용할 수 있는 팁중 PK가 없는 테이블에 대해서 데이터 수행전에 PK 선택하거나 또는 테이블 생성 후 PK 컬럼을 추가하여 데이터 마이그레이션하면 되는 팁을 알려 드리겠습니다. 1) PK가 없는 테이블에 대해 이관전 PK 컬럼 선택 후 데이터를 이관하는 방법 2) PK가 없는 테이블 정보를 그대로 생성하고 데이터를 이관전에 seq 컬럼을 추가하여 그 컬럼에 대해 PK로 만들어 주므로 PK에 대한 재작업이 안해도 되는 방법 위 두가지를 병행하여 데이터 이관 작업을 진행하면 좀 더 쉽게 데이터 이관 작업을 할 수 있다. 1단계 - 원본과 대상 유형을 선택한다. - 다음버튼을 클릭한다. 2단계 - 편집버튼을 클릭하여 "원본 정보"를 등록하여 접속이 되는지 테스트버튼을 클릭하여 확인한다. (연결이름 : 임의로 작성, 호스트 주소 : IP주소, 연결 포트 : 사용하는 접속 포트, 데이터베이스 이름 : SERVICE_NAME, 사용자 이름 : 실제사용자ID, 비밀번호 : 실제비밀번호) - 테스트버튼을 클릭하여 접속이 안되는 경우는 연결포트 또는 데이터베이스 이름, 사용자이름, 비밀번호가 틀...
    Date2018.12.31 Category알려요~ By엄기호 Views151
    Read More
  7. No Image

    CUBRID 매니저 가져오기 마법사 유용한 팁!

    CUBRID 매니저 가져오기 마법사 유용한 팁! 다량의 데이터를 엑셀로 작성해서 넣는 경우가 많으실 텐데요 CUBRID 매니저에서 UI로 간단하고 쉽게 데이터를 넣을 수 있습니다. 바로 가져오기라는 기능인데요 가져오기는 스키마, 데이터를 파일로부터 데이터베이스 서버로 import를 하는 기능 입니다. (스키마는 SQL 파일만 지원하며, 데이터는 SQL, CSV, XLS, TXT를 지원합니다.) 가져오기 마법사는 아래의 3단계로 구성되어 있습니다. •가져오기 유형 선택 • 가져오기할 데이터 소스 및 옵션 선택 • 가져오기 옵션 확인 여기서 팁 한가지! XLSX 파일은 엑셀 2007부터 추가된 파일 포맷이며 CUBRID 매니저는 XLSX 파일을 지원하지 않으므로, XLSX 파일을 원본으로 하여 데이터 가져오기 작업을 수행하는 경우 정상적인 데이터 입력을 보장할 수 없습니다. 따라서, XLSX 파일은 "다른 이름으로 저장" 메뉴를 통해 반드시 XLS 파일로 변환한 후에 사용해야 합니다. 그리고 XLS 파일로 저장 시 파일 문자집합을 신경 써 주셔야 합니다. 엑셀 한글 버전에서는 따로 문자집합을 설정 안 할 경우 기본 인코딩이 EUC-KR로 되어 있어 파일의 문자집합 옵션을 맞지 않게 데이터를 가져오...
    Date2018.12.31 Category제품 여행 By강주원 Views93
    Read More
  8. Docker, Kubernetes 환경에서 CUBRID 컨테이너 서비스 해보기

    Docker, Kubernetes 환경에서 CUBRID 컨테이너 서비스 해보기 최근에 여러 기업에서 Docker, Kubernetes를 사용하여 컨테이너로 서비스 하는 사레들을 많이 보았습니다. CUBRID도 컨테이너로 만들어서 Docker, Kubernetes 환경에서 서비스 해보려고 합니다. Docker는 '가장 빨리 만나는 Docker: 클라우드 플랫폼 어디서나 빠르게 배포하고 실행할 수 있는 리눅스 기반 경량화 컨테이너'라는 책으로 처음 접하였습니다. 책을 구매해서 보는 것을 권장드리지만 'http://pyrasis.com/docker.html' 페이지에서 책의 내용을 공개하고 있습니다. 책이 너무 길다면 Slideshare, 'https://www.slideshare.net/pyrasis/docker-fordummies-44424016' 페이지에서 슬라이드로 요약된 내용을 볼 수 있습니다. Docker는 Docker라는 회사에서 OS에서 제공하는 가상화 기술을 사용하여 만든 오픈소스 Container 프로젝트의 결과물입니다. 컨테이너는 호스트에 게스트 환경을 구성한다는 점에서는 가상머신과 비슷하지만 OS를 별도로 설치해 줄 필요가 없고, 호스트와 동일한 성능을 낼 수 있다는 장점이 있습니다. 이외에도 여러가지 장점이 많지만 가장 큰 장점은 배포가 쉽다는 점이라고 생...
    Date2018.12.31 By주영진 Views376
    Read More
  9. No Image

    기술지원 중 자주받는 질문들을 살펴보자 !

    큐브리드 엔지니어로 기술지원을 수행하면서 자주 받는 질문들을 크게 10개 단락으로 나누어 모아 보았습니다. 큐브리드를 사용해주시는 많은 분들에게 작게나마 도움이 되기를 바라는 마음으로 작성해 보았습니다. 자세한 내용은 하단에 매뉴얼 링크를 달아 두었으니 참조 부탁 드립니다 1. DB 백업/복구 1) 백업 명령어를 알고 싶어요. ① $ cubrid backupdb -D <백업 경로> -z --no-check <DB명> 2) 증분 백업도 지원하나요? ① 큐브리드는 1차, 2차 증분 백업을 지원합니다. ② 증분 백업을 하기 위해서는 백업 옵션 중 -l 옵션을 사용하면 됩니다. 백업수준은 0,1,2 3가지로 나뉘어 지며 각각 전체 백업, 1차 증분 백업, 2차 증분 백업을 의미합니다. ③ 예시 : cubrid backupdb -D <백업 경로> -z --no-check -l 1 <DB명> 3) 복구는 어떻게 해야 하나요? ① $ cubrid restoredb -B <백업 파일 경로> <DB명> 4) 시점 복구도 지원하나요? ① 큐브리드는 어떠한 옵션도 지정되지 않은 경우 기본적으로 마지막 커밋 시점까지 데이터베이스가 복구됩니다. 시점 복구를 하기 위해서는 -d 옵션으로 시간을 지정할 수 있으나, 지정한 복구 시점까지 복구하기 위한 활성로그/보관 로그 ...
    Date2018.12.30 Category제품 여행 By허서진 Views173
    Read More
  10. DBMS? 힐끗 다른 쪽을 바라봤다

    시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다. 그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다. 그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다...
    Date2018.12.28 Category나머지... By조성룡 Views274
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 Next
/ 10

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2147 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales