RDSがt2インスタンスでどのくらい速くなったか試してみた

はじめに

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日RDSでt2インスタンスタイプが選択可能になりました。 旧世代と現行世代でどの程度のパフォーマンス差があるのか気になったので、ベンチマークしてみました。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。 ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

使用データは以下のコマンドでロードしています。

java JR scripts\tpcc_load.js -nAgents 8 -param0 100

"-param0"に100を指定しているので、データ件数は以下になります。

Table	Records
warehouse	100
district	1000
customer	3,000,000
history	3,000,000
item	10,000,000
stock	10,000,000
orders	3,000,000
new_orders	900,000
order_line	30,000,000 (approx.)

ベンチマーク対象

ベンチマーク対象は以下の３タイプです。全てCPU数が１のインスタンスです。参考としてdb.m3.mediumも計測しました。

インスタンスタイプ	DB Engine Version	vCPU	メモリ (GiB)	ネットワーク	時間あたりの料金 On Demand(Tokyo) 2014年8月21日時点
db.m1.small	MySQL 5.6.13	1	1.7	低	$0.075
db.t2.small	MySQL 5.6.13	1	2	低から中	$0.052
(参考)db.m3.medium	MySQL 5.6.13	1	3.75	中	$0.120

MySQLの場合は、t2インスタンスがMySQL5.6以降で使用可能になります。MySQL5.5では使用できないのでご注意下さい。

Tiny TPC-Cを実行するインスタンスは、c3.xlargeのWindows Server 2012 R2を使用しています。なお、Tiny TPC-C実行インスタンスと各RDSは同じAZでベンチマークを取得しています。

結果

計測は、多重度を1、6、16、64に変化させスループット、最大CPU使用率を計測しました。 各々のスループットとレスポンスタイムは以下の様になりました。なお、レスポンスタイムは90パーセンタイルを表示しています。

db.m1.small

Throughput

多重度	Throughput(tps)
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	2.9	2.9	0.3	0.3	0.3
4	7.9	7.9	0.8	0.8	0.8
16	10.9	10.9	1.1	1.1	1.1
64	12.3	12.3	1.2	1.2	1.2

Response Time

多重度	Response Time (90%tile)
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	247 ms	105 ms	81 ms	734 ms	1112 ms
4	378 ms	157 ms	144 ms	832 ms	1940 ms
16	1022 ms	546 ms	386 ms	2937 ms	4007 ms
64	4524 ms	1713 ms	1118 ms	9455 ms	9673 ms

 

db.t2.small

Throughput

多重度	Throughput
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	4.1	4.1	0.4	0.4	0.4
4	11.7	11.7	1.2	1.2	1.2
16	17.3	17.3	1.7	1.7	1.7
64	15.8	15.8	1.6	1.6	1.6

Response Time

多重度	Response Time (90%tile)
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	185 ms	84 ms	56 ms	452 ms	827 ms
4	252 ms	118 ms	95 ms	425 ms	1324 ms
16	657 ms	363 ms	249 ms	1281 ms	2518 ms
64	3210 ms	1698 ms	930 ms	5384 ms	8844 ms

 

(参考)db.m3.medium

Throughput

多重度	Throughput
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	16.0	16.0	1.6	1.6	1.6
4	26.8	26.8	2.7	2.7	2.7
16	45.8	45.8	4.6	4.6	4.6
64	50.5	50.5	5.0	5.0	5.0

Response Time

多重度	Response Time (90%tile)
	New-Order	Payment	Order-Status	Delivery	Stock-Level
1	59 ms	39 ms	2 ms	83 ms	2 ms
4	165 ms	104 ms	4 ms	251 ms	3 ms
16	318 ms	218 ms	27 ms	445 ms	30 ms
64	988 ms	1258 ms	92 ms	1328 ms	101 ms

まとめ

計測時のRDSのメトリクスは以下になります。メトリクスは計測中の最大値を表示しています。

インスタンスタイプ	多重度	Total Throughput (Tran/Sec)	CPU使用率	DiskQueueDepth (Count)	ReadIOPS (Count/Sec)	WriteIOPS (Count/Sec)
db.m1.small	1	6.74	28.81 %	23.02	180.54	548.39
	4	18.24	58.33 %	29.65	305.48	561.20
	16	25.08	68.67 %	25.53	364.42	532.85
	64	28.22	88.14 %	37.40	353.48	559.94
db.t2.small	1	12.97	8.33 %	29.81	202.63	651.33
	4	26.96	19.33 %	28.75	368.18	778.32
	16	39.86	26.27 %	25.92	476.67	742.92
	64	36.25	24.83 %	45.05	414.86	493.34
(参考) db.m3.medium	1	36.9	40.33 %	3.76	1.1	440.40
	4	61.54	72.67 %	7.59	1.1	682.76
	16	105.33	96.33 %	10.83	1.1	793.45
	64	116.07	99.33 %	9.20	1.1	687.69

メトリクスの結果を見ると以下のことが言えます。

• db.t2.smallはdb.m1.smallに比べて、1.3〜1.9倍程度高速である。
• db.t2.smallはdb.m1.smallに比べて、CPU使用率が3分の1程度である。
• ReadIOPSが大量に有るので、メモリに収まらないデータ量で計測していると考えられる。

db.m3.mediumはReadIOPSがほとんど無いので、データがメモリに乗っていたと考えられます。

最後に

今回の計測では、db.t2.smallのCPUを使い切れませんでした。多数のDisk I/OによりI/O Waitが頻発したためと思われます。CPU使用率の差が大きいため、データサイズが小規模でデータがメモリに載る場合は、もっと性能差が発生したのではないかと思います。

db.m1.smallよりdb.t2.smallの方が低価格ですが、高性能であることが確認できました。MySQLで5.6を使用できる場合は、こちらを使用する方がよいでしょう。