Background Image
조회 수 1351 추천 수 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. 데이터 베이스 접근 제어와 CUBRID

    데이터 베이스 서비스/운영 환경에서는 데이터의 손실을 근본적으로 차단하기 위한 여러가지 솔루션이 있습니다. 그 중 대표적인 솔루션인 데이터 베이스 접근 제어가 어떻게 CUBRID와 연동 되는지에 대해 기술하였습니다. CUBRID 접속 환경 CUBRID 데이터 베이스의 접근하는 기본적으로 2가지 형태 입니다. (환경에 따라 다를 수 있습니다.) 데이터 베이스 개발자 또는 관리자를 위한 경우 - IDE, Manager 툴을 사용하여, CUBRID 사용, 관리 CUBRID 데이터베이스를 활용하여, 애플리케이션을 서비스 하기 위한 경우 - 웹 서비스를 위한 WAS 사용, 별도의 애플리케이션 사용 CUBRID는 데이터베이스의 연결 전 BROKER 서버의 PORT로 접속 하여, 데이터베이스와 연결 됩니다. 브로커 포트 확인 하기 - 현재 설정 된 값은 기본 설정 값으로 환경 설명을 위한 정보 입니다. 구성 시 변경 가능 합니다. - query_editor(TCP_30000) 개발 및 관리자용 / broker1(TCP_33000) 서비스용 cubrid@host1$ cat $CUBRID/conf/cubrid_broker.conf [broker] MASTER_SHM_ID =30001 ADMIN_LOG_FILE =log/broker/cubrid_broker.log [%query_editor] -- 브로커 명 SERVICE =ON SSL =OFF BROKER_PORT...
    Date2020.08.23 Category제품 여행 By윤준수 Views2334 Votes0
    Read More
  2. 가벼운 웹 프레임워크 Flask위에 CUBRID 얹기

    Python 기반 Web Framework를 떠올리면 DJango를 떠올릴텐데요. Django 보다 가볍고 쉬운 Flask Web Framework와 CUBRID 데이터 베이스 연동 하는 방법을 기술 하였습니다. - Windows 환경에서의 구성과 Linux 환경에서의 구성 Spec.CUBRID 10.2 64bit Windows 10 64 bit - python 3.6.7 - Flask 1.1.2 - Werkzeug 1.0.1 Ubuntu 20.04.1 LTS (Linux) - python 3.8.2 - Flask 1.1.2 - Werkzeug 1.0.1 CUBRID Server# vi /etc/hosts - hostname과 IP 매칭 # ufw allow 33000/tcp # su - cubrid $ wget http://ftp.cubrid.org/CUBRID_Engine/10.2_latest/CUBRID-10.2-latest-Linux.x86_64.sh $ sh CUBRID-10.2-latest-Linux.x86_64.sh $ cubrid service start $ cubrid server start demodb Windows (Flask) WEB ServerPython Install python : https://www.python.org/ - 3.6.7 Release version 다운로드 및 설치 - 환경 변수 Path : C:\Users\<username>\AppData\Local\Programs\Python\Python36\Scripts 추가 Path : C:\Users\<username>\AppData\Local\Programs\Python\Python36 추가 flask Install cmd> pip3 install flask cmd> flask --version CUBRID Driver - CUBRID FTP...
    Date2020.08.12 Category제품 여행 By윤준수 Views2909 Votes1
    Read More
  3. DBeaver Database Tool 큐브리드 사용하기

    1, DBeaver 소개 DBeaver는 SQL 자동 완성과 구문 강조를 지원하는 편집기를 제공하며 이클립스 플러그인 구조 기반의 플러그인 아키텍처를 제공함으로써 데이터베이스에 특화된 기능이나 데이터베이스에 독립적인 기능들을 제공할 수 있게 한다, DBeaver와 CUBRID 사용은 JDBC 드라이버와 데이터베이스 Connection 정보를 설정해 사용할 수 있다. 2, DBeaver 다운로드(https://dbeaver.io/) 2, DBeaver 설치 - 언어선택 후 윈도우 프로그램 설치와 동일하게 “다음” 클릭해 설치를 완료한다. 3, DBeaver CUBRID 연결 3-1, 콘센트 모양 클릭 3-2, Select your database 매뉴에서 CUBRID 선택 3-3, JDBC Connection Setting* General 입력정보 - Host : CUBRID 서버 IP정보 입력 - Server & Database/Schema : 데이터베이스명(Oracle 기준 SID) * Authentication 입력정보 - Username : dba - Password : 비번 (참조: CUBRID는 설정 전 DBA 초기 패스워드 없음) 3-4, Edit Driver Setting* Edit Driver Settings + CUBRID - Url Template 기본에는 jdbc:CUBRID:{host}:{port}:{server}:{database}:: 등록되어 있으나 jdbc:CUBRID:{host}:{port}:{database}::: 로...
    Date2020.07.09 Category제품 여행 By정만영 Views8836 Votes0
    Read More
  4. named pipe를 활용한 압축 백업하기.

    작년 12월 18일에 CUBRID 10.2가 릴리즈 되었다. 자세한 링크는 다음과 같다. https://www.cubrid.com/3824761 이번 버전부터 backup 시 named pipe 를 활용 할 수 있다. Named Pipe | 파이프를 이용해 명령들을 연결하여 사용하거나 명령, 프로세스 치환을 사용하면 명령 실행 중에 자동으로 pipe 가 생성되어 사용된 후 사라지게 되는데요. 이때 생성되는 파이프를 이름이 없다고 해서 unnamed pipe 또는 anonymous pipe 라고 합니다. 이에 반해 named pipe 는 직접 파이프를 파일로 만들어 사용합니다. 자 이제 Named pipe를 생성해 보자. 1 2 3 $ mkfifo backup_pipe $ ls -al backup_pipe prw-rw-r--. 1 hiclass hiclass 0 May 25 10:40 backup_pipe 이렇게 생성해도 되고 1 2 3 $ mknod backup_pipe p $ ls -al backup_pipe prw-rw-r--. 1 hiclass hiclass 0 May 25 10:40 backup_pipe 이렇게 생성 할 수도 있다. 이제 생성한 파이프를 이용하여 백업을 해보자. 먼저 용량비교를 위해서 파이프를 사용하지 않은 일반 백업을 해 보겠다. $ cubrid backupdb demodb -S -l 0 -z -D . -o bk.out Backup Volume Label: Level: 0, Unit: 0, Database demodb, Backup Time: Mon ...
    Date2020.05.25 Category제품 여행 ByHiCLASS Views1301 Votes0
    Read More
  5. CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager)

    들어가며 데이터베이스는 결국 데이터를 저장해야 하고 데이터를 저장할 공간을 필요로 한다. 운영체제 위해서 동작하는 큐브리드는 운영체제로부터 필요한 만큼의 공간을 할당받고 이를 필요에 따라 효율적으로 사용한다. 이 글에서는 큐브리드가 영구저장장치에 데이터를 저장하기 위하여 내부적으로 어떻게 저장공간을 관리하는지에 대하여 이야기한다. 이를 통해 데이터베이스를 연구하고 개발하는 개발자들이 오픈소스 데이터베이스인 큐브리드에 좀 더 쉽게 접근할 수 있었으면 한다. - 이 글의 내용은 버전 10.2.0-7094ba을 기준으로 하나, 최신 develop branch의 11.0.0-c83e33 에서도 차이가 없는 것으로 보인다. 큐브리드의 저장공간 관리 큐브리드 서버는 여러 모듈들이 복합적이고 정교하게 동작하며 데이터를 관리한다. 이 중 저장공간을 관리해주는 모듈로는 디스크 매니저 (Disk Manager)와 파일 매니저 (File Manager)가 존재한다. 이들의 역할을 명확히 하기 위해서는 먼저 큐브리드에서 저장 공간을 어떠한 단위로 관리하는지를 알아야 한다. 페이지와 섹터 페이지(Page)는 큐브리드의 가장 기본적인 저장공간의 단위이다. 페이지는 연속적인 바이트의 연속...
    Date2020.03.31 Category제품 여행 By김재은 Views1596 Votes1
    Read More
  6. linux버전 CUBRID 기본 설치 디렉터리 바꾸기

    10.1 버전 부터 linux 용 버전인 CUBRID-10.x.x.xxxx-d56a158-Linux.x86_64.sh를 설치하면 기본 설치 디렉터리가 예전과 다르게 엄청 길어진다. 아래의 그림과 같이 보이게 된다. 유지관리나 해당 콘솔에서 작업을 할 때 디렉터리명이 길어지면 상당히 불편하다. 이전 버전과 같이 CUBRID로 설치 되게 설치 패키지를 수정해 보자. 일단 linux용 버전의 패키지.sh 파일의 구조는 다음과 같다. vi로 열어보면 상단 shell script + 하단 tar with gzip 으로 구성 되어 있다. 그래서 일단 스크립트 부분과 tar+gz 부분을 분리해 보자. 스크립트 소스 네에는 다음과 같은 힌트가 있다. 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 # take the archive portion of this file and pipe it to tar # the NUMERIC parameter in this command should be one more # than the number of lines in this header file # there are tails which don't understand the "-n" argument, e.g. on SunOS # OTOH there are tails which complain when not using the "-n" argument (e.g. GNU) # so at first try to tail some file to see if tail fails if used with "-n...
    Date2020.01.21 Category제품 여행 ByHiCLASS Views1341 Votes6
    Read More
  7. No Image

    LOB 데이터 경로 변경하기

    운영을 하다 보면 DB 데이터의 경로를 변경해야 하는 경우가 있는데요, CUBRID의 경우 DB 백업/복구를 통해 DB 데이터의 경로 변경을 지원하고 있습니다. 하지만 LOB 데이터는 DB 내부에 저장되지 않고, 외부 파일 시스템에 파일 형태로 저장되고 DB 내부에는 해당 파일의 위치정보만 저장되기 때문에 DB 백업/복구 시에는 LOB 데이터 파일에 대한 별도 관리가 필요합니다. 이 글에서는 DB 데이터 경로변경에 더불어 LOB 데이터의 경로를 변경할 수 있도록 가이드하려고 합니다.(9.3기준) 1. 테스트 정보 - DB 명 : testdb - 기존 경로 : /home/cubrid/CUBRID/databases/testdb - 변경 경로 : /disk/testdb 2. 경로 변경 절차 1) 서비스 종료 $ cubrid service stop @ cubrid server stop: testdb Server testdb notified of shutdown. This may take several minutes. Please wait. ++ cubrid server stop: success @ cubrid broker stop ++ cubrid broker stop: success @ cubrid manager server stop ++ cubrid manager server stop: success @ cubrid master stop ++ cubrid master stop: success 2) DB 백업 (백업 옵션은 매뉴얼 참조) $ cubrid backupdb -D /disk/BACKUP...
    Date2020.01.16 Category제품 여행 By허서진 Views2004 Votes0
    Read More
  8. No Image

    SSH 공개키 인증을 사용하여 암호 없이 편리하게 원격 호스트에 접속하기-!

    SSH 키는 공개 키 암호화 방식 및 인증 확인 응답 인증을 사용하는 SSH 서버에 대해 자체 식별하는 방식입니다. 비공개 서버에 접속하기 위해서는 인증절차를 거쳐야 하는데요, 기존에 비밀번호를 네트워크를 통해 보내는 비밀번호 인증은 네트워크 상에서 ID/비밀번호가 그대로 노출되는 문제가 있고, 접속할 때마다 입력해야 하는 번거로움이 있습니다. SSH 키는 이와 달리 공개키 암호 방식을 사용하여 서버에서 인증받을 수 있으며, 암호를 생략하고 원격 호스트로 접속할 수 있습니다. 과정은 아래와 같습니다. 1. 로컬 호스트에 키 생성(private key, public key) 2. 원격 호스트에 public key 복사(public key 만으로는 복호화할 수 없기 때문에 여러 서버에 복사해도 무관) 3. 로컬 호스트에서 원격 호스트로 ssh 접속 4. 원격 호스트에서 public key로 암호화 된 정보를 로컬 호스트에게 주고, 로컬 호스트는 private key와 원격 호스트의 public key를 이용하여 복호화 수행 5. 인증 완료 시 암호 입력 필요 없이 접속 가능 실제 명령어 수행 과정을 살펴보도록 하겠습니다. 1. 로컬 호스트에 키 생성 ssh-keygen 명령어를 이용해 private/public 키를 생성합니다. s...
    Date2020.01.03 Category나머지... By허서진 Views17268 Votes0
    Read More
  9. No Image

    LINUX 설정 값 nproc, nofile 과 큐브리드의 관계

    LINUX 설정 값 nproc, nofile 과 큐브리드의 관계 리눅스의 설정 값 중 nproc, nofile이 있습니다 [정의] 1. nproc : User당 사용할 수 있는 프로세스 최대 개수 2. nofile : User당 오픈할 수 있는 파일 개수 (리눅스에서는 모든 개체를 파일로 봅니다.) [문제 사항] 값이 적을경우 아래와 같은 문제가 발생할수 있습니다 큐브리드 계정으로 로그인이 안되는 오류 발생 cubrid server 에러에 shutdown a connection이 발생할수 있습니다 [설정 값 확인] < USER MAX 값 확인 > $ ulimit -aS |grep "max user processes" $ ulimit -aH |grep "max user processes" < open file MAX 값 확인 > $ ulimit -aS |grep "open files" $ ulimit -aH |grep "open files" [측정 방법] 1. nproc # ps h -Led -o user |sort |uniq -c |sort -n - nproc는 프로세스 외 LWP 또한 측정하며, 위와 같은 명령어로 확인할 수 있습니다. 2. nofile $ expr `lsof -u [User Name] |wc -l` - 1 [설정 방법] # vi /etc/security/limits.d/20-nproc.conf 수정 (RHEL 7 기준) limits.d디렉토리의 설정 값이 마지막 적용되는 값 입니다. (limis.conf의 값이 먼저 적용 되고, 마지막으로 limits.d 디렉토리...
    Date2020.01.03 Category제품 여행 By강주원 Views18809 Votes0
    Read More
  10. No Image

    큐브리드에서의 신입사원

    2019년 9월 1일 첫 직장으로 큐브리드에 입사하였다. 날이 그리 차갑지도 덥지도 않은 그저 그런 가을 날에, 걱정 반 기대 반을 가슴에 품고서 새로운 사무실에 들어가 새로운 사람들과 만나게 되었다. 새로운 만남, 새로운 생활을 한다는 기대감과, 무슨 일을 하게 될까, 과연 잘 할 수 있을까 하는 걱정이 공존되는 날이었다. 데이터베이스 보다는 운영체제, 커널, 시스템만 했던 사람이 잘 적응할 수 있을 까, 늦깎이 신입사원이 잘할 수 있을까 등 걱정이 많았지만, 하지만 이번 글에서는 새해가 오는 만큼 걱정 보다는 좋았던 점에 대해서만 다루겠다. 큐브리드에서의 생활은 기대했던 것과는 달리 늘 좋았다. 물론, 큐브리드 블로그에서 쓰는 글이라 믿지 못할 지도 모르겠지만 늘 좋았다. 내가 경험했던 직장생활은 '미생'이 유일했기에 하는 말일 수도 있겠지만, 생각했던 것과는 다른 생활이었다. 신입사원이 느꼈던 좋은 점에 대해 몇 가지 나열하자면, 우선, 대화가 자유롭다. 직급에 상관없이 서로 질문하고, 대답해주고, 대화하는 것에 아무런 거리낌이 없다. 오프라인으로 서로 질의응답을 하는 것은 물론, 온라인으로 서로 소통하는 것에 있어 자유롭다...
    Date2019.12.31 Category나머지... By김주호 Views579 Votes0
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 16 Next
/ 16

Contact Cubrid

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