Amazon RDS を設計するとき、Read Replica と Multi-AZ はよく混同されます。

どちらも「本番 DB を強くする仕組み」に見えるからです。でも、目的はまったく違います。Multi-AZ は高可用性と自動フェイルオーバーのための構成で、Read Replica は読み取り負荷を逃がすための構成です。

この記事では、試験でも実務でも間違えやすい RDS の Read Replica と Multi-AZ の違いを、設計判断に使える形で整理します。

先に結論

RDS の Multi-AZ は高可用性のための構成です。Read Replica は読み取りスケールのための構成です。

この 2 つを同じ「DB を複製する機能」として扱うと、設計を間違えます。

| 要件 | 使うもの | 理由 |

|---|---|---|

| 障害時に自動で切り替えたい | Multi-AZ | スタンバイへフェイルオーバーするため |

| 読み取りクエリを分散したい | Read Replica | 参照系処理を replica に逃がせるため |

| 書き込み性能を水平に伸ばしたい | どちらでも解決しにくい | primary の書き込み設計が残るため |

| 更新直後の整合性が重要 | primary 読み取りを検討 | replica lag があり得るため |

覚え方は単純です。

Multi-AZ は止めないため。Read Replica は読ませるため。

Multi-AZ が解く問題

Multi-AZ は、RDS の可用性を上げるための構成です。別の Availability Zone にスタンバイを配置し、DB インスタンスや AZ に障害が起きたときにフェイルオーバーできるようにします。

アプリケーションは通常、同じ RDS エンドポイントへ接続します。障害時には RDS 側でフェイルオーバーが行われ、接続先が切り替わります。

Multi-AZ が効くのは、たとえば次のような要件です。

  • 本番 DB の単一障害点を減らしたい
  • 障害復旧を手作業にしたくない
  • DB メンテナンス時の影響を下げたい
  • RTO を短くしたい

重要なのは、Multi-AZ のスタンバイは通常時の読み取り先ではないという点です。ここを読み取りスケールの手段として期待すると、最初から設計がずれます。

Read Replica が解く問題

Read Replica は、ソース DB から非同期で複製される読み取り専用の DB です。

用途は、参照系処理を primary から逃がすことです。

たとえば、次のようなワークロードに向いています。

  • 管理画面の一覧表示
  • ダッシュボード用の集計
  • レポート生成
  • バッチの参照処理
  • 読み取りが多い API

構成イメージはこうです。

```text

Write:

Application -> RDS Primary

Read:

Application -> RDS Read Replica

```

ただし、Read Replica は非同期です。primary に書き込まれたデータが replica に反映されるまで遅延することがあります。

この replica lag を無視すると、更新直後に古いデータを読んでしまいます。整合性が必要な画面では、primary から読む、または一定時間だけ primary に寄せるなどの設計が必要です。

障害対策として Read Replica を使うときの注意

Read Replica は昇格できます。つまり、障害時の復旧策として使えないわけではありません。

ただし、Multi-AZ のような自動フェイルオーバーとは違います。

Read Replica を DR や復旧候補として使うなら、少なくとも次を決める必要があります。

  • どのタイミングで replica を昇格するか
  • アプリケーション接続先をどう切り替えるか
  • DNS や設定値をどう更新するか
  • replica lag がどこまで許容されるか
  • 切り戻し手順をどうするか

「replica があるから高可用性も大丈夫」はかなり危険です。高可用性を自動化したいなら、まず Multi-AZ を見ます。

書き込み負荷には効かない

Read Replica は読み取りには効きますが、書き込み負荷の根本解決にはなりません。

書き込みは primary に集中します。Multi-AZ も書き込み性能を水平に伸ばすための機能ではありません。

たとえば、注文作成、在庫更新、ログ書き込みのような更新系が詰まっている場合、Read Replica を増やしても主問題は残ります。

この場合は、次のような見直しが必要です。

  • インデックスとクエリ設計
  • トランザクション範囲
  • バッチ処理の粒度
  • インスタンスクラスやストレージ性能
  • Aurora の採用
  • DynamoDB や SQS への切り出し

「DB が重い」という言葉だけで replica を足すのは危険です。読み取りが重いのか、書き込みが重いのかを分ける必要があります。

判断表

| 質問 | 答えが Yes なら |

|---|---|

| DB 障害時に自動復旧したいか | Multi-AZ |

| SELECT の量を primary から逃がしたいか | Read Replica |

| 更新直後のデータを必ず読みたいか | primary 読み取りを検討 |

| レポートや分析だけ分離したいか | Read Replica |

| 別リージョンに複製したいか | Cross-Region Read Replica |

| 書き込み性能を伸ばしたいか | 別の設計見直し |

まとめ

RDS の Multi-AZ と Read Replica は、役割が違います。

  • Multi-AZ は高可用性と自動フェイルオーバーのため
  • Read Replica は読み取り負荷分散のため
  • Read Replica は非同期なので replica lag がある
  • Multi-AZ は通常時の読み取り先を増やす機能ではない
  • 書き込み性能の問題は別途設計を見直す

判断するときは、「止めないための構成か」「読ませるための構成か」を先に分ける。これだけで、RDS の設計判断はかなり事故りにくくなります。