※この発言は個人の見解であり、所属する組織の公式見解ではありません
測定結果
とりあえず結果を知りたい人・時間がない人向けのまとめ。
ポイントは以下。
- CloudSQLは通常業務であれば全然使えるパフォーマンス
- read onlyの測定でCloud SQL Proxyを経由したらパフォーマンスが上がった。
- read writeの測定ではCloud SQL Proxyの経由ありなしではパフォーマンスは変わらななかった。
Amazon Auroraの方が全然パフォーマンスがよい。
| transactions(tps) | read/write requests(rps) | |
|---|---|---|
| read only (Cloud SQL Proxyなし) | 5969.48 | 59844.80 |
| read only (Cloud SQL Proxyあり) | 8010.22 | 80102.26 |
| read write (Cloud SQL Proxyなし) | 2894.55 | 11578.44 |
| read write (Cloud SQL Proxyあり) | 2955.41 | 11821.88 |
あらまし
Amazon AuroraよりGoogleCloudSQLの方が早いんやで、というGoogle社のblogエントリを見て、ほんまかいなと思い検証。
あわせてCloudSQL Proxy経由での性能も評価した。
ちなみに本件、自腹で検証しているのでGCPの利用料金のことを考えると胃が痛いです。
実施内容
今回ベンチマークテストの方法はAmazon Web Services社のホワイトペーパであるAmazon Aurora Performance Assessmentを元に極力近くなるよう環境構築をGoogleCloudPlatform上に構築した。
ホワイトペーパではr3.8xlarge x 4台のVMからAmazon Aurola r3.8xlargeにsysbenchを実行している為、今回構築した測定環境ではn1-highcpu-32 x 4台のVMからGoogleCloudSQLv2の最高のマシンスペックであるdb-n1-highmem-16にsysbenchを実行した。
なお今回の測定ではsysbenchで大量のmemoryは不要と判断しn1-highmem-32ではなく、n1-highcpu-32を選択しています。
instance type のスペック比較
| instance type | vCPU | memory(GiB) |
|---|---|---|
| r3.8xlarge | 32 | 244 |
| n1-highcpu-32 | 32 | 28 |
| db-n1-highmem-16 | 16 | 104 |
CloudSQLにdb-n1-highmem-32のスペックがない時点で負けてるじゃねーかと思った。
うちはうち、よそはよその精神で。
環境構築
Cloud SQL Instance構築
gcloud sql コマンドからMYSQL_5_7のinstanceを構築できないのでCloudConsoleで構築。
弄ったのは以下。
Version: MYSQL_5_7
tier: db-n1-highmem-16
binaryLogEnabled: false
StorageはデフォルトのSSD 10GB (auto scale: false)としています。
今回のテストではデータは5GB弱であり、メモリ(innodb_buffer_pool)に乗ること、disk access速度はディスク容量で変わるものの、初期はバーストがかかり、バーストがかからなくなった頃には全て読み込んでいるいるであろうという判断をしています。
database作成
export MYSQL_IP=<CloudSQLのIP>
mysql -uroot -h"${MYSQL_IP}" -e "CREATE DATABASE IF NOT EXISTS sbtest"
mysql -uroot -h"${MYSQL_IP}" -e "GRANT ALL ON sbtest.* TO 'sysbench'@'%' IDENTIFIED BY 'sysbench'"
test用のdata作成
sysbench \
--test=tests/db/oltp.lua \
--mysql-host="${MYSQL_IP}" \
--mysql-port=3306 \
--mysql-user=sysbench \
--mysql-password=sysbench \
--mysql-db=sbtest \
--mysql-table-engine=innodb \
--oltp-table-size=25000 \
--oltp-tables-count=250 \
--db-driver=mysql \
prepare
benchmark client(VM)の構築
ホワイトペーパの手順がyumを使用していたので、合わせる為centos-7を使用しています。
machine-typeはn1-highcpu-32を使用しています。
また、以下をinstallしています。
yum install bzr
yum install automake
yum install libtool
yum install mysql-devel
yum install mysql
# sysbenchのinstall
cd /src/sysbench
bzr branch lp:sysbench
cd sysbench
./autogen.sh
./configure
make
mkdir -p /srv/sysbench/src
また、cloud_sql_proxyをこの手順でinstall、設定しています。
testの実施
MSQL_IPをCloudSQLのIPおよびCloud SQL Proxy使用時は127.0.0.1を指定して実施しています。
read only
ホワイトペーパと同様に4台から一斉に実施したところ、毎回1-２台応答が返ってこない現象となったので、比較的安定する3台でベンチを実施する形で測定した。
sysbench \
--test=tests/db/oltp.lua \
--mysql-host=${MYSQL_IP} \
--oltp-tables-count=250 \
--mysql-user=sysbench \
--mysql-password=sysbench \
--mysql-port=3306 \
--db-driver=mysql \
--oltp-table-size=25000 \
--mysql-db=sbtest \
--max-requests=0 \
--oltp_simple_ranges=0 \
--oltp-distinct-ranges=0 \
--oltp-sum-ranges=0 \
--oltp-order-ranges=0 \
--max-time=600 \
--oltp-read-only=on \
--num-threads=500 \
run
read write
read onlyの時以上にnum-threadsが大きくなっていて3台でも測定が安定しなかった為、2台でベンチを実施する形で測定した。
/sysbench \
--test=tests/db/oltp.lua \
--mysql-host=${MYSQL_IP} \
--oltp-tables-count=250 \
--mysql-user=sysbench \
--mysql-password=sysbench \
--mysql-port=3306 \
--db-driver=mysql \
--oltp-table-size=25000 \
--mysql-db=sbtest \
--max-requests=0 \
--max-time=600 \
--oltp_simple_ranges=0 \
--oltp-distinct-ranges=0 \
--oltp-sum-ranges=0 \
--oltp-order-ranges=0 \
--oltp-point-selects=0 \
--num-threads=1000 \
--rand-type=uniform \
run
計測結果
今回、私自身がAmazon Auroraの測定をしていないので、Amazon Auroraの数値はここには載せません。
もし比較するのであれば、ホワイトペーパをご参照ください。
read only (Cloud SQL Proxy なし)
sysbnech client 1
sysbench client 2
sysbench client 3
read only (Cloud SQL Proxy あり)
意外にもCloud SQL Proxyを経由すると数値が良くなった。
オーバヘッドがあると思ってたけどこれには驚き。
sysbench client 1
sysbench client 2
sysbench client 3
read write (Cloud SQL Proxy なし)
sysbench client 1
sysbench client 2
read write (Cloud SQL Proxy あり)
測定不能。Cloud SQL Porxyの動作が正しくないように見受けられるので、調査をすすめる。
調査したところ、cloud_sql_proxyのMax open filesの値がOSデフォルト(1024)だった為に発生していたので、cloud_sql_proxy起動時の設定を見直して再度計測した。
Cloud SQL Proxyなしの場合と比較すると微増ではあるが、誤差の範囲内なのでreadと比較してCloud SQL Proxyを経由することによるパフォーマンスの恩恵はなさそう。
sysbench client 1
sysbench client 2
まとめ
- Cloud SQLにAmazon Auroraと同じパラメータでベンチマークテストを実施しようとしても、正常に実施できない。
num-threadsを減らすなり、VM台数を減らす必要がある。
ということから現状は性能においてAmazon Aurora > Cloud SQLと判断できる。 - とはいえCloud SQLは32vCPUのinstanceがまだないので、これから本気だせばワンチャンある？
- Cloud SQL Proxyを経由させるとreadのパフォーマンスが上がる。
ただしwriteのtestを実施したところエラーが発生したので、Cloud SQL Proxyを本番投入するのはまだ早そう。 - Cloud SQL Proxyを経由させてもread/writeベンチマークテスト時のパフォーマンスは変わらない。
- Cloud SQL Proxy、そろそろ本番投入を考えてみてもいいのでは。
最後にもう一度
※この発言は個人の見解であり、所属する組織の公式見解ではありません