DB負荷試験をやった話

こんにちは！インフラチームの川田です。

業務では社内ネットワーク構築・運用やツールの検証などしています。
本記事では、1月末から2月初頭にかけて行ったDB検証のベンチマーク結果をまとめたいと思います。

試験環境

今回は以下4つの環境を対象にMySQL 5.7互換のあるDBを構築し、ベンチマークを測りました。

• Google Compute Engine (以下GCE)
• Google CloudSQL
• Amazon EC2
• Amazon Aurora

サービス概要

GCE及びEC2は、仮想マシンを構築することができるサービスです。
CloudSQLとAuroraは、フルマネージド型DBサービスです。どちらも簡単なので、とりあえずDB構築してみたいという初心者にオススメです。
CloudSQLはチューニング項目はありませんが、AuroraではMySQLのmy.cnfで設定できる項目の一部を変更できます。

インスタンス概要

GCPで使用したマシンスペックは次の表の通りです。

GCEでのディスク容量は500GB SSD永続ディスク、CloudSQLは2TB SSDとしました。はじめにデフォルト要領で計測を行っていましたが、GCPではディスクサイズによってIOPSとスループットが向上するため、本記事ではディスク容量を多めに取った状態での結果を記載しています。
また、CloudSQLへの接続方法は外部IPアドレスを直接指定するか、proxyを経由するかの2通りがあります。2通りで検証を行ったところ、外部IPで接続した方が1.3倍ほど良い性能が得られました。本記事内の結果は外部IPで接続したときのものです。

AWSで使用したマシンスペックは次の表の通りです。

EC2のディスク容量はデフォルトの10GB 汎用SSDとしました。
RDSでは設定項目をパラメータグループとして扱います。
今回のAuroraでの検証パラメータグループはデフォルトを使用しています。

試験内容

使用したベンチマークツールはtpcc-mysqlとsysbenchです。
tpcc-mysqlはTPC-Cの仕様に沿ったベンチマークツールです。
今回のベンチマークで使用したパラメータは以下の通りです。

• warehouse: 5
• warmup time: 10
• bench time: 180
• connection: 64

試行回数は各環境で3回ずつ、結果は1分間に処理したトランザクション数です。
CPUが2,4,8コアのインスタンスを対象に検証を行いました。
tpcc-mysqlはGCEもしくは、EC2の8コアインスタンス上で実行しました。

sysbenchは、Luaスクリプトによってシナリオを変更することができます。
今回のベンチマークで使用したLuaスクリプトは以下の8つです

• bulk_insert.lua
• oltp_insert.lua
• oltp_point_select.lua
• oltp_read_write.lua
• oltp_update_index.lua
• oltp_write_only.lua
• select_random_points.lua
• select_random_ranges.lua

パラメータは次の通りです。

• thread: 256
• bench time: 180

試行回数は各環境1回ずつ、結果は1秒間に処理したトランザクション数です。
マシンスペックは全環境で8コアのインスタンスを使用しました。
sysbenchもGCEもしくは、EC2の8コアインスタンス上で実行しました。

また、今回の検証では2月7日に正式リリースされたばかりAurora MySQL 5.7互換を早速使ってみました。
tpcc-mysqlとsysbenchでの試験はMySQL5.7互換での結果を出していますが、最後にMySQL5.6互換のAuroraとの比較も行いました。
手順はこちらを参考に、ベンチマーク用AMIに同梱されているsysbenchを用いて検証を行いました。使用したシナリオは次の通りです。

• oltp
• readonly
• readwrite
• selectonly
• writeonly

ベンチマーク結果

まずはtpcc-mysqlの結果です。
CPUのコア数が2, 4, 8のインスタンスで検証を行いました。
GCEとEC2上で構築したMySQLはチューニング前後共に計測しています。
チューニング前後ではinnodb_buffer_pool_sizeなどを変更しています。

続いて、sysbenchの結果です。

最後にAurora 5.6と5.7の比較です。

まとめ

tpcc-mysqlの結果から、GCE, EC2インスタンスのチューニング後の性能が非常に良いことがわかります。GCEとEC2ではチューニング前後共にGCEの方が性能が高くなっています。性能差が大きく開いているため今後機会があれば、もう少し調べてみたいと思います。
また、sysbenchのoltp_write_only.luaとoltp_read_write.luaの結果を見るとCloudSQLとAuroraのwrite性能が他よりも低いことがわかります。

Auroraはデフォルトのパラメータグループでベンチマークを取っているので、チューニング次第ではさらに良い性能が見込めるのではないでしょうか。また、Amazonが提供するAurora負荷テスト用AMIでのsysbench検証結果では、とても良い性能が出ています。32コアインスタンスを使用していることや専用sysbenchのため、他のsysbench結果と単純比較は出来ませんが、スケールアップすることで順当に性能向上が見込めます。そして、AuroraのMySQL5.6互換、5.7互換の比較については、readonlyとselectonlyの性能が圧倒的に高くなっています。

CloudSQLについては、tpcc-mysqlではスケールアップした場合に他と比べて性能向上しませんでした。しかし、sysbenchのbulk_insertの結果が他より高い値が計測できました。並行処理が少なく、一度の書き込み量が多い環境では良い性能が出ると考えられます。

これらの結果から、Auroraはread性能が強い傾向が現れていたので、Webサイトなどに向いていると思います。write性能が求められる環境では、素のMySQLをチューニングしていくと良いのではないかと思います。

最後に

本番環境を想定したシナリオで測定するのがベストですが、これらの計測結果が誰かのDB選定の参考になれば幸いです。

また、Aimingではインフラエンジニアを絶賛募集中です！
ご興味のある方がいましたら、是非ご応募ください！