Couchbase 도입기 - 3

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 이 매우 손쉽게 된다는 것도 매우 매력적입니다.


이 다음 이야기는 다음 글에서 계속합니다...

Couchbase 도입기 - 2

Couchbase 을 도입하기로 마음 먹었습니다. 국내에 총판도 있어서 유사시 구입해서 지원을 받을 수 있는 환경이기도 했습니다. 활성화가 잘 되어 있다고는 할 수 없지만 네이버에 카페도 운영하고 있었습니다.

그런데, 도입 후 가격에 대해 문의를 했는데, 딸리는 영어 실력에 솔루션에 대한 이해가 떨어져서 도입 예상가를 제대로 판단하지 못한 문제가 발생했습니다.
처음 도입 시 1 대만 도입해도 되고, 24 시간 서비스 안받아도 되니 가장 저렴한 것으로 구입해도 되겠네...라는 생각을 가졌고, 본사에서 운영하는 사이트에서 제시된 2000 달러(2백만원 초반)면 상용 솔루션으로 전환도 가능하겠다고 생각했습니다.

하지만, Couchbase 는 1 대를 운영하는 것으로는 정상적인 운영이라고 부르기 힘든 제품입니다. 데이터에 대한 분산(Sharding)을 지원하고, 장애가 발생한 서버의 데이터를 재분산(Rebalancing)하는 특징이 있기 때문에, 최소 3 대 이상을 운영해야 제대로 된 구성이라고 할 수 있습니다.
그리고, 초기 도입 시 무조건 교육 패키지를 포함해야 합니다. 한국 총판에서는 (가격을 밝혀도 되는지 모르겠지만) 대략 프리미엄 급 제품 1 개의 가격만큼 책정을 해놓았더군요. 미국 본사의 방침이기도 하답니다.

결국 엔터프라이즈 급으로 도입하기 위해서는 최소 천만원 초중반의 비용이 소모된다는 결론에 도달하게 됩니다. 그래서, 아무 회사에서 엔터프라이즈로 바로 도입하는 건 무리라고 생각합니다. 물론 자료가 많아져서 커뮤니티 버젼으로도 운영 시 장애가 발생해도 해결하는데 큰 어려움이 없어진다면 커뮤니티로 도전하는 회사가 늘겠습니다만...사실 이걸 커뮤니티로 써도 될 정도의 자료가 있는 제품이라고 다른 분에게 권하기는 어렵겠더라구요. 자료를 유실해도 크게 문제가 없는 개인이 운영하는 커뮤니티나 조그만 포털 정도에서 쓰는 거면 몰라도요...

어쨌든 이런 비용 문제 때문에, 우리 회사도 일단은 커뮤니티 버젼으로 시작은 하기로 했습니다. 서비스 시작 후 수입이 괜찮을 것 같다면 바로 구입한다는 전제 조건 하에서요.



Couchbase 의 또 다른 특징은 Cloud 와 같이 공인 IP 을 하나만 쓰고 포트를 나워서 쓰는 환경에서는 쓰기가 쉽지 않다는 것입니다. 이는 모든 경우에 해당하는 것은 아닌데, SDK 을 이용해서 각 프로그램에서 접속을 할 때 귀찮은 일이 발생하게 됩니다. 사실 Couchbase 는 가상 머신이 아닌 실제 머신에서 운영하는 것을 권장합니다만...서버가 유동적으로 늘어나거나(Scale Out) 줄어들 수 있는(Scale In) 환경(대표적인게 게임 서버 쪽입니다)에서는 Cloud 서비스를 생각하게 됩니다. 요즘 많은 게임 회사들이 Cloud 쪽을 선호하는 이유이기도 합니다.
어쨌든...Couchbase 는 각 프로그래밍 언어을 위한 SDK 을 제공하는데, 사용하기 매우 편리합니다만, 접속 시에는 Clustering 방식 때문에 약간 독특한 방식을 취합니다. 가장 큰 문제는 여러 개의 연결된 Couchbase 중 하나의 서버에 접속하여 데이터를 처리하는 것이 아니라, 접속 목록을 SDK Client 에 제공하면 순서대로 접속을 시도한 뒤, 서버에서 사용 가능한 서버들의 도메인과 포트 정보를 보내준다는 것입니다. 그래서 Cloud 등에 들어있는 서버에 접속하기 위해서는 대표 서버 하나의 정보만을 이용해서 접속을 하도록 소스 상에 설정을 해둬야 합니다. 이를 자동화하지 않는다면 상황에 따라 서버 접속 정보를 바꿔줘야 하는 불편함이 발생하게 됩니다.
또한, 사용하는 포트 중 11210 이후 포트가 있는데(아마 Memcached 쪽 포트일 듯) 이게 우리 회사가 사용하는 KT UCloudbiz 의 예약 포트번호입니다. 그래서 이 포트를 열기 위해서는 게시판에 별도 요청을 해야 합니다. 이것도 나름 귀찮더군요.



이 다음 이야기는 다음 글에서 계속합니다...

Couchbase 도입기 - 1

Couchbase 는 NoSQL 제품 중 하나입니다.

Couchbase 는 상용이고, 커뮤니티 버젼이라는 무료 버젼도 제공하고 있습니다.
MySQL 등의 커뮤티니 버젼이 동일 버젼에 기능에 제약이 있거나 상용 버젼에 일부 코드가 튜닝되어 나온다는 등의 기능 차이가 있다면, Couchbase 는 (아직까지는)마이너 버젼 1 개 차이의 이전 버젼을 배포하는 것이 특징인 것 같습니다. 예를 들면, 2.2 버젼이 Enterprise 버젼(상용)의 최신 버젼이라면 Community 버젼은 2.1 을 제공하는 형태입니다. 이 글을 쓰는 지금은 2.5 가 최신 버젼이고, 2.2 에서 2.5 로 바로 건너띈 바람에 Community 버젼은 2.2 가 제공되고 있습니다.

