MySQL Cluster で各ノードのスケールアウトを検証する
MySQL Cluster の各ノード（SQL ノード・データノード）を最大 8 台ずつまで拡張し、どれだけスケール出来るのかを検証してみたいと思います。
なお、検証用のベンチマークツールとしては、tpcc-mysql を今回は使用しています。
MySQL Cluster とは
MySQL Cluster はシェアードナッシングシステムでのインメモリーデータベースのクラスタリングを可能にするテクノロジです。シェアードナッシングアーキテクチャーでは、非常に安価なハードウェアでシステムが動作し、ハードウェアやソフトウェアの要件が最小限に抑えられます。
MySQL Cluster は、単一障害点が発生しないように設計されています。シェアードナッシングシステムでは、各コンポーネントに固有のメモリーとディスクが用意され、ネットワーク共有、ネットワークファイルシステム、SAN などの共有ストレージメカニズムの使用は推奨またはサポートされません。
MySQL Cluster は、標準の MySQL Server と NDB (「Network DataBase」 を表します) と呼ばれるインメモリーのクラスタ化されたストレージエンジンを統合したものです。
[ 引用元 ： MySQL リファレンスマニュアル 18.1 MySQL Cluster の概要 ]
検証環境
検証環境として Amazon Web Services(以下 AWS) 上に 最大 8×8 のノード数で MySQL Cluster 環境を以下の図のように構築しました。
各インスタンスサイズ
- 管理ノード ：t2.small
- SQLノード ：t2.small
- データノード：t2.xlarge
- tpcc-mysql ：t2.large
実際にスケールアウト構成を検証する際には、SQL ノード 2 台、データノード 2 台からはじめ、それぞれのノード数を 4、6、8 台と増やしていき、最大 8 × 8 のノード数で検証しております。
今回は、各ノード追加後にデータのリストアを行っているため、データ再配置は全てリストア時に行われております。
また、使用パッケージ・バージョンは以下のパッケージを使用しております。
[sh]
mysql-cluster-community-client-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-common-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-data-node-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-libs-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-libs-compat-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-management-server-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-ndbclient-7.5.4-1.el7.x86_64.rpm
mysql-cluster-community-server-7.5.4-1.el7.x86_64.rpm
[/sh]
tpcc-mysql は GitHub から Clone し、コンパイルしたものを使用しています。
実行に関しては、warehouse を 50、コネクションを 128、計測時間は 60 分、助走時間を 5 分としています。
各種設定ファイルは、ほぼデフォルト設定とし、下記のパラメータを追加・変更しています。
※メモリ設定等の性能に関する部分を抜粋しています。
[ini]
/var/lib/mysql-cluster/config.ini
[ndbd default]
NoOfReplicas = 2
DataMemory = 11264M
IndexMemory = 2048M
ODirect = true
MaxNoOfConcurrentOperations = 131072
MaxNoOfConcurrentTransactions = 131072
TimeBetweenLocalCheckpoints = 6
NoOfFragmentLogFiles = 384
[/ini]
[ini]
/etc/my.cnf（SQLノード）
[mysqld]
ndbcluster
ndb_use_exact_count = 0
ndb_index_stat_enable = 0
ndb_force_send = 1
ndb_log_update_as_write = OFF
optimizer_switch = “engine_condition_pushdown=on”
transaction_isolation = REPEATABLE-READ
explicit_defaults_for_timestamp = ON
default_storage_engine = NDBCLUSTER
sql_mode = NO_ENGINE_SUBSTITUTION
max_connections = 1000
[/ini]
ベンチマーク
- データノード×2、SQLノード×2（D2 × S2）
- データノード×2、SQLノード×4（D2 × S4）
- データノード×2、SQLノード×6（D2 × S6）
- データノード×2、SQLノード×8（D2 × S8）
- データノード×4、SQLノード×2（D4 × S2）
- データノード×4、SQLノード×4（D4 × S4）
- データノード×4、SQLノード×6（D4 × S6）
- データノード×4、SQLノード×8（D4 × S8）
- データノード×6、SQLノード×2（D6 × S2）
- データノード×6、SQLノード×4（D6 × S4）
- データノード×6、SQLノード×6（D6 × S6）
- データノード×6、SQLノード×8（D6 × S8）
- データノード×8、SQLノード×2（D8 × S2）
- データノード×8、SQLノード×4（D8 × S4）
- データノード×8、SQLノード×6（D8 × S6）
- データノード×8、SQLノード×8（D8 × S8）
上記の各ノード状態で tpcc-mysqlを用い、tpmC を計測した結果が下記の表となります。
| S2 | S4 | S6 | S8 | |
|---|---|---|---|---|
| D2 | 9,874.150 | 17,184.117 | 18,148.650 | 18,399.316 |
| D4 | 8,589.150 | 18,276.301 | 25,260.584 | 26,821.684 |
| D6 | 8,380.884 | 16,530.617 | 22,719.717 | 26,667.934 |
| D8 | 9,224.533 | 17,906.166 | 24,117.684 | 27,118.283 |
まとめ
- SQL ノード 4 台まではデータノード数に関係なくスケールアウトしていますが、データノードが 2 台では、それ以上スケールアウトできませんでした。
- データノードを 4 台、6 台、8 台と増やしていくと、SQL ノードの台数に比例してスケールしています。
- tpcc-mysql のデータ・クエリでは、SQL ノード・データノード双方を増やしたほうがスケールし、性能向上が見込める結果となりました。
- データノードをスケールアウトさせると、各ノードの消費メモリ量が減るので、スペックダウンも検討することが出来ると考えられます。
