ニフティクラウドにMySQLは載せられるのか？ パフォーマンス大検証！

こんにちは、ちなつです。
ニフティクラウドでは来月に向けてあれこれ準備中。なにが始まるのかは来月のお楽しみです。

さて今回は、パフォーマンスチューニングが好きで、特に並列化プログラミングがマイブームなライター・石田健亮氏の記事をご紹介します。

（＊本記事の最後に石田氏のプロフィールを掲載しています）

*********************************************************************

はじめまして、ドリーム・アーツの石田です。

ニフティクラウド上で「Shopらん」という多店舗運営事業者向けの業務アプリケーションをSaaSとして提供しています。流通・小売業の方、ぜひ以下の製品サイトをご参照ください。
⇒ http://www.dreamarts.co.jp/shoprun/ （別ウィンドウが開きます）

以前は、自社で購入したサーバーを使って、データセンターにラックスペースを借りて運用していましたが、現在は運用コストの削減を目的に、ニフティクラウドでのサービス提供を移行しつつあります。

今日は、我々がニフティクラウドを採用する際に最も気をつかった仮想サーバー上でのMySQLのパフォーマンスについて書いてみます。

ニフティクラウドでMySQL？

仮想化には、向いているサーバーと向いていないサーバーがあります。よく言われるのが、Web系のアプリケーションサーバーは向いていて、データベースサーバーは向いていないというもの。

まさにそのとおりで、仮想化環境でデータベースというのはなんとも筋の悪い手です。

これは、CPUやメモリといった資源は仮想化されても単に分割されているだけで物理的なリソースをほとんどそのまま利用できるのに対して、データベースの性能が依存するハードディスクは1台のディスクの中で並列に動作できませんから共有する他の仮想サーバーの分性能低下が発生しまうことが原因です。

MySQLをニフティクラウドで動かす場合、SELECTなどの参照クエリについては、メモリが8GBや16GBといったメモリリッチなサーバータイプも提供されているため、InnoDBエンジンのバッファープールのサイズを大きめにとっておけば、性能が問題になるケースはほとんど無いと思います。

問題は、INSERT, UPDATEの書き込みクエリです。書き込みはトランザクションできちんと書きこまれたことを確認しないといけないので、最終的にディスクの性能に全体の性能が左右されてしまいます。

さて、バリバリ仮想化環境であるニフティクラウドのサーバーで、オンライントランザクション用途でのMySQLは使い物になるのでしょうか？

＜ポイント０＞ ディスクの話の前に

まず少なくとも一般的なMySQLチューニングは施しておいたほうがいいです。

MySQLが遅いときは、たいていディスクI/Oがボトルネックになっていますが、あなたのアプリケーションでディスクI/OではなくCPUがボトルネックになっているときは、CPUのコア数が多いインスタンスに変更してお金で解決する前に、アプリが発行しているSQLを見直したほうが安いです。

いくらニフティクラウドのCPUが速いからといって無闇に浪費するのもお金の無駄ですし地球にもやさしくないですからね。

＜ポイント１＞ Disk100を使う

ニフティクラウドでは、作成したサーバーに最初から付いてくる30GBのローカルディスクの他に、データ領域用の追加ディスクが提供されています。

追加ディスクには、オンライン用途のためのDisk100とアーカイブ用途のためのDisk40があります。

最後にベンチマークの結果を載せていますが、MySQLで使うのならばDisk100以外の選択肢はありません。ローカルディスクは一見速そうなんですがこれまでの経験上サーバーによりかなり性能にバラつきがあるのと、Disk40はとてもオンライン用途では利用できないほど遅いからです。

Disk100の追加ディスクを作成してサーバーに追加すると、仮想サーバーからは、/dev/sd? というSCSIディスクとして見えますので、ニフティクラウドのヘルプにある通りに、適当なマウントポイントを作ってそこにマウントします。

例えば、/data にマウントした場合、そのディスクにMySQLのデータファイルを配置するには、/etc/my.cnfのdatadirの行を以下のように変更します。

[mysqld]
datadir         = /data/mysql

その後、以下のコマンドで /data/mysql にデータファイルを作成します。

# /usr/bin/mysql_install_db --user=mysql

＜ポイント２＞ MySQLの一時ファイルの置き場を変更

MySQLはソート処理がソートバッファーメモリに収まらないときなど、ディスク上に一時ファイルを作って処理することがあります。（そもそもそんな処理にならないようにアプリを作るのが鉄則ですが・・・）

この一時ファイルの置き場は、MySQLはTMPDIR環境変数を利用するので、/tmpになります。

ところが、/tmpは、ニフティクラウドのインスタンスではローカルディスクになりますから、性能が安定しないです。

