작성일자

클라우드 서비스에서의 분산서버 처리 기술 (Draft)

과연 분산처리 시스템이 필요한가?

먼저 내가 도입하려는 시스템이 과연 분산처리 시스템이 필요한가 부터 생각해 볼 필요가 있다.

만약에 다음과 같은 서비스류라면  당장 뒤로가기 버튼을 누르기 바란다.

  1. 워드프레스등의 CMS(Contents Management System)으로 동작하는 홈페이지
  2. 여행사 홈페이지
  3. 회사소개 홈페이지
  4. 하루 방문자 10000명 이하로 예상되는 서비스

트래픽이 많지 않은 웹 또느 앱 서비스에서 굳이 오버스펙을 갖출필요는 없다.  하지만 클라우드가 대세라하여, 많은 개발자들이 필수적으로 분산서버처리를 하려고 하는 경향이 있는 듯 하다. 하지만 서버 한대로 동작해도(혹은 웹호스팅으로 동작해도 충분한) 될 정도인 경우가 대부분이다.
너무 많은 도입 사례가 있고, AWS 도입 사례가 과연 자신의 서비스에 맞는지 다시 확인해 볼 필요가 있을 것이다.
너무 많은 클라우드 만능주의가 팽배한 것 같다. 클라우드를 도입한다고 해서 모든 트래픽을 처리할 수 있다는 것은 사실이 아니며, 요금이 저렴한 것이 아니다.

많은 개발자/경영자들이 오해하는 것이 저렴한 서비스를 위해서 클라우드 서비스를 도입한다고 한다. 하지만 이는 무조건 맞지 않는 말이며, 클라우드 서비스에서 제공하는 제품들을 잘 연계시키고 잘 튜닝을 해야 요금의 절약과 더불어 급증하는 트래픽을 감당할 수 있다.

한마디로 말하면 분산처리 시스템을 만드는 시간에 본 서비스를 더 가다듬는 편이 나을 수도 있다. (시간을 아끼자)

다음의 경우라면 분산처리 시스템 도입을 고려가 있는 류이다.

  1. 메시징앱
  2. 폭발적으로 성장할 수 있을만한 앱
  3. 많은 트래픽을 처리해야 하는 웹서비스
  4. 게임

메시징앱이라면 당연히 분산서버처리 기술을 가지고 있어야 하는 것이 당연하다. 언제 폭발적으로 증대할 지 모르는 것에 대비하는 것이 당연할 것이다. 만약 내부 채팅으로 사용하는 경우라면, 이용할 사용자가 이미 정해져 있기 때문에 단일 서버 구성으로 하여도 충분할 것이다.

만약 글로벌을 대상으로 포토앱을 만든다 하면, 당연히 분산서버처리 기술은 필수불가결할 것이다. 역시나 많은 트래픽을 대비하기 위함이고, 시간이 지나면 지날수록 증대되어가는 저장공간을 갖추어야(대비해야) 할 것이다.

게임도 마찬가지로, 분산서버 처리는 필수라고 할 수 있겠다. 아키텍처적으로 이러한 구조로 만들지 않는다면 급급할 수 있다. php 로 게임 서버 만든경우를 봤는데 당연히 대용량 트래픽에는 대비하기 힘들다. 가능하지 않다고는 말을 못하겠지만 훨씬 더 나은 대안들이 많이 있으므로 게임서버에서의 php는 자제하는 편이 좋다.

분산서버 처리를 위한 기술들

로드 밸런싱
흔히 L4장비라고 불리우는 로드 밸런싱은 분산서버 처리를 위한 뼈대를 이루는 장치라고 할 수 있겠다. 로드 밸런싱 장비에 IP가 부여가 되며, 이 로드밸런서에 연결되어 있는 N개의 장치 중 한곳으로 라우팅 시킨다. 이 때 서버가 사용할 수 없는 상태인 서버를 회피하여 연결하게 되는데 이로 인해 이용할 수 없는 서버로 라우팅 되는 것을 방지해준다.
AWS를 사용한다면 Elastic Load Balancer를 사용할 것이며 대부분의(모든) 클라우드 서비스 제공 업체가 로드밸런서를 지원하기 때문에 이를 기반으로 N개의 서버를 연결시키게 할 수 있다.

