リードレプリカ・シャーディング・パーティショニングの違いとは？クラウドDBのスケーリング手法を整理する実践ガイド

オンプレのDBサーバーで「とにかく上位機種に換装すればいい」という対処を繰り返してきたエンジニアが、クラウド移行の設計レビューで「リードレプリカを活用してください」「シャーディング設計が必要です」「パーティショニングの粒度が荒すぎる」と一度に指摘を受けてパニックになる——そんな場面は珍しくない。

3つはいずれも「DBを負荷に耐えさせるための手法」という共通点があるが、目的・対象・コストが根本から異なる。「なんとなく似たもの」として曖昧に理解したまま設計すると、後から大規模なリアーキテクチャを迫られる。本記事では、AWSとAzureの具体的なサービスに対応させながら、3つの手法の違いと現場での選び方を整理する。

なぜDBスケーリングが問題になるのか？

オンプレ環境では、DBのスケーリングはほぼ「スケールアップ（サーバーの増強）」一択だった。CPU・メモリ・ディスクのスペックを上げ、共有ストレージに接続する Oracle RAC のようなHA構成が高価ながらも標準的な選択肢だった。

クラウドでも同じアプローチは取れる。しかし、クラウドには「読み取りを分散させる」「データを水平に分割する」「大規模テーブルの検索範囲を絞る」という選択肢が用意されており、用途に応じて使い分けることで、コストと性能の両立が可能になる。その選択肢の名前が、リードレプリカ・シャーディング・パーティショニングの3つだ。

リードレプリカとは？

リードレプリカは、マスター（プライマリ）DBのデータを非同期または同期でコピーし、読み取り専用のスタンバイインスタンスを作る仕組みだ。書き込みはプライマリが受け持ち、レポート・集計・参照系のクエリをレプリカに流すことで、プライマリの負荷を下げる。

AWSの実装（Amazon RDS・Aurora）

Amazon RDS では、MySQL・PostgreSQL・MariaDB エンジンでリードレプリカを作成できる。東京リージョン（ap-northeast-1）内だけでなく、大阪リージョン（ap-northeast-3）など別リージョンにクロスリージョンレプリカを作ることも可能で、DRの用途にも使われる。Amazon Aurora は最大15台のリードレプリカをクラスター内に持てる設計になっており、オートスケーリングと組み合わせることでトラフィック増減に追従できる。

料金は、レプリカ1台につきインスタンス費用がほぼそのままかかる点に注意が必要だ（例: db.r7g.large を東京リージョンで動かす場合、2026年7月時点の参考値で1時間あたり約$0.32。レプリカが3台あれば3倍になる）。

Azureの実装（Azure SQL Database・Azure Database for PostgreSQL）

Azure SQL Database では「読み取りスケールアウト」機能として、Business Critical ティアや General Purpose + ゾーン冗長構成でリードレプリカが自動的に作成される。接続文字列に ApplicationIntent=ReadOnly を付けるだけで参照トラフィックをレプリカに振り分けられる。Azure Database for PostgreSQL（フレキシブルサーバー）では最大5台のリードレプリカを作れる。

リードレプリカが効く場面・効かない場面

・効く場面: 参照クエリが書き込みの数倍以上ある（ECサイトの商品一覧・管理画面レポートなど）
・効かない場面: 書き込みがボトルネックになっている場合（レプリカを増やしても根本解決しない）
・落とし穴: 非同期レプリケーションの場合、レプリカの読み取りがプライマリより数ミリ秒～数秒遅れる（レプリケーションラグ）。金額確定や在庫確認など強整合性が必要な処理はプライマリに向ける設計が必要だ。

CAP定理・強整合性・結果整合性の使い分けは別記事で詳しく解説しているので参照してほしい。

シャーディングとは？

シャーディングは、テーブルのデータを「シャードキー」と呼ばれる値を基準に複数のDBサーバー（シャード）に水平分割して分散配置する手法だ。1つのインスタンスに収まらない規模のデータや、単一DBサーバーのスループット限界を超える書き込みを捌くために使われる。

例えばユーザーIDの末尾1桁を基準にシャードを4つ作ると、0・1・2が入るシャード0、3・4・5が入るシャード1——といった形でデータが分散する。書き込みも読み取りも特定のシャードに集中せず、水平スケールが可能になる。

AWSの実装（Amazon DynamoDB）

