フレームワーク活用ガイドひとことで言うと#
データベースのデータを複数のサーバーにコピー（レプリケーション）して、読み取り性能の向上や障害時の自動切り替えを実現する仕組み。「卵を一つのカゴに盛るな」のDB版。
押さえておきたい用語#
- Primary / Leader（プライマリ）
- 書き込みを受け付けるマスターとなるDBサーバーのこと。すべての変更はここから始まる。
- Replica / Follower（レプリカ）
- Primaryのデータをコピーして保持する読み取り専用のサーバー。読み取り負荷を分散する役割を持つ。
- Replication Lag（レプリケーションラグ）
- PrimaryとReplicaの間でデータの反映に生じる遅延を指す。ミリ秒〜秒単位で発生し得る。
- Failover（フェイルオーバー）
- Primaryが障害で停止した際に、Replicaを新しいPrimaryに自動昇格させる仕組みである。
- Synchronous / Asynchronous
- データの複製を書き込み完了前に行う（同期）か、完了後に行う（非同期）かのレプリケーション方式。
データベースレプリケーションの全体像#
こんな悩みに効く#
- データベースの読み取り負荷が高く、レスポンスが遅延している
- DBサーバーが単一障害点になっており、障害時にサービスが全停止する
- 分析クエリが本番DBに影響を与えている
基本の使い方#
- 非同期レプリケーション: 書き込み性能が落ちないが、ラグが発生する。大多数のユースケースではこれで十分
- 同期レプリケーション: Replicaへの書き込み完了を待ってから応答する。データ損失ゼロだが書き込みが遅くなる
- 準同期（Semi-synchronous）: 少なくとも1台のReplicaへの書き込みを保証するバランス型
- 読み取り負荷分散: 同一リージョンに2〜3台
- 高可用性: 異なるAZに配置
- 災害対策: 別リージョンにDR用Replicaを配置
具体例#
月間MAU200万のニュースアプリ。朝8時のプッシュ通知後に読み取りリクエストが通常の20倍に急増し、DB応答が平均3秒に悪化していた。
Read Replicaを3台追加し、記事取得APIの読み取りをReplicaに分散。
| 指標 | Before | After |
|---|---|---|
| ピーク時DB応答 | 3秒 | 120ms |
| 同時接続数上限 | 500 | 2,000 |
| Primary CPU使用率 | 95% | 35% |
レプリケーションラグは平均50ms。記事公開後に「最新記事が見えない」問題が稀に報告されたが、公開APIだけPrimary読み取りにすることで解消した。
月間取引額500億円を扱う決済プラットフォーム。DBの単一障害点を排除し、RPO（Recovery Point Objective）= 0（データ損失ゼロ）を達成する必要があった。
Aurora PostgreSQLのマルチAZ構成を採用。
- 同期レプリケーションで3AZに配置
- 自動フェイルオーバー（検知から切り替えまで30秒以内）
- 週次のフェイルオーバー訓練を自動実行
2年間で3回のAZ障害が発生したが、いずれも データ損失ゼロ・ダウンタイム30秒以内 で復旧。SLAの99.99%可用性を達成し続けている。
工場のセンサーデータを毎秒1万件書き込むIoTプラットフォーム。書き込みと分析クエリが同一DBで競合し、分析ダッシュボードの更新が5分以上遅延していた。
分析用の非同期Replicaを別途設置し、役割を分離。
- Primary: センサーデータの書き込み専用（高スループット最適化）
- Replica 1-2: リアルタイム監視ダッシュボード用（同一AZ、ラグ100ms以内）
- Replica 3: 日次分析レポート用（別リージョン、重いクエリOK）
ダッシュボードの更新遅延が 5分 → 200ms以下 に改善し、分析レポートの重いクエリがPrimaryに影響を与えなくなった。
やりがちな失敗パターン#
- レプリケーションラグを考慮しない — 書き込み直後に読み取ると古いデータが返ることがある。ユーザー自身の操作結果は必ずPrimaryから読む設計にする
- フェイルオーバーのテストをしない — 本番で初めてフェイルオーバーが動くと、想定外の問題が起きやすい。定期的にフェイルオーバー訓練を行う
- Replicaを増やしすぎる — Replicaが多いほどPrimaryのレプリケーション負荷が増える。読み取りキャッシュ（Redis等）を併用して台数を抑える
- すべての読み取りをReplicaに振り分ける — 「自分が今書いたデータを直後に読む」パターン（Read Your Writes）はPrimaryに向ける必要がある
まとめ#
データベースレプリケーションはデータを複数サーバーにコピーすることで、読み取り性能と可用性を向上させる基本技術。非同期レプリケーションが大多数のケースで適しており、ラグの影響を受ける箇所だけPrimary読み取りにするのが現実的な設計になる。フェイルオーバーの定期訓練とレプリケーションラグの監視を怠らないことが安定運用の鍵。