実践！DBベンチマークツールの使い方

IDC Frontier Inc. All rights reserved.
E50: 実践！DBベンチマークツールの使い方
～IDCFクラウドRDBをベンチマークのデモで紹介～
2018年7月29日 July Tech Festa 2018
株式会社IDCフロンティア
クラウド事業本部ビジネス開発部
藤城拓哉 @tafujish

2
自己紹介
【業務】
IDCFクラウドのサービス開発
（担当：IDCFクラウドRDB）
【趣味】
ベンチマーク
藤城拓哉 (FUJISHIRO TAKUYA)
@tafujish

3
Agenda
 IDCFクラウドとRDBサービスのご紹介
 ベンチマークとは
 データベースのベンチマークとは
 sysbenchの例
 tpcc-mysqlの例
 ケーススタディ
ベンチマークは良いぞぉ～

4
株式会社IDCフロンティア
主にデータセンターや
クラウドなどITインフラ
の提供を行っております
【データセンター】
首都圏、関西、東北、九州のデータセンター群
【クラウド IaaS】
東日本リージョン／西日本リージョン

5
4つの領域でサービスを展開
③クラウド ④ビッグデータ
①ネットワーク ②データセンター
Since 1986 Since 2000
Since 2009 Since 2014

6
IDCFクラウドとは

7
IDCFクラウドの特長1
ファイアウォール、ロードバランサー
高機能な仮想ルーターが無料で使える
ワンコインからGPUまで
コスパを追求したラインナップ

8
安定性を意識した
実装と運用

9
月額上限付き時間従量月定額
国内向けを意識した
料金プラン・請求方法

10
・高性能
・圧倒的な拡張性
・高度なセキュリティ
オンプレとクラウドを併用し
全体コストの最適化

11

12
サービスラインアップ・連携サービス
（高性能ロードバランサー）
（広域負荷分散）
サービス
ラインアップ
連携サービス
RDB
コンピューティング
（リソースモニタリング）（Push配信）（メール配信）（アプリデバック）（脆弱性試験）

13
IDCFクラウド RDB とは

14
構成
Client
StandbyActive
Client
障害時にDNSベースの
自動切替え
プライベートコネクト経由の
アクセスも可能
※Client側にStaticRouteの設定が必要
お客様環境
IDCFクラウドコンピューティング
RDBRDB
FQDNによる
アクセス
ボリュームミラーリング
MySQL

15
IDCFクラウド RDB とは
わかりやすい料金移行のしやすさ
シンプルなUI
オールフラッシュ性能
障害切替の速さ
低遅延の応答性能
RDB開発の工夫点従来のIDCFクラウドの良い点
ハードウェア専有タイプ無停止スペックアップ

16
IDCFクラウド RDB 料金
RDBマシン料金
 月額上限付き時間従量料金
 マシンタイプ毎の料金
 Light.S1 から小さくはじめられる
データディスク料金
 コンピューティングに準ずる
 月額 20円/GB
 時間 0.04円/GB
 1GB～利用可能
冗長構成料金
 冗長時は2台分の料金
※ データディスクを含む
 シングル構成も可能
バックアップ料金
 オブジェクトストレージ
を利用
 50GBまで無料
 7.8円/GB
オプションオプション
予算のサイジングがしやすい価格体系

17
tpcc-mysql ベンチマークスコア比較
A社
(Gen1)
A社
(Gen2)
IDCFクラウド
RDB
B社
(Gen2)
A社
(Gen1)
A社
(Gen2)
IDCFクラウド
RDB
B社
(Gen2)
warehouse=500 (I/Oバウンド) warehouse=50 (CPUバウンド)
• 4vCPU/32GBに近いマシンタイプ
• 冗長化あり
• 国内リージョン
• 1時間実行計測
TpmC
ベンチマークの実測として高性能

18
ネットワークレイテンシ比較
みんなが困っていること IDCFクラウド RDB
常に低レイテンシを実現

19
sysbench (OLTP) しながらスケールアップ
0
200
400
600
800
1000
1200
1400
0
200
400
600
800
1000
1200
1
16
31
46
61
76
91
106
121
136
151
166
181
196
211
226
241
256
271
286
301
316
331
346
361
376
391
406
421
436
451
466
481
496
511
526
541
556
571
586
Transactions/sec
Latency(99%)[msec]
経過時間 [sec]
Scale-up
L8→XL16
Scale-up
M4→L8
高負荷状態から無停止で抜け出し可能

