Direct Connect経由なFusion-ioとRDSはどっちが速いのかを繋いで、ベンチマークしてみた。

こんにちわ、デプロイ王子こと廣瀬 一海(@kazumihirose)です。

• 背景
• 目的
• 検証環境について
• TCP-Cについて
• ベンチマーク結果
• コネクション時の通信帯域
• MySQLサーバーのパラメーターの差異に関して
• 資料：セッティングパラメーター
• sysbench-lua 0.5について
• ベンチマーク結果

背景

RDBMSにおけるOLTP処理において、Fusion-io社のioDrive2はゲームなどを中心に非常に高い性能を示しており、各RDBMSのストレージとして採用されています。この事から、ioDrive2に匹敵する性能をクラウド求にられていくことが予想されます。

目的

本検証はハイブリッドクラウド環境において、ioDrive2搭載サーバの実運用性を検証することを目的としています。
EquinixにioDrive2を搭載した物理サーバを設置し、AmazonVPC内から、Amazon Direct Connectを経由して各種ベンチマークを行い、その性能と実運用性を検証を行います。

検証環境について

検証環境は以下の図の通りです。

Amazon VPCの1つのサブネットに、ベンチマーク用インスタンスとAmazon RDSのインスタンスを起動しています。また、Equinixデータセンターには物理サーバが設置されており、このサーバまでは本VPC及びDirectConnectを介して、互いに疎通しています。
各検証機のスペックは以下の表を参考にしてください。

Benchmark クライアント インスタンス

Amazon RDS ターゲット インスタンス

Equinix FusionIO搭載 物理サーバー

TPC-Cについて

TPC-CはTPCによって策定されたベンチマーク仕様の一つで、過去のTPC-A/TPC-Bの改良ベンチマークにあたります。このベンチマークでは卸売業の業務を参考モデルとしており、注文・支払いなどのトランザクションを実行し、システムの性能を測定します。
データはwarehouseを500をデーターセットとしてあらかじめ準備しました。
参考指標としてwarehouseは数値が多いほどスケールファクターとして扱われます、またクライアントからコネクションにより並列度が決定されます。
ioDrive2および、RDSのインスタンスに対し、以下の組み合わせのベンチマークを行いました。

ベンチマーク組み合わせ

ioDrive および RDSそれぞれ以下の組み合わせで行いました。

ベンチマーク結果

低コネクションレートでは、時折RDSがioDriveがピークで超えることがありますが、概ねioDrive2の方がトランザクション性能面ではRDSよりも良いという結果が出ています。
ioDrive2では意図的にクエリキャッシュを切っています。よって、RDSにクエリキャッシュが搭載されている影響である可能性が高いと推察しています

w100-c50

w100-c100

w100-c200

w250-c50

w250-c100

w250-c200

w500-c50

w500-c100

w500-c200

コネクション時の通信帯域

ベンチマーク時に計測したDX端点のルーターの帯域グラフを以下に掲載します。

C50時

C100時

C250時

MySQLサーバーのパラメーターの差異に関して

RDSとioDrive2におけるパラメータの差異のみを記載します。

(※表が大きいため、文字を小さくして全体を表示しています。詳細は、元記事をご参考いただければ幸いです。)

資料：セッティングパラメーター

すべてのセッティングにかかわるパラメーターを以下に記載します。

(※表が大きいため、文字を小さくして全体を表示しています。詳細は、元記事をご参考いただければ幸いです。)

sysbench-lua 0.5について

sysbenchは、mysqlやmariadb/perconaなどでよく使われているDBベンチマークツールです。
本来はCPUやメモリの性能を測定する目的のものですが、機能拡張によりRDBMSのベンチマークも可能になっています。
今回は8個のテーブル、40000000行に対し、スレッド数を1 2 4 8 16 32 64 128 256と可変させながらioDrive2および、RDSのインスタンスに対しベンチマークを行いました。
なお、計測したクエリは以下の通りです。

oltp.lua

pathtest = string.match(test, “(.*/)”) or “”

dofile(pathtest .. “common.lua”)

function thread_init(thread_id)
 set_vars()

if (db_driver == “mysql” and mysql_table_engine == “myisam”) then
 begin_query = “LOCK TABLES sbtest WRITE”
commit_query = “UNLOCK TABLES”
else
 begin_query = “BEGIN”
commit_query = “COMMIT”
end

end

function event(thread_id)
 local rs
 local i
 local table_name
 local range_start
 local c_val
 local pad_val
 local query

table_name = “sbtest”.. sb_rand_uniform(1, oltp_tables_count)
 db_query(begin_query)

for i=1, oltp_point_selects do
 rs = db_query(“SELECT c FROM “.. table_name ..” WHERE id=” .. sb_rand(1, oltp_table_size))
 end

for i=1, oltp_simple_ranges do
 range_start = sb_rand(1, oltp_table_size)
 rs = db_query(“SELECT c FROM “.. table_name ..” WHERE id BETWEEN ” .. range_start .. ” AND ” .. range_start .. “+” .. oltp_range_size – 1)
 end

for i=1, oltp_sum_ranges do
 range_start = sb_rand(1, oltp_table_size)
 rs = db_query(“SELECT SUM(K) FROM “.. table_name ..” WHERE id BETWEEN ” .. range_start .. ” AND ” .. range_start .. “+” .. oltp_range_size – 1)
 end

for i=1, oltp_order_ranges do
 range_start = sb_rand(1, oltp_table_size)
 rs = db_query(“SELECT c FROM “.. table_name ..” WHERE id BETWEEN ” .. range_start .. ” AND ” .. range_start .. “+” .. oltp_range_size – 1 .. ” ORDER BY c”)
end

for i=1, oltp_distinct_ranges do
 range_start = sb_rand(1, oltp_table_size)
 rs = db_query(“SELECT DISTINCT c FROM “.. table_name ..” WHERE id BETWEEN ” .. range_start .. ” AND ” .. range_start .. “+” .. oltp_range_size – 1 .. ” ORDER BY c”)
end

if not oltp_read_only then

for i=1, oltp_index_updates do
 rs = db_query(“UPDATE ” .. table_name .. ” SET k=k+1 WHERE id=” .. sb_rand(1, oltp_table_size))
 end

for i=1, oltp_non_index_updates do
 c_val = sb_rand_str(“###########-###########-###########-###########-###########-###########-###########-###########-###########-###########”)
query = “UPDATE ” .. table_name .. ” SET c='” .. c_val .. “‘ WHERE id=” .. sb_rand(1, oltp_table_size)
 rs = db_query(query)
 if rs then
 print(query)
 end
 end

i = sb_rand(1, oltp_table_size)

rs = db_query(“DELETE FROM ” .. table_name .. ” WHERE id=” .. i)

c_val = sb_rand_str([[
 ###########-###########-###########-###########-###########-###########-###########-###########-###########-###########]])
 pad_val = sb_rand_str([[
 ###########-###########-###########-###########-###########]])

rs = db_query(“INSERT INTO ” .. table_name .. ” (id, k, c, pad) VALUES ” .. string.format(“(%d, %d, ‘%s’, ‘%s’)”,i, sb_rand(1, oltp_table_size) , c_val, pad_val))

end — oltp_read_only

db_query(commit_query)

end

ベンチマーク結果

かなり傾向の違うグラフになっていますが、並列度が増大した際には比較的優位な結果が出ています。

TPS # read only

TPS # read/write

avg read only

avg read/write

99 read only

99 read/write

元記事はこちらです。
「Direct connect経由なFusion-IOとRDSはどっちが速いのかを繋いで、ベンチマークしてみた。」