高可用性とデータ・シャーディングを実現できるMySQL Fabricとは?

MySQL Fabricとは?
MySQL Fabricは、MySQLサーバー群を管理する統合型のフレームワークです。MySQL Fabricを使うことにより、高可用性(HA)とデータ・シャーディングによる拡張性を実現できます。

図1: MySQL Fabric
MySQLのレプリケーション機能を使って高可用性構成を実現している場合、マスターのサーバーに障害が発生した時に、スレーブのサーバーを新しいマスターに昇格させるフェイルオーバー処理が必要になります。このフェイルオーバー処理を自動化するために、MySQL 5.6ではMySQL Utilities(※)にmysqlfailoverという機能が追加されました。
※MySQL Utilitiesは、Pythonでかかれた便利なスクリプト集です。詳細は以下の記事も参考にして下さい。
[参考]Pythonで作られた便利なコマンドラインツール MySQL Utilities
mysqlfailoverを使うことでMySQLサーバーのフェイルオーバー処理を自動化できますが、その際にアプリケーションからの接続先を新しいマスターへと切り替える必要があります。また、スレーブのサーバーを複数台で構成し、参照処理の負荷分散を実現していた場合も、フェイルオーバーによってスレーブサーバーのうち1台がマスターに変更されるため、アプリケーションからの接続先を切り替える(1台のスレーブサーバーを負荷分散の対象から外す)必要があります。
このような課題を解決するために登場したのが、今回ご紹介するMySQL Fabricです。MySQL Fabricを使うと、マスターのサーバーに障害が発生した際のフェイルオーバー処理を自動化できるだけでなく、フェイルオーバーによってMySQLサーバーの構成が変更された場合でも、アプリケーションからMySQLサーバーへの接続先を切り替える必要がありません。アプリケーションを変更する必要無く、そのまま使い続けられます。
またMySQL Fabricでは、参照処理/更新処理の拡張性も提供しています。システムの規模を拡張する際に「処理性能を向上させたい」という要望が出てくると思いますが、MySQL Fabricを使うとアプリケーションを変更することなく、MySQLサーバーの台数を増やすだけで負荷分散により処理性能を向上できます。参照処理の性能向上はスレーブサーバーの台数を増やすことで、また更新処理の性能向上はデータ・シャーディング(分割)によって実現できます。そしてスレーブサーバーの台数を増やしたり、データ・シャーディングを行ったりした場合でも、アプリケーションは変更せずにそのまま使い続けられます。
この機能は昨年labs.mysql.com(※)で発表されましたが、反響が大きかったため開発が活発に進み、2014年5月27日に製品版(GA)となりました。
※labs.mysql.comは、テスト用に、より先進的、実験的な機能を含んだMySQLを提供しています。テスト目的であるため、labs.mysql.comの製品を本番環境では使用しないでください。
MySQL Fabricは、MySQL Utilitiesの一部として提供されています。そして、内部でMySQL 5.6で追加されたGTIDモードによるレプリケーションやレプリケーションユーティリティ(MySQL Utilitiesのレプリケーション関連の機能)を活用しています。そのため、管理するMySQLサーバー群はMySQL 5.6以降(※)が対象となります。GTIDとレプリケーションユーティリティの概要については、過去の連載でも紹介していますので、それぞれの概要についてはこちらの記事もご参照下さい。
※記事執筆時点(2014年9月時点)でのサポート対象はMySQL 5.6のみですが、今後のバージョンについても製品版(GA)リリース後に、サポートされる予定です。
また、MySQL Fabricを使用するためにはMySQL Fabricに対応したコネクタを使用する必要があります。2014年9月時点で対応しているコネクタはPHP、Python、Javaですが、今後他の言語のコネクタも追加予定です。また、O/RマッパーのHibernateとDoctrineもサポートされています。
MySQL Fabricの特徴/利点
前述の通りMySQL Fabricを使うと、自動フェイルオーバーによる高可用性と、参照/更新処理に対する負荷分散による拡張性を実現できます。そしてこれらをアプリケーションから意識することなく実現できる、という大きな利点があります。MySQL Fabricを使うと、MySQLサーバーの構成が変わってもアプリケーションからの接続先を変更する必要がありません。また後述しますが、アプリケーションからMySQLサーバーへは直接接続できるため、MySQL Fabricを使うことによるオーバーヘッド(性能低下)もありません。
更にMySQL Fabricの機能は、MySQLのレプリケーション機能を基盤として実装していますので、今まで培ってきたMySQLのスキルもそのまま活用できます。MySQLのレプリケーション構成に慣れている方は、すぐにMySQL Fabricを活用できるでしょう。
MySQL Fabricの特徴と利点は、こちらのページでもご紹介しています。
MySQL Fabricのアーキテクチャ
概要
MySQL Fabricは、MySQLサーバー群の構成情報を管理しているMySQL Fabricサーバーと、MySQL Fabricに対応したコネクタから構成されます。MySQL Fabricサーバーは、Pythonで動作する小さなサーバーですが、構成情報を格納するためのリポジトリとしてMySQLデータベースを利用しています。このリポジトリは、Backing Storeと呼ばれています。
マニュアルでも解説されていますが、Backing Storeのテーブル構成は通常のMySQLデータベースであるため、mysqldump等の手段でバックアップできます。Backing Storeに格納されている構成情報は、MySQL Fabricにとって非常に重要であるため、バックアップ取得が推奨されています。
MySQL Fabricを使用する場合、アプリケーションからの接続先にはMySQL Fabricサーバーを指定します。またMySQL Fabricに対応したコネクタは、MySQLサーバー群の構成情報を受け取り、コネクタ自身にキャッシュします。そのためアプリケーションからMySQLサーバーへ接続する際には、直接MySQLサーバーへ接続できます。MySQL Fabricサーバーを経由する必要が無いため、アプリケーションに対するオーバーヘッドはありません。
高可用性を実現する仕組み
MySQL Fabricは、MySQLサーバー群を「高可用性グループ」という単位で管理します。高可用性グループに2台以上のMySQLサーバーを所属させることで、MySQLのレプリケーション機能を使ったマスター/スレーブ構成の高可用性が実現されます。高可用性グループ内のマスターサーバーに障害が発生すると、MySQL Fabricは自動的にフェイルオーバーを実行し、スレーブサーバーの中から1台を新しいマスターに昇格させます。そして、MySQL Fabricサーバーで管理している構成情報を変更し、コネクタに構成情報が変わったことを通知します。構成情報が変わったことを認識したコネクタは、次回接続時に適切なMySQLサーバーに接続しなおして処理を実行できます。