20
IDCFクラウドのJTF向けクーポン
金額：1万円
クーポンコード：＜会場限定＞
登録期限：7月28日～8月31日
有効期限：（登録日から）3か月

21
最高のITエンジニアリング
を身に着ける

22
最高のベンチマークテクニック
を身に着ける

23
ベンチマークとは
元の意味
 基準点
 比較指標
→ 処理性能を測る

24
なぜベンチマークをするのか
基準点
 システムの処理性能把握
→ どこまで耐えられるか = スケール時の目安
比較指標
 環境の比較
→ サービス・機器・スペックの選定やサイジング
最終的にはコストの最適化

25
ミドルウェア
ハードウェア
どこのベンチマークをするのか
CPU メモリI/O ディスクI/O ネットワークI/O
WEB DB FW・LB ・・・
システム全体

26
ミドルウェア
ハードウェア
システム全体
システムリリース前にやる
システムの処理性能把握＝負荷試験
システムを作る前にやる
環境選定（事前調査）
システムを作る前・最中にやる
アプリ完成前からテストしたい

27
ミドルウェア
ハードウェア
システム全体
システムリリース前にやる
システムの処理性能把握＝負荷試験
システムを作る前にやる
環境選定（事前調査）
システムを作る前・最中にやる
アプリ完成前からテストしたい
本日のネタ

28
なぜ、DBのベンチマークは “最高” なのか
CPU、メモリ、ディスク、NWすべての性能が影響
→ 難しい
• ツールを動かすだけでなく、構成から考える必要がある
• ボトルネックがどこかわかりにくい
→ 上手く扱えれば有用
• CPUやディスクI/Oのベンチマークにもなる
• システム全体の中でボトルネックになりやすいDBを把握

29
DB以外のベンチマークが気になる方はこちら
総集編に収録されています

30
本日のゴール
 DBベンチマークのツールが実行できる
 実行結果を読み取れる
 ベンチマークの目的に合わせたパラメータ設定ができる
→ 比較表を作成し、必要なスペックの選定ができる

31
DBのベンチマーク
下ごしらえ

32
DBベンチマークの準備
CPU等をベンチマークするとき
 ツールを落として実行
DBをベンチマークするとき
 DBサーバーを準備
• DBのconfigどうしよ
 クライアントを準備
• クライアントもそこそのスペックいる
 ツールを落として
• インデックスはる？
 テストデータを準備
• バックアップとっておく
 実行
• 時間かけて測る

33
DBベンチマークの構成
クライアントとサーバーが同一マシン
 シンプルで実行しやすい
 ツール側もCPUリソースを消費する
 ディスクI/O性能が目的なら有り
サーバー
ベンチ
ツール
DB
サーバー
サーバー①
ベンチ
ツール
サーバー②
DB
サーバー
クライアントとサーバーが別マシン
 実構成に近い
 ネットワーク（NIC）にも負荷がかかる
 通常はこちらの構成を利用

34
DBベンチマークの性能指標
1. 単位時間あたりの処理性能
QPS (Queries Per Second)
= RPS (Requests Per Second)
TPS (Transactions Per Second)
TPM (Transactions Per Minute)
2. 応答時間
Response Time [ms (milliseconds)]

35
DBベンチマークの性能指標
1. 単位時間あたりの処理性能
QPS (Queries Per Second)
= RPS (Requests Per Second)
TPS (Transactions Per Second)
TPM (Transactions Per Minute)
2. 応答時間
Response Time [ms (milliseconds)]
目標値として設定するならこれ
●同時接続時に、90%ラインの
レスポンスタイムが▲秒以下
どれくらい処理できるか確認す
るときはこれ（中身に意味があれば
トランザクション、なければクエリ）

36
DBベンチマークツール ※MySQLの例
単純にクエリを繰り返す
 mysqlslap
 sysbench ※カスタマイズ可能
実際の業務を模した複雑なクエリ
 tpcc-mysql (卸売)
 LinkBench (ソーシャルネットワーク)
本日はsysbenchとtpcc-mysqlを取り上げます

37
sysbench

