Amazon RDS を設計するとき、Read Replica と Multi-AZ はよく混同されます。
どちらも「本番 DB を強くする仕組み」に見えるからです。でも、目的はまったく違います。Multi-AZ は高可用性と自動フェイルオーバーのための構成で、Read Replica は読み取り負荷を逃がすための構成です。
この記事では、試験でも実務でも間違えやすい RDS の Read Replica と Multi-AZ の違いを、設計判断に使える形で整理します。
まず結論
RDS の Multi-AZ と Read Replica は、次のように分けて考えると迷いにくいです。
| 目的 | 選ぶもの | 主な役割 |
|---|---|---|
| DB 障害時にもサービスを止めにくくしたい | Multi-AZ | 高可用性、自動フェイルオーバー |
| SELECT が重く、読み取り処理を分散したい | Read Replica | 読み取りスケール、参照系ワークロード分散 |
| DR や別リージョン参照を考えたい | Read Replica / Cross-Region Read Replica | 非同期レプリケーションによる複製 |
| 書き込み性能を水平に伸ばしたい | 原則どちらでもない | アプリ設計や DB 選定から見直す |
雑に言うと、Multi-AZ は落ちたときの保険、Read Replica は読みに行く先を増やす仕組みです。名前が似ているだけで、責任範囲は別物です。
なぜ混同しやすいのか
どちらも「DB のコピー」を作るように見えます。ここが罠です。
Multi-AZ では、別の Availability Zone にスタンバイ DB インスタンスが用意されます。障害時には RDS が自動的にフェイルオーバーします。通常時、アプリケーションがこのスタンバイへ読み取りに行くものではありません。
Read Replica では、ソース DB から非同期でデータを複製した読み取り専用の DB が作られます。アプリケーションは参照系クエリを replica endpoint に向けることで、読み取り負荷を逃がせます。
つまり、同じ「複製」でも用途が違います。
Multi-AZ は高可用性のための構成
Multi-AZ の主目的は、DB インスタンスや AZ 障害が起きたときに復旧時間を短くすることです。
たとえば、プライマリ DB がある AZ で障害が起きた場合、RDS はスタンバイ側へ自動フェイルオーバーします。アプリケーションは通常、同じ DB エンドポイントを使い続けます。DNS の切り替えなどは内部で処理されます。
Multi-AZ が向いているのは、次のようなケースです。
- 本番 DB の可用性を上げたい
- DB インスタンス障害時の手動復旧を避けたい
- メンテナンスや障害時の停止時間を短くしたい
- RTO を短くしたい
ただし、Multi-AZ を有効にしても読み取り性能が単純に 2 倍になるわけではありません。スタンバイは基本的にフェイルオーバー用です。読み取り分散のために使うものではありません。
Read Replica は読み取りスケールのための構成
Read Replica の主目的は、読み取り負荷を分散することです。
たとえば、次のような処理を replica に逃がせます。
- レポート画面の SELECT
- ダッシュボード用の集計クエリ
- バッチの参照処理
- 分析に近い読み取りワークロード
アプリケーション側で、書き込みは writer endpoint、読み取りは replica endpoint へ振り分けます。
更新系処理:
アプリケーション -> RDS Primary
参照系処理:
アプリケーション -> Read Replica
ただし、Read Replica は非同期レプリケーションです。ソース DB に書き込んだ内容が、replica に即時反映されるとは限りません。
ユーザーが更新直後に同じデータを読む画面では、replica lag を考慮しないと「保存したはずなのに表示されない」という嫌なバグが出ます。インフラのせいにされがちですが、だいたい設計の問題です。
障害時の挙動が違う
Multi-AZ は障害時に自動フェイルオーバーします。これが一番大きな価値です。
Read Replica は、障害時に自動的に primary の代わりになるとは限りません。必要に応じて replica を昇格できますが、アプリケーション接続先の切り替えや運用手順を考える必要があります。
| 観点 | Multi-AZ | Read Replica |
|---|---|---|
| 主目的 | 高可用性 | 読み取り分散 |
| レプリケーション | 同期または準同期に近い構成として扱われる | 非同期 |
| 通常時の読み取り利用 | 基本しない | する |
| 障害時 | 自動フェイルオーバー | 昇格や切り替え設計が必要 |
| replica lag | 設計上の主論点ではない | 重要 |
書き込み負荷対策にはならない
Read Replica を増やすと、読み取りは逃がせます。しかし、書き込みの主担当は primary DB です。
大量 INSERT、UPDATE、DELETE が詰まっている状況で Read Replica を増やしても、書き込み性能そのものは改善しません。Multi-AZ も同じです。高可用性は上がりますが、書き込みスループットを水平分散する機能ではありません。
書き込みが問題なら、次を検討します。
- インデックス設計
- トランザクション設計
- バッチ処理の分割
- インスタンスサイズ変更
- ストレージ性能
- Aurora など別エンジンの検討
- DynamoDB など別サービスへの切り出し
「DB が重いから replica を足す」は、原因が読み取りなら正解、書き込みならだいたい的外れです。
選び方の早見表
| 状況 | 判断 |
|---|---|
| 本番 DB の障害耐性を上げたい | Multi-AZ |
| SELECT が多くて primary が苦しい | Read Replica |
| 更新直後のデータ整合性が重要 | primary 読み取りを優先、replica lag に注意 |
| レポートや分析系だけ分離したい | Read Replica |
| AZ 障害時に自動で切り替えたい | Multi-AZ |
| DR 目的で別リージョンに複製したい | Cross-Region Read Replica などを検討 |
| 書き込み性能を伸ばしたい | Multi-AZ / Read Replica だけでは足りない |
まとめ
RDS の Read Replica と Multi-AZ は、似た名前の便利機能ではありません。目的が違います。
- Multi-AZ は高可用性と自動フェイルオーバーのため
- Read Replica は読み取り負荷分散のため
- Read Replica は非同期なので replica lag を考慮する
- Multi-AZ を有効にしても読み取り性能が単純に増えるわけではない
- 書き込み負荷の解決には、別の設計判断が必要
試験でも実務でも、まず「落ちたときの話か」「読みに行く量の話か」を分ける。ここを分ければ、Multi-AZ と Read Replica の選択はかなり整理できます。