図2: MySQL Fabricの構成
障害が発生するとフェイルオーバーが実行され、MySQLサーバー群のマスター/スレーブの構成が変更されますが、その際にアプリケーションからの接続先を変更したり、VIP(仮想IP)を切り替えて接続先を制御したりする必要が無いというのがポイントです。ただ障害が発生したサーバーで実行中であった処理はエラーになるため、再実行の仕組みはアプリケーション側に実装しておく必要があります。接続しなおして処理を再実行することで、適切なMySQLサーバーに接続して処理を再開できます。
更新/参照での負荷分散、参照処理の負荷分散を実現する仕組み
「高可用性グループ」は通常1台のマスターサーバーと1台以上のスレーブサーバーで構成されますが、更新処理をマスターのサーバーで実行し、参照処理をスレーブのサーバーで実行することで更新処理/参照処理の負荷分散を実現できます。また、複数台のスレーブサーバーを所属させることで、参照処理を複数のサーバーで処理し、参照処理の負荷分散も実現できます。スレーブとサーバー間のロードバランシングは、自動的に行われます。
更新処理を実行する際はアプリケーションからの接続時に「READWRITEモード」を、参照処理の実行時にはアプリケーションからの接続時に「READONLY」モードをそれぞれ指定することで、自動的に適切なMySQLサーバーに接続して処理を実行できます。
以下の図中では、Pythonで更新処理を実行する例を紹介しています。事前にMySQL Fabric で複数台のMySQLサーバーを使って高可用性グループを定義している前提です。接続先のサーバーに MySQL Fabricサーバーを指定し、プロパティで「READWRITE」モードを指定するだけで、どのサー バーがマスターなのかを意識することなく、 INSERT文を実行できます。
※MySQL Fabricサーバーが"localhost:32274"で動作している場合の例です。また、MySQL Fabricで高可用性グループを定義する具体的な方法は、今後の連載で紹介予定です。

