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

요즘에도 프로그램 개발 시 RDBMS 뿐만 아니라 NoSQL을 혼용해서 사용하거나 NoSQL 만으로 구성하려는 시도가 꾸준히 있습니다. 역시 그 이유로 가장 대표적인 게 RDBMS의 속도나 장애 대응에 의문을 품기 때문일 것입니다. 저 역시도 이미 수년 전부터 NoSQL을 써서 개발을 했던 경험이 있고, 유명한 NoSQL 제품을 비교하고 테스트했었고, 실제로 서비스를 개시한 경험도 몇 차례 있습니다. 그중에서도 단연 Couchbase을 사용한 경우가 압도적으로 많았습니다. 또한, 회사 동료들에게 Couchbase을 영업(?)하여 사용하게 만든 경우도 몇 차례 있었고요.

 

그럼 왜 Couchbase을 선택하게 되었을까요?

사실 이 질문에 대한 답을 얻기 위해서는, 장점에 대한 나열보다도 Couchbase 보다 유명하거나 유망한 경쟁 제품에 비해 어떠한 점에서 문제가 적었는지를 나열하는 게 더 적합한 것 같습니다. 그래서 이 글에서는 경쟁 제품에 대한 비판 아닌 비판이 나올 것입니다. 물론 타제품의 열렬한 옹호자들께서는 댓글 등으로 반론을 제기해주시면 이 글을 읽는 다른 분들(특히 NoSQL을 선택해야 하는 분들)에게 큰 도움이 될 것입니다.

비교에 앞서, RDBMS의 경우 제품을 선택할 때 가격이 가장 큰 요소가 됩니다. SQL이라고 하는 표준적인 언어가 존재하고, 이를 기반으로 약간의 독자적인 문법이 있을 뿐 대부분의 요소는 대동소이하기 때문입니다. DB, Table, Column, Record, Index, Transaction, Stored Procedure, Function, Trigger,... 와 같은 요소들은 대부분의 RDBMS 가 모두 가지고 있는 요소들입니다. 하지만, 가격이나 지향점에 따라 속도를 포기하고 안정성을 지향한다던지, 속도를 위해 일부 기능을 포기한다던지 하는 차이점이 존재하긴 합니다. 하지만, NoSQL 은 좀 다릅니다. RDBMS에서 아쉬운 점들 중 일부를 더 강력하게 사용하기 위해서 개발된 경우가 대부분이기 때문에 특정 기능에 특화된 경우가 많기 때문입니다. 그래서 속도를 중시하는 제품, 아주 큰 데이터(문서) 처리를 중시하는 제품, 특정 정보(지도, 그래프,...) 처리를 중시하는 제품 등 조금은 범용적이라 할 수 있는 RDBMS 와는 선택 기준이 달라질 수밖에 없습니다. 이 점을 고려해서 읽어주시면 고맙겠습니다.

 

1. Memcached

NoSQL 제품을 거론할 때 가장 빼놓을 수 없는 제품 중 하나가 바로 Memcached입니다. 아주 오랜 기간 동안 사랑받아 왔으며, 아직도 많은 곳에서 사용하고 있는 NoSQL 제품입니다. Memcached의 가장 큰 특징은 바로 "속도"입니다. 현존하는 NoSQL 제품 중 가장 빠른 응답 시간을 제공하는 것 중 하나로 생각하면 됩니다. 무엇에 대한 것일까요? 바로 "질문"에 대한 "답"에 관해서입니다. 이를 key와 value로 대체해서 생각하면 됩니다.

어떠한 데이터에 대해서 key 라는 질문(혹은 이름)으로 답(혹은 값)을 저장해두면 Memcached는 이를 Memory에 저장해뒀다가 사용자의 요청(질문)에 가장 빠른 방법을 동원해 결과(답)를 제공해주는데 특화되어 있다는 것이죠.

 

문제는, 아주 오래전에 만들어진 제품이다보니 key을 검색하는 방법이 아주 한정적이다는 것입니다. 예를 들어 "2019-06-11.0001" ~ "2019-06-11.0005"라는 형태로 다섯 개의 key을 만들어 어떠한 값을 저장해뒀을 때, 2019-06-11로 시작하는 key 모두를 가져오라고 할 때 사용자가 일일이 0001, 0002, ~, 0005까지 한 번씩 호출해야 한다는 것입니다(물론 Plugin 을 이용해서 이를 개선할 수는 있을 겁니다만). 제품의 이름처럼 cache에 적합한 형태만 제공하기 때문에 단독 사용보다는 RDBMS에 질의하기 전 먼저 cache 용도로 조회해볼 때 더 적합한 형태입니다.