Auto Scaling
대부분의 클라우드 서비스 제공 업체들이 오토스케일링을 지원하며, 작동방식은 비슷하다.
서버의 부하(CPU Load, RAM 여유) 등을 체크하여 서버를 생성하는 방식이다. 이 때 미리 만들어놓은 가상 이미지로 서버를 생성하게 된다. 최근에는 Docker 와 함께 Auto Scaling 서버 구성을 많이 하는 편이다.

Stateless 설계
Stateless 를 간단히 설명하자면 상태가 없다는 의미이다.
다음의 내용을 고려하여 자신의 서비스에 맞는 적용 방법을 만들어보자.

1. 세션을 로컬 파일구조로 사용하지 않는다. 대안방법은 Redis나 MongoDB를 이용하여 세션을 쓰는 방법이 있다.
2. 파일 저장시 로컬에 사용하지 않는다. AWS의 S3를 사용하거나, MongoDB의 GridFS 등이 대안이다.
3.  Apache 는 피하고 보다 Scalable하게 구성할 수 있는 Nginx를 이용한다.
4. 내부 서버에서만 동작하는 서비스(예를 들면 socket.io) 의 stateless 여부를 확인하자(내부적으로 로컬에서 쓰는 부분을 DB를 사용하게 하면 해결된다.) socket.io의  경우 socket.io-redis 나 socket.io-mongodb 패키지를 이용하면 해결된다.
5. 데이터베이스는 분리하여 구성하자.

데이터베이스의 샤딩
웹/앱서버를 분산시켰다고 해서 끝은 아니다. 데이터베이스 또한 확장이 가능한 구조가 필요하다.
대부분의 데이터베이스가 샤딩(Sharding)을 통한 Scale-out 을 지원한다. Mysql 등의 대부분의 상용 및 오픈소스 데이터베이스에서 지원한다.
샤딩을 사용해야 하는 이유는 DB 저장 공간을 scale-out 하게 쓰기위함이다. 더불어, 쓰기 성능 또한 향상된다.
레플리카(Replica)도 거의 필수로 구축을 해야 하는데, 이는 가용성, 무결성, 두가지를 모두 만족시킨다. 즉, 안정적 운영과 함께 잘 안깨지게 구성이 가능하다. 읽기 성능이 좋아지는 것은 레플리카 구축되었을 시의 전리품이다.
처음 서비스 시작할 때는 단일 Master-Slave 구조 또는 레플리카셋(Replica-set) 로 구성한 후에 샤딩이 가능한 구조로 시작하는 편이 비용면에서 이득이다. (DB는 웹서버 보다 오래 버티기에 처음에는 적은 수로 구성해도 문제없다.)

그럼 어떤 클라우드 서비스를 쓰면 되나 ?

Auto Scaling과 Load Balancing 이 지원되는 클라우드 서비스를 선택하면 된다.
가장 많이 쓰는 AWS를 추천하며(가장 많이 쓴다는 것은 그만큼 개발자들의 레퍼런스도 많다는 의미이므로 자료를 구하기 수월하다)
최근에 한국 리전이 생긴 Microsoft 의 Azure를 선택하거나 (같은 요금대의 스펙이 AWS보다 약간 좋은 장점) , 최고의 가성비를 자랑하는 Google Cloud Platform을 사용할 수 있다. 요금이 가장 저렴한 Digital Ocean 으로는

국내에서만 서비스 하길 원한다면, 약간 더 저렴하게 이용할 수 있는데 KT의 Ucloud, 스마일서브의 iwinV  등의 클라우드 서비스를 이용할 수 있다. 물론 레퍼런스는 적기에 많은 시행착오가 필요할 것이다.

