データベース

リードレプリカりーどれぷりか

レプリケーション読み取り専用スケールアウト負荷分散RDS非同期レプリケーション

リードレプリカについて教えて

簡単に言うとこんな感じ！

データベースの「読み取り専用コピー」だよ！本棚（メインDB）は1冊しかないけど、「読むだけ」の人向けにコピーを何冊も作っておくイメージ。本を「借りたい人（読み取り）」と「書き込む人（更新）」を分けることで、メインDBの混雑を大幅に減らせるってこと！

リードレプリカとは

リードレプリカ（Read Replica）とは、データベースのメインサーバー（プライマリと呼ぶ）のデータを複製し、読み取り専用として提供する仕組みです。アプリケーションからの「SELECT（データを取得する）」クエリをリードレプリカに向けることで、プライマリへの負荷を分散させられます。

データベースへのアクセスは、一般的に「書き込み」よりも**「読み取り」のほうが圧倒的に多いです。たとえばECサイトであれば、商品一覧を見たり、検索したりする操作（読み取り）は一日に何百万回と発生しますが、注文を確定する（書き込み）のはその一部だけです。リードレプリカはこの非対称性を活かし、読み取りを担当するサーバーを増やすことでスケールアウト（台数を増やして処理能力を上げること）**を実現します。

AWS RDS、Google Cloud SQL、Azure Database、そして自前で構築するMySQL・PostgreSQLなど、多くのデータベースサービスで標準的にサポートされています。現代のWebサービスでは、データベース設計の定番パターンのひとつです。

リードレプリカの仕組みと構造

データの流れ

操作	送り先	説明
INSERT / UPDATE / DELETE（書き込み）	プライマリ	データの変更はすべてここに集約
SELECT（読み取り）	リードレプリカ	コピーから読み取り、プライマリの負荷を下げる

プライマリへの変更は非同期レプリケーション（少し遅れてコピーが反映される方式）によってリードレプリカに伝えられます。そのため、書き込み直後の瞬間はレプリカ側のデータが古いことがあります（これをレプリケーションラグと呼びます）。

アプリケーション
    │
    ├─── 書き込み ──▶ [プライマリDB]
    │                      │
    │               非同期レプリケーション
    │                      │
    ├─── 読み取り ──▶ [リードレプリカ①]
    ├─── 読み取り ──▶ [リードレプリカ②]
    └─── 読み取り ──▶ [リードレプリカ③]

覚え方のポイント

「リード（Read）= 読む、レプリカ（Replica）= コピー」そのまま英語の意味通りです。「読み取り専用のコピーDB」と覚えれば完璧です。

リードレプリカの主な特徴

特徴	内容
読み取り専用	直接書き込み操作はできない
非同期レプリケーション	プライマリとわずかな時間差が生じる場合がある
複数台作成可能	読み取り負荷に応じて台数を増減できる
フェイルオーバー用途にも使える	プライマリ障害時に昇格させて継続運用が可能

歴史と背景

1990年代後半〜2000年代初頭 — Webサービスの普及とともにDBへのアクセス集中が問題化。レプリケーション機能がMySQLなどのOSSで整備され始める
2000年代中盤 — MySQL 5.0（2005年）がレプリケーション機能を強化。「マスター・スレーブ構成」として広く普及（現在は「プライマリ・レプリカ」と呼ぶことが主流）
2013年 — AWS RDSがリードレプリカ機能を正式サポート。クラウド上でボタン一つでレプリカを作成できる時代へ
2010年代後半 — SNS・動画配信サービスの爆発的拡大により、読み取りスケールアウトの必要性がさらに高まる。Aurora（MySQL/PostgreSQL互換のAWSサービス）など、リードレプリカ前提で設計されたクラウドDBが登場
現在 — クラウドDBサービスでは複数のリードレプリカを異なるリージョン（地理的拠点）に配置するクロスリージョンレプリカも一般的に

リードレプリカ vs 関連する技術との比較

リードレプリカと混同しやすい技術がいくつかあります。図と表で整理します。

技術	主な目的	書き込み分散	読み取り分散	複雑さ
リードレプリカ	読み取り負荷分散	✗	✅	低
マルチAZ	障害時の自動切替（高可用性）	✗	✗	低
シャーディング	大規模データの水平分割	✅	✅	高
キャッシュ（Redis等）	超高速な読み取り応答	✗	✅	中

レプリケーションラグに注意

リードレプリカの最大の注意点はレプリケーションラグ（複製の遅延）です。プライマリに書き込んだデータが、リードレプリカに反映されるまでわずかな時間差が生じます。

プライマリ:  [注文確定=100件] ← 書き込み直後
レプリカ  :  [注文確定=99件]  ← まだ古いデータ（数ミリ秒〜数秒の遅れ）

「注文直後に件数を表示する」など書き込み直後に読み取りが必要な処理は、リードレプリカではなくプライマリから読み取るよう設計する必要があります。

実務での活用シーン

リードレプリカは以下のようなケースで特に効果を発揮します。

レポート・集計クエリ — 月次売上集計など、重い分析クエリをレプリカに向けることで業務アプリへの影響をゼロに
検索機能の高速化 — ECサイトの商品検索など大量アクセスを複数レプリカで受け捌く
開発・テスト環境 — 本番データのコピーを開発者に提供する用途にも活用可能
障害対策の布石 — プライマリ障害時にレプリカを昇格させて素早く復旧

発注・選定時のチェックポイント：

リードレプリカは何台まで作れるか？（AWSのRDS MySQLは最大15台など、サービスにより異なる）

レプリケーションラグの許容値はどのくらいか？

クロスリージョン（別地域へのレプリカ）は必要か？

レプリカ追加時のコスト感は？（台数分のDB料金が発生する）