導入
「可用性を上げたい」と「読み取り性能を上げたい」は、どちらも「RDSを複製すればいい」と混同されがちですが、SAAでは目的が違う機能として明確に区別されます。この違いを取り違えると設問を確実に落とします。
説明
Amazon RDS は、MySQL・PostgreSQL・MariaDB・Oracle・SQL Server に対応したマネージドリレーショナルDBサービスです。SAAでは次の2つの複製機能を対比で理解する必要があります。
| 機能 | 目的 | レプリケーション | 昇格 | リージョン |
|---|---|---|---|---|
| Multi-AZ配置 | 高可用性（障害対策） | 同期 | 自動フェイルオーバー | 同一リージョン内の別AZ |
| リードレプリカ | 読み取りスケーリング | 非同期 | 手動で昇格可能 | 同一・クロスリージョンどちらも可 |
Multi-AZは常にスタンバイとして待機し、通常時は直接アクセスできません。プライマリが故障すると、DNSの切り替えによって自動的にスタンバイへフェイルオーバーします。一方リードレプリカは、読み取り専用の接続先としてアプリケーションから直接クエリを実行でき、読み取りが多いワークロードの負荷分散に使います。
flowchart LR
App["アプリケーション"] -->|"書き込み"| Primary["プライマリ (AZ-a)"]
Primary -->|"同期レプリケーション"| Standby["スタンバイ (AZ-c)<br/>障害時に自動フェイルオーバー"]
Primary -->|"非同期レプリケーション"| Replica["リードレプリカ<br/>読み取り専用で直接接続"]
App -->|"読み取り"| Replica
SAAではこう問われる：「可用性を高めたい」「単一障害点をなくしたい」→ Multi-AZ。「読み取り負荷でDBが詰まっている」「レポート集計クエリを分離したい」→ リードレプリカ。両方の要件が同時に出た場合は、Multi-AZ配置のRDSに対してリードレプリカを追加する構成が正解になります。
具体例
あるメディアサイトが、2つの別々の悩みを抱えていました。取り違えないのがSAAの勘所です。
- 悩み1：DBサーバーが落ちると記事が全部読めなくなる（可用性） → Multi-AZ。別AZに同期スタンバイを待機させ、プライマリ障害時に自動フェイルオーバー。数分でサービス復帰。
- 悩み2：編集部が重い集計レポートを流すと、本番の記事表示まで遅くなる（読み取り負荷） → リードレプリカを追加し、レポート用の重い読み取りをそちらへ逃がす。本番の書き込み・表示が軽くなる。
ここで頻出の引っ掛けが「リードレプリカで可用性を上げる」という選択肢。もっともらしいですが、リードレプリカは自動フェイルオーバーの対象ではないので可用性対策にはなりません。可用性＝Multi-AZ、読み取り負荷＝リードレプリカ。両方欲しければMulti-AZのRDSにリードレプリカを足すのが正解です。
読んでみよう
「Multi-AZ＝同期・自動・待機系」「リードレプリカ＝非同期・手動・読み取り可」という対比を丸ごと覚えてください。SAAの選択肢には「リードレプリカで可用性を上げる」というもっともらしい誤答が必ず混ざります。読み取りレプリカは自動フェイルオーバーの対象ではないことを忘れないでください。