왜 Couchbase 을 선택하게 되었나? (2)

2019/06/11 - [DB/Couchbase] - 왜 Couchbase을 선택하게 되었나? (1)

 

이전 글에서 Couchbase을 선택하기에 앞서 Memcached와 Redis을 선택하지 않은(정확히는 주력으로 사용하지 않는) 이유를 언급했습니다. 실제로 두 제품 모두 실제 사용을 했던 제품이고 사용 중 발생하는 문제점이 너무나 치명적이어서 당장 바꾸지 않으면 안 되는 정도의 문제는 아니었습니다. 하지만, 두 제품 모두 cache 성격에 가까운 key/value 타입의 NoSQL이다 보니 다른 제품과 혼용해서 사용하지 않으면 서비스를 하는데 문제가 발생할 여지가 있었습니다. 가장 두드러지는 문제는 저장공간을 Memory로 사용하기 때문에 용량에 대한 제약이 크다는 것이었습니다.

그래서 저장 용량이 크게 필요한 경우를 고려해야 했을 때에는 다른 제품도 고려해야만 했습니다.

 

3. MongoDB

Memcached 나 Redis 도 아주 유명한 제품이지만, MongoDB 역시 이에 못지않은 인지도를 자랑하는 제품이기 때문에 많은 자료를 쉽게 찾을 수 있었습니다. NoSQL이 RDBMS의 특정 문제를 개선하기 위해 사용되는 특성상 몇 가지 지향점을 타입으로 명명하여 발전해오고 있는데, MongoDB는 Document 타입의 NoSQL로 분류되는 제품입니다. 많은 문서를 효과적으로 저장하고 검색하여 사용하는 것을 목표로 하는 것입니다.

문서는 Json으로 저장되고(효과적으로 처리하기 위해 Bson을 사용하도록 개선) Schema를 가지지 않기 때문에 MySQL의 Alter Lock와 같은 문제에서도 비교적 자유롭습니다. 다만, 속도가 느리다는 단점과 안정성에서 어느 정도 문제가 있다는 평가가 있었지만, 비교적 최근에 이를 많이 개선했다고 알려졌습니다. 그리고 필요할 경우 유상 서비스를 통해 지원도 받을 수 있습니다.

 

그렇기 때문에 제가 일했었던 회사에서도 Couchbase와 MongoDB 두 제품을 가지고 BMT을 진행했었습니다. 대외비 내용이기 때문에 자세한 내용은 적을 수 없지만, 아쉽게도 동일 조건에서 1대로 서비스를 운영했을 때의 성능은 크게 차이가 나지 않았으나 Cluster을 구성하고 Sharding으로 데이터를 분산 처리했을 경우 성능의 차가 명확히 드러났습니다. 또한, Couchbase의 경우 최소 3대만으로도 Cluster 구성을 충족할 수 있으나, MongoDB은 9~11대 정도의 서버가 필요하다는 것도 문제점으로 지적되었습니다(필요한 Daemon을 모두 별도의 서버에 설치한다는 가정하에).

그리고, 실제 서비스를 운영해야 할 팀이 개발팀이 아니라 DBA팀이어서 관리 방법이 얼마나 편리하고 자료를 찾기 쉬운가도 평가 기준이었는데, 유료 구독을 하지 않으면 Web UI을 이용할 수 없다는 것도 문제가 되었습니다. 그래서 자료가 많다는 장점이 크게 부각되지 못한 점도 있었습니다.

 

4. ElasticSearch

사실 ElasticSearch 가 비교대상이 되어야 하는지 좀 의문이긴 합니다. 명백히 ElasticSearch은 Index을 이용한 검색엔진이고, Document 저장 용도로 쓰기에는 일반 기능이 부족합니다. 하지만, 굉장히 놀랍게도 많은 곳에서 ElasticSearch을 데이터 저장소로 쓰고 있는 경우가 많았습니다. 강력한 검색 기능과 여러 제품을 혼용해서 쓰는 것에 대한 부담 때문인 것 같았습니다.

하지만, ElasticSearch가 자체적으로 제공하는 운영 툴은 미약하며, 서드파티 프로그램을 통해 제공되는 기능은 나름 쓸만하지만 사용방법이 살짝 까다롭고 모든 기능이 통합된 형태가 아니라서 학습에 필요한 노력이 필요하다는 문제가 있었습니다. 가볍게 사용하기에는 ElasticSearch가 요구하는 기본 사양도 높은 편이고요.

 

사실, Couchbase 4 이전에는 ElasticSearch와 혼용해서 사용하는 방법도 꽤나 사용되었지만, Couchbase 가 자체적인 검색엔진을 탑재하게 되어 한글 형태소 분석기가 필요하다거나 하는 상황이 아니라면(단순 한글 검색은 n-gram으로 어느 정도 되기에) ElasticSearch와 혼용되어 사용할 필요성도 낮아진 게 현재의 상황입니다.