概要
2018年6月28日にリリースされたIDCFクラウドRDBを試しに使ってみます！実はクローズドβ版も使ってみたので、正式版との比較も少し。
公開仕様
検証ポイント
- 構築容易性:
- 素の MySQL と比較して、簡単に構築できるか？
- パフォーマンス:
- 素の MySQL と比較して、著しくパフォーマンスが劣化していないか？
- 単クエリのレイテンシ (応答遅い)
- 多数のクエリのスループット (ちょっとずつしかクエリを捌けない)
- リソース消費量 (燃費悪い)
- 素の MySQL と比較して、著しくパフォーマンスが劣化していないか？
- 安定性:
- 動き続けるか？(1週間くらい放置したらいつの間にかハングしてたりすると困る)
-
想定ユースケース:
- とりあえず WordPress用の DB として使えそうか？
-
メンテ性:
- ちゃんとバックアップ/リストアできるか？
- 不意に壊れたときは、どんな段取りでサービス復旧できそうか？
-
公開仕様収集:
- クラウド事業者 (IDCF) 側での定期的なメンテナンスはあるか？
- もしあれば、メンテ中は RDS はどのような稼働状態になるか？ (停止 or 稼働を維持するがパフォーマンス劣化？)
構築の容易性
RDBの作成
まずはRDBを作成してみる
- 操作内容はごく簡単。仮想マシンを作るのと同じ感覚でポチポチ作成できる
- データベースはmysql_5.7のみ対応
- バックアップはオブジェクトストレージにバケットを作成してからでないと作れない仕様
- RDB作成にかかった時間は約2分半。β版の時は3分から4分かかっていたので、ちょっと早くなった印象
変更・管理
RDSの操作
- 削除ボタンはあるが、停止、再起動のボタンは見当たらない。停止や再起動、手動でのフェイルオーバーなどは出来ない様子
リサイズ
- 無停止でスペックアップが可能
- Lightタイプから他のタイプへは変更できない。これは仮想マシンと一緒
- innodb_buffer_pool_sizeはメモリサイズに併せて自動で変更してくれるらしい
- スペックダウンを伴うリサイズはできない。今後提供予定と仕様書に記載あり
ボリューム
- 無停止で増設可能
- ボリュームの最大サイズ1,000GBまで何度でも拡張可能
- ボリュームサイズの削減はできない仕様書に明記。縮小するときは作り直し
バックアップ
- 手動でもバックアップの作成ができるが、保存期間やバックアップ実行日時、バックアップ先のバケットの変更ができる箇所は見当たらない。変更の際は作り直しになってしまいそう
- オブジェクトストレージ側でバックアップ用のバケットを削除してしまうことができてしまうので注意
クライアントからのアクセス
- FQDN でホストを指定してアクセスする。特に問題なし
[root@rdb-test1 ~]# mysql -h qg-test.local.rdb.idcfcloud.net -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 46
Server version: 5.7.22-log MySQL Community Server (GPL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
バックアップ・リストア(メンテナンス性)
バックアップ
- データサイズ 343.88 MB で、バックアップにかかった時間は12分（バックアップ開始時間：朝6時 → 作成日時が06:12:11）β版の時は50分かかっていたので、早くなった印象。
リストア
上記で取ったバックアップからRDBを復元してみる。
ゾーン：lux、 マシンタイプ：standard.S4、バックアップ：なし
にしてリストアを実行。
Creating の状態で 2分強…
Restoring の状態で 5分半待って…
何故か、Error に
何度か条件を変えてリストアを試してみたがErrorとなったため、何か障害が起こっていたのかもしれない。時間がないので問い合わせは割愛。リストアはまたの機会に試してみる。
パフォーマンス
RDB と MySQLをインストールした通常の仮想マシン を用意して、mysqlslapを使ってパフォーマンス測定をし、結果を比較する。
スペック
比較対象のインスタンスのスペックは、RDBに合わせて以下とする。
| 項目 | 設定値 |
|---|---|
| OSタイプ | CentOS 7.1 |
| マシンタイプ | light.S2 |
| ボリューム | 15GB |
| MySQL | mysql_5.7 |
テスト内容
- テスト実行用インスタンスは別に用意
- 比較対象用のDBサーバ と テスト実行用サーバ はRDB と同じゾーン内に配置
- RDBは冗長化ありと冗長化なし、及びβ版（冗長化なし）を比較する
- チューニングはしない状態で計測する
- 3クライアントから計1万回のSQL文を実行するケースと、50クライアントから計10万回のSQL文を実行するケースのテストを実行
- テストの試行回数は各ケースとも10回
- 各ケースとも以下の種別のテストをそれぞれ実行
| 種類 | 生成されるSQL |
|---|---|
| read | テーブルスキャンをするSELECTを実行 |
| key | 主キーを使ったSELECTの実行 |
| write | テーブルに挿入 |
| update | update文の実行 |
| mixed | 挿入とテーブルスキャンするSELECTが半分ずつ実行 |
コマンド例
# mysqlslap \
> --no-defaults \
> --user=root \
> --password \
> --host=qg-test.local.rdb.idcfcloud.net \
> --engine=innodb \
> --auto-generate-sql \
> --auto-generate-sql-load-type=read \
> --auto-generate-sql-add-autoincrement \
> --number-of-queries=100000 \
> --concurrency=50 \
> --iterations=10
50クライアント・10万クエリの結果
処理時間の比較 (単位：秒)
| 項目 | read | key | write | update | mixed |
|---|---|---|---|---|---|
| RDB(冗長化なし) | 108.596 | 20.674 | 21.212 | 29.8 | 21.551 |
| RDB(冗長化あり) | 119.143 | 20.534 | 30.657 | 34.194 | 25.434 |
| RDB（β版） | 184.674 | 41.769 | 32.77 | 42.356 | 34.55 |
| 通常インスタンス | 115.109 | 17.747 | 43.277 | 28.325 | 20.422 |
- β版は通常インスタンスよりreadの処理速度が特に遅い結果だったが、リリース版のRDBは通常インスタンスと同程度の処理速度となっている
3クライアント・1万クエリの結果
処理時間の比較 (単位：秒)
| 項目 | read | key | write | update | mixed |
|---|---|---|---|---|---|
| RDB(冗長化なし) | 9.757 | 1.291 | 23.242 | 25.607 | 13.823 |
| RDB(冗長化あり) | 9.464 | 1.418 | 24.455 | 22.784 | 9.335 |
| RDB（β版） | 40.656 | 2.926 | 10.181 | 9.522 | 6.000 |
| 通常インスタンス | 9.107 | 1.051 | 32.218 | 33.4215 | 17.711 |
- 50クライアント・10万クエリの時と同様、readの処理速度は改善している
- 通常インスタンスと同程度または少し早い
MySQLパラメータを確認してみる
innodb_buffer_pool_sizeはメモリサイズに併せて自動で変更してくれるらしいので、スペックの違うRDBを作成し、主要なパラメータの違いを見てみる。
| S2 | S4 | S8 | |
|---|---|---|---|
| max_connections | 151 | 151 | 151 |
| join_buffer_size(KB) | 256 | 256 | 256 |
| sort_buffer_size(MB) | 0.25 | 0.25 | 0.25 |
| read_buffer_size(KB) | 128 | 128 | 128 |
| read_rnd_buffer_size(KB) | 256 | 256 | 256 |
| key_buffer_size(MB) | 8 | 8 | 8 |
| innodb_buffer_pool_size(GB) | 1 | 2 | 5 |
| innodb_log_buffer_size(MB) | 16 | 16 | 16 |
| tmp_table_size(MB) | 16 | 16 | 16 |
| max_heap_table_size(MB) | 16 | 16 | 16 |
| innodb_log_file_size(MB) | 128 | 256 | 256 |
| innodb_log_files_in_group | 2 | 2 | 2 |
- この中では buffer_pool_size と log_file_size が自動で調整されるようだ。
外からチューニングできるか
mysqlのパラメータが外から変更できるか試してみる。
mysql> SET GLOBAL max_connections = 257;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 257 |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> SET GLOBAL join_buffer_size = 512 * 1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SESSION join_buffer_size = 512 * 1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'join_buffer_size';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| join_buffer_size | 524288 |
+------------------+--------+
1 row in set (0.01 sec)
mysql> SET GLOBAL sort_buffer_size = 1 * 1024 * 1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SESSION sort_buffer_size = 1 * 1024 * 1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'sort_buffer_size';
+------------------+---------+
| Variable_name | Value |
+------------------+---------+
| sort_buffer_size | 1048576 |
+------------------+---------+
1 row in set (0.00 sec)
mysql> SET GLOBAL read_rnd_buffer_size = 512 * 1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'read_rnd_buffer_size';
+----------------------+--------+
| Variable_name | Value |
+----------------------+--------+
| read_rnd_buffer_size | 524288 |
+----------------------+--------+
1 row in set (0.00 sec)
- 外からパラメータを変更することはできた。
- フェイルオーバー等が発生した時に元に戻ってしまうのではないかという懸念がある
安定性
- 1週間経過時点では問題なさそう。