38
sysbench は良いぞぉ~
 様々なベンチマークが可能
 DB（OLTP）
 CPU
 Memory
 File I/O
 Threads
 Mutex
 MySQL以外にもPostgreSQLに対応
 パラメータが豊富で、出力も様々可能
 クエリ（OLTP）が色々用意済みで、カ
スタマイズも可能

39
sysbench インストール
パッケージのインストールのみ
【Debian/Ubuntu】
【RHEL/CentOS】
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt -y install sysbench
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
sudo yum -y install sysbench
最新の情報はこちら https://github.com/akopytov/sysbench

40
sysbench OLTPのテスト例
/usr/share/sysbench にスクリプトが設置されます
oltp_delete.lua
oltp_insert.lua
oltp_point_select.lua
oltp_read_only.lua
oltp_read_write.lua
oltp_update_index.lua
oltp_update_non_index.lua
oltp_write_only.lua
※実際に実行するクエリは oltp_common.lua の中で確認できる

41
sysbench 実行例
1. データベース（sbtest）作成
2. データ作成＋インデックス作成（oltp_read_writeの例）
mysqladmin -u <user> -h <host> --password=<password> create sbtest
sysbench ¥
--db-driver=mysql --threads=8 ¥
--tables=8 --table-size=100000 ¥
--mysql-user=<user> --mysql-password=<password> --mysql-host=<host> ¥
oltp_read_write prepare
 データ作成のときは prepare
 threads（スレッド数）、tables（テーブル数）、tables-size（テーブルサイズ）
は負荷の規模に応じて変える

42
sysbench 実行例
3. 測定（oltp_read_writeの例）
sysbench ¥
--db-driver=mysql --threads=16 ¥
--tables=8 --table-size=100000 ¥
--time=600 ¥
--mysql-user=<user> --mysql-password=<password> --mysql-host=<host> ¥
oltp_read_write run
 データ作成のときは run
 threads（スレッド数）、tables（テーブル数）、tables-size（テーブルサイズ）
は負荷の規模に応じて変える
 time（測定時間：秒）はスコアが安定する（数十分）くらいの時間が必要

43
sysbench デモ
StandbyActive
Client
RDBRDB
MySQL
IDCFクラウド RDB
IDCFクラウド
sysbench

