ScyllaDB 소개

:: ScyllaDB 소개 및 테스트 바로가기 ::

ScyllaDB 소개

Scylla vs. Cassandra benchmark 따라하기 1 : VirtualBox에서 테스트

Scylla vs. Cassandra benchmark 따라하기 2 : 사내 개발장비 테스트

Scylla vs. Cassandra benchmark 따라하기 3 : AWS 테스트

ScyllaDB 테스트 마무리

Cassandra는 대표적인 Column Family Oriented NoSQL 중 하나이다. Cassandra의 Use Cases 페이지(http://www.planetcassandra.org/apache-cassandra-use-cases/)만 들어가봐도 얼마나 많이 사용되고 있는지 알 수 있다. 

Cassandra가 Java로 만들어져있다는 것은 대부분 알고있는 사실이다. Java 오픈소스 중 C/C++로 구현하는 것은 어렵지 않게 찾아볼 수 있다. Lucene과 CLucene, HBase와 HyperTable 이 대표적인 예이다. Cassandra도 이와 같이 C++로 구현한 오픈소스가 있다. ScyllaDB라는 NoSQL은 Cassandra와 호환되는 Column Family Oriented NoSQL이다.

ScyllaDB의 홈페이지(http://www.scylladb.com/)에서는 다음과 같이 믿기 힘든 내용을 볼 수 있다.

<그림 1> ScyllaDB 홈페이지에 있는 소개 문구

Cassandra와 완전히 호환되면서 10배나 빠르다는 내용을 볼 수 있다. 2배정도 빠르다고 하면 순진한 척 하고 믿어줄 수는 있다. 하지만 10배나 빠르다는 것은 진짜 그런지 확인하지 않고 믿기에는 무리가 있다. 

다음번 포스팅에서는 ScyllaDB 홈페이지에서 진행한 "ScyllaDB vs Cassandra Benchmark"를 직접 확인해보도록 하겠다.

먼저 ScyllaDB에 대해서 알아보면 다음과 같다.

ScyllaDB 소개

ScyllaDB는 C++로 구현한 Cassandra이다. 일반적인 경우 구현 언어가 Java에서 C++로 바뀐다 해서 성능이 10배 향상되는 경우는 거의 찾아보기 힘들다. 그럼에도 테스트를 진행해서 실제 10배 성능향상이 있는지 확인하고자 하는 이유는 ScyllaDB를 만든 사람들 때문이다.

ScyllaDB는 KVM을 만든 사람들이 만들었다. KVM은 Google Compute Engine, OpenStack에서 사용하는 가상화를 위한 Hypervisor이다. 아무래도 시스템에 대해서 매우 잘 알고있는 사람들이 만들었기 때문에 시스템 자원을 최대한 효율적으로 활용해서 10배의 성능 향상을 얻을 수 있었던 것으로 예상한다.

ScyllaDB는 요즘 사용되는 하드웨어에 최적화된 Architecture를 사용하고 있다. 일반적인 JVM 아키텍쳐와 비교해보면 다음과 같다.

<그림 2. 일반적인 JVM 아키텍쳐)와 ScyllaDB 아키텍쳐>

ScyllaDB 홈페이지에서는 좌측의 일반적인 JVM 아키텍쳐는 낮은 CPU 활용, 상대적으로 비용이 많이 드는 Locking, 갑작스런 Latency 불안정 문제를 가지고 있다고 한다. 그러면서 우측 ScyllaDB 아키텍쳐는 shared-nothing 방식을 기반으로 하기 때문에 한대의 시스템에서 1백만 CQL까지도 처리할 수 있다고 한다.

Shared-nothing 방식은 리퀘스트가 처리할 CPU를 할당받아서 거기에서 다 처리하는 방식이라고 ScyllaDB 홈페이지에서 설명하고 있다. 이와 같은 방식으로 만든 Seastar라는 Framework이 있는데 ScyllaDB는 Seastar Framework를 사용하고 있다.

아무튼 ScyllaDB는 shared-nothing 방식의 Seastar Framework를 사용하여 구현하였기 때문에 context switching이 적고 시스템 자원을 최대한으로 활용할 수 있다.

시스템 자원을 최대한 활용하는 방식으로 만들었다고는 하지만 몇가지 문제점(?)들이 예상되기는 한다. 특히 이벤트 처리하는 부분에서 이벤트 처리를 OS에게 맡기는게 아니라 직접 polling하기 때문에 아무 일도 하지 않는 상태에서 모든 CPU를 사용하게 된다.

예를들어 4Core짜리 시스템이 있다면 ScyllaDB를 실행시켜놓은 것만으로 Load Average가 4.0 이 될 것이다. 물론 실행시 옵션을 줘서 사용할 Core 수를 조절할 수는 있다. 서비스를 위해서는 적어도 Core 2개는 일하지 않는 상태로 두는 것이 좋을 것 같다.

현재 ScyllaDB는 Cassandra 2.1.8에서 Thrift와 SSL을 제외하고는 완벽히 호환된다고 한다. 하지만 성능 향상을 위해서 Gossip과 Internal Streaming은 ScyllaDB가 따로 구현했기 때문에 Cassandra 노드와 ScyllaDB 노드를 하나의 클러스터로 구성하는 것은 불가능하다.

NoSQL이 Scalability와 성능을 강조하는 경우가 많기 때문에 Cassandra보다 10배 빠르다고 하는 ScyllaDB는 곧 있으면 주목받을 수 있을꺼라 생각한다. ScyllaDB GA버전이 나오면(2016년 1월에 나온다고 한다.) 어떤 반응이 있을지 기대된다.