Couchbase 도입기 - 3

예전(2014년 4월 16일 수요일)에 제가 적었던 블로그 내용을 옮겨왔습니다.

Couchbase 는 RHEL 이나 Ubuntu 계열에서 쉽게 설치가 가능합니다. 저의 경우 KT UcloudBiz 을 이용중이라 CentOS 6.5 을 사용중이고, yum install 로 Couchbase.com 에 있는 rpm 을 직접 설치하는 방식을 이용해서 설치하고 있습니다.

Couchbase 의 가장 편리한 점은 통상적으로 오픈소스 프로그램을 설치할 때 설정 파일을 열어 텍스트로 된 설정값을 수정하는 작업을 선행하는 형태의 작업이 필요없다는 것입니다. 상용으로도 제공되는 제품이다보니 설정이 굉장히 깔끔한 편입니다. yum 으로 install 한 뒤에 자동으로 couchbase-server 가 start 되어 있어서 바로 접속이 가능합니다.

첫번째 서버를 설치한 뒤 웹브라우저를 통해 8091 포트로 접속하면 설치 화면으로 접속이 가능합니다. 거기서 Admin 의 아이디와 비밀번호도 지정할 수 있고, 설치 위치도 지정할 수 있습니다. 그리고, 두번째 서버부터는 바로 첫번째 서버의 도메인을 지정하여 바로 연결할 수 있습니다.

이렇게 서버를 설치한 뒤 1 대 이상의 Couchbase 가 Clustering 이 되면 기본적으로 Data 을 분산하여 관리합니다(Sharding). Couchbase 내부의 알고리즘에 의해 데이터가 분산되어 저장되기 때문에 SDK 등으로 접속 시 원하는 자료를 불러오고 싶을 때 모든 서버를 뒤질 필요 없이 자료가 저장된 서버에서 가져오기 때문에 서버의 개수가 늘어날수록(Scale Out) 부하 분산이 되어서 속도가 느려지는 현상이 줄어듭니다. 일반적으로 Couchbase 는 서버의 사양을 올리는 것보다(물론 메모리는 크면 좋습니다) 이렇게 개수를 늘리는 쪽이 성능 향상에 도움이 되는 형태입니다.
그리고 이렇게 분산된 데이터는 각각 다른 서버의 Disk 에 Replica 로 저장이 되어 있기 때문에 장애가 발생해도 데이터가 유실되지 않습니다. 만약 하나의 서버에 장애가 발생한다면 해당 서버를 FailOver 처리를 한 뒤 Rebalacing 을 해주면 남아있는 서버에 남아있는 장애 서버의 자료의 Raplica 을 꺼내와 기존 서버의 메모리에 있는 자료들과 혼합하여 다시 분산 작업(Sharding) 을 진행하게 됩니다. 그리고 장애 서버는 Remove 할 수 있게 됩니다. 이 동작이 서버 중지 후 가능한 것이 아니라 서비스 도중 이루어지기 때문에 무중지 서버 운영이 가능하다는게 Couchbase 의 큰 장점 중 하나입니다. 그리고 장애가 발생한 서버를 고치거나 새로운 신규 서버를 투입한 뒤 다시 Rebalacing 을 할 때에도 마찬가지로 알고리즘에 의해 분산 저장(Sharding) 을 해서 서버는 항상 비슷한 양의 데이터를 분산 저장해서 응답 속도에 문제가 발생하지 않도록 구성되어 있습니다.

일반적인 운영에서 드러나는 가장 중요한 특징이 Sharding 와 Rebalacing 입니다. 그리고 장애 발생시 FailOver 처리와 Remove 처리 또한 이해가 필요한 작업입니다. 시간이 걸리는 작업인데 무턱대로 눌렀다가는 데이터 유실이 발생할 수도 있습니다(경험담). 서버를 추가한 뒤(yum 으로 설치 후 add server 을 이용해 매우 쉽게 추가 가능합니다) Rebalance 만 해주면 Scale Out 이 매우 손쉽게 된다는 것도 매우 매력적입니다.