다음번에 실제로 node.js 를 이용한 Stateless 구조의 웹서버를 구축해보겠다. (아마 한참 걸릴 수도)

추신 : 요청 오면 바로 올릴 생각입니다. 아직 찾는 사람이 많지 않아.. 게으르기에..

오늘은 여기까지.

작성일자

VIM 사용하다가 저장시 root 계정이 없다고 뜬다면?

리눅스/MAC 에서

vi /etc/hosts 와 같이 시스템 파일을 건들고, 열심히 수정을 하였습니다. 그런데 만약 sudo 명령어를 잊고 실행시켰다는 것을 알았다면?  다시 작성할까…. 고민하시는 분들을 위한 꿀팁입니다.

:는 명령어 내린다는 것을 다들 알것이고, w 는 저장입니다. 이에 뒤붙여서 !sudo tee % 하면 비밀번호 입력하라고 합니다. 비번입력하면 신기하게 저장됩니다.

:w !sudo tee %

이제 파일 다시 수정하지 마세요.

MAC 에서도 적용되는 내용입니다.

오늘은 여기까지.

작성일자

sysbench 내 서버의 CPU, RAM, SSD 성능을 알아보자!

안녕하세요. 스타트업하는 개발자 DevKwon 권선우입니다.

간단히 CPU, RAM, HDD(SSD)의 벤치마킹 하는 방법을 알아보겠습니다. 바로 sysbench 명령어를 이용하여 벤치마킹을 해보겠습니다.

SYSBENCH

sysbench 를 이용해보겠습니다.

CPU 벤치 방법

sysbench --test=cpu --cpu-max-prime=20000  --num-threads=2 run   
설치는 centos 는
yum install sysbench
ubuntu는
apt-get install sysbench
간단합니다. 스레드 2개로 벤치마킹한다는 겁니다. 코어가 여러개 있는 서버는 –num-threads 를 CPU 개수만큼(하이퍼스레딩 되면 X2 추가) 해주면 더 정확한 벤치가 이루어 집니다.
싱글스레드 값을 알고싶으시면 –num-threads 를 1로 잡으시면 됩니다.
MAC 또한 가능한데 brew 로 sysbench 를 선택하시고
brew install sysbench
해보시면 벤치마킹 해볼 수 있습니다.
홈브루(brew) 의 사용 방법은
여기를 참조해 주시기 바랍니다.
아래는 mac 에서의 CPU sysbench  명령어입니다.  –max-requests 와 –max-time을 추가한 이유는 brew 로 인스톨한 sysbench 의 버전이 상위 버전이므로(현재 최신 버전 1.0.4) 디폴트 값이 안잡혀서 잡아주었습니다.
sysbench --test=cpu --cpu-max-prime=20000  --num-threads=4 --max-requests=10000 --max-time=100 run

 

sean@localhost:~$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 2

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
 total time: 15.3272s
 total number of events: 10000
 total time taken by event execution: 30.6441
 per-request statistics:
 min: 1.40ms
 avg: 3.06ms
 max: 27.11ms
 approx. 95 percentile: 9.13ms

Threads fairness:
 events (avg/stddev): 5000.0000/0.00
 execution time (avg/stddev): 15.3221/0.00

잠시 기다려 보면 아래와 같은 결과 값이 나옵니다. total time 을 보시면 되고 15.32초가 걸렸습니다. 지금 서버는 cpu 2개인 서버인데, 만약 –num-thread 값을 1로 바꾸면 거의 두배인 30.6초 정도 나오게 되겠습니다.

맥북 프로에서는 8.3267s,, 스마일서브 1core (iwinv) 14.3366s,  2core : 7.3577s 정도 나왔습니다. CPU많으면 개수만큼 성능이 좋네요.

이런식으로 벤치 마킹을 하시면 됩니다.

RAM 성능 측정 방법은

sysbench --test=memory run

RAM  성능 측정하는 지표는 역시 실행시간입니다.

제 맥북 프로에서는 49.2817s, 스마일서브(iwinv) 호스팅 계정은 70.5834s, Azure 2Core instance 는 68.1875s 이였습니다.

