SingleStore 는 분산(Distributed) 데이터베이스로 Shared Nothing 구조를 가지고 있습니다. 따라서 현재 시스템보다 더 높은 성능이 요구될 때 쉽게 수평 확장(Scale Out)할 수 있는 것이 큰 장점입니다.
이번 테스트에서는 k6 성능테스트 툴로 Data API 를 이용해 트랜잭션이 실행되는 도중에 온라인으로 수평 확장(Scale Out) 및 축소(Scale In) 작업을 수행하도록 하겠습니다.
실제 SingleStore 입장에서는 Leaf Node 를 추가/삭제하는 작업을 수행합니다.
SingleStore 클러스터가 온라인 상태에서 Leaf 노드를 추가/삭제할 동안 성능의 변화를 파악하기 위해 k6 실행 결과를 csv 로 로깅할 것입니다.
로깅된 csv 데이터를 터미널(terminal)에서 그래프로 출력하기 위해 gnuplot 프로그램을 설치합니다.
sudo yum -y install gnuplot
Scale In/Out 작업이 없는 상태에서의 그래프를 먼저 그려 보겠습니다.
k6 에서 각 iteration 시간은 unix time 으로 로깅하고 해당값은 1초마다 변합니다.
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 클러스터 구성을 확인합니다.
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 를 추가하도록 하겠습니다.
# 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초 내외로 실행되었습니다.
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초가 소요되었고 그래프상의 성능 감소 모습은 다음과 같습니다.
- 현재 테스트 환경은 작은 컴퓨팅 파워의 동일 장비에서 모든 노드가 실행되며 I/O 등의 간섭 또한 배제되지 않으므로 정상적인 리밸런싱 속도로 볼 수 없습니다.
- 실제 운영 환경은 컴퓨팅 파워가 테스트 환경보다 크고 여러 장비에서 동시에 리밸런싱을 수행하므로 훨씬 빠르고 성능 영향도 역시 작은 상태를 유지합니다.
- 그럼에도 불구하고 지속적인 DML 유입이 발생하는 상황에서 10%~20% 내외의 성능 저하만을 보이는 점은 SingleStore 의 온라인 스케일 아웃 기능이 매우 훌륭하게 동작하고 있음을 확인할 수 있습니다.
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 의 성능 감소폭도 그다지 크지 않음을 확인 할 수 있었습니다.