
Web業界のシステムではよく「LAMP」という言葉を耳にします。Linux、Apache、MySQL、PHPの頭文字を繋げたものです。この「LAMP」の「M」に当たるMySQLというデータベースは現在もっとも普及しているデータベースの一つです。
MySQLはオープンソースで使い勝手が良いものですが、Oracleと比べて決定的に異なる点があります。それはデータベースのクラスタリングです。OracleにはRAC(Real Application Clusters)と呼ばれる製品があり、複数台のサーバー(ノード)で一つのデータベースを構成することができます(図1)。どれか一つのノードが倒れても、他のノードが生きている限り、操作の制限なくデータを更新・参照することができることが特徴です。
これに対し、通常のMySQLにはクラスタリング機能はなく、全く別の仕組みのレプリケーション機能を持っています。レプリケーションは、複数台のサーバーをマスターとスレーブに分け、マスターへのデータ更新を非同期でスレーブに伝えるという仕組みです(図2)。スレーブの台数を増やして参照処理を散らすことで負荷分散を行います。
しかし、あるデータ(データベースもしくはテーブル)に対してマスターは必ず1台です。そのためマスターが倒れてしまうと、該当箇所の更新処理が完全に停止します。
また、マスターとスレーブは非同期で、データの同一性を保証する仕組みを取っていません。そのためマスター上のディスクが壊れてしまうと、スレーブ上のディスクから故障直前の状態にマスターを完全に復旧させることが保証できません。
データの同一性に対する一つの解決策として、MySQLにDRBD(*1)を組み合わせてマスター上のファイルを別のサーバーに複製する方法が広く知られています。ただし、DRBDを利用してもMySQLのマスターが倒れてしまえば、更新処理が止まってしまうのは変わりません。
こうした更新処理におけるレプリケーションの弱点を完全に解決するためには、レプリケーションではなくクラスタリングを実装するということになります。このクラスタリングをMySQLに採り入れたものがMySQLクラスターです。
MySQLクラスターはクラスタリングを実装したデータベースをMySQLに組み込んだものです。元々別の製品だったものを、MyISAMやInnoDBなどと同じストレージエンジン形式で組み込んでいます。
そのため、通常のMySQLサーバープロセスとは別に、クラスタリングされたデータベースのプロセスを別に持ちます。MySQLクラスターでは、MySQLサーバープロセスがあるサーバーを「SQLノード」として利用し、クラスタリングされたデータベースのあるサーバーを「データノード」と呼びます(図3)。
データノードは本来メモリベースのインメモリデータベースです。最近のバージョンになって、ディスクベースのデータノードも選択できるようになりました。しかし、ディスクベースといえどもデータ量に合ったメモリを割り当てないと性能が出ないため、サービスにおけるデータ使用量なども考慮して、GMOとくとくショップではメモリベースを採用しています。
MySQLクラスターをクラスタリングされたデータベースとして扱うには、有償の専用APIを用いない限り、SQLノードを通してデータノードにアクセスします。つまり、SQLノードからデータノードへの通信が必ず発生します。また、データノード間もたくさん通信を行います。この通信の多さが、MySQLクラスターを扱う上で非常に重要なファクターとなります。
データがどのデータノードに振り分けられるかは、原則1レコードずつプライマリキーのハッシュ値で行われます。そのため、ヒット件数が多く、取得するデータ量が大きい範囲検索などを行うと、データノード間、データノードとSQLノード間の通信が多く発生し、性能が落ちることは容易に想像がつきます。MySQLクラスターではとりわけプライマリキーによる検索をうまく使うことが大切になります。GMOとくとくショップではそのことを意識してシステムを構築しています。
SQLノードは、通常のMySQLサーバープロセスであることには変わりないので、MyISAMやInnoDBのテーブルも利用することができますが、テーブルを作成したSQLノードでしか見ることができません。こうしたこともMySQLクラスターならではの特徴ではないでしょうか。
後ほど説明しますが、特定のSQLノードでしか見れないことを利用して、GMOとくとくショップはバッチ処理専用のSQLノードを立てて運用しています。
MySQLクラスターは、OracleRACとは異なりシェアード・ナッシング(共有ディスクを使わない)型のクラスタリングのため、一つのデータが自分の複製を1個以上別のノードに持つ必要があります。この複製の数をレプリカ数と呼び、データノード数とレプリカ数で構成が決まります。
一般的な構成はデータノード4台でレプリカ数2とする構成で、GMOとくとくショップでもこの方法を採用しています。
データノード4台、レプリカ数2のとき(図4)、全データはA、B、C、Dに4分割され2つのグループに分かれて(ABとCD)、グループ内で相互に複製を持合います。データノード1が倒れても、他のデータノードを見ればABCDが揃うのでシステム停止しません。
ただし、同じノードグループの2台が同時に倒れてしまうとABCDが揃わなくなるのでシステム停止します。
GMOとくとくショップでは、データノード2台、レプリカ数2の構成も検討しましたが、その場合は一つのノードグループのみとなり、1台当たりのデータ量が総データ量と等しくなります。1台のサーバーに搭載されたメモリで全データ量を賄わなくてはならず、GMOとくとくショップのデータ量とシステムリソースを考慮するとあまり現実的でなかったため、データノード4台、レプリカ数2の構成を採用しています。
後編(3/17公開)では、GMOとくとくショップにおけるMySQLクラスターの構築や運用管理などについて説明します。
*1:DRBD (Distributed Replicated Block Device) =Linuxプラットフォームの分散ストレージシステム
- 【第2回】「GMOとくとくショップ」オープンにあたって - GMOとくとくショップと最新テクノロジー -
- 【第7回】「GMOとくとくショップ」に組み込まれたテクノロジー(前編)- Hadoopをどのように利用しているか? -
- 【第7回】「GMOとくとくショップ」に組み込まれたテクノロジー(後編)- Hadoopを使った構築方法やチューニングポイント、運用管理 -
- 【第10回】「GMOとくとくショップ」ではどのようにMySQLクラスターを利用しているか?(後編)- MySQLクラスター構築方法と運用管理 -
- 【第13回】「GMOとくとくショップ」で利用しているEucalyptusとは?(前編)- Eucalyptusの仕組みについて -
- 【第13回】「GMOとくとくショップ」で利用しているEucalyptusとは?(後編)- Eucalyptusの構築や運用管理について -
- 【第16回】「GMOとくとくショップ」のHadoop集計-Hiveの利用方法-(前編)- Hiveをどのように利用しているか? -
- 【第16回】「GMOとくとくショップ」のHadoop集計-Hiveの利用方法-(後編)- 実際に使用しているHiveQLについて -
- 【第19回】「GMOとくとくショップ」で利用しているアプリケーションフレームワークについて- Webアプリケーションフレームワークとは? -
*本文中に記載されている会社名および商品名・サービス名は、各社の商標 または登録商標です。




























