「MySQL on EC2」と「RDS for MySQL」と「Aurora MySQL」で性能を測ってみた

はじめに

こんにちは。大阪オフィスの林です。

「MySQL on EC2」と「RDS for MySQL」と「Aurora MySQL」でRead/Writeの性能がそれぞれどのくらいなのか実際に検証して確認してみましたので、記事としてまとめておきたいと思います。

注意とお断り

本記事でフォーカスしている「性能」は、システムの構成、システムの使い方／使われ方、クラウドの状況、検証の環境／方法などで変動性が非常に大きい項目（めっちゃ保険掛ける…）です。検証で使っている数字（スレッド数やクエリ数など）も幾分か主観で設定している値のため、本記事の内容を根拠に設計などをおこなうのは避けて頂き、あくまでも参考としてご覧頂けますと幸いです。

 「Amazon Aurora」

検証をおこなう経緯も含めて「Amazon Aurora」について少しだけ触れておきたいと思います。公式ページはこちらから。

Amazon Aurora は、標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速です。また、商用データベースと同等のセキュリティ、可用性、信頼性を、10 分の 1 のコストで実現します。

前々から「標準的なMySQLと比べて最大で5倍高速」という部分がどうしても気になっていたということもあり、今回検証してみることにしました！

検証準備

検証環境の説明

今回は3つのDB環境を対象に検証をおこないます。

1. MySQL on EC2
2. RDS for MySQL
3. Aurora MySQL

1. 「MySQL on EC2」

下図をご覧ください。「MySQL on EC2」はEC2にMySQLをインストールし、別のEC2からDB接続して性能を測定していきます。

2. 「RDS for MySQL」　および　3. 「Aurora MySQL」

「RDS for MySQL」と「Aurora MySQL」はAWSから提供されているRDSサービスを利用します。また、インスタンスタイプに依存して性能も変わってきてしまうので、インスタンスタイプは共通（r5.large系）にします。Auroraの場合、小さいインスタンスタイプ（t2.smallなど）を使うとmax-connectionの最大数が「45」になってしまい十分な検証が出来なさそうだったので、少々リッチなインスタンスタイプですが「r5.large」を使って検証を進めることにしました。また、RDSのパラメータグループもデフォルトとします。※「MySQL on EC2」も同系のインスタンスタイプを使用します。

環境スペック

簡単ですが、今回の検証環境のスペックをまとめておきます。

環境	インスタンスタイプ	ストレージタイプ	サイズ	MySQLバージョン
MySQL on EC2	r5.large	汎用 SSD (gp2)	8GiB	5.7.28
RDS for MySQL	db.r5.large	汎用 (SSD)	20GiB	5.7.22
Aurora MySQL	db.r5.large	DBクラスター		5.7.12

検証ツール

性能測定を行うツールは、MySQLの性能測定ということでMySQLにバンドルされている「mysqlslap」を使います。「mysqlslap」の詳細および公式はこちらから。※「mysqlslap」は下記のコマンドを実行すればインストールできます。

検証内容の説明

今回検証する内容を下記にまとめました。

検証タイプ	スレッド数	クエリ数	説明
Read/Writeの割合を50%ずつでクエリを実行	1	2,000	1スレッドで2,000クエリの読み書きを実施した時の性能を測定します。
	50	2,000	50スレッドで2,000クエリの読み書きを実施した時の性能を測定します。
	150	2,000	150スレッドで2,000クエリの読み書きを実施した時の性能を測定します。
	500	2,000	500スレッドで2,000クエリの読み書きを実施した時の性能を測定します。

※「mysqlslap」では、ほかにもread (テーブルのスキャン)、write (テーブルに挿入)、key (主キーの読み取り)、update (主キーの更新)の検証タイプを選択できますが、今回は「Read/Write」で性能を見ていきたいと思います。

検証コマンドの説明

下記のコマンドでクエリを発生させて、その際の性能を見ていきます。

コマンドオプションを説明します。詳細および公式はこちらをご確認ください。

コマンドオプション	説明
--auto-generate-sql	SQL ステートメントがファイルおよびコマンドオプションを使用して指定されない場合、自動的に生成します。
--auto-generate-sql-guid-primary	自動生成されたテーブルに GUID ベースの主キーを追加します。
--engine=innodb	ストレージエンジンを指定します。
--number-int-cols=20	--auto-generate-sql が指定された場合に使用する INT カラムの数を指定します。
--number-char-cols=20	--auto-generate-sql が指定された場合に使用する VARCHAR カラムの数を指定します。
--concurrency=1	SELECT ステートメントを発行する際、シミュレートするクライアントの数を指定します。今回はここの値を変えてスレッド数に応じた各MySQLの性能差を見ていきたいと思います。
--auto-generate-sql-write-number=2000	各スレッドで実行する行挿入の回数を指定します。
--auto-generate-sql-execute-number=2000	自動的に生成するクエリーの数を指定します。
--auto-generate-sql-load-type=mixed	テストの負荷タイプを指定します。「mysqlslap」では、read (テーブルのスキャン)、write (テーブルに挿入)、key (主キーの読み取り)、update (主キーの更新)を選択できます。
-u	mysqlログインユーザ名を指定します。
-h	接続先ホスト名を指定します。
-p	パスワードを指定します。

検証結果

結果は「number of seconds to run all queries（すべてのクエリを実行する秒数）」として評価されます。

検証タイプ	スレッド数	クエリ数	MySQL on EC2	RDS for MySQL	Aurora MySQL
Read/Writeの割合を50%ずつでクエリを実行	1	2,000	2.173 sec	5.173 sec	8.048 sec
	50	2,000	20.860 sec	19.931 sec	22.742 sec
	150	2,000	76.816 sec	55.856 sec	47.838 sec
	500	2,000	414.476 sec	260.460 sec	144.682 sec

まとめ

スレッド数が増えれば増えるほど、Auroraの良さが出てるように見えますね～。何が何でもRDSに移したりするのではなく、シングルスレッドのときにどういったアーキテクチャを採用すればいいのかなど、データベースの使われかたをしっかりと見極めたうえでデータベースエンジン（サービス）を選定したほうがよさそうですね。（あたりまえか！？）

インスタンスタイプやパラメータをチューニングしたりして挙動を見るのも面白そうですし、新しいインスタンスタイプが出たり、新しい機能が追加されたときにどのように性能に変化が生じるのかも楽しみです！