Amazon DynamoDB はシャーディングをマネージドサービスとして提供している代表例だ。テーブル作成時に指定する「パーティションキー」がシャードキーに相当し、AWS がキー値のハッシュを元に内部のパーティション（シャード）にデータを分散する。ユーザーはシャードの存在を意識せず、テーブルを1つのように扱えるが、パーティションキーの設計を誤ると「ホットパーティション」問題（特定キーに負荷集中）が起きる。

詳しいパーティションキー設計はAmazon DynamoDB入門を参照してほしい。

セルフマネージドのシャーディング

RDS（MySQL や PostgreSQL）では、シャーディングはアプリケーション側か Vitess・Citus などのミドルウェアで実装するのが一般的だ。AWS が自動でシャードを管理してくれるわけではないため、シャードの追加・データ再分散（リバランシング）が発生する運用コストを見込んでおく必要がある。

・効く場面: 書き込みが大量発生する・単一インスタンスのストレージ容量を超える規模のデータ
・効かない場面: シャードをまたぐ JOIN や集計クエリが多い（複数シャードのデータを集めるコストが発生する）
・落とし穴: シャードキーは後から変えられない設計になることが多い。アクセスパターンが変わるとシャードキーの選択が失敗だったと気づいても、再設計のコストが膨大になる。

パーティショニングとは？

パーティショニングは、1つのテーブルを「パーティション」と呼ばれる物理的または論理的な部分に分割し、クエリ実行時にスキャン範囲を絞り込む（パーティションプルーニング）手法だ。シャーディングと混同されやすいが、決定的に違うのは「単一DBインスタンス内で完結する」点だ。複数のサーバーにデータを分散させるシャーディングとは目的が異なり、パーティショニングの主目的はクエリ性能の改善とストレージ管理の効率化だ。

パーティショニングの代表的な種類

・レンジパーティション: 日付や連番の範囲で分割。例：注文テーブルを月ごとに分割し、当月分のみスキャン
・リストパーティション: 特定の値リストで分割。例：国コード別にパーティションを切る
・ハッシュパーティション: キーのハッシュ値で均等に分割。負荷を均等化する目的で使われる

AWSの実装（Amazon Redshift・RDS）

Amazon Redshift では、テーブルの「ソートキー」と「ディストリビューションキー」の設計がパーティショニングに近い役割を担う。ゾーンマップ（各ブロックに格納された値の最小・最大値を記録した索引）により、不要なブロックのスキャンを省ける。Redshift のコスト最適化でも、このスキャン削減が料金削減の根幹になっている。

RDS（PostgreSQL・MySQL）では宣言的パーティショニングをサポートしており、日次・月次バッチで古いパーティションをアーカイブ・削除する運用が組みやすい。

Google Cloud / Azure での利用

BigQuery では DATE や INTEGER のカラムパーティションとクラスタリングを組み合わせることで、クエリコストを最大80%削減できる。Azure Synapse Analytics（旧 Azure SQL Data Warehouse）でも同様にテーブルパーティションが重要な設計要素だ。

・効く場面: 時系列データ・ログデータなど「範囲でよく絞り込む」クエリが多いテーブル
・効かない場面: 全件スキャンを前提とした小さなテーブル（パーティション管理のオーバーヘッドが無駄になる）
・落とし穴: パーティションキーに含まれない列での絞り込みでは、全パーティションのフルスキャンが走る（パーティション枝刈りが発生しない）

3手法の比較表

観点	リードレプリカ	シャーディング	パーティショニング
主目的	読み取り負荷の分散	書き込み・ストレージの水平スケール	クエリ性能改善・管理効率化
データの配置	複数インスタンスにコピー（全量）	複数インスタンスに分散（部分）	単一インスタンス内で分割
書き込みスケール	しない（プライマリ1台が受け持つ）	する（各シャードが書き込みを担当）	しない
JOINの容易さ	容易（全データが揃っている）	困難（シャードをまたぐ場合）	容易（単一インスタンス内）
導入コスト	低（AWSマネージド）	高（アプリ側の設計変更が必要）	中（DDLの変更が必要）
一般的な用途	参照重視のWebアプリ・レポート	SNS・IoT・大規模トランザクション	DWH・ログ・時系列分析

AWSとAzureのサービス対応表

