スケールアウト ソリューションとしてレプリケーションを使用できるため、データベース クエリ負荷を複数のデータベース サーバに分けることができす。ただし、これには一定の制約があります。

レプリケーションは、ひとつのマスタから複数のスレーブに分散できるため、読み込み頻度が高く、書き込みと更新の頻度が低い場合でのスケールアウトに最適です。ウェブサイトなどはこのカテゴリに該当し、ユーザによるウェブサイトの閲覧、情報取得または入力、製品の検索などに対応します。

書き込みが必要な場合に、ウェブ サーバがレプリケーション マスタと通信する一方で、レプリケーション スレーブが読み込み分を担当します。 このシナリオでのレプリケーション レイアウトのサンプルは 図 5.6. 「スケールアウト レプリケーションのパフォーマンス向上の概略図」 を参照してください。

図 5.6. スケールアウト レプリケーションのパフォーマンス向上の概略図

データベース アクセスを担うコードの一部を適当にモジュール化するときは、それを複製したセットアップで実行するよう変換すると、スムーズかつ簡単です。マスタにすべての書き込み分を、そしてマスタまたはスレーブに読み込み分を送るには、データベース アクセスの実装を変更します。 コードでこのレベルの抽出を確保できない場合は、クリーン アップなどのモチベーション向上にもなるので、複製システムをセットアップすることをお勧めします。 次の関数を実装してラッパー ライブラリまたはモジュールを作成することから始めます。

関数名safe_ の safe_ は、関数がすべてのエラー条件を処理することを意味します。 ここでは、読み取りのための接続、書き込みのための接続、読み取り実行、書き込み実行で統合インタフェースを持つことが重要です。

次に、ラッパー ライブラリを使用するようにクライアントコードを変換します。このプロセスは困難ですが、長期的に見ると有意義です。 ここで説明したアプローチを使用するアプリケーションはすべて、マスタ・スレーブ構成の利点を活用できます。 このコードは保守が非常に簡単で、トラブルシューティング オプションの追加にも手間がかかりません。 つまり、1 つか 2 つの関数を修正するだけで、各クエリに所要時間をログしたり、どのクエリがエラーの原因になったかを特定できます。

コード作成の経験が豊かであれば、MySQL の標準ディストリビューションに含まれている replace ユーティリティを使用して変換タスクを自動化することも可能です。または独自の変換スクリプトを作成することもできますが、その際にはプログラミング コードが一貫して認識できるスタイルが理想的です。そうでない場合は、書き換えることをお勧めしますが、少なくとも 一貫したスタイルに整えてください。