1. バックアップの種類
RDSのバックアップには「自動バックアップ」と「手動スナップショット」の2種類があります。
自動バックアップ
- 毎日1回、指定した時間帯に自動取得
- 保持期間：1〜35日（0に設定すると無効）
- ポイントインタイムリカバリ（PITR）が可能
- 保持期間を過ぎると自動削除される
- RDS削除時に自動バックアップも削除される
手動スナップショット
- 任意のタイミングで手動取得
- 保持期間の制限なし（明示的に削除するまで保持）
- PITRは不可（取得時点にしか戻せない）
- RDS削除後もスナップショットは残る
- デプロイ前・長期保存・別環境への移行に適している
2. 自動バックアップとスナップショットの最大の違い：PITR
自動バックアップだけが持つ機能で、特定の日時に復元できます。
| 自動バックアップ | 手動スナップショット | |
|---|---|---|
| 復元粒度 | 任意の日時に復元可能 | 取得時点のみ |
| 仕組み | フルスナップショット＋トランザクションログ | フルコピーのみ |
| ログ | 含む | 含まない |
3. スナップショット vs dump（論理バックアップ）
| 項目 | スナップショット | dump |
|---|---|---|
| 取得方法 | AWSがストレージレベルで取得 | DBエンジンがSQL/データを出力 |
| 出力形式 | AWS独自バイナリ形式 | SQLファイル / CSVなど |
| 取得・復元速度 | 速い | 遅い（DBサイズに比例） |
| 可搬性 | RDS内でのみ使用可能 | どこでも使用可能 |
| 特定テーブルのみ | ❌ 不可（DB全体のみ） | ✅ 可能 |
| RDS以外への復元 | ❌ 不可 | ✅ 可能（オンプレ等） |
dumpが向いている場面
- 特定テーブルだけ移行したい
- RDS以外の環境（オンプレ・他クラウド）に移行したい
- バックアップの中身を確認・編集したい
- 長期保存してS3などに保管したい
RDS間の移行（本番→ステージングなど）はスナップショットが最適です。
4. マルチAZ（スタンバイ）とリードレプリカの違い
| 項目 | マルチAZ（スタンバイ） | リードレプリカ |
|---|---|---|
| 目的 | 可用性・フェイルオーバー | 読み取り負荷分散 |
| 読み取りに使えるか | ❌ 不可 | ✅ 可能 |
| フェイルオーバー | ✅ 自動 | ❌ 手動 |
| レプリケーション | 同期 | 非同期 |
| データの遅延 | なし | ラグあり |
マルチAZ（スタンバイ）
スタンバイは待機専用で、通常時はトラフィックを受けません。プライマリに障害が発生すると自動的にスタンバイに切り替わります。同期レプリケーションのためデータ損失がありません。
通常時：アプリ → プライマリ（読み書き）
↓ 同期
スタンバイ（待機中・使えない）
障害時：アプリ → スタンバイ（自動昇格・切り替え）
リードレプリカ
通常時からアプリの読み取りクエリを受け付けます。障害時の自動フェイルオーバーはされません。非同期レプリケーションのため若干のラグがあります。
通常時：アプリ（書き込み） → プライマリ
↓ 非同期
アプリ（読み取り） → リードレプリカ
5. マルチAZの同期レプリケーションの仕組み
同期レプリケーションの流れ
① アプリが書き込みリクエスト
② プライマリがデータを書き込み
③ スタンバイへ同期レプリケーション
④ スタンバイの書き込み完了を確認
⑤ アプリへ「書き込み完了」を返す
③④が完了するまでアプリに応答を返さないのが同期レプリケーションの特徴です。これによりデータ損失ゼロを実現していますが、書き込みレイテンシが微増します。
エンジン別の実装
| エンジン | 実装方式 |
|---|---|
| MySQL / MariaDB | Amazon独自の同期ブロックレベルレプリケーション |
| PostgreSQL | WAL（Write-Ahead Log）のストリーミングレプリケーション |
| Oracle / SQL Server | 各エンジンネイティブの同期レプリケーション |
フェイルオーバー時の動作
プライマリに障害が発生した場合、通常1〜2分以内に自動切り替えが行われます。DNSがスタンバイのIPに切り替わるため、アプリのエンドポイント変更は不要です。（接続の再試行は必要）
6. スナップショット取得時の本番環境への影響
| 構成 | I/Oへの影響 | 備考 |
|---|---|---|
| シングルAZ | あり | 一時的なI/O停止が発生する場合がある |
| マルチAZ | ほぼなし | スタンバイから取得するため影響が小さい |
| Aurora | なし | 分散ストレージのため影響なし |
マルチAZ構成の場合
本番トラフィック → プライマリ（影響なし）
スナップショット取得 → スタンバイ ← ここから取得
レプリケーションへの影響
レプリケーション自体が止まることはありません。ただしシングルAZのプライマリから取得する場合、I/O負荷上昇によりリードレプリカのレプリケーションラグが一時的に増加する可能性があります。マルチAZ構成ではスタンバイから取得するため、プライマリ・リードレプリカともに影響はほぼありません。
スナップショット取得元の自動判定
| 操作 | 取得元 |
|---|---|
| 自動バックアップ（マルチAZ） | スタンバイから自動取得 |
| 手動スナップショット（マルチAZ） | スタンバイから自動取得 |
| 手動スナップショット（シングルAZ） | 指定インスタンスから取得（自動切替なし） |
| mysqldumpなどのツール | 接続先次第（自分で制御） |
シングルAZ ＋ リードレプリカ構成の場合、自動的にレプリカから取得されません。レプリカから取得したい場合はインスタンス識別子を明示的に指定する必要があります。
7. RDSのロール種類
| ロール表示 | 意味 |
|---|---|
| インスタンス | シングル構成またはマルチAZ（レプリカなし） |
| プライマリ | マルチAZ または リードレプリカの親 |
| スタンバイ | マルチAZのスタンバイインスタンス |
| レプリカ | リードレプリカ |
CLIでの確認方法
リードレプリカの確認
aws rds describe-db-instances \
--db-instance-identifier your-db \
--query 'DBInstances[0].ReadReplicaDBInstanceIdentifiers'
# 空配列 [] であればリードレプリカなし
マルチAZの確認
aws rds describe-db-instances \
--db-instance-identifier your-db \
--query 'DBInstances[0].MultiAZ'
# true であればマルチAZ構成
8. 本番→ステージング環境へのデータ移行手順
本番RDS → スナップショット取得 → ステージングRDSとして復元
Step 1: 本番環境のスナップショット取得
aws rds create-db-snapshot \
--db-instance-identifier prod-db \
--db-snapshot-identifier prod-snapshot-$(date +%Y%m%d)
Step 2: スナップショットの復元（ステージング用DBとして）
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier staging-db \
--db-snapshot-identifier prod-snapshot-$(date +%Y%m%d) \
--db-instance-class db.t3.medium \
--db-subnet-group-name staging-subnet-group \
--no-publicly-accessible
Step 3: 移行後の必須対応
- 個人情報・機密データのマスキング（メール・電話番号・パスワード等）
- 外部連携（決済・通知API等）の向き先をステージング用に変更
- VPC・セキュリティグループがステージング用になっていることを確認
- アプリの接続先エンドポイントを更新
移行時の注意点
| 確認項目 | 理由 |
|---|---|
| VPC / セキュリティグループ | 本番と混在させない |
| 個人情報のマスキング | 法的リスク（個人情報保護法等） |
| 外部APIの向き先 | ステージングから本番APIを叩かないよう |
| RDSエンドポイントの変更 | アプリの接続先を必ず更新 |
| 暗号化キー（KMS） | 別アカウントの場合はキーのコピーが必要 |
No responses yet