RDS Multi-AZ vs リードレプリカ — 目的・フェイルオーバー・レプリケーション方式の違い

根本的な違い：目的が異なる

Multi-AZとリードレプリカは目的が全く異なる。混同しないことが試験の基本だ。

特徴	Multi-AZ	リードレプリカ
主目的	可用性（HA・DR）	パフォーマンス（読み取りオフロード）
レプリケーション	同期（スタンバイはプライマリと常に同一）	非同期（わずかな遅延あり）
スタンバイへのアクセス	不可（フェイルオーバー時のみ昇格）	可能（読み取りクエリを向けられる）
エンドポイント	同じエンドポイントが自動切り替え	別エンドポイント（接続先変更が必要）
フェイルオーバー	自動（60〜120秒）	手動昇格（数分）
用途	本番環境の可用性確保	レポート、分析、読み取り分散

Multi-AZの仕組み

プライマリ インスタンス (AZ-a) ←→ スタンバイ インスタンス (AZ-c)
  ↓                                       ↓
すべての書き込みを同期レプリケーション
プライマリ障害時 → 自動フェイルオーバー

フェイルオーバーのトリガー:
  - AZの障害
  - プライマリインスタンスの障害
  - OSのメンテナンス（AWSによるパッチ適用）
  - ストレージの問題

フェイルオーバー時はDNSレコードが更新され、既存の接続は切断される。アプリケーションは同じエンドポイントに再接続するだけでよい。

# Multi-AZを有効にしてRDSインスタンスを作成
aws rds create-db-instance \
  --db-instance-identifier my-prod-db \
  --db-instance-class db.r6g.large \
  --engine mysql \
  --engine-version 8.0 \
  --multi-az \
  --allocated-storage 100 \
  --master-username admin \
  --master-user-password SecurePassword123!

RDS Multi-AZ Clusterとの違い

2022年以降、Multi-AZ Cluster（1プライマリ + 2リードスタンバイ）が追加された。

Multi-AZ DB Instance（従来）:
  プライマリ1台 + スタンバイ1台
  スタンバイは読み取り不可
  フェイルオーバー: 60〜120秒

Multi-AZ DB Cluster（新）:
  プライマリ1台 + リードスタンバイ2台（異なるAZ）
  リードスタンバイは読み取り可能（Aurora的な機能）
  フェイルオーバー: 35秒以内（より高速）

リードレプリカの仕組み

プライマリ → 非同期レプリケーション → リードレプリカ1
                                   → リードレプリカ2
                                   → リードレプリカ3

最大15個のリードレプリカ（Auroraの場合）、通常RDSは最大5個
レプリカラグが発生する（通常数秒以内）
「セカンダリインデックスを作ってクエリを最適化する」等の用途

# リードレプリカの作成
aws rds create-db-instance-read-replica \
  --db-instance-identifier my-db-replica-1 \
  --source-db-instance-identifier my-prod-db \
  --db-instance-class db.r6g.large

# クロスリージョンリードレプリカ（DR用）
aws rds create-db-instance-read-replica \
  --db-instance-identifier my-dr-replica \
  --source-db-instance-identifier arn:aws:rds:ap-northeast-1:123456789012:db:my-prod-db \
  --region ap-northeast-3 \
  --db-instance-class db.r6g.large

リードレプリカのプライマリ昇格

リードレプリカをプライマリとして昇格できる。DR時に使用する。

# リードレプリカをスタンドアロンDBに昇格
aws rds promote-read-replica \
  --db-instance-identifier my-db-replica-1

昇格前の注意事項：

バックアップを有効化することでリードレプリカのポイントインタイムリカバリが可能
昇格後はソースDBとの関係が切れ、独立したインスタンスになる

バックアップ設定との関係

Multi-AZの場合:
  自動バックアップはスタンバイ側から実施（プライマリのI/O影響なし）

リードレプリカの場合:
  リードレプリカに自動バックアップを設定することでソースDBへの影響を減らせる
  ただしリードレプリカのバックアップはデフォルト無効

RDSとAuroraのレプリカ比較

RDS（MySQL/PostgreSQL等）:
  - バイナリログ（binlog）ベースのレプリケーション
  - リードレプリカ最大5つ
  - フェイルオーバーに数分かかる

Aurora:
  - 共有ストレージアーキテクチャ（ログ転送のみ）
  - リードレプリカ最大15つ
  - フェイルオーバー30秒以内
  - リードレプリカ自動フェイルオーバー昇格

試験頻出ポイント

シナリオ	回答
AZ障害時の自動復旧	Multi-AZ
読み取りクエリの負荷分散	リードレプリカ
Multi-AZスタンバイに読み取りクエリを送れるか	不可（フェイルオーバー時のみ）
別リージョンにDRを構築	クロスリージョンリードレプリカ
昇格後もソースDBと同期を続けるか	しない（独立したインスタンスになる）
フェイルオーバーはどれくらいかかるか	60〜120秒（DNSのTTL含む）

まとめ

Multi-AZは「可用性（HA）」のためにあり、リードレプリカは「パフォーマンス（スケールアウト）」のためにある。Multi-AZのスタンバイには読み取りアクセスできないことと、リードレプリカのレプリケーションが非同期（データ遅延あり）であることが試験の核心ポイントだ。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感