DBサーバのスケールアウト
前述したように、Webサーバ、アプリケーションサーバは、比較的容易にスケールアウトすることができます。ただ図2をみると分かるとおり、DBサーバが一極集中型の構成になりやすく、負荷が収集しシステムのボトルネックとなりやすい特徴があります。次にDBサーバのスケールアウト手法について考えてみましょう。
DBサーバのクラスタリング
クラスタリングは、データベースを複数並列に並べ、ミドルウェアやデータベース製品の機能により、同一のデータが複数のデータベースに一貫性を保ち同時に保存されることを保証します。どのデータベースにアクセスしても同一のデータが存在していますので、データベースアクセスによる負荷を分散させることができます。
図3にDBサーバのクラスタリングについて示しました。
クラスタリングで問題となるのは、その並列台数の限界です。複数のDBサーバに同一のデータが同時に存在することを保証するには限界がありますし、サーバの台数を増やすほどその同期のための処理コストは高まります。従ってスケールのしやすさで言うと、今回述べるDBサーバのスケール手法の中では、最もスケールしない手法と言えるでしょう。
データレプリケーション
データベースのレプリケーション機能を使用することで、マスタとなるデータベース（マスタDB）のデータを、スレーブのデータベースに順にレプリケーション（複製）していく手法です。アプリケーションからのアクセスに対し、更新系の処理はマスタDB、参照系の処理はスレーブDB、と担当と分けることで負荷を分散し、システム全体の性能を向上します。
図4にDBサーバのデータレプリケーションについて示しました。
問題点としては、更新処理は必ずマスタデータに対して行われるため、更新が多いシステムの場合は、マスタDBへの負荷がボトルネックとなりシステム全体の性能が劣化することです。また、スレーブDBへのデータレプリケーションが遅延すると、マスタDBとスレーブのDBでデータ内容にずれが出ることがあります。
DB分割（第1段階：データ種別によるDB分割）
比較的データの更新の頻度が少ないマスタデータ系、頻繁にデータ登録、更新処理が実行されるトランザクションデータ系などというようにデータ種別ごとにDBを分割する手法です。図6にデータ種別によるDB分割について示しました。
データ特性ごとにデータベースを分けることで、参照処理や更新処理などの処理ごとの影響をそれぞれ受けることなく、負荷の配分を最適化することができます。問題点としては、マスタデータとトランザクションデータをSQLのJOINを用いて同時に取得することができなくなるため、取得したデータを組み合わせるロジックを実装する必要が出てくることです。
DBを分割（第2段階：データレンジによるDB分割）
データ種別ごとにDBを分割して、負荷分散をはかったとしても、アクセス数やデータ量の増加に伴い、DBの負荷は次第に上がっていきます。その段階で検討されるのが、データレンジ（データ範囲）によるDB分割です。図6にデータレンジによるDB分割について示しました。
これは、例えば、IDのレンジごとに保存するDBを選択し、データを格納する手法です。この手法では、DBは理論上無制限に並列に並べることができますので、今まで述べた手法の中で、最もスケールする手法であると言えるでしょう。問題点は、アプリケーション側では、同じ種別データでも、データレンジによってDBを選択するロジックを実装する必要があり、さらにロジックが複雑になることです。