図3: 更新処理の例
更新処理の負荷分散を実現する仕組み(データ・シャーディング)
高可用性グループを複数作ることで、データ・シャーディング(分割)による更新処理の負荷分散を実現できます。データ分割の方法は、RANGE(範囲)、HASHの2種類があります。またシャーディングのキーに指定する列は、現時点では数値型のみの対応となります。
シャーディング手法や、RANGEでのシャーディング時のマッピング定義(どのシャードにどの範囲のデータを格納するのかの指定)はMySQL Fabricによって行いますが、アプリケーションから意識する必要があるのは、「シャーディングされているテーブルが、どの列をキーにしてシャーディングされているか」のみです。どのような手法や範囲でデータがシャーディングされているのかは、意識する必要がありません。そのため、データ量の増加や同時実行処理数の増加等によりシャードを追加し、シャーディングを再構成した場合でも、その構成変更はアプリケーションから透過的になります(アプリケーションは変更する必要がありません)。
以下の図中では、testデータベースのempテーブルがemp_no列でシャーディングされている場合のINSERT処理の例を紹介しています(先ほどと同様に、Pythonによる処理の例です。シャーディングの定義は既に実施している前提です)。プロパティでシャーディングキーを指定するだけで、INSERT文はシャーディングしていない場合と同様に実行できます。
※MySQL Fabricでシャーディングを定義する具体的な方法は、今後の連載で紹介予定です。

図4: シャーディングの例
MySQL Fabricのダウンロード、製品マニュアル
本記事を読んでMySQL Fabricに興味を持った方は、是非試していただければと思います!
製品のダウンロード先、マニュアルなどは以下をご参照下さい。
- MySQL Fabricのダウンロード
MySQL Utilitiesに含まれているので、MySQL Utilitiesをダウンロード下さい。 - 製品マニュアル
MySQL Utilities 1.4 のマニュアルの「Chapter 8. MySQL Fabric」部分がMySQL Fabricのマニュアルです。
また、MySQL FabricのFAQはこちらをご参照下さい。「MySQL Fabricサーバーに障害が起きたらどうなるの?」といった、よくある質問に対する回答がまとめられています。
MySQL Fabricの今後
現時点で対応しているコネクタはPHP、Python、Javaのみですが、今後も新しいコネクタの追加を検討しています。他にも、複数シャードにまたがるトランザクションや、複数シャードにまたがるUNION処理など、様々な機能拡張を検討しています。
MySQL Fabricの今後の機能拡張について要望等があれば、MySQL Bugsでバグ報告や機能追加要望を受け付けています。皆さんからのフィードバックがあれば、開発もより活発に進みますので、是非フィードバックをお寄せ下さい!!

図5: bugs.mysql.com
※MySQL Fabricは無償版(コミュニティエディション)でもご利用いただけますが、商用版の場合はEnterprise Editionをご契約いただく必要があります(MySQL Utilities、MySQL Fabric共に、こちらのページでご案内している通りEnterprise Editionのみでサポート対象となっています)。
※本稿において示されている見解は、私自身の見解であって、私の所属するオラクルの見解を必ずしも反映したものではありません。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- オラクル、可用性と拡張性の高いMySQL構成の管理を簡素化する「MySQL Fabric」を発表
- MySQL 5.6での機能強化点(その3)- 人気のレプリケーションが更に機能強化
- オラクル、「MySQL 5.7 Development Milestone Release(DMR)」をリリース
- DBドキュメント出力とMEBのためのGUI、次期版6.1の新機能を紹介
- MongoDB Tokyo 2013で語られた、NoSQLを上手に使うためのポイントとは
- オラクル、データベース性能を向上させた最新の「MySQL 5.7 Development Milestone Release」を発表
- Pythonで作られた便利なコマンドラインツール MySQL Utilities
- MySQL5.5- 性能改善と可用性向上
- 非同期レプリケーション!
- PostgreSQL9.0の安定性と高い可用性を実証 アシストによるPostgreSQL検証セミナーレポート