MySQLをチューニング,そしてスケールアップ/スケールアウトへ

第7回 MySQLのスケールアップおよびスケールアウト構成

この記事を読むのに必要な時間:およそ 3 分

スケールアウト構成の特徴

サーバや稼働ノードの台数を増やすことで実現するスケールアウト構成では,ハードウェアスペックの上限に縛られずにシステム全体の性能向上を図ることができるのが最大のメリットです。これは大規模なWebシステムでは必須の要件となります。

スケールアップ構成と比較して考慮すべき点が多く,かつ構成は複雑になりがちです。データの持たせ方やサーバ間でのデータの同期方法によって制約が出てくることや,アプリケーションからサーバへのアクセス時にどのサーバを選択すべきかの考慮が必要になってきます。

スケールアウト構成でのデータの持たせ方

スケールアウト構成ではデータの保持のしかたによって2つの構成に分けることができます。構成内の全てのサーバがデータ全体を保持する方法と,各サーバでデータの一部分を分担して保持する方法です。

図3 全サーバが同じデータを保持する構成

図3 全サーバが同じデータを保持する構成

この場合,アプリケーションからどのサーバにアクセスしても基本的に同じデータが得られるメリットがあります。さらに同じデータが複数のサーバに管理されているため,耐障害性も高まります。全体として格納できるデータ量は各サーバで拡張できる容量に制限されてしまいます(厳密には各サーバの内,最も拡張性が低いサーバが制約要因となります⁠⁠。

データ変更を全てのサーバに対して一度に同期的に行うと,全てのサーバからの応答を待つ必要があり,性能面では非常に不利になります。そのため,データの変更は1台だけに行い,その内容を後から他のサーバにコピーして行く構成が取られることがあります。これがMySQLサーバのレプリケーション機能の挙動です。更新処理の拡張性はデータ変更を行うサーバの性能拡張性に制約されますが,参照処理はデータコピー先の複数のサーバで分散して処理が行えるため,参照処理の拡張性が期待できます。多くのWebシステムでは参照処理の比率が極めて高くなるため,MySQLサーバのレプリケーション機能が非常に適していたこともあり,数多くのWebシステムのバックエンドデータベースとしてMySQLサーバが選択されています。

下記は各サーバにデータを分散配置した構成です。

図4 各サーバでデータの一部分を分担して保持する構成

図4 各サーバでデータの一部分を分担して保持する構成

この場合,サーバを追加しただけ容量を増やすことができるため,全体としてのデータ量は事実上無制限となります。アプリケーション側でどのサーバにどのデータが格納されているかを知っておく必要があります。ただし上記の図の構成ではサーバに1台でも障害が発生するとデータが破損してしまうことになるため,可用性を求められるデータベースとしては不適切です。

そこでデータを分割しつつも,データの複製を持つことで障害への対策を行う構成もあります。

図5 データの分割と複製を同時に行う構成

図5 データの分割と複製を同時に行う構成

この場合はいずれの構成でも,全サーバの合計容量の半分が全体としての最大のデータ量となります。MySQL Clusterは上記の(1)の構成を取ることで,性能および容量の拡張性と,可用性を両立しています。またMySQL Fabricでも同様に上記の(1)の構成を取っていますが,同じデータを持っているサーバをそれぞれグループに分け,グループ内ではレプリケーション機能を使ってデータをコピーしています。MySQL Fabricでは指定した列の値の範囲またはハッシュ値でテーブルを分割して各グループに分散していきます。

スケールアウト構成でのデータベースへのアクセス方法

全てのサーバが同じデータを持つ構成の場合,全てのサーバの役割が同じであれば単に順番に(またはランダムに)アクセスすれば問題ありません。しかしMySQLサーバのレプリケーション機能のように,更新と参照を処理するサーバが分かれる場合には,何らかの方法でアクセスを制御する必要があります。アプリケーションがJavaまたはPHPの場合には,アプリケーションからの接続部品の設定でこの制御が可能です。

Javaの場合はMySQL用JDBCドライバのConnector/Jにて,接続URLの中で各サーバの役割とホスト名またはIPアドレスを指定する方法が使えます。

PHPの場合はMySQLネイティブドライバのmysqlndのプラグインとして,レプリケーション構成へのアクセス制御が可能になっています。

それ以外の開発言語の場合には,MySQL Proxyを利用するケースもあります。ただし,MySQL Proxyは将来的にAPIや仕様が変更される可能性がゼロでは無いためアルファ版の扱いとなっています。そのため,MySQL Proxyを使わずに独自のレプリケーション構成へのアクセス制御機能を作り込まれている例も少なくありません。

MySQL Clusterへのアクセスも同様です。MySQL Clusterではアプリケーションからアクセスするサーバの役割は全て同じため,単純なロードバランスと障害発生時の接続切り替えの設定のみで済みます。

MySQL Fabricでは,各サーバが参照用か変更用かと言った役割やどのデータを保持しているかを管理し,かつ各サーバの稼働状態を管理するノード(Fabric Node)が存在しています。アプリケーションは初回接続時にこのノードから各サーバの役割とデータの担当箇所についてのマッピング情報を取得し,参照や変更するレコードとマッピング情報を比較してアクセス先のサーバを見つけることができます。

構成の選択

参照処理の性能拡張性が必要な場合は,MySQLレプリケーション機能を活用することで,低コストで要件を満たせることが多くあります。

データを変更する処理の性能拡張性が必要な場合,スケールアップ構成で対応できる範囲には限度があり,また可用性を合わせて考慮するとコストが高くなって行きます。現時点のMySQL Fabricでは,データの複製は非同期レプリケーションなので可用性の面では課題は残ります。性能拡張性と可用性の両立が求められる環境ではMySQL Clusterが選択肢として検討対象になります。

MySQLサーバのレプリケーション機能とMySQL Clusterについては,次回以降でアーキテクチャや性能特性,適用領域,利用上の注意点などを解説していきます。

次回は

次回はMySQLサーバのレプリケーション機能のアーキテクチャを解説いたします。

著者プロフィール

梶山隆輔

MySQL Sales Consulting Senior Manager。

日本オラクル(株)において,MySQLのお客様環境への導入支援や製品の技術解説を担当するセールスコンサルタントチームのアジア太平洋地域リーダー。多国籍なMySQL部門にて,オーストラリア,インド,台湾などに在籍するチームメンバーを束ね,アジア太平洋地域の25以上の国や地域でのMySQL普及やビジネスの拡大をミッションとする。