はじめに

各クラウドベンダーからMySQLベースのマネージドサービスが提供されていますが、今回 MySQL Database Service (以降、MDSと表記) と、代表的な MySQL ベース DBaaS である Amazon RDS とで、ベンチマークを通じて、その違いを探ってみました。

ベンチマーク環境や前提条件など

今回のベンチマーク計測では、対象の両サービスでスペックやパラメータは揃えて比較する方針とし、いずれかが不利になるような設定変更やチューニングは施さないことを前提としています。

しかしながら、それぞれのサービスごとに仕様が異なる点もあり、変更がきかず条件が揃えられない部分も少なからずあります。
そこは、該当サービスの特色・特徴と捉えて、そのままの状態とします。

また、今回はシングルインスタンス構成での計測とし、レプリケーションや高可用性構成に準ずるようなトポロジー構成は対象外としています。

ベンチマークツールには、メジャーどころである sysbench (1.0.20) を使用します。
OLTP Read/Write テストシナリオで、並列実行数(threads)を8～2998の範囲で増加させ、各ケースでの TPS(transaction per sec), Response Time を確認していきます。

対象スペック

両サービスとも選択可能な最新のタイプで、CPU/メモリーが同等になるようにしました。
※スペックですが、今回は最高速を目的としていないので、中間スペックを選んでいます。

OCI

MDS	・MySQL.VM.Standard.E3.8.128 (8 OCPUs/128GB) ・MySQL 8.0.22 ・ストレージ：200GB
sysbench実行サーバー (Compute)	・VM.Standard.E3.Flex (4 OCPUs/16GB RAM) ・ストレージ：200GB (※1) ・NW bandwidth: 4 Gbps

AWS

RDS	・db.r6g.4xlarge (16 vCPUs/128GB) ・MySQL 8.0.21 (選択可能な最新バージョン) ・ストレージ：プロビジョンド SSD 200GB(3000IOPS) / 300GB(15000IOPS) (※2)
sysbench実行サーバー (EC2)	・t3a.xlarge (4 vCPUs/16GB RAM) ・ストレージ：200GB (※1) ・NW bandwidth: 最大 5 Gbps

※1：テストデータの論理バックアップ格納用。詳細は後述します
※2：IOPS のパターンについても後述します

MySQL パラメータ

今回ベンチマーク実行用に、事前に変更したパラメータは以下となります。
なお、これ以外で、選択したシェイプ/インスタンスタイプによって自動調整されるパラメータ値は原則そのままとしています。

MDS

※ MDS で変更可能なパラメータ、および変更方法については以下の記事も併せてご覧ください。
MySQL Database Service のシステム変数について | スマートスタイル TECH BLOG

RDS

また、バイナリーログは、MDSではデフォルトで出力(停止など変更不可)という仕様になっています。
RDS は自動バックアップを有効化することで出力されるので、両者バイナリーログが出力されるようにしておきました。

テストデータ、ディスクサイズ

テストデータは innodb_buffer_pool_size のサイズに収まる容量としました。

• 約 60GB (1000 万件 × 30 テーブル )

インスタンス作成時に指定するディスクサイズは、テストデータ作成時のバイナリーログ出力量分を加味し、200GB で用意しました。

また、RDS のプロビジョンド IOPS 15000 を設定するには、サービスの仕様制約上 300GB を確保する必要がありました。
Amazon RDS DB インスタンスストレージ – Amazon Relational Database Service

DB インスタンスの作成時に、IOPS レートとボリュームのサイズを指定します。割り当て済みストレージに対する IOPS の比率 (GiB 単位) は 0.5 以上でなければなりません。Amazon RDS は、DB インスタンスを変更するまで、その IOPS レートを提供します。

大まかなベンチマークの手順

1. インスタンスの作成、パラメータの調整
2. ベンチマーク用テストデータのロード
3. データロードしたスキーマを論理バックアップ
   • 両サービスとも、スナップショットによるバックアップは取得できますが、新規インスタンスにリストアする目的のバックアップであり、取得元インスタンスへはリストアできません。
     ※MDSのバックアップとリストアについては、以下の記事もご一読ください。
     MySQL Database Serviceのバックアップとリストア | スマートスタイル TECH BLOG
   • MDS は、MySQL Shell の dumpSchemas ユーティリティで OCI の Object Storage に直接エクスポート、リストア時はそれをインポートすることができるので、今回活用しました。
   • RDS からも、MySQL Shell を使って OCI の Object Storage へエクスポートすることは可能です。ただ、RDSから外部への送信は課金が発生するため、今回は、sysbench実行サーバー側にバックアップ用ディスクを追加し、mydumper/myloader で論理バックアップ・リストアを行うようにしました。
   • この際の、バックアップ・リストアの各サービス/各ツールでの実行時間の計測も控えましたので、比較を後述します。
4. ANALYZE TABLE 実行
   • MySQL Shell の loadDump ユーティリティには analyzeTables というオプションがあり、on を設定しておくと、データロード後に ANALYZE TABLE を自動で実行してくれるという便利な機能が備わっています。
     MySQL :: MySQL Shell 8.0 :: 8.6 Dump Loading Utility
5. インスタンス再起動
   • 今回ベンチマーク計測のため、テスト実行時には計測対象をリフレッシュする目的で再起動を行っていますが、RDS は停止・起動時に実行される内部処理を待つ必要があり、停止に数分待つこともしばしばありました。
     ※これに関しては、公式ドキュメントにも記載がありました。
     一時的に Amazon RDS DB インスタンスを停止する – Amazon Relational Database Service
   • MDS では、innodb_fast_shutdown 相当の停止オプションを実行時に選択することが可能です。(デフォルト：高速)
