みなさんこんにちは、研究所の鷲北です。第1回ではMariaDB Galera Clusterのインストールを、第2回ではLVSを使ったDBシステム冗長化を行いました。今回はいよいよクラスタ化されたDBシステムの評価をしてみたいと思います。構成は前回のシステムを引き続き使っていきますので、どのようなシステムであるか、詳細はそちらをご覧ください。

ノード数による性能の比較

DBクラスタは複数のノードに処理を分散できるため、ノードの数が増えるほど性能が上がっていくことが期待されます。しかし一方でデータの同期を取るためのオーバーヘッドがあるため、必ずしもN台で構成すればN倍になるわけではありません。MariaDB Galera Clusterの場合、ノード数に対してどれぐらい性能が変化するのかをベンチマークで比較してみましょう。 テストはさくらのクラウド・プラン1（仮想1コア、メモリ2GB）で行いました。DB用途には不向きなスペックですが、今回はノード数で比較したいのでコストを抑えるためにこれらを使用しました。DBクラスタは第2回までで説明したように構築した環境下で、1ノードから順に増やしていけるようになっています。また比較対象として単独サーバで動作する通常版のMariaDBサーバも用意し、同じベンチマークを実行しています。ノード数およびクラスタのオーバーヘッドを見たいので、単独サーバでもクラスタと同じInnoDBをエンジンとして使います。 DBサーバのコンフィギュレーションですが、凝った設定はせず、テストのためにコネクション数を増やすこととバッファサイズを大きくするだけにとどめました。

innodb_buffer_pool_size=1536M
innodb_log_file_size=256M
max_connections=1100

sysbenchによるベンチマーク

まず、sysbenchのOLTPテストを試してみます。テスト用テーブルを作成するスクリプトは以下のようになります。

sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-user=root --mysql-password=PASSWORD --mysql-host=192.168.0.20 --mysql-db=sbtest --mysql-table-engine=innodb prepare

• –oltp-table-size テスト用テーブルのサイズを指定します。大きくなるほどディスクやメモリを消費します
• –mysql-user、–mysql-password DBにアクセスするためのアカウント名とパスワードを指定します
• –mysql-host DBのIPアドレスを指定します。クラスタの場合はVIPになります

ベンチマークの実行はこのようになります。

sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-user=root --mysql-password=PASSWORD --mysql-host=192.168.0.20 --mysql-db=sbtest --mysql-table-engine=innodb --num-threads=10 --max-requests=0 --max-time=300 --oltp-test-mode=simple run

テスト用のオプションは以下の通りです。

• –num-threads 同時アクセス数を指定します。これを変化させて負荷状況を比較します
• –max-requests 最大リクエスト数。0にして無制限にしておきます
• –max-time 今回は5分間（300秒）アクセスして、トランザクション数を比較したいので300を指定しておきます
• –oltp-test-mode テストモードにはいくつかありますが、代表的なのがsimple（読み込みのみ）とcomplex（読み書き）の2種類です。今回は訳あってsimpleを指定しています

このようなテストを、対象DBとスレッド数を変えつつデータを採取してみました。

• 単独と1ノードでは、単独の方が勝っています。スレッド数に対して一定の割合でトランザクション数が悪くなっています。これはクラスタ化によるオーバーヘッドと考えられます。1ノード・クラスタでは、最後の1000スレッドのテストでメモリがわずかに不足してセッションが落ちてしまい、データが取れませんでした
• クラスタの方は、ノード数に比例してトランザクション数が増えているのが分かります。その伸び率は1ノードに対して2ノードで+50%、3ノードで+60%、4ノードで+69%でした。またsingleとの比較では2ノードで+36%、3ノードで+44%、4ノードで+52%でした

さて本来でしたらsysbenchではcomplexモードでテストしたいのですが、今回断念せざるを得ない状況になりました。sysbenchのcomplexモードでは単純なクエリをセットにして発行しますが、同じテーブルに対して激しく書き込みを行うため衝突が多発します。クラスタの場合、例えばdb1とdb2間でこのような衝突が起こると、一方は成功し他方は失敗することになります。このとき、ロールバックするとかエラーカウントしてくれればいいのですが、sysbenchは致命的エラーと称してベンチマークを中断してしまうのです。ノード数が複数あり、ノード数×スレッド数が15を超えるぐらいになるとベンチマークが取れなくなってしまいます。

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
ALERT: failed to execute mysql_stmt_execute(): Err1317 Query execution was interrupted
FATAL: database error, exiting...
Done.

マルチ・マスターのクラスタではこのような衝突は不可避であり、だからこそトランザクションが失敗したときにリトライするなど、クライアントの処理で対応するべき問題なのですが、残念ながらsysbenchはそのようになっていないようでした。

tpcc-mysqlによるベンチマーク