또한, Cluster 을 제대로 지원하지 않기 때문에 Client에서 임의로 여러 Memcached 서버에 데이터를 나눠서 저장하는 방식으로 장애 대응을 하고 부하분산을 하고 있기 때문에 서버 장애가 실제로 발생할 경우 Client의 구현 방식에 따라 데이터 오염이나 일부 데이터 조회 실패 등 여러 문제를 야기할 수 있습니다. 서버가 모두 꺼졌다가 켜졌을 때 내용이 모두 사라져 cache 적중이 되지 않기 때문에 cache 데이터가 충분히 누적되기 전까지는 데이터가 저장된 다른 시스템에 부하를 크게 전가하는 문제도 발생합니다.

 

그래서, 전 Memcached 을 쓰는 곳에서는 가급적 빠른 시간 내에 타제품으로의 교체를 강력히 권고하고 있습니다.

 

2. Redis

Memcached 의 대안으로 널리 알려졌으며, 현재에는 Memcached의 인지도를 뛰어넘어 NoSQL 중 속도가 중요시되는 시스템에서는 가장 많이 거론되는 제품이 바로 Redis입니다. Redis는 기본적으로 Memcached와 마찬가지로 key와 value로 값을 저장하며 Memcached 보다는 느릴지 몰라도 사실상 Memcached와 비교해도 큰 차이가 없을 정도의 강력한 반응속도를 보여줍니다. 사실, 느리다는 것도 표에서 나타나는 수치로 비교하는 것이지 실제 서비스에서 Redis 가 느려서 서비스가 곤란하다고 하는 경우는 본 적이 없습니다.

뿐만 아니라, Memcached 가 제공하지 못하는 범위검색을 포함하여 몇 가지 유용한 기능을 제공하기 때문에 사용성이 매우 우수합니다. 프로그램도 가볍고 간단하고요. 특히 ZRank라고 하는 ranking 기능은 다른 제품(RDBMS, NoSQL 모두)에서 제공하고 있는 경우가 거의 없기 때문에 아주 많은 사용자가 이용하는 서비스에서 순위표(랭킹)를 제공해야 한다면 Redis는 필수 불가결한 제품이 될 수 있습니다.

데이터의 저장도 기본적으로는 메모리에 저장하지만, 설정에 따라 주기적으로 파일시스템에 백업을 저장합니다. 그리고 자체적으로 제공하는 Cluster 나 Sentinel 혹은 Twemproxy, Zookeeper 같은 스크립트나 서비스를 이용하여 장애 대응도 할 수 있습니다.

 

하지만, Redis 의 가장 큰 문제점은 관리하기가 까다롭다는 점입니다. Redis 가 매우 안정적인 제품이긴 하지만 운영 시 발생할 수 있는 문제를 개발자나 인프라 담당자가 쉽게 인지하고 해결할 수 있어야 하는데, Redis는 이러한 부분에 있어서는 매우 불친절한 제품인 게 사실입니다. 또한, Redis에서 사용하는 용어 중 일부가 RDBMS 나 다른 NoSQL 제품에서 사용하는 그것과 일치함에도 불구하고 의미가 달라 혼동되는 경우가 있어서 개발자에게 잘못된 사용을 유도(?)하는 경우도 있습니다(대표적으로 transaction).

예를 들어, Redis 가 동작하고 있는 장비의 메모리를 절반 이상 데이터 저장에 사용할 경우 Redis 의 성능이 급격히 나빠지는 문제가 존재했었습니다(지금도 있는지는 모르겠네요). 이에 대한 해결책은 "시스템 재시작" 밖에 없었고요. 또 다른 예로, 메모리의 데이터를 디스크에 저장하는 것이 동기화되지 않고 설정에 따라 특정 간격으로 저장하기 때문에 시스템에 장애가 발생했을 경우 메모리의 데이터가 디스크에 저장되지 않아 재시작 시 데이터가 유실되는 문제도 존재합니다.

Redis Cluster 도 Master-Slave 구조이기 때문에 Master 의 장애에 취약하고 Sentinel의 key 분산도 운영하는 사람이 직접 관여해서 처리해야 하기 때문에 매우 조심스럽습니다.

 

그래서 Redis 는 운영 경험이 있는 인프라 조직이 갖춰지지 않은 곳에서 처음 도입할 때에는 다시 한번 생각하라고 권하고 싶습니다.

 

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