目次
1. 結論
RDSの可用性と弾力性を支える2つの巨大な柱が Multi-AZ と リードレプリカ です。 – Multi-AZ は「高可用性（壊れないこと）」のための仕組みで、別AZに予備（スタンバイ）を置きます。 – リードレプリカ は「スケーラビリティ（処理能力）」のための仕組みで、読み取り専用のコピーを増やします。
2. SAAで出やすいポイント
- RDS Multi-AZ:
- 同期複製: 書き込み時にスタンバイ側にも同時に書き込む。
- 自動フェイルオーバー: メインが壊れたら自動でスタンバイがメインに昇格。DNSが自動で切り替わるためアプリ側の設定変更は不要。
- リードレプリカ (Read Replica):
- 非同期複製: メインに書き込んだ後、少し遅れてコピーに反映される。
- 読み取り分散:
SELECTクエリをレプリカに飛ばすことで、メインの負荷を減らす。 - 昇格: レプリカを独立したDBとして「昇格」させることも可能（災害復旧時など）。
- Auroraの場合: Multi-AZとリードレプリカが高度に統合されており、レプリカがフェイルオーバー先を兼ねる。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「データベースの可用性を高める（HA）」 | Multi-AZ | フェイルオーバーが必要 |
| 「読み取り負荷（Read-heavy）の分散」 | リードレプリカ | 参照専用コピーの増設 |
| 「最小限のダウンタイムで障害復旧」 | Multi-AZ | 自動フェイルオーバー機能 |
4. ひっかけポイント
- Multi-AZは性能向上ではない: スタンバイ機にはアクセスできないため、読み取り速度は上がらない。むしろ同期複製の分、わずかに書き込みが遅くなる場合がある。
- リードレプリカは自動フェイルオーバーではない: 通常のRDSでは、メインが壊れてもレプリカが自動でメインに代わることはない（Auroraは別）。
- クロスリージョンレプリカ: 別のリージョンにレプリカを作ることで、災害復旧（DR）対策としても利用できる。
5. 覚え方
- 「Multi-AZは身代わり、レプリカは分身」。
- 本体が倒れたら身代わり（スタンバイ）が立ち上がる。仕事が多すぎたら分身（レプリカ）を作って手伝わせるイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| RDS Proxy | フェイルオーバー時のコネクション維持を助け、復旧をさらに速める。 |
| Aurora | Multi-AZとレプリカのいいとこ取りをしたAWS独自の高性能DB。 |
| ElastiCache | リードレプリカを増やす前に検討すべき、読み取り負荷軽減の手段。 |
7. Obsidian管理メモ
- 復習ポイント: 「同期か非同期か」「自動フェイルオーバーがあるかないか」の表を脳内に叩き込む。
- 関連ノート: RDSとAuroraの徹底比較
8. HTMLファイル名
rds-multi-az-vs-read-replica.html