44
sysbench 測定結果
SQL statistics:
queries performed:
read: 1829968
write: 522700
other: 261372
total: 2614040
transactions: 130660 (217.67 per sec.)
queries: 2614040 (4354.84 per sec.)
ignored errors: 52 (0.09 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 600.2589s
total number of events: 130660
Latency (ms):
min: 10.52
avg: 73.50
max: 6850.97
95th percentile: 231.53
sum: 9602990.46
← TPS
← QPS
← Response Time

45
sysbench 測定に便利なオプション①
・・・
[ 100s ] thds: 16 tps: 216.01 qps: 4278.11 (r/w/o: 2975.08/871.02/432.01) lat (ms,95%): 344.08 err/s: 0.00 reconn/s: 0.00
・・・
--report-interval=1
指定した時間毎（秒）の結果を出力。
時間経過によるスコアの安定性を確認できる。
↑
TPS
↑
QPS
↑
Response Time

46
sysbench 測定に便利なオプション②
41.104 |******* 1443
41.851 |********* 1762
42.611 |********** 2096
43.385 |************ 2516
44.173 |**************** 3161
44.976 |******************** 3993
45.793 |************************* 5130
46.625 |****************************** 6021
47.472 |************************************ 7220
48.335 |*************************************** 7961
49.213 |**************************************** 8120
50.107 |************************************** 7758
51.018 |************************************** 7637
51.945 |********************************* 6789
52.889 |***************************** 5937
53.850 |************************* 5119
54.828 |******************** 4144
55.824 |***************** 3528
56.839 |************** 2779
57.871 |************ 2355
58.923 |********** 1990
--histogram=on
Laytency (Response Time)の
分布を確認できる。

47
sysbench のデータサイズ
--table-size データベースサイズ [MB]
10000 2.8
100000 23
1000000 230
10000000 2,131
--tables データベースサイズ [MB]
1 230
2 439
4 890
8 1,655
--tables 1 のとき
--table-size 1000000 のとき
テーブル数×テーブルサイズでデータサイズが決まる
メモリ上に乗り切るデータサイズだと
→ 主にCPUに負荷がかかる
CPU-bound
メモリ上に乗り切らないデータサイズだと
→ 主にディスクI/Oに負荷がかかる
I/O bound

48
tpcc-mysql

49
tpcc-mysql は良いぞぉ~
 TPC-Cを参考にOSS実装
 卸売業を参考とした在庫管理のフロー
 実際の業務を模し、複雑な負荷をかける
ことが可能
 wharehose（倉庫）パラメータでデータ
規模を指定可能
 ディスクI/Oにガツンと負荷をかけられる

50
tpcc-mysql インストール
1. 【Debian/Ubuntu】ビルドに必要なパッケージのインストール
1. 【RHEL/CentOS】ビルドに必要なパッケージのインストール
2. 【共通】ビルド
apt install git gcc make mysql-client libmysqlclient-dev -y
最新の情報はこちら https://github.com/Percona-Lab/tpcc-mysql
yum install git gcc make mariadb mariadb-devel -y
git clone https://github.com/Percona-Lab/tpcc-mysql.git
cd tpcc-mysql/src
make
cd ..

51
tpcc-mysql インストール
3. データベース（tpcc）作成
4. テーブル作成
5. データ作成
6. インデックス作成
mysqladmin -u <user> -h <host> --password=<password> create tpcc
mysql -u <user> -h <host> --password=<password> tpcc < ./create_table.sql
./tpcc_load -h <host> -d tpcc -u <user> -p <password> -w 50
mysql -u <user> -h <host> --password=<password> tpcc < ./add_fkey_idx.sql
※ -w はデータサイズ規模（warehouse）

52
tpcc-mysql を実行する前にバックアップ
同じ測定を複数回実施したいとき、
データ作成に時間かかるので、
データ・インデックス作成後、測定開始前に
バックアップをとることをおススメです。
1. ダンプ
 mysqldumpやxtrabackup
 DBサービス起動したまま可能
 時間かかる
2. コールドバックアップ
 サービスを停止してdatadir下をコピー
 高速なのでオススメ
DBへのwriteクエリ等の更新や挿
入があるとDB内のデータが変わる
ため、2回目実行しても同じ結果が
得られない

53
tpcc-mysql 実行例
測定
-w warehouse データ規模
-c connections 同時接続数
-l running_time 測定時間（秒）
-i report_interval 指定した時間毎に結果出力（秒）
-r warmup_time 測定前のウォームアップ時間（秒）
./tpcc_start -h <host> -P 3306 -d tpcc -u <user> -p <password> -w 50 -c 32 -l 600 -i 60 -r 0

54
tpcc-mysql デモ
StandbyActive
Client
RDBRDB
MySQL
IDCFクラウド RDB
IDCFクラウド
tpcc-mysql

55
tpcc-mysql 測定結果
<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.48% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 99.99% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 99.99% [OK]
<TpmC>
38179.102 TpmC ← TPM

56
tpcc-mysql 測定結果（定期レポート）
60, trx: 7121, 95%: 402.806, 99%: 601.046, max_rt: 1103.069, 7130|425.495, 713|238.339, 712|895.679, 706|1166.206
120, trx: 5190, 95%: 601.766, 99%: 2539.417, max_rt: 4962.138, 5194|4072.930, 519|283.796, 519|4984.786, 521|1420.736
180, trx: 4264, 95%: 1121.245, 99%: 1595.299, max_rt: 3258.285, 4261|2299.293, 428|202.829, 423|3301.626, 428|1344.811
240, trx: 6025, 95%: 765.965, 99%: 982.879, max_rt: 1238.932, 6023|946.613, 602|93.649, 603|1507.521, 603|661.941
300, trx: 6534, 95%: 700.597, 99%: 894.169, max_rt: 1066.967, 6531|888.620, 652|55.833, 652|1168.198, 654|753.374
360, trx: 5898, 95%: 769.873, 99%: 1094.713, max_rt: 1373.785, 5904|1170.824, 591|246.228, 592|1492.686, 591|824.014
420, trx: 4522, 95%: 880.885, 99%: 1048.842, max_rt: 1249.462, 4521|1029.945, 453|77.874, 452|1678.444, 453|774.947
480, trx: 5127, 95%: 876.939, 99%: 1112.885, max_rt: 1448.340, 5121|1298.610, 512|79.652, 512|1643.632, 514|663.227
540, trx: 5927, 95%: 976.720, 99%: 1243.228, max_rt: 1404.741, 5921|1307.893, 592|74.536, 592|1695.186, 593|1121.459
600, trx: 6857, 95%: 796.121, 99%: 1072.656, max_rt: 1295.642, 6854|1228.602, 686|247.134, 685|1583.367, 678|774.220
…
-i 60
指定した時間毎（秒）の結果を出力。
時間経過によるスコアの安定性を確認できる。
↑
Transactions
↑
Response Time

57
tpcc-mysql のデータサイズ
warehouse データベースサイズ[GB]
50 3.5
100 7.0
500 35.4
1000 71
1500 107
warehouseを大きくして
I/O bound に負荷をかけよう

58
Case Study

59
Case 1 性能比較
次に開発する新規サービスは、クラウドサービスのDBaaSを使ってみよう。
でも、マシンタイプ色々あってどれにしよう。
1. 想定の負荷を仮定する
tpcc-mysqlの方が負荷大き目
【sysbench】
--threads=16
--tables=8
--tables-size=100000
--time=3600
oltp_read_write
2. 各マシンタイプにて同じ設定で計測
※クライアントのスペックは大き目を用意しておく
（ここでは highcpu.L8）
【tpcc-mysql】
-w 500
-c 32
-l 3600
-r 0

60
Case 1 性能比較：応用
各社サービス間の比較も可能
【ポイント】
・apples to apples
CPU/メモリ
冗長化設定
リージョン/ゾーン

61
Case 2 時間経過による性能の変化
最終的なベンチ結果のみだけでなく、
時間経過による影響も確認したい。
1. 測定時にレポート設定
毎秒表示のときは1、毎分は60。
【sysbench】
--report-interval=1
【tpcc-mysql】
-i 1
2. 対象の列を抜き出してグラフ化
※tpcc-mysqlで60秒の例

62
Case 2 時間経過による性能の変化：応用
動的なスペックアップも
確認可能

63
Case 3 ディスクI/O性能
超速いSSDを手に入れたぞ。
I/Oに負荷がかかった状態でどれくらい速いのかな。
1. tpcc-mysqlが複雑な処理なのでベター
2. warehouseを大きくする
ここでは –w 1500
※my.cnfでI/O周りのチューニング入れる

64
Case 4 MySQLのパラメーター
よし、MySQLをベンチマークするぞ。
MySQLのconfigどうしよう・・・
innodb_flush_method=O_DIRECT
innodb_write_io_threads=16
innodb_read_io_threads=8
innodb_io_capacity=10000
1. ベストは、本番時に利用予定のもの
や社内で決まっているもの
2. なければ、ほぼデフォルトにして、
innodb_buffer_pool_sizeを設定し
ておく（搭載メモリの7割前後）
3. 高速なSSDであれば、I/O周りの設
定を入れておく例→

65
Case 5 同時接続数
メニーコアCPU搭載サーバーを手に入れたぞ。
CPUコアが多いってことは、並列数（同時接続数）も多くさばけるよね。
Percona Database Performance Blog
https://www.percona.com/blog/2018/07/11/amd-epyc-performance-testing-ps-systemd/
1. 同時接続数を指定して測定する
【sysbench】
--threads=512
【tpcc-mysql】
-c 512
2. 同時接続数を変更し、測定を繰り返す
4, 8, 16, 32, 64, 128, 256, 512など

66
DBのベンチマークに興味をもったあなたへ
https://www.percona.com/blog/
 最新のハードウェアやMySQLの情報
 ベンチマークツールの紹介
 sysbench-tpcc

67
むすび
DBのベンチマークができるようになったら練習兼ねて、
IDCFクラウド上でお試しください。
 IDCフロンティアもブース出展中
 IDCFクラウド RDB の無料キャンペーンは7末まで

68
IDCFクラウドのJTF向けクーポン
金額：1万円
クーポンコード：＜会場限定＞
登録期限：7月28日～8月31日
有効期限：（登録日から）3か月

69
Happy benchmarking!

実践！DBベンチマークツールの使い方

More Related Content

What's hot (20)

Similar to 実践！DBベンチマークツールの使い方 (20)

More from Fujishiro Takuya (12)

実践！DBベンチマークツールの使い方