レプリケーションを使わないMySQLの冗長化

こんにちは、DBMSチームの三谷です。

ヤフーでは多くのサービスでMySQLを利用しています。MySQLはヤフーを支える重要な技術の1つです。

私のチームではヤフーのさまざまなサービスのデータベースを集約して管理・運用しています。
集約することでコストの削減やノウハウの蓄積といった効果を生み出しています。

今回はこの集約環境の冗長化方法についてご紹介します。

集約環境の構成

集約環境ではマスターの冗長化にレプリケーションを利用せず、エンタープライズ向けの共有ストレージを利用したアクティブ・パッシブ型のHA構成を採用しています。
データファイルを共有ストレージに置き、どのマスターサーバーからでも同じデータに対してアクセスできるようにしています。

マスターサーバーがダウンした際にはスタンバイ機に仮想IP（VIP）を移し、ダウンしたMySQLを自動的に立ち上げるよう、Oracle Clusterwareを用いて制御しています。
Oracle ClusterwareはOracle社製のクラスタリングソフトウエアです。Oracle 製品は高価だと思っている方が多いと思いますが、Oracle Clusterwareは無償で利用することが可能です（※）。

※ 別途、Oracle Unbreakable Linuxのサポート契約は必要。詳しいライセンスについてはOracle社にご確認ください。

集約環境のため1台のマスターサーバーにはさまざまなサービスのMySQLが動いています。それぞれのMySQLに異なるポート番号を割り当てる構成です。
10個以上のMySQLを1台のサーバーに収めることが出来ており、コストの削減につながっています。

メリット・デメリット

MySQLではレプリケーションを利用した冗長化が一般的です。
ヤフーでも多くのシステムでレプリケーションを利用して冗長化を行っています。

レプリケーション用いた構成と共有ストレージを用いた構成を比べた場合の代表的なメリットとデメリットを紹介します。

メリット

■ スレーブの昇格作業が不要

レプリケーションを用いた冗長構成の場合、一般的に以下のような手順でフェイルオーバーを行います。
　 (1). 最も進んでいるスレーブを特定
　 (2). 遅れているスレーブがあった場合、最新のスレーブと同じデータにする
　 (3). (1)で選んだスレーブをマスターとして設定しなおす
　 (4). スレーブの接続元を新マスターに切り替える
今回のような集約環境では、1台のサーバーのダウンで多数のMySQLが影響を受けるため、このような煩雑なスレーブの昇格作業を手作業で行うことは不可能です。
スレーブの昇格作業が不要なHA構成は集約環境に適しています。

■ サーバー数が減らせる

マスターのみでも可用性が担保できるため、冗長化のためのスレーブを用意する必要がありません。
実際、この環境を利用する人たちの7割がマスターのみを選択しています。3割の人たちは読み取りが多いためスレーブを利用しています。
また、複数台のアクティブサーバーに対して、1台のスタンバイサーバーを割り当てることが可能なため、DRDB+MySQLといったディスクを同期する仕組みを利用したHA構成と比較してもサーバー数を減らせています。
サーバー数が減ればデータセンター費用や管理にかかるコストを削減することが出来ます。

■ データロストのリスクがない

レプリケーションは非同期で行われます。マスターに書き込んだデータがスレーブにコピーされるまでにタイムラグがあります。
マスターサーバーがダウンした時、スレーブにレプリケーションされてないデータが万が一あった場合は、そのデータはロストしてしまいます。
共有ストレージを利用した場合はストレージに必ず最後に書き込まれたデータが残っているためデータはロストしません。

データがロストしないセミ同期レプリケーションを利用する選択肢もありますが、パフォーマンスへのインパクトが大きいためあまり採用されていません。

デメリット

■ 初期導入コストが高め

一番のデメリットはエンタープライズ向けのストレージにかかるコストです。
最近は比較的安価になりましたが、サーバーと比べると高価です。
しかし、上述のようにスレーブを減らせるメリットがありますので、多くのMySQLで利用すれば、サーバーの削減で浮いたコストのほうがストレージのコストを上回ります。

■ フェイルオーバーにかかる時間が長くなる可能性がある

フェイルオーバーの際には、障害により中途半端な状態になってしまったデータファイルを一貫性を保った状態にする、「クラッシュリカバリ」と呼ばれる処理が走ります。
更新量が多いデータベースではクラッシュリカバリに時間を要する場合があります。その他、障害の検知などの時間を含めると、フェイルオーバーの際に数分のダウンタイムが発生してしまう可能性があります。
マルチマスター構成など、スタンバイ機に常にMySQLが稼働している構成と比べると、長いダウンタイムとなります。

性能

性能についてはどうでしょうか。

sysbenchを利用して、共有ストレージ（NFS）を利用した場合と通常のハードディスクを利用した場合で比較してみました。
ハードディスクは2.5インチ・10Krpm・SAS接続のものを4本利用しRAID 1+0構成にしています。
性能面では同時接続数が上がると、ハードディスクが共有ストレージを上回るようです。

注目したいのは、sync_binlog（バイナリログの同期書き込み）を有効に設定した場合の性能です。
ハードディスクでは極端に性能が低下してしまいますが、共有ストレージであればそこそこの性能が出ています。
エンタープライズ向けのストレージには不揮発メモリが搭載されおりディスクへの同期書き込みによる性能低下が最低限に抑えられるためです。

sync_binlog を無効にした場合、マスターの障害時にバイナリログがロストしてしまい、マスターとスレーブでデータに差異が発生する可能性があります。
MySQLではデータの安全性より性能を優先し、sync_binlogを無効にして運用されているケースが多いと思います。
エンタープライズ向けのストレージを使うことで、パフォーマンスを保った上で安全性も向上させることが出来ます。

このようにヤフーではコストと安全性を兼ね備えたMySQL環境を構築しています。
レプリケーションを利用した構成が注目されがちですが、そのほかの構成についても検討するきっかけになればと思います。