SingleStore Hands-On #5 Online Scale Out/In

🎯 개요

SingleStore 는 분산(Distributed) 데이터베이스로 Shared Nothing 구조를 가지고 있습니다. 따라서 현재 시스템보다 더 높은 성능이 요구될 때 쉽게 수평 확장(Scale Out)할 수 있는 것이 큰 장점입니다.

​

이번 테스트에서는 k6 성능테스트 툴로 Data API 를 이용해 트랜잭션이 실행되는 도중에 온라인으로 수평 확장(Scale Out) 및 축소(Scale In) 작업을 수행하도록 하겠습니다.

​

실제 SingleStore 입장에서는 Leaf Node 를 추가/삭제하는 작업을 수행합니다.

​

🎯 gnuplot 설치

SingleStore 클러스터가 온라인 상태에서 Leaf 노드를 추가/삭제할 동안 성능의 변화를 파악하기 위해 k6 실행 결과를 csv 로 로깅할 것입니다.

로깅된 csv 데이터를 터미널(terminal)에서 그래프로 출력하기 위해 gnuplot 프로그램을 설치합니다.

 

sudo yum -y install gnuplot

 

🎯 k6 조회 성능 그래프

Scale In/Out 작업이 없는 상태에서의 그래프를 먼저 그려 보겠습니다.

k6 에서 각 iteration 시간은 unix time 으로 로깅하고 해당값은 1초마다 변합니다.

▶ 동시 세션수 10, 지속시간 : 60초

 

k6 run -e K6_CSV_SAVE_INTERVAL="1s" --out csv=k6_unix.csv -u 10 -d 60s data-api.js

grep iterations k6_unix.csv | \
awk -F, 'NR>1{arr[$2]++}END{for (a in arr) print a, arr[a]}' | sort

grep iterations k6_unix.csv | \
awk -F, 'NR>1{arr[$2]++}END{for (a in arr) print a, arr[a]}' | sort | \
gnuplot -e "set terminal dumb 99 23; set grid xtics; set yrange [0:5000]; \
plot '<cat' using 2 with line"

 

로깅된 데이터를 시간단위로 가공하면 1초당 평균적으로 3700 회 정도의 iteration 이 발생했습니다.

​

이 데이터를 gnuplot 으로 plot 을 그려보면 더욱 쉽게 파악이 됩니다.

​

🎯 SingleStore Leaf 노드 추가

먼저 현재 SingleStore 클러스터 구성을 확인합니다.

 

sdb-admin list-nodes

 

localhost 즉 127.0.0.1 에 3308 포트를 사용하는 새로운 Node 를 추가합니다.

 

sdb-admin create-node --host 127.0.0.1 --port 3308 --password 1234

 

Unknown 역할의 새로운 Node 가 추가되었습니다. 운영환경이라면 SingleStore 클러스터에서 신규 Box 가 준비된 것을 의미합니다. 노드가 추가되면 해당 노드에 Aggregator 또는 Leaf 를 상황에 따라 추가할 수 있습니다.

​

이번 테스트에서는 새로운 추가된 노드의 MemSQL ID 를 이용해 해당 Node 에 Leaf 를 추가하도록 하겠습니다.

▶ 터미널 #1 에서 Leaf 노드 추가 전에 k6 성능 테스트를 먼저 수행

▶ 터미널 #2 에서 10초 경과한 시점에 Leaf 노드 추가 명령어 수행

▶ 터미널 #2 에서 20초 경과한 시점에 airportdb 파티션 rebalance 수행

 

# Terminal #1
k6 run -e K6_CSV_SAVE_INTERVAL="1s" --out csv=k6_scaleout.csv -u 10 -d 240s data-api.js

# Terminal #2 10초 경과 시점에 수행
sdb-admin add-leaf --memsql-id 48B90C6155 --password 1234 -y

# Terminal #2 20초 경과 시점에 수행
singlestore -p1234 -e 'rebalance partitions on airportdb'

 

add-leaf 명령은 1초 내외로 실행되었습니다.

gnuplot 으로 그래프를 그려보겠습니다.

 

grep iterations k6_scaleout.csv | \
awk -F, 'NR>1{arr[$2]++}END{for (a in arr) print a, arr[a]}' | sort | \
gnuplot -e "set terminal dumb 199 23; set grid xtics; set yrange [0:5000]; \
plot '<cat' using 2 with line"

 

파티션 리밸런스 명령은 Online 상태에서 Select 와 Insert 업무가 동시에 수행되고 있으므로 가변적인지만 이번 테스트에서는 178초가 소요되었고 그래프상의 성능 감소 모습은 다음과 같습니다.

▶ 10초 대 add-leaf 명령어 수행시 2-3초간 성능 감소

▶ 20초~200초까지 파티션 복제에 따른 성능 감소

▶ 200초 무렵 파티션 프로모션과 함께 리밸런싱 종료에 따른 성능 감소

​

현재 테스트 환경은 작은 컴퓨팅 파워의 동일 장비에서 모든 노드가 실행되며 I/O 등의 간섭 또한 배제되지 않으므로 정상적인 리밸런싱 속도로 볼 수 없습니다. 실제 운영 환경은 컴퓨팅 파워가 테스트 환경보다 크고 여러 장비에서 동시에 리밸런싱을 수행하므로 훨씬 빠르고 성능 영향도 역시 작은 상태를 유지합니다.

그럼에도 불구하고 지속적인 DML 유입이 발생하는 상황에서 10%~20% 내외의 성능 저하만을 보이는 점은 SingleStore 의 온라인 스케일 아웃 기능이 매우 훌륭하게 동작하고 있음을 확인할 수 있습니다.

 

🎯 SingleStore Leaf 노드 제거

Scale In 작업은 Leaf 제거 -> Node 제거 방식으로 수행됩니다.

Leaf 가 제거되면 add-leaf 명령이 수행될 때와는 다르게 자동으로 리밸런싱이 수행됩니다. 따라서 소요되는 시간도 리밸런싱 시간에 따라 가변적입니다.

​

Leaf 노드 제거는 성능 측정 없이 명령어만 제공하도록 하겠습니다.

sdb-admin remove-leaf --memsql-id 48B90C6155 -y
sdb-admin delete-node --memsql-id 48B90C6155 --stop -y

​

🎯 마무리

현재 준비된 테스트 환경이 하나의 장비에서 SingleStore 클러스터를 구성했기 때문에 실제 Scale-In/Out 의 제대로 된 성능을 보여주지는 못하고 있습니다.

​

하지만 Online 상태에서도 노드 추가/제거 작업이 원활하게 동작하였고 동시 수행하고 있는 DML Query 의 성능 감소폭도 그다지 크지 않음을 확인 할 수 있었습니다.

​

마지막 포스트에서는 SingleStore 에서 Object Storage 를 데이터베이스 저장소로 사용하는 Unlimited Storage Database 기능을 알아보겠습니다.