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

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

ScyllaDB 소개

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

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

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

ScyllaDB 테스트 마무리

ScyllaDB의 Benchmark 따라하기

지난 포스팅에서는 VirtualBox, 사내 개발장비에서 각각 ScyllaDB와 Cassandra의 성능을 테스트해보았다. 역시나 ScyllaDB 홈페이지에 나와있는 성능 10배 향상은 확인할 수 없었다. 게다가 사내 개발장비에서 테스트한 결과에서는 Cassandra가 약간이나마 더 좋은 성능을 보여줬다.

하지만 앞에서 진행한 2번의 테스트는 아직은 정확한 성능을 측정했다고는 할 수 없다. 부하를 주는 클라이언트가 1대뿐인 환경에서 진행되었고 시스템 사양도 실제 서비스에서 사용하기에는 무리가 있을만하기 때문이다.

이번에는 AWS에서 ScyllaDB와 Cassandra를 테스트해보도록 하겠다. 각 DB의 구성은 Single Node로 구성해서 테스트했다.

테스트에 사용할 EC2 Instance는 다음과 같다.

DB서버(ScyllaDB/Cassandra)

• m3.xlarge : vCPU=4, 메모리=15G
• Volume : m3.xlarge에서 기본 제공되는 SSD 사용

부하 테스트 클라이언트

• t2.micro : vCPU=1, ECU=변수, 메모리=1G

:: m3.xlarge DB Server, 부하테스트 클라이언트 1대로 테스트 ::

1) 쓰기 테스트

쓰기 테스트에 사용한 명령은 앞서 진행했던 명령어와 동일하다.

cassandra-stress write duration=10m -mode native cql3 -rate threads=700 -node $SERVER

쓰기 성능테스트를 한 결과는 다음과 같다. 

ScyllaDB 평균 TPS : 17792

Cassandra 평균 TPS : 22692

ScyllaDB는 앞서 진행했던 사내 개발장비에서보다 낮은 성능을 보여주고 있다. AWS의 Instance Disk I/O 성능이 사내 개발장비보다 낮기 때문에 당연한 결과일 수 있다.

2) 읽기 테스트

VirtualBox 테스트와 마찬가지로 데이터를 먼저 채워넣은 후 읽기 테스트를 진행했다.

읽기 테스트는 다음의 명령은 다음과 같다.

cassandra-stress mixed 'ratio(read=1)' duration=10m -pop 'dist=gauss(1..10000000,5000000,500000)' -mode native cql3 -rate threads=700 -node $SERVER

결과는 다음과 같다.

ScyllaDB 평균 TPS : 15911

Cassandra 평균 TPS : 27918

3) 읽기/쓰기 테스트

테스트에 사용한 명령은 다음과 같다.

cassandra-stress mixed 'ratio(read=1,write=1)' duration=10m -pop 'dist=gauss(1..10000000,5000000,500000)' -mode native cql3 -rate threads=700 -node $SERVER

결과는 다음과 같다.

ScyllaDB 평균 TPS

   읽기 : 9262, 쓰기 : 9241

Cassandra 평균 TPS

   읽기 : 1700, 쓰기 : 1689

결과를 종합해서 살펴보면 다음과 같다.

	ScyllaDB	Cassandra
쓰기	17792	22692
읽기	15911	27918
읽기/쓰기	7772/7767	10729/10739

<표 1. AWS에서의 benchmark결과>

m3.xlarge가 vCPU가 4개뿐이어서 큰 기대를 하지는 않았다. 그런데 결과는 기대 이하로 Cassandra가 더 빠르게 나왔다.

이정도까지 했으면 "ScyllaDB가 결과를 너무 과대포장했네~"라고 생각할 수 있을만 하다. 그런데 테스트 중 측정된 Load Average를 보면 좀 더 테스트가 필요하다는 필요성을 느낄 수 있다.

ScyllaDB와 Cassandra 테스트 중 측정된 Load Average는 다음과 같다.

	ScyllaDB	Cassandra
Load Average	4.2 ~ 5.5	10.5 ~ 15.5

<표 2. 테스트 중 측정된 Load Average>

만약 이렇다면 부하 테스트 클라이언트의 수를 늘렸을 때 ScyllaDB는 더 많은 일을 할 수 있을 것 같다. 물론 ScyllaDB는 Architecture상 Load Average가 크게 올라가지 않을 수 있다.

:: m3.xlarge DB Server, 부하테스트 클라이언트 10대로 테스트 ::

1) 쓰기 테스트

테스트 결과는 다음과 같다. 

ScyllaDB 평균 TPS : 71983

Cassandra 평균 TPS : 32966

2) 읽기 테스트

결과는 다음과 같다.

ScyllaDB 평균 TPS : 60496

Cassandra 평균 TPS : 27739

3) 읽기/쓰기 테스트

결과는 다음과 같다.

ScyllaDB 평균 TPS

   읽기 : 29018, 쓰기 : 28994

Cassandra 평균 TPS

   읽기 : 12555, 쓰기 : 

결과를 종합해서 살펴보면 다음과 같다.

	ScyllaDB	Cassandra
쓰기	71983	32966
읽기	60496	27739
읽기/쓰기	29018/28994	12555/12540

<표 2. AWS에서 Client가 10개인 경우의 benchmark결과>

부하테스트 클라이언트를 1대로만 했을때는 Cassandra의 약 80%의 성능 정도만 보이던 ScyllaDB였다. 그런데 클라이언트를 10대로 하니 Cassandra의 2배 이상의 성능을 보여주고 있다.

특이한 점은 Cassandra의 경우 부하를 1대에서 주는 경우와 10대에서 주는 경우 읽기 성능이 크게 달라지지 않았다. 반면에 ScyllaDB는 쓰기 성능과 비슷한 비율로 증가한 것을 알 수 있다.