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 の主目的は、DB インスタンスや AZ 障害が起きたときに復旧時間を短くすることです。

たとえば、プライマリ DB がある AZ で障害が起きた場合、RDS はスタンバイ側へ自動フェイルオーバーします。アプリケーションは通常、同じ DB エンドポイントを使い続けます。DNS の切り替えなどは内部で処理されます。

Multi-AZ が向いているのは、次のようなケースです。

ただし、Multi-AZ を有効にしても読み取り性能が単純に 2 倍になるわけではありません。スタンバイは基本的にフェイルオーバー用です。読み取り分散のために使うものではありません。

Read Replica の主目的は、読み取り負荷を分散することです。

たとえば、次のような処理を replica に逃がせます。

アプリケーション側で、書き込みは writer endpoint、読み取りは replica endpoint へ振り分けます。

更新系処理:
  アプリケーション -> RDS Primary

参照系処理:
  アプリケーション -> Read Replica

ただし、Read Replica は非同期レプリケーションです。ソース DB に書き込んだ内容が、replica に即時反映されるとは限りません。

ユーザーが更新直後に同じデータを読む画面では、replica lag を考慮しないと「保存したはずなのに表示されない」という嫌なバグが出ます。インフラのせいにされがちですが、だいたい設計の問題です。

Multi-AZ は障害時に自動フェイルオーバーします。これが一番大きな価値です。

Read Replica は、障害時に自動的に primary の代わりになるとは限りません。必要に応じて replica を昇格できますが、アプリケーション接続先の切り替えや運用手順を考える必要があります。

Read Replica を増やすと、読み取りは逃がせます。しかし、書き込みの主担当は primary DB です。

大量 INSERT、UPDATE、DELETE が詰まっている状況で Read Replica を増やしても、書き込み性能そのものは改善しません。Multi-AZ も同じです。高可用性は上がりますが、書き込みスループットを水平分散する機能ではありません。

書き込みが問題なら、次を検討します。

「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 の選択はかなり整理できます。