6. ベンチマーク実行 (実行時間：1h)
7. データ削除
8. 論理バックアップを再ロード
9. 以降、threadsを変更しながら 4.～ 8. をテストケース分繰り返し

今回は、各threadsごと3回ベンチマークを実行し、中央値を取りました。

計測結果

1. MDS vs Amazon RDS プロビジョンドIOPS:3000

最初のケースでは、RDS は、インスタンス作成時にプロビジョンドSSDを選択した際にデフォルト入力されている 3000 IOPS のスペックで計測しました。

(※クリックして拡大)

MDS と比較すると、グラフの通り大幅な性能差が見られました。

2. MDS vs Amazon RDS プロビジョンドIOPS:15000

そこで、MDS の IOPS を確認してみたところ、MDS で使用されるブロックボリュームのパフォーマンスレベルは Higher Performance であることが判明しました。

Oracle Cloud Infrastructure Documentation | Block Volume Performance や AWSと比べて低コストのCloud Infrastructure | Oracle 日本 といった公開情報から、以下の仕様であることが分かります。

• 最大IOPS / GB：75 (4 KB block size)

今回 MDS 側は ストレージサイズを 200GB としましたので、単純計算では 15000 IOPS に相当することになります。

ということで、次のケースとして、RDS の プロビジョンド IOPS を 15000 に設定し、改めてプラットフォームとしての条件を揃えた場合の比較を行いました。

(※クリックして拡大)

並列実行数が 1024 程度までは TPS, Response Time ともに処理性能は同等でした。
それ以上の高スレッド数においては、RDS は性能劣化の一途を辿っているのに対し、MDS では劣化というほどの状態は変化せず、一定の性能を保っているため、スケーラビリティが維持しているように見受けられます。

max_connections の最大値 3000 の手前当たりでは、最大で TPS に 2.2倍、Response Time で 4.0倍の開きが見られました。

既にお気付きかもしれませんが、MDS は MySQL Enterprise Edition ベースで実装・提供されています。

その Enterprise Edition で利用可能な機能の一つである、MySQL スレッド・プールが、今回の状況は大きな効果を与えていると考えます。
MySQL :: MySQL Enterprise Scalability

MDS では スレッド・プールプラグインがデフォルトで有効(無効化は不可) となっています。

定常的に多量の同時接続数が発生する OLTPなどの要件や、一時的なラッシュ状態が発生した場合でも、性能やサーバーリソースを維持したい場合に、このスレッド・プールが利用できるという点では、MDS を採用するメリットがあると考えます。

コスト差について

忘れずにお伝えしておきたいのが、IOPS を変更したことによる発生コストの違いです。

RDS で 15000 IOPS を使用する場合、プロビジョンド SSD ストレージ料金 (毎月0.15USD/GB) + プロビジョンドIOPS料金 (毎月0.12USD/IOPS) が必要となります。
(※ap-northeast-1リージョンの料金例)

そして、前述の AWS のプロビジョンド IOPS の仕様により、300 GB のストレージが必要となるので、1インスタンスあたり、(300 GB * 0.15 USD) + (15000 IOPS * 0.12) = 毎月 1,845 USD のコストとなります。

MDS は、この分のコストが(デフォルト Higher Performanceなので)発生しません。

年間のクラウドサービス料として算出してみると、下記のグラフの通り、1/7のコストメリットが出てきます。

※当然ながら、システム要件によっては 15000 IOPS は過剰、ということもありますが、単に MDS のデフォルトと比較した場合になりますので、ご了承ください。

テストデータの Dump, Load の比較 (MySQL Shell Dump/Load Utility vs mydumper/myloader)

ベンチマーク手順の紹介の折に触れましたが、各回実行時に、スキーマ単位で論理バックアップを再ロードし直してベンチマークを取得していました。

その際に、MySQL Shell Dump ユーティリティ と、並列実行可能として著名なツール mydumper/myloader との実行時間の比較も行ってみました。

mydumper/myloader は、MySQL Shell Dump ユーティリティのように、直接オブジェクトストレージへ転送することはできない(※)ため、sysbench 実行サーバー(Compute,EC2)にアタッチしたディスクに出力、そこからリストアする方式としました。

※oci cli put を用いて mydumper の dump データをオブジェクトストレージへ転送することも可能ですが、今回はそのような仕掛けを用意しなかったため対象外としました。

MySQL Shell Dump ユーティリティも、並列実行数を設定することができ、以下は12並列実行で統一して計測した結果となります。
Object Storage への Dump 出力の場合、mydumper と比べても 3.6倍程度高速でした。

MySQL Shell Dump/Load ユーティリティは、異種プラットフォーム/クラウドからのマイグレーションツールとして は勿論のこと、運用上の論理バックアップ目的でも非常に高性能で有益なツールでもあると言えますね。

まとめ

今回のベンチマーク比較を通して、MDS には、OLTP処理での高性能及び安定性があることが分かりました。
これは、MySQL Enterprise Edition ベースである機能の優位性、主に MySQL スレッド・プールの効果ですが、それだけでなく、ブロックボリュームのパフォーマンスレベルがデフォルトで Higher Performance となる点も、基礎の性能に大きく寄与することになります。

そして、(クラウドサービスの大きな選定条件ともいえる)コストメリットも、他のクラウドサービスと MDS で同性能を求めた場合と比較しても、MDS のほうがより安価である点が挙げられます。

MySQLベースのマネージドサービスの選定において、MDS と RDS との違いや特色、メリットとしてご参考としていただければ幸いです。

---

---

---

---