102400.00 MiB transferred (2077.77 MiB/sec)  와 같이 초당 전송 속도를 보는 것도 측정방법의 한 방법이겠습니다.

이번엔 SSD(HDD포함) 측정을 해보겠습니다.

mkdir test
cd test
sysbench --test=fileio --file-total-size=1G prepare

sysbench --test=fileio --file-total-size=1G --file-test-mode=rndrw --max-time=60 --max-requests=0 run

sysbench --test=fileio --file-total-size=1G cleanup

먼저 test 디렉토리를 만들고, 거기에서 prepare 명령어로 준비 과정을 거칩니다. (벤치마킹 돌릴 파일 생성)

run 명령어로 벤치마킹을 합니다. 이제 잠시 기다리면 결과가 나옵니다. 이번에는 초당 입/출력 대역폭으로 벤치마크 결과를 판단해보겠습니다.

sean@localhost:~/test$ sysbench --test=fileio --file-total-size=1G --file-test-mode=rndrw --max-time=60 --max-requests=0 run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
128 files, 8Mb each
1Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed: 29400 Read, 19600 Write, 62596 Other = 111596 Total
Read 459.38Mb Written 306.25Mb Total transferred 765.62Mb (12.76Mb/sec)
 816.64 Requests/sec executed

Test execution summary:
 total time: 60.0018s
 total number of events: 49000
 total time taken by event execution: 10.0451
 per-request statistics:
 min: 0.00ms
 avg: 0.21ms
 max: 23.24ms
 approx. 95 percentile: 0.73ms

Threads fairness:
 events (avg/stddev): 49000.0000/0.00
 execution time (avg/stddev): 10.0451/0.00

file-total-size는 RAM 용량이상으로 이상으로 넉넉하게 잡아주시면 더 정확한 결과가 나올 수 있습니다. 저는 대략만 알면 되기에 1G 만 테스트 해보았습니다.

마지막으로 cleanup 명령어로 파일을 제거해 주시면 되겠습니다. rmdir test 로 디렉토리도 제거하시고요.

실행결과는 다음과 같습니다.

맥프로 SSD의 성능이 어마어마했는데요.

HDD :     read, MiB/s:                  270.85    written, MiB/s:               180.57  의 결과가 나왔습니다.
애저의 local SSD 결과도 좋았는데요 무려 151.85Mb/sec (입/출력 평균) 의 결과가 나왔습니다. 애저의 managed ssd는  14.609Mb/sec 에 불과하였습니다.
일반 호스팅(통큰아이)의 SSD 는 23Mb/sec 정도 하였습니다. iwinv도 비슷한 수준입니다.
대략적으로 서버의 벤치마킹은 sysbench 이거 하나면 됩니다.
오늘은 여기까지.

 

 

작성일자

node.js 프로세스 매니저 pm2

node.js 의 프로세스 매니저는 pm2 , forever, npm 이 있다.

forever 로 서비스를 구동할 수도 있고, npm run 으로 서비스를 구동할 수도 있다.

npm 이 패키지 매니저라고 생각했던 분들이 많을 거라 생각한다. 하지만 npm 은 프로세스 매니저로도 사용할 수 있고, 빌드 자동화를 위한 도구로도 사용할 수도 있다.

과거에는 forever 를 많이 사용하였지만, 점점 pm2 가 대세화가 되고 있는 느낌이다.

만약에 프로세스 매니저를 사용하지 않고 있다면 forever 도 pm2도 뭐든 좋으니 꼭 사용하길 바란다.

나 또한 pm2 를 사용하기 이전에는 forever 를 서비스 매니저로 사용하고 nodemon 으로 파일 변경을 watch 하여 개발용으로 사용하였다.

하지만 pm2가 있기 때문에 더 이상 다른 프로세스 매니저는 필요 없다고 생각한다.

