Amazon RDSのSingle-AZ、マルチAZ DBインスタンス、マルチAZ DBクラスターの違いと選び方

Amazon RDSでは、データベースを一つのアベイラビリティゾーンに置くSingle-AZと、複数のアベイラビリティゾーンを使う二種類のマルチAZ構成を選べます。
違いは台数だけではなく、障害時の切り替え方、読み取り処理を分散できるか、運用費用にも表れます。

先に結論を示すと、停止を許容できる開発環境にはSingle-AZ、高可用性を優先する一般的な本番環境にはマルチAZ DBインスタンス、高可用性と読み取り分散の両方が必要な環境にはマルチAZ DBクラスターが候補になります。
ただし、最終判断にはデータベースエンジン、負荷、復旧目標、予算を一緒に確認する必要があります。
Amazon RDSそのものの仕組みを先に確認したい場合は、Amazon RDSと他社のマネージドデータベースを比較した解説も参考になります。

構成比較の前に押さえる用語

可用性の構成を選ぶには、AWSの名称と復旧目標を分けて理解する必要があります。

アベイラビリティゾーン（AZ）

AWSリージョン内にある、互いに分離された拠点の単位です。
複数のAZへデータベースを配置すると、一つのAZで問題が起きた場合に別のAZへ切り替えられる構成を作れます。

フェイルオーバー

稼働中のデータベースに障害が起きたとき、待機系または読み取り用のデータベースを新しい書き込み先へ切り替える処理です。

RPO（目標復旧時点）

障害発生時に、どの時点までのデータを復旧できれば業務上許容できるかを示す目標です。

RTO（目標復旧時間）

障害発生からサービスを再開するまでに、どれだけの時間を許容するかを示す目標です。

RPOとRTOはサービス名から自動的に決まる値ではありません。
ワークロード、トランザクションの状態、接続側の再試行、復旧手順まで含めて設定し、テストで確かめます。

三つの構成を一覧で比較

この表は構成の違いをつかむための比較です。
実際の料金と性能は、リージョン、DBインスタンスクラス、ストレージ、I/O、データ転送、負荷の特性によって変わります。

Single-AZは構成の単純さを優先する

Single-AZでは、一つのAZに一台のDBインスタンスを配置します。
別AZに待機系を置かないため、構成要素と費用を抑えやすく、開発環境や検証環境に適しています。

一方、稼働中のAZやDBインスタンスに問題が起きても、別AZのスタンバイへ自動でフェイルオーバーする仕組みはありません。
元記事にあった「必ずバックアップから手動復元する」という説明は障害の種類によって対応が異なるため、ここでは「マルチAZと同じ切り替えはできない」と捉えるのが適切です。

Single-AZを選ぶ前に、停止が売上や業務へ与える影響と、復旧作業を担当できる時間帯を確認します。
本番環境でも停止を許容できる用途はありますが、「小規模だからSingle-AZ」と規模だけで決めると、必要な復旧水準を見落とします。

マルチAZ DBインスタンスは高可用性に重点を置く

マルチAZ DBインスタンスでは、プライマリの変更を別AZのスタンバイへ同期して複製します。
プライマリで障害が発生した場合は、Amazon RDSがスタンバイへ自動で切り替えます。

スタンバイは障害時の切り替え先であり、通常の読み取り処理には使えません。
高可用性のための構成と、読み取り性能を増やすための構成は同じではないため、読み取り負荷を分散したい場合は別の選択肢が必要です。

同期複製では、Single-AZより書き込みやコミットの待ち時間が増える場合があります。
元記事の「RPOは0、RTOは1分から2分」という固定的な表現は、復旧目標と実際の結果を混同します。
フェイルオーバー時間はデータベースの活動状況や復旧処理の条件で変わるため、アプリケーションの再接続まで含めて確認します。

マルチAZ DBクラスターは読み取り分散にも対応する

マルチAZ DBクラスターは、三つのAZにライター1台と読み取り可能なリーダー2台を配置します。
ライターから二つのリーダーへ半同期で複製し、障害時にはリーダーの一つを新しいライターへ昇格させます。

二つのリーダーへ読み取り処理を振り分けられる点が、マルチAZ DBインスタンスとの大きな違いです。
この利点を使うには、アプリケーション側でも書き込み先と読み取り先を分ける必要があります。

フェイルオーバーはマルチAZ DBインスタンスより短くなる傾向がありますが、常に同じ時間で完了するわけではありません。
未適用の変更やデータベースの活動状況などが切り替え時間に影響するため、監視と定期的なフェイルオーバーテストを設計に含めます。

対応するデータベースエンジンはMySQLとPostgreSQLです。
利用できるエンジンバージョン、リージョン、DBインスタンスクラスには条件があるため、採用時点のAWS公式情報を確認します。

構成を選ぶ四つの手順

1. 停止とデータ損失の許容範囲を決める
   業務が許容できるRPOとRTOを先に定めます。
2. 読み取り負荷を分けて把握する
   読み取りを別のDBインスタンスへ分散する必要がなければ、マルチAZ DBインスタンスで要件を満たせる場合があります。
3. 利用条件と接続方式を確認する
   DBエンジン、バージョン、リージョン、インスタンスクラスに加え、アプリケーションがフェイルオーバー後に再接続できるかを確認します。
4. 同じ負荷で費用と性能を測る
   台数だけでなく、ストレージ、I/O、データ転送、監視、運用作業まで含めて比較します。

可用性が必要だからといって、常に三台構成が適切とは限りません。
読み取り分散を使わないシステムでは、マルチAZ DBクラスターの追加費用を生かせない可能性があります。

可用性とバックアップを混同しない

マルチAZは、障害時に別のDBインスタンスへ切り替えてサービスを継続しやすくする仕組みです。
バックアップは、誤操作やデータ破損が起きたときに過去の状態へ戻すための仕組みであり、解決する問題が異なります。

したがって、マルチAZを選んでもバックアップと復元テストは別に設計します。
バックアップを含む復旧運用は、AWS Backupとクラウドの復旧運用を扱った解説も参照してください。

構成選定のまとめ

Single-AZは構成と費用を抑えやすい一方、別AZのスタンバイへの自動切り替えはありません。
マルチAZ DBインスタンスは高可用性を得られますが、スタンバイを読み取りには使えません。
マルチAZ DBクラスターは高可用性と読み取り分散を両立できますが、対応条件と三台分の構成を考慮する必要があります。

選定では、構成名から先に決めず、RPO、RTO、読み取り負荷、対応エンジン、予算を順に照合します。
そのうえで障害を想定したテストを行えば、資料上の比較だけでは見えない再接続や復旧手順の課題も確認できます。