もうひとつ、tpcc-mysqlベンチも実施してみました。これは多数の「製品」を抱える「倉庫」をDB上に構築し、その間で行われる取引をシミュレートするベンチマークです。sysbenchに比べ衝突発生時の処理がしっかりしているようでしたので、こちらでも試してみました。倉庫の数を100とし、コネクション数（スレッド数に相当）を増やしながらノード数または単独サーバのベンチマーク・スコア（TpmCという数値になります）を比較します。

• 単独サーバの性能は200コネクションまでの間でもっともよく、DBクラスタは及ばない結果となりました。これは書き込み時のオーバーヘッドが大きいこと、衝突発生時のリトライはさらに時間がかかることが原因と思われます
• DBクラスタにおいても、有意な差とは言えないかもしれませんが、2ノード構成がもっともスコアがよいようです。3ノード、4ノードと増えるにつれて悪くなっていくようです。1ノードにおいても処理のオーバーヘッドか、数値が安定しなかったり劣化しています
• 単独サーバのグラフの推移をみると、100コネクション以上のスコアがどんどん悪くなっているのが分かります。これはサーバのCPU性能やメモリ容量限度となり、ロードアベレージの極端な増加や性能劣化が発生したためです。この傾向は1ノードのときにもみられます。しかしノード数が増えていると、負荷は分散されるため性能の上限が伸びていることが分かります。このような場合には大きな負荷をN台に分散できるクラスタの方が有利であるようです
• 2ノードの200コネクションのテスト中にセッションが切れてしまい、tpcc-mysqlが終了してしまいました。このためデータが取れていません

tpcc-mysqlにおいても衝突の問題はあります。デッドロックが発生するとこんなエラーが発生します。

1213, 40001, Deadlock found when trying to get lock; try restarting transaction

エラーについて調べてみると、tpcc-mysqlもクラスタDBのテストには向いていないようです。

互換性

WordPressのバックエンドDBとして利用する限りでは、特に問題の発生しなかったMariaDBですが、アプリケーションによってはエラーが発生することもあります。今回ベンチマークを取るに当たって、各サーバの負荷状況を記録するためにZabbixを使ったのですが、このZabbixのバックエンドにMariaDBを使おうとしたときにエラーに遭遇しました。

キーワードでググってみると Installation issues with PHP5 というページに行き当たります。PHPのmysqlライブラリと、インストールしたMariaDBのライブラリのバージョンが合致しないことが原因のようです。対策としては

• mysqlndを使う
• エラーレベルを下げて警告がでないようにする
• MariaDBクライアントのライブラリを使ってPHPをコンパイルしなおす
• MySQLクライアントライブラリを使ってMariaDBを使う

などが示されています。CentOS 6.3環境でPHPのコンパイルに挑戦してみたのですが、Zabbixを動かすだけなら1時間ぐらいの試行錯誤でなんとかなります。しかしyumに慣れ切ってしまっていると面倒この上ないので、MariaDB対応版PHPパッケージが出るまで使うのを控えようかなあという気持ちが湧いてきてしまうのが難点です。このような問題は他のアプリケーションでも発生しうるため、十分な確認が必要でしょう。

おわりに

今回の評価はちょっとベンチマークで回してみただけなので、良し悪しについて結論を出すような話ではありませんが、今後実証を続けていく場合、どのように構成するかを考えてみました。

• MariaDB Galera Clusterのインストールは非常に簡単です。RCリリース直後にリポジトリにバグがあってダウンロードできないトラブルがあったりしましたが今はfixされています。今回説明した手順で、誰でも試していただけると思います
• マルチ・マスターは便利なのですが、書き込み時のロックは比較的甘いようです。すでに述べたとおりトランザクションの失敗に備えた処理が不可欠なので、アプリケーションによっては動かなかったり修正が必要になったりします。単純に「MySQLサーバを入れ替える」という目的には、クラスタは向いていません
• クラスタDBはオーバーヘッドが大きいのも問題のひとつです。4ノード以上にしても性能上のメリットはあまりなく、一定数を超えるとオーバーヘッドが上回って性能が落ち始める可能性もあります

今回のベンチマークから思ったのは、たぶん3ノード構成ぐらいがよいのだろうなということです。性能上は2ノードが一番よいようですが、メンテナンスや障害発生時に1ノード外れると、残り1ノードでは性能がかなり落ちてしまいます。3ノード構成であれば1つを外しても2ノードで十分に性能を維持できます。

既存のDBサーバから乗り換えるようなケースでは、現時点ではまだ確かめないといけない事柄が多いと思います。負荷分散のテクニックは色々あり、レプリケーションの場合と比較することも必要で、場合によっては従来の手法の方が高速で安定しているかもしれません。ただセットアップが簡単であることは非常に魅力的です。今後も開発が進むことを大いに期待したいと思います。