pm2 의 장점으로는

  1. app.json 파일을 만들어서 여러 프로세스를 한꺼번에 관리할 수 있다.
  2. watch옵션 으로 개발하는 모드로 사용할 수 도 있다.
  3. cluster mode 를 자체적으로 지원한다.
  4. 자체적인 모니터링 도구 (pm2 monit) 를 지원한다.
  5. keymatrix 와의 연동으로 웹에서 실시간 모니터링이 가능하다. (1개 서버만 무료, 그 후로 유료) (https://keymetrics.io/)
  6. 업데이트가 빠르다.

그럼 다음 챕터에서 pm2 의 사용 방법을 안내하겠다.

 

 

 

작성일자

웹마스터 도구 사용하기 (Draft)

웹마스터 도구는 웹사이트를 운영할 때 반드시 등록해야 하는 것들 중 하나이다.

검색엔진을 통해서 나의 웹사이트에 접속하게 되는데 , 웹마스터 도구를 사용하면 내 웹사이트가 검색엔진에서 어떻게 색인되고 있는지 정상적으로 크롤링은 되고 있는지 알 수 있다.  또 sitemap.xml 을 등록하여 내 사이트 구조를 명시해서 검색엔진이 내 웹사이트를 좀 더 구조적으로 크롤링할 수 있도록 도와줄 수 있다.

구글, 빙, 네이버에서 웹마스터 도구를 지원하기 때문에, 모두 등록해 주는 것이 좋다.

https://www.google.com/webmasters

http://www.bing.com/toolbox/webmaster

http://webmastertool.naver.com/

다음은 별도의 웹마스터 도구를 지원하지 않는다.

다만 사이트 등록은 가능하므로, 반드시 등록해주도록 하자. 등록하는 비용은 모두 무료이다.

https://register.search.daum.net/index.daum

한가지 첨언을 하자만, 15여년 전 쯤에 네이버나 다음 등 웹사이트 등록을 하려면 돈을 내고 등록을 해야 했었다.(빠른 등록일 경우는 유료였고, 무료로 하려면 한참 기다려야 했었다.)

작성일자

scp 명령어로 sftp 대신 쓰기

scp 명령어는 리눅스와 맥에서 사용할 수 있으며, 한줄의 명령어로 손쉽게 원격지로 복사할 수 있는 명령어이다.
물론 sftp 명령어로 sftp 로 접속하여 put [파일명] , get [명령어] 와 같이 복사할 수 도 있지만, sftp 로 접속후, 명령어를 입력하여야 하는 불편함이 있다.
백업본 복사와 같이 명령어 하나로 스케쥴링을 해야 하는 경우라면 scp 명령어가 적합하다고 할 수 있겠다.
scp [원본경로] [목적지경로] 와 같이 사용이 가능하다.
특이한 점은 원본경로와 목적지 경로 모두 로컬 혹은 원격저 서버 주소를 사용할 수 있다는 점인데 원격지에서 내 로컬로 복사,  로컬에서 원격지로 복사, 원격지에서 타원격지로의 복사가 가능하다.
scp myfile.tar.gz user@server.com:~
위와 같이 실행한다면 내 로컬에 있는 파일을 원격지의 사용자 계정 home으로 전송하는 의미이다. (~는 home directory)
반대로 원격지의 파일을 로컬로 복사한다면 아래와 같이 사용하면 된다.
scp user@server.com:~/myfile.tar.gz ./
./는 현재 디렉토리라는 의미이므로 여기에서는 현재 위치한 디렉토리로 복사해 오게 된다.
만약 비밀번호를 물어보기 싫다면 공개키 방식을 사용하여 인증하거나, pem authentication 을 사용하는 방법을 사용하면 된다.
pem key 를 사용하려면 -i [key파일] 옵션을 추가하면 된다.
 -i pem.key
공개키 방식으로 비밀번호업이 ssh 와 sftp, scp 를 연결할 수 있는 방법은 다음번에 소개하겠다.


작성일자

VI(VIM) 에서 대소문자 안가리고 검색하기

vi 를 사용할 때
/검색어 와 같은 방법으로 문자열 검색을 할 수 있다.
이때 vi의 기본설정으로는 아무것도 없다.
vi ~/.vimrc
vi 로 .vimrc 파일을 연 후에
set ignorecase
와 같이 입력한 후 저장한다.
이제 소문자로 검색하여도 대소문자 가리지 않고 문자열을 찾을 수 있다!
vi 명령어를 잘 모르는분들을 위하여 대략적인 vi의 사용 방법을 남긴다.
쓰기 a
쓰기 모드에서 나가기 esc
종료 명령어 :wq
강제 종료 :q!
30행으로 이동 :30
마지막 행으로 이동 :$
현재줄의 마지막으로 이동 $
검색 /검색어
첨언 : vim 은 vi 의 향상된 버전으로, vi는 vim으로 대체 되었다. 최신의 리눅스에서 vi 명령어를 사용하여도 vim 으로 동작하므로, 동일하다. vim대신에 한글자 줄여서 vi명령어로 써도 괜찮다.


작성일자

MongoDB 에서의 백업과 복구

mongodump로 백업하기

MongoDB 에서 백업을 하는 명령어는 mongodump이다.

mongodump 명령어를 이용하여 백업을 하려면 다음과 같이 입력해 보자.

mongodump -uusername -ppassword -d myapp -o ~/backup

mongodump -u내계정 -p내패스워드 -d db명 -o 백업할 위치

-u 와 -p 옵션은 붙여서 사용할 수 있다.

만약 특정 콜렉션만 백업을 하고 싶다면

-c 콜렉션명

옵션으로 특정 콜렉션만 백업을 할 수도 있다.

mongorestore 로 복구하기

mongorestore -u계정명 -p비밀번호 -d db명 ~/backup

mongodump와 틀린점은 -o 옵션을 사용하지 않고 바로 기술하는 점이 다르다.

MongoDB 의 버전이 달라서 복구가 정상적으로 안될 경우(Nmap 에서 Wiredtiger로 변경할 경우) 가 있는데 인덱스 복구를 못하는 경우일 수 있다. 이 때는

--noIndexRestore

옵션을 추가하고, 인덱스를 다시 걸어주면 되겠다.

 

MongoDB클라이언트인 Studio 3T(구 MongoChef) (https://studio3t.com/) 를 이용하면 더 쉽게 백업과 복구가 가능하다. Studio 3T의 사용방법에 대해서는 다음에 안내하도록 하겠다.

나의 경우는 스케쥴링할 때는 mongodump 를 사용하고 crontab 을 사용하여 데일리 백업본을 만들고, 일반적으로 데이터 수정 / 이동 작업할 때는 Studio 3T로 작업을 하는 편이다.

작성일자

MongoDB 와 안정성

여러분이 MongoDB 를 도입하려 사용하려고 한다면 주변에서는 한번 말릴 것이다.  의심의 눈초리로 “MongoDB 가 DB가 깨질 수 있다는데 안전한가요?” 이러한 질문들을 많이 들어봤다.

결론적으로말하자면 깨질 수 도 있다. 하지만 복구가 가능하다. 다른 데이터베이스도 깨질 수 있지 않는가 하는 것이 필자의 생각이다. 한가지 예를 들면 MySQL 이 깨질 수도 있는 것이다. 물리적인 손상은 어쩔 수 없는거 아닌가? 하는 것이다.

물론 예전 버전에서는 안정성이 낮았지만 현재의 버전, 특히 WiredTiger 엔진에서는 안정성이 대폭적으로 좋아졌기 때문에 깨질 확률이 그렇게 많지는 않다는 것을 말하고 싶다.

기본적으로 데이터베이스의 백업은 주기적으로 (최소 Daily)  하는 것이 원칙이며, 시스템이 다운되거나 물리적 손상이 있어서 복구가 못하게 되는 순간이 오면 백업해 놓은 백업으로 복구하는 것이 일반적인 복구 절차이며, 이는 모든 데이터베이스 시스템에서 동일하게 적용되는 것이다.

MongoDB 서비스가 가동중에 갑자기 전원을 끈다면, mongod 실행시에 –repair 옵션을 써서 복구를 진행해야 할 것이다. 아직 물리적인 손상으로 인하여 MongoDB를 재가동 시키지 못한 경우는 없지만, 대부분은 –repair 옵션으로 복구가 가능할 것이다.

MongoDB 라고 하여 안정성이 낮다고 하는 것은 “기우이다”라는 것을 말하고 싶다.

그럼 접근 방법을 달리하여 아에 안정적으로 구동될 수 있는 시스템을 구성한다면 어떨까 하는 것이다.

이 때 사용하는 것이 Replication이다.

Master / Slave 라고도 하며 Primary / Slave 라고도 하는 이 구조, (MongoDB 에서는 Primary / Slave) 로 표현한다.

대부분의 DB에서 지원하며 , 안정성을 위해 데이터베이스를 복제하며, 한쪽 데이터베이스가 구동되지 않은 상태라고 하더라도, 다른 나머지 데이터베이스 중 하나가 그 역할을 대신할 수 있게 하는 방법이다.

MongoDB에서는 보통 3개로 된 Replica set(복제셋) 을 사용하며 Master , Slave 2개로 구성한다.

그리고 이 3개의 Replica set 으로 구성되면 상시 구동되는 데이터베이스를 만들 수 있다.

만약 시스템 중 한곳에서 물리적인 업그레이드를 한다거나해서 시스템을 리부팅을 시킬 필요가 있을 경우에도 그냥 작업을 하고 다시 구동을 하면 자동적으로 그 중지되어 있던 상태의 데이터 값을 다른 데이터베이스에서 복제해 오게 된다. (정말 아무런 작업을 안해줘도 다시 살아난다.)

따라서 중단 없이 운영을 해야 하는 시스템에는 이 Replica set이 필수라고 할 수 있겠다.

Replica set 을 구성해서 좋은점 중 한가지를 소개하면, 만약 통계 프로그램을 구동시킬 때 부하가 많이 걸리게 될 것이다. 이것을 Slave 데이터베이스에 연결하여 작업을 하면 실 서비스에 영향을 받지 않으면서 통계를 낼 수 있다. 안정적으로 운영하면서도 통계가 필요할 경우 적합한 사용방법이라고 할 수 있겠다.

다음 챕터에는 이 Replica set 을 직접 만들어 보는 방법을 안내하겠다.

작성일자

Git 에서 비밀번호 물어보지 않게 하기

Git 를 사용할 때 git pull 등의 명령어를 실행할 때 비밀번호를 물어보게 될 때 매번 물어보지 않게 하는 방법을 안내한다.
두가지 방법이 있는데
1. repository url 에서 비밀번호는 입력하는 방법
2. 캐시를 설정하는 방법
이 있다.
git clone 을 할 때 다음과 같이 비밀번호를 미리 입력한다면 비밀번호를 물어보지 않는다. 이렇게 이용할 수도 있으나 추천 하지는 않는다.
git clone https://myid:mypassword@bitbucket.org/myid/myapp.git
캐시를 설정하여 특정시간동안 비밀번호를 다시 물어보지 않게끔 할 수 있다.
여기서 –global 옵션과 함께 명령어를 실행한다면 모든 계정에 대해서 캐싱을 한다는 의미이다. 만약 특정 git 디렉토리만 설정한다면 –global 옵션을 제거해 주면 된다.
git config --global credential.helper cache  
디폴트는 900초(15분) 동안 캐시를 저장하므로 15분이 지나고 다시 시도하면 비밀번호를 다시 물어보게 된다.
넉넉하게 타임아웃을 설정할 수 있는데 만약 10일간 캐시를 설정한다고 한다면 다음과 같이 입력하면 된다.
git config --global credential.helper 'cache --timeout=864000'
이제 더 이상 비밀번호를 물어보지 않는다. 야호!