Couchbase 는 Linux 배포판 중 Redhat, Debian 계열의 패키지인 rpm 와 deb 을 지원하고 있으며, 각각 yum 와 apt-get 을 통해 네트워크 설치를 지원합니다. 이런 패키지 관리자를 통해 설치할 경우 의존성이 있는 패키지를 동시에 설치해주므로 좀 더 편리한 설치가 가능합니다.


Couchbase 는 CouchDB 와 Memcached 을 섞어놓은 솔루션입니다. 그러므로, Couchbase 의 자료 뿐만 아니라 CouchDB 의 map/reduce 에 관한 자료나 Memcached 에 관한 자료를 참고하시면 도움이 많이 됩니다.





제가 Couchbase 을 도입하게 된 이유는 속도와 자동화된 기능 때문입니다.

게임 회사에 입사해서 게임 서버를 Java 로 개발하게 되었는데, 무료 위주의 솔루션으로 구축하자는 회사의 방침에 따라 정보 저장은 RDBMS 인 MySQL, 정확히는 MariaDB 를 사용하도록 일찌감치 낙점되었습니다. 그리고 Clustering 의 경우 MariaDB 에서 지원하는 Galera Cluster 을 쓰는 것으로 결정하였습니다. MySQL 의 NDB 클러스나 MMM, Master-Master Circular Replication 보다 사용하기 용이하고 완벽한 동기식 Cluster 라는 장점 때문이었습니다.
하지만, 이건 저의 착각이었습니다. Galera Cluster 의 경우 매우 좋은 성능을 보여주는 Cluster 임에는 분명했지만, Write 가 대량으로 발생하는 시스템에서는 그다지 좋은 성능을 보여주지 못하는 문제가 있었습니다. 한 서버에 Write 을 하게 되면 다른 모든 서버에 bin-log 을 복제하여 이를 적용하게 되고, 적용이 완료된 상태가 되어야 Write 작업이 마무리되게 되는데, 이 시간이 처리 속도의 관점에서 그리 빠르지 않다는 것이었습니다. 그래서 입력하는 서버에서 DeadLock 이 발생하는 것이 아니라 전파하는 속도 사이에 다른 요청이 들어와서 DeadLock 이 발생하는 문제가 생겼습니다. 이를 해결하기 위해서는 한 개의 MariaDB 에만 Write 을 하도록 하고, 나머지 서버에서는 Read-Only 상태로 사용해야 한다는 제약이 있다는 것을 알게 되었습니다.
일반적인 웹사이트에서는 Read 가 압도적으로 많기 때문에 이러한 구성이 문제가 없으나, 게임 서버는 그렇지 않습니다. 거의 1:1 의 Write/Read 가 발생하는 것이 정상적인 모습이기 때문입니다. 특히나 Log 형태의 데이터가 많아서 어떨 때에는 Write 비율이 더 많습니다.

그리고, KT UCloudBiz 을 이용하는데, KT UCloudbiz 에서만 제공한다고 알고 있는 "SSD" 서버의 성능은 압도적으로 좋은 퍼포먼스를 보여줍니다만, 그렇다고 해서 하루 수 천만 라인의 Write 가 이루어지는 게임 서버의 요구를 만족할 수는 없었습니다. SSD 서버의 경우 저의 테스트로는 초당 1만 건 정도의 트랜젝션을 처리할 수 있었습니다. 병렬로 늘리는(Scale Out) 작업이 불가능하다록 위에서 언급했기 때문에 프로그래밍 적으로 샤딩(Sharding)을 하지 않고서는 서비스를 할 수 없다는 결론이 나왔습니다.

그래서 최초로 생각한 것은 Redis 였습니다.

Redis 는 무료이며, Key-Value 방식의 간단한 구조를 가지고 있지만 매우 빠른 속도를 자랑하는 NoSQL 솔루션입니다. 단순 증가 필드도 지원해서 MySQL 계열에서 가지는 문제 중 하나인 auto increment(auto increment 필드로 지정해두면, 해당 테이블 추가시 Table Lock 이 발생한다!!!)를 해결할 수도 있었습니다.
하지만, 메모리를 이용하는 방식이라 데이터 유실에 대한 위험이 존재했고, 이를 보안하기 위한 하드디스크를 이용하게 될 경우 속도가 비극(?)적으로 느려진다는 보고가 보였습니다. 굉장히 꺼려지는 부분이었습니다.
거기다, 더 큰 문제가 발생했습니다. Clustering 이 원하는 형태대로 지원이 안되는 것이었습니다. 여러 개의 Redis 을 설치한 뒤 Sentinel 이라는 자체 솔루션을 이용해 Cluster 을 구성할 수 있었지만 수동으로 정상적인 서버의 위치를 알려줘야 했고, 이를 해결하기 위한 githup 의 몇몇 솔루션을 적용해봤으나 서비스 중단 시간이 수십초 씩 걸리는 문제가 발생했습니다.
게임에서 이런 중단 시간은 용납이 안됩니다.



그래서 찾아낸 것이 Couchbase 였습니다. 적극 권장하는 솔루션입니다...만...고생도 좀 했습니다.



이 다음 이야기는 다음 글에서 계속합니다...