手法	AWSサービス	Azureサービス	備考
リードレプリカ	Amazon RDS / Aurora リードレプリカ	Azure SQL Database（ReadOnly接続）/ Azure DB for PostgreSQL	RDSは最大5台、Auroraは最大15台
シャーディング（マネージド）	Amazon DynamoDB（パーティションキー設計）	Azure Cosmos DB（パーティションキー設計）	内部シャーディングを自動管理
シャーディング（セルフ）	RDS + Vitess / アプリ側ルーティング	Azure DB for PostgreSQL + Citus	運用コスト高め。設計段階から要検討
パーティショニング	RDS / Redshift（ゾーンマップ・ソートキー）	Azure SQL Database / Synapse Analytics	BigQuery・Athenaでも中心的な最適化手法

選択の判断基準——現場でどう判断するか

1. 読み取りが書き込みより圧倒的に多い場合

まずリードレプリカを検討する。導入コストが3手法中もっとも低く、アプリケーションの変更も「接続先エンドポイントを参照用とプライマリ用に分ける」だけで済むことが多い。段階的に台数を増やせるため、負荷試験をしながら必要なレプリカ数を調整できる。

2. 書き込みがスケールアップの限界を超えそうな場合

シャーディングを検討する。ただし、アプリケーション側でシャードキーを意識したクエリ設計が必要になるため、早い段階で設計に組み込まないと後から直す工数が膨大になる。DynamoDB や Azure Cosmos DB のようにシャーディングをマネージドサービスとして提供するものを選ぶと、自前でシャードを管理するより運用負荷が大幅に下がる。Azure Cosmos DB のパーティションキー設計は失敗コストが高いため、参照系クエリのアクセスパターンを事前に洗い出してから決定したい。

3. 特定クエリが遅い・集計コストが高い場合

まずパーティショニングを検討する。既存テーブルの DDL を変更するだけで導入できるケースも多く、「WHERE 条件に使う列をパーティションキーにする」だけで大幅な改善が見込める。特に OLAP 系の処理（集計・レポート・分析）では、パーティショニングとクラスタリングの組み合わせが最初の最適化手段として有効だ。

4. 3手法の組み合わせも現実的

実務では1つだけを選ぶのではなく、組み合わせて使うことも多い。例えば、「DynamoDB でシャーディングを行い、参照系レポートは S3 エクスポート後に Athena でパーティション設計して集計する」という構成は、書き込みと分析を完全に分離できるため、大規模サービスで広く採用されている。RDS と Aurora の違いも、リードレプリカの台数制限・フェールオーバー速度などで実務判断に関わるため、DB選定と合わせて確認しておきたい。

よくあるトラブルと対処法

リードレプリカでレプリケーションラグが常時発生する

リードレプリカのラグが数秒以上続く場合、プライマリへの書き込みレートがレプリカの処理能力を超えている可能性がある。レプリカのインスタンスサイズを上げる、あるいは Aurora に移行して並列レプリケーション機能を活用するのが定番の対処だ。根本的には書き込みがボトルネックになっており、シャーディングへの移行を検討するサインでもある。

DynamoDBでホットパーティション警告が出る

パーティションキーの設計が偏っていると、特定のパーティションへのリクエストが集中する。対処の第一歩はキー設計の見直し（ランダムサフィックスを付けてキーを散らすなど）だが、抜本的にはアクセスパターンから再設計が必要になることもある。DynamoDB Accelerator（DAX）を前段に置いて読み取りをキャッシュすることで一時的に緩和できる。

パーティションプルーニングが効かない

WHERE 句でパーティションキー以外の列しか使っていないと全パーティションがスキャンされ、かえって遅くなる。クエリ実行計画（EXPLAIN）でプルーニングが発生しているかを確認し、パーティションキーを絞り込みに使っているクエリパターンになるよう再設計する。

本記事のまとめ

リードレプリカ・シャーディング・パーティショニングの違いを整理すると以下のとおりだ。

・リードレプリカ: 読み取り分散のため「同じデータを複数インスタンスにコピー」する。導入コスト低、アプリ変更少ない
・シャーディング: 書き込みと容量をスケールするため「データを複数インスタンスに分散」する。設計コスト高、アプリへの影響大
・パーティショニング: クエリ性能向上のため「単一インスタンス内でテーブルを分割」する。中程度の導入コスト、クエリ設計が要件

オンプレで「スケールアップのみ」で対処してきた場合、まずリードレプリカで読み取り分散を試みるのが失敗リスクが低い。その後、書き込みのボトルネックが見えてきたらシャーディング検討、クエリ最適化が課題ならパーティショニングという順番で段階的に適用するのが現場でのセオリーだ。