（2018.7.26追記）
この記事で使用したIDCFクラウド RDBは、2016年8月に廃止された旧サービスのものですので、ご注意ください。

その後、IDCFクラウドのRDBは、2018年6月に新たな形で（再）リリースされています。

・IDCF Cloud RDB
https://www.idcf.jp/cloud/rdb/
（2018.7.26追記ここまで）

IDCFクラウドRDBの性能を確認するべく、sysbenchによるベンチマークテストを行ってみました。

・Sysbench
https://github.com/akopytov/sysbench

また、ちょうどよいタイミングでAWSのRDS for Auroraも正式リリースされたので、RDS for MySQL, RDS for Auroraも、IDCFクラウドRDBと同じ条件でベンチマークテストを行い、結果を比較します。

・IDCFクラウド RDB
http://www.idcf.jp/cloud/rdb/

・【AWS発表】Amazon Auroraをご利用頂けるようになりました！
http://aws.typepad.com/aws_japan/2015/07/now-available-amazon-aurora.html

ベンチマークテストの条件

サーバー構成

ベンチマークテストを行うサーバー構成としては、sysbenchを実行するクライアント用サーバー1台、DBサーバー1台（IDCFクラウドRDBは1ノード、RDSはシングル構成）のシンプルな構成としました。
下図のようなイメージです。

 

また、IDCFクラウドRDBでは、1ノードあたりのスペックを落として3ノードによるマルチマスター構成のベンチマークテストも行いました。
3ノードへのDBアクセスの分散には、HAProxyを使用しました。
こちらは下図のようなイメージです。

 

サーバー環境、スペックは次のとおりです。
クライアント用サーバーとDBサーバーのスペックは、各テストでほぼ同じとしました。

サービス	ゾーン	DBインスタンスタイプとスペック	クライアントインスタンスタイプとスペック	DB月額料金
AWS RDS for MySQL 5.6	ap-northeast-1a	db.r3.large 2vCPU,15GBMem, Disk SSD100GB	m4.large 2vCPU, 8GBMem	$187.18
AWS RDS for Aurora	us-east-1b	db.r3.large 2vCPU,15GBMem	m4.large 2vCPU, 8GBMem	$222.28
IDCF RDB (1node)	henry	M16 2vCPU,16GBMem,Disk100GB	M8 2vCPU,8GBMem	23,900円
IDCF RDB (3node)	henry	S4 x 3 1vCPU,4GBMem,Disk100GB	M8 2vCPU,8GBMem	31,200円

※RDS for AuroraのDB月額料金は、ストレージ100GB使用を想定、I/O料金は含まない。

sysbenchの実行条件

• sysbench OLTPテストを行う。
• sysbenchのバージョンは0.4.12.7。
• スレッド数4, 16, 64, 128, 256のそれぞれについて、読み込みのみ(Read Only)と読み書き(Read-Write)の2パターンのテストを行う。
• テストパターンごとに、データレコードの作成→キャッシュに載せるため、プレウォームでスレッド数16 Read Onlyのテストを実行→テストパターンの実行→データレコードの削除を行う。
• テスト用レコード数は100万、最大実行時間は2分。

テスト実行コマンド例は次のとおりです（スレッド数4、Read-Writeテストの場合）。

$ sysbench --test=oltp \
--oltp-test-mode=complex --oltp-table-size=1000000 \
--num-threads=4 --max-time=120 \
--mysql-host=<DB Endpoint> --mysql-table-engine=innodb \
--mysql-user=test --mysql-password=test run

 

テスト条件

各テストで共通の条件は次のとおりです。

• クライアント用サーバー上のsysbenchから、同一ゾーン、同一プライベートネットワーク内のDBサーバーにアクセスする。
• DBパラメータは基本的にはデフォルトままとする。ただしmax_connectionsのデフォルト値は小さく、同時接続256のテストを行うため、300に変更した。
• 計測日時は、日本時間の2015年8月20日15時から19時ごろ。

ベンチマークテストの結果

Transaction per sec（秒間トランザクション数）値をグラフにしました。
テストは念のため2回実施しましたが、数値はせいぜい1～2%程度しか違わなかったため、1回目の値をグラフ化しました。

Read Only

 

Read-Write

 

※IDCFクラウドRDB (3node)は、のRead-Writeはすべてのスレッド数でデッドロックが発生しました。また、2回目に行ったテストの256スレッドでは、「ALERT: failed to execute mysql_stmt_execute(): Err1317 Query execution was interrupted」のエラーが発生しました。これらのエラーについては後述します。
※リソースグラフで見る限り、各テスト実施時のDBサーバーの使用メモリは、空きがある状態でした。

考察

• ReadOnlyでは、RDS for Auroraの値がよい。また、IDCFクラウドRDB (3node)の値はかなりよい。
• ReadWriteでは、RDS for AuroraとRDS for MySQLの値はあまり変わらない。また、IDCFクラウドRDBは1node, 3nodeとも、RDSよりかなり低い値となった。
• RDS for MySQLは、ReadOnlyとReadWriteの値の差が小さい。

となりました。

この結果だけを見ると、以下のことがいえます。

• AWS RDSはRDS for MySQL, RDS for Auroraとも参照、更新の性能バランスがよい。
• AWS RDS for Auroraは性能面で劣らないため、リードレプリカの性能が落ちないことやディスク自動領域追加などの機能を考えると、RDS for MySQLよりもRDS for Auroraを使ったほうがよい。
• ただし、現在は一番低いスペックがdb.r3.large(2vCPU,15GBMem)でそれより低スペックのタイプがなく、また、まだ東京リージョンでは使用できない。
• IDCFクラウドRDBは、更新処理の割合が少ないケースに向いている。
• IDCFクラウドRDBを使用する場合は、シングル構成に比べて、1台あたりのスペックを落としてマルチマスター構成にすると参照性能が大きく向上する。冗長性も上がる。
• ただし、更新処理が多いとデッドロックなどのエラーが発生する場合もある。

IDCFクラウドRDBマルチマスターのエラーについて

IDCFクラウドRDBのマルチマスター3nodeのRead-Writeのテストでは、デッドロックや「ALERT: failed to execute mysql_stmt_execute(): Err1317 Query execution was interrupted」のエラーが発生しました。

マルチマスターDBに対するsysbenchでこのようなエラーが発生してしまうことについては、さくらインターネット研究所さんの以下の記事がありました。

・MariaDB Galera Clusterを試す (3)
http://research.sakura.ad.jp/2013/02/28/mariadb-galera-cluster-3/

「同じテーブルに対して激しく書き込みを行うため衝突が多発します。」
「マルチ・マスターのクラスタではこのような衝突は不可避であり、だからこそトランザクションが失敗したときにリトライするなど、クライアントの処理で対応するべき問題なのですが、残念ながらsysbenchはそのようになっていないようでした。」
とのことです。

一般的なWebアプリケーションでsysbenchのような激しい更新処理は発生しないのかもしれませんが、本番運用で使用する場合は、事前に負荷テストを実施して問題なく動作することを確認したほうがよいですね。

なお、以下の記事に、この問題への対処方法が記載されていました。

・Avoiding Deadlocks in Galera – Set up HAProxy for single-node writes and multi-node reads
https://severalnines.com/blog/avoiding-deadlocks-galera-set-haproxy-single-node-writes-and-multi-node-reads

HAProxyで更新用と参照用のエントリーを別々に用意し、

• 更新は1ノードに対して行い、他のノードをバックアップノードとして登録しておく
• 参照は複数ノードに対して順に行う

とする方法です。
この方法であれば、デッドロックや衝突時の問題を回避しつつ、ノード障害時もDBアクセスを継続できるので可用性を確保でき、高い参照性能を得られます。
現時点では、本番運用では、この方法を採用したほうが安心ですね。

まとめ

IDCFクラウドRDBと、AWS RDS for MySQL/RDS for Auroraに対して、sysbenchによるベンチマークテストを行い、結果を比較してみました。
1クライアントでのシンプルな条件のテストでしたが、この条件におけるそれぞれの特徴が見られました。

複数のクライアントだと結果が異なるでしょうし、このテストがサービスの優劣を表すわけではありません。
本番環境での採用を検討する場合は、実際のアプリケーションそのものや近い条件でテストしましょう。

（関連記事）
・IDCFクラウド　RDBマルチマスターを試してみた
https://inaba-serverdesign.jp/blog/20150819/idcfcloud_rdb_multimaster.html

・IDCFクラウドRDBとAWS RDSの仕様比較
https://inaba-serverdesign.jp/blog/20150819/idcf_rdb_aws_rds_spec.html

・Amazon RDS for Auroraについて
https://inaba-serverdesign.jp/blog/20150320/aws_rds_aurora.html

・IDCFクラウドRDBサービスの廃止について思うこと。
https://inaba-serverdesign.jp/blog/20160531/idcf_rdb_abolished.html