単一AZで稼働しているRDS for MySQLがあります。AZ障害時にもDBの可用性を高めたいです。アプリケーション側の変更を最小にする構成はどれですか？

解説

RDS Multi-AZは同期レプリケーションと自動フェイルオーバーにより、AZ障害時の可用性を高めます。

選択肢ごとの解説

実務での使いどころ

RDS Multi-AZ 配置は、同一リージョン内の異なるアベイラビリティゾーンにスタンバイ DB を自動で構築し、プライマリ DB との間で同期レプリケーションを行う構成である。プライマリ AZ の障害時には自動的にフェイルオーバーが発生し、DB エンドポイント（DNS 名）の参照先がスタンバイ側に切り替わるため、アプリケーションは接続先文字列を変更せずに復旧できる。フェイルオーバーは概ね 60〜120 秒程度で完了し、シングル AZ 構成と比べて RTO が大幅に短縮される。 Multi-AZ と Read Replica の使い分けが SAA-C03 の頻出論点である。Multi-AZ は可用性向上のためのスタンバイ構成であり、スタンバイ DB は通常読み取りには使えない（一部例外として Multi-AZ DB Cluster というオプションでは読み取り可能なスタンバイを 2 つ持つ）。Read Replica は読み取り性能向上のための非同期レプリカで、可用性向上が主目的ではなく、フェイルオーバー先としては手動昇格が必要となる。両者を組み合わせて、書き込み系は Multi-AZ で守り、読み取り系は Read Replica でスケールさせる、というのが大規模 RDS 構成の標準形である。 Multi-AZ にはコスト面のトレードオフがある。スタンバイ DB インスタンスが追加で起動するため、シングル AZ と比較しておおむね 2 倍のコンピュート料金が発生する。それでもアプリ側の接続変更不要でフェイルオーバー対応できる点で、可用性要件のあるワークロードでは標準的に選ばれる。SAA-C03 では「AZ 障害時にも可用性を維持」「アプリ変更最小」要件で Multi-AZ が正解、誤答はストレージタイプ変更、バックアップ無効化、パブリックサブネット移動など、可用性とは別軸の操作が並ぶ。