GMO最新ネット業界レポート【第10回】テクノロジー編（後編）

第10回テクノロジー編（後編）

前編では、「GMOとくとくショップ」で利用しているMySQLクラスターの概要や仕組みなどをレポートしました。今回は、「GMOとくとくショップ」におけるMySQLクラスターの構築や運用管理などを紹介する。

1.MySQLクラスターの構築

前編でMySQLクラスターのSQLノード、データノードについて触れましたが、もう1種類重要なノードが存在します。それが管理ノードです。管理ノードは主にクラスタリングに関するパラメータ設定を制御します。SQLノード、データノード、レプリカ数の指定や、テーブルやインデックスに割り当てるメモリサイズ、トランザクションの細かい設定などを行います。

管理ノードで大事な点は、冗長化です。管理ノードは常に稼働していないとシステムが停止するわけではありませんが、管理ノードが稼働していないとシステム操作ができなくなるため、GMOとくとくショップでは管理ノードを二重化して運用しています。これらの設定は通称「config.ini」と呼ばれる設定ファイルで記述します。通常のMySQLで設定する、いわゆる「my.cnf」とは別のファイルです。データノードのパラメータは「config.ini」で設定しますが、SQLノードは通常のMySQLサーバープロセスなので従来通り「my.cnf」でパラメータを設定します。

SQLノードの「my.cnf」では通常のMySQLとは異なるMySQLクラスター向け設定が必要で、主に以下の設定があります。

MySQLクラスターのストレージエンジンを有効化（ndbcluster）
管理ノードのIPアドレス＆ポートを指定（ndb-connectstring=”xxxxx”）
SQLノード自身のIPアドレスを指定（bind-address=”xxxxx”）
クエリキャッシュを有効化しない（query_cache_type=0）

bind-addressを設定しないとネットワーク越しにSQLノードに上手く繋がらないので、必ず設定します。ndb-connectstringについては管理ノードを二重化しているときは、セミコロン「;」区切りで記述します。

例）ndb-connectstring =”192.168.10.1:1186; 192.168.10.2:1186”

ndb-connectstringの設定は、SQLノードだけでなく、管理ノード自身やデータノードを操作するときにも必要になります（管理ノードに接続するため）。そのため、GMOとくとくショップでは管理ノードやデータノードにも、ndb-connectstring 設定のみを記述したmy.cnfを配置して、操作するときには必ずこの「my.cnf」を参照するようにしています。ただし、SQLノード以外では「mysqld」セクションでなく、「mysql_cluster」セクションで記述します。

一番注意が必要なのはクエリキャッシュを有効化しないことです。誤って有効化すると、クエリキャッシュはSQLノード単位でキャッシュされるため、接続するSQLノードによって値が違う事象が発生します。SQLノードとして扱う際はクエリキャッシュを必ず無効化します。

続いて、GMOとくとくショップにおける管理ノード、SQLノード、データノードの構成を見てみましょう。

図5 管理ノード、SQLノード、データノード構成イメージ

GMOとくとくショップではMySQLクラスターの構築に当たってサーバーを仮想化しています（図5）。

MySQLクラスターは有償の専用APIを用いない限りSQLノードを経由してデータノードに通信します。SQLノードが多いほど同時に大量の処理を捌けることになるので、SQLノードを増やすことは性能上有利になります。

しかしMySQLクラスター構成では、通常のMySQLよりデータベースに関わるサーバーリソースが大きく増えるので、SQLノードをたくさん構築することはあまり現実的ではありません。GMOとくとくショップでは、性能と冗長性を確保した上で、サーバーコストを抑えるような設計を目指しました。

例えば、トップページからの検索に検索エンジンを利用し、商品ページを開くときにデータベースを検索します（プライマリキーによる検索）。また、検索エンジンやデータベースより手前で強力なキャッシュ機構を使っているため、データベースへの検索自体もできる限り少なくしています。そのため、SQLノードに多くのサーバーリソースを割り当てなくても済みます。

データベースの冗長性に関しては、MySQLクラスターのクラスタリングに加えて、SQLノードとAPサーバーの間にロードバランサーを挟むことで、SQLノードに対しても冗長性と負荷分散を行う構成にしています。

前編でMySQLクラスターは通信が多いと述べましたが、少しでも良くするために、同じ物理サーバーに仮想サーバーのSQLノードとデータノードを1台ずつ構築する構成にしました。

このうち1台の物理サーバーには、バッチ専用SQLノードの仮想サーバーも用意して、GMOとくとくショップの商品データの更新などに利用しています。バッチ処理は特に通信ロスをなくすことが重要なので、仮想化は有効な手段ではないでしょうか。

2.MySQLクラスターのバックアップ運用

最後に、MySQLクラスターのバックアップについて説明しましょう。通常のMySQLではレプリケーション構成であれば、マスターからホットバックアップ（データベースを稼働したままバックアップ）したり、スレーブからコールドバックアップ（データベースを停止してバックアップ）する方法があります。MySQLクラスターではデータノードのデータは有償のツールを使うことなくホットバックアップすることができます。ただし、SQLノードに個別に作成したMyISAMやInnoDBは当然対象外になります。

MySQLクラスターのバックアップは管理ノード上で操作します。最初に、ndb_mgmクライアントを使って管理ノードに入ります。管理ノード上で、以下のコマンドを打つだけでバックアップできます。

ndb_mgm　> START BACKUP

バックアップ先は管理ノードの「config.ini」の中でBackupDataDirに指定したパスになります。どれか一つのデータノードにまとめてバックアップされるわけではなく、各データノードのBackupDataDirにそれぞれバックアップファイルが作成されます。バックアップファイルの中身は、前編の図４で言うところのABCDそれぞれになります。データノード1であればA、データノード2であればB、という具合です。そのため最終的には、各データノードからバックアップファイルを別のバックアップサーバーに移してまとめておく必要があります。

図6 バックアップ取得イメージ

MySQLクラスターのバックアップの特徴として、バックアップを行うとバックアップファイル一式を含んだディレクトリがBackupDataDir配下に作成されます。このバックアップディレクトリおよびバックアップファイルの名前にユニークな整数のバックアップ番号が割り当てられ、リストアするときに必要な情報になります。

管理ノードでSTART BACKUPをするとログなどから何番のバックアップ番号か分かります。GMOとくとくショップでは、管理ノードに接続してバックアップを実行、バックアップ番号をログから取得し、その番号のバックアップディレクトリを各データノードからリモートコピーするスクリプトを用意して運用しています（図6）。

リストアはこのバックアップファイルだけで行うことができます。また、データノードの構成が同じなら、バックアップを取得した環境だけでなく、別の開発環境などにもリストアできます。

取得したバックアップファイルはどのデータノードから取得したかを記録しておき（バックアップファイル名に付けられたMySQLクラスターのノードIDからも知ることができます）、取得元のデータノードの任意の場所にバックアップファイルをコピーします。リストア用のバックアップファイルはBackupDataDir配下に置かなくても構いません。

リストア用のバックアップファイルを配置した後のリストア手順として、以下に記載します。

1.SQLノード停止
2.管理ノードおよびデータノード停止（管理ノード上でSHUTDOWN）
3.管理ノード起動
4.データノード初期化（「config.ini」のDatadirで指定した場所にあるファイルを設定ファイル以外は全て削除してから、initialオプション付きでデータノード起動）
5.データノードが全て起動し終わるまで待機
6.データノード1をテーブル定義などのメタデータ含めてリストア（データノード1で以下のコマンドを実行）

7.他のデータノードをリストア（各データノードで以下のコマンドを実行。メタデータがリストアされれば⑥のリストアを全部待たずに実行でき、同時実行も可能）

8.SQLノード起動

GMOとくとくショップでは開発環境を再構築する際に、リストアを利用しています。

最後に…次世代システム研究室ではクラウドを作りたいエンジニアを募集しています。ご興味がある方はこちらからエントリーをお願いします。