ニフティクラウド上でMySQLを使う場合、この一時ファイル置き場は必ず高速なDisk100領域に作るべきです。

一時ファイルの置き場を/dataでマウントされたdisk100領域に変更するには、まず /data/tmp を作成して、mysqlの実行ユーザーで書き込み可能なようにします。

# mkdir -p /data/tmp
# chown mysql.mysql /data/tmp

そして、/etc/my.cnfファイルの[mysqld]セクションに、以下のように書いてあげればOKです。

[mysqld]
tmpdir = /data/tmp

＜ポイント３＞ ストライピングで物理ディスクを超える

ほとんどのアプリケーションは、ここまでの設定で十分な性能が得られるのではないでしょうか。ただ、まだ物理ディスクに比べるとI/O性能がイマイチです。より高い性能を求めるには複数の仮想ディスクを束ねてストライピングでパフォーマンスを稼ぐことができるはず。とのことでストライピングに挑戦してみます。

ニフティクラウドの場合、ストレージにはアイシロン社の製品を採用しているとのことですので、作成した仮想ディスクが別のノードに配置されればきっと性能が上がるはずです。

今回はCentOS上でのストライピングとしてはもっとも手軽なLVMを使って、2台のDisk100のディスクをまとめて1台のHDDとして利用出来るように構築します。

ニフティクラウドのサーバーに2台の同容量の仮想ディスクを接続します。

サーバーを起動すると、/dev/sdbと/dev/sdcとして見えるはずです。まずこの2台のディスクをLVMで扱えるようにします。直接ディスク全体を使うのでfdiskは要りません。

# pvcreate /dev/sdb /dev/sdc
  Physical volume "/dev/sdb" successfully created
  Physical volume "/dev/sdc" successfully created

次に、この2台のディスクを束ねてボリュームグループを作成します。

# vgcreate vg0 /dev/sdb /dev/sdc
  Volume group "vg0" successfully created

2台のディスクを束ねたボリュームグループから、ストライピングされた論理ディスクを切り出します。

論理ディスクを切り出すとき、lvcreateコマンドの -i オプションでストライプサイズを指定します。仮想ディスクが2台ですから -i2 となります。

# lvcreate -l 100%FREE -i2 -I64 -n data vg0
  Logical volume "data" created

最後にこの論理ボリュームにファイルシステムを作成します。データディスクの領域ですからroot用の隠し領域とかは不要なので、-m 0 を指定しています。

# mkfs.ext3 -m 0 /dev/vg0/data

しばらく待つとファイルシステムが出来上がるので、さっそくマウントしてみましょう。

# mkdir /data
# mount -t ext3 /dev/vg0/data /data

これで、ストライピングしたディスクができました。MySQLからみれば普通のディスクなので使い方は変わりありません。

ストライピングで性能が上がるかどうかは、ディスクがどのストレージ装置に収容されるか次第で運によるところがあるかもしれませんので、このあたりはご自身で運試しをしてみてください。

最後にベンチマーク結果を

最後に、bonnie++を使っていろいろなディスクのベンチマークを取ってみたので参考までに掲載しておきます。

【計測環境】

・bonnie++ 1.96 を以下のオプションで使用

# bonnie++  -q -d /data -x 5 -u root -s 512 -r 256 -m 'lvm x2'

・5回計測した結果の平均値を比較

・ファイルシステムは、ext3で統一

・計測した環境は以下の５パターン

・MySQLでの利用を想定しているので、連続したブロックの書き換え性能を見るSequential Rewriteと、ブロック間でヘッドのシーク性能を見るRandom Seekで比較！

それぞれ一番左の physical というデータが物理サーバーのものです。

どちらのグラフも棒が高いほど性能が高いことを示しています。

Disk100を2本ストライピングしたときにようやく物理ディスクと同等以上に並びました。このぐらいの性能があれば普通の物理サーバー向けに作成されたソフトウェアは特に問題なく動きますね。

ニフティクラウド上にMySQLなどデータベースサーバーを載せるときはぜひ参考にしてください。

＃しかしDisk40遅いですね。アーカイブ用途といってもこの速度だとネットワークでAmazonにアーカイブする方が速いかもしれません。＞頑張れニフティ

------------------------------------
プロフィール

   ライターネーム：石田 健亮

株式会社ドリーム・アーツで小売事業者向けSaaS「Shopらん」
を企画、開発。
メインの仕事はプログラマーだがサーバー管理や営業もこなす
ユーティリティプレイヤー。
最近好きな事はパフォーマンスチューニング。
特に並列化プログラミングがマイブーム。
キライなことはデータセンターでの作業。騒音と乾燥が弱点。
ニフティクラウドでデータセンターに行く必要が無くなったことが
本当の利点だと思っている。
------------------------------------