第7回はMySQLのスケールアップ構成およびスケールアウト構成のポイントを解説します。

システム拡張の方向性

システム全体の性能向上のためには、個別の要素技術のチューニングだけでは無く、全体構成の最適化が必要です。データベースに限らず以下の2つの方向性を検討します。

スケールアップによる性能改善の度合いを垂直拡張性（Vertical Scalability⁠）⁠、スケールアウトの場合は水平拡張性（Horizontal Scalability）と呼ぶこともあります。ソフトウェア製品によってはいずれかの方向性を重視した実装になっていることもあります。

スケールアップ構成の特徴

CPUやメモリ、ストレージ、ネットワークなどのハードウェアを増強することで実現するスケールアップ構成では、管理対象とすべきノードが増えないことが大きなメリットです。また、多くの場合はソフトウェアの設定パラメタを増強したスペックに合わせて調整することで、より高い性能が得られることもメリットとなります。MySQLサーバのバージョンが新しくなるにつれて、CPU数が増加した場合の性能拡張性（スケーラビリティ）も向上しています。下記は公開されているCPU数を増加させた場合のMySQL 5.6と5.5の参照更新処理の性能比較です。

下記はMySQLの開発エンジニアが公開している開発中のMySQL 5.7と5.6の参照更新処理の性能比較です。上記とはテストを行っているハードウェアが異なるため、絶対値の比較では無く、あくまでもバージョン間での相対的な比較用となります。

スケールアップ構成は入手可能なハードウェアのスペックが上限となります。とは言え、コストを掛けることさえできれば最新のハードウェアであれば非常に高いスペックのサーバを手に入れることは可能です。

データベースはディスクへのアクセスを頻繁に行うことが多いため、ストレージの性能がボトルネックになっている場合にはストレージをハードディスクからフラッシュベースのストレージに換えることも有用になります。オラクル製フラッシュストレージのSun Flash Accelerator F80 PCIe Cardを利用するためのLinuxやMySQLのチューニング例は下記の資料を参照してください。

• URL：http://www.oracle.com/us/technologies/linux/linux-and-mysql-optimizations-wp-2332321.pdf

ただし将来的に求められるハードウェアスペックに合わせたサーバを事前に用意することは、初期投資が大きくなることを意味します。高いスペックのサーバを用意したにも関わらず、サービスが想定よりも利用されない場合には無駄な投資となってしまいます。

システムの負荷の上昇や利用者の増加に合わせてより高スペックのハードウェアを置き換えることも不可能ではありませんが、ハードウェアの調達や設置にはある程度の時間がかかります。クラウドサービスであれば調達や設置の時間は大幅に削減できるかとは思いますが、いずれにせよデータベースやアプリケーションの移設と新しい環境でのテストの時間を考慮しなければなりません。特にコンシューマ向けのWebサービスやソーシャルゲームなどは、サービス開始時点ではどれだけの利用者がいつ増加するか見通しにくいため、迅速に移設するための仕組み作りが求められます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 参考：Configuring Master/Slave Replication with Connector/J

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

• 参考：Mysqlnd replication and load balancing plugin

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

• 参考：MySQL Proxy

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

• 参考：Configuring Load Balancing with Connector/J

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

構成の選択

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

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

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

次回は

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