Amazon RDS バックアップ戦略とディザスタリカバリ設計
Amazon RDS のバックアップ機能は、データベースの可用性と信頼性を確保する重要な仕組みです。この記事では、RDS バックアップの基本概念から実践的な災害復旧戦略まで、初心者にも分かりやすく解説します。
RDS バックアップの基本概念
バックアップメカニズムの概要
Amazon RDS は2つの主要なバックアップ方式を提供しています。
自動バックアップの特徴
自動バックアップは RDS の標準機能で、データベース全体の日次スナップショットとトランザクションログを自動的に作成します。この機能により、最大35日前までの任意の時点にデータベースを復旧できるポイントインタイム復旧（PITR）が可能になります。
手動スナップショットの利点
手動スナップショットは、重要なメンテナンス作業前やアプリケーションのアップデート前に作成する手動のバックアップです。自動バックアップとは異なり、明示的に削除するまで無期限に保持され、他のリージョンにコピーすることも可能です。
RPO・RTOの計画
災害復旧計画では、回復目標時間（RTO）と回復ポイント目標（RPO）の設定が重要です。ビジネスの重要度に応じて、適切な目標値を設定します。
| システム重要度 | RPO目標 | RTO目標 | 推奨バックアップ戦略 | コスト影響 |
|---|---|---|---|---|
| ミッションクリティカル | 5分以内 | 30分以内 | Multi-AZ + 頻繁スナップショット | 高 |
| ビジネスクリティカル | 1時間以内 | 2時間以内 | 日次自動バックアップ + 週次手動スナップショット | 中 |
| 開発環境 | 24時間以内 | 4時間以内 | 週次スナップショット | 低 |
バックアップ戦略の設計と実装
1. 自動バックアップ設定
自動バックアップの設定は、データベースの重要度とビジネス要件に応じて調整します。
基本設定項目
バックアップ保持期間 本番環境では14日間、開発環境では7日間の設定が一般的です。重要なシステムでは最大35日間まで延長できます。
バックアップウィンドウ システムの負荷が低い深夜時間帯（例：午前3-4時）に設定することで、パフォーマンスへの影響を最小限に抑えられます。
削除保護 本番環境では削除保護を有効にして、誤った削除操作を防止します。
# RDS バックアップ設定例
BackupRetentionPeriod: 14 # 14日間保持
PreferredBackupWindow: "03:00-04:00" # 深夜時間帯
DeletionProtection: true # 削除保護有効
CopyTagsToSnapshot: true # スナップショットにタグコピー監視とアラート設定
バックアップの成功・失敗を監視するため、CloudWatch アラームと SNS 通知を設定します。バックアップが失敗した場合、運用チームに即座に通知されるよう仕組みを整えます。
2. 手動スナップショット管理
手動スナップショットは、重要な作業前やデータ保護の追加レイヤーとして活用します。
スナップショット作成タイミング
定期スナップショット 週次または月次の定期スナップショットにより、長期的なデータ保護を実現します。重要なシステムでは、業務時間外に自動作成するよう EventBridge でスケジュール設定します。
メンテナンス前スナップショット データベースのメジャーアップグレードやアプリケーションの重要な変更前には、必ず手動スナップショットを作成します。問題が発生した場合の迅速なロールバックに活用できます。
クロスリージョンコピー 災害復旧のため、重要なスナップショットを別リージョンにコピーします。これにより、リージョン全体の障害からもデータを保護できます。
ライフサイクル管理
手動スナップショットは明示的に削除しない限り永続的に保持されるため、適切なライフサイクル管理が重要です。
| スナップショット種別 | 保持期間 | 保持数 | 用途 |
|---|---|---|---|
| 日次 | 7日間 | 7個 | 短期復旧 |
| 週次 | 30日間 | 4個 | 中期復旧 |
| 月次 | 1年間 | 12個 | 長期保管 |
| 年次 | 7年間 | 5個 | コンプライアンス |
ポイントインタイム復旧（PITR）
1. PITRの仕組みと利点
ポイントインタイム復旧（PITR）は、データベースを過去の任意の時点まで秒単位で復旧できる強力な機能です。
PITRの動作原理
PITRは2つの要素を組み合わせて動作します：
- 日次スナップショット - データベース全体の状態を記録
- トランザクションログ - スナップショット以降の全変更を記録
復旧可能な時間範囲
- 最古時点: 最も古いスナップショットの作成時刻
- 最新時点: 約5分前（トランザクションログの同期遅延のため）
- 精度: 秒単位での指定が可能
2. PITR最適化のポイント
パフォーマンス最適化
ストレージ設定 復旧速度を重視する場合は gp3 ストレージを選択し、必要に応じて Provisioned IOPS を設定します。
ネットワーク配置 復旧先インスタンスを元のインスタンスと同じ AZ に配置することで、ネットワーク遅延を最小化できます。
インスタンスサイズ 復旧時は元のインスタンスと同等以上のサイズを選択して、復旧処理を高速化します。
復旧時間の短縮
| 最適化項目 | 推奨設定 | 効果 |
|---|---|---|
| ストレージタイプ | gp3 | 高速I/O性能 |
| 配置 | 同一AZ | ネットワーク遅延最小 |
| インスタンスクラス | 同等以上 | CPU・メモリ性能確保 |
| 暗号化 | 有効 | セキュリティ確保 |
3. 復旧テストとDRiL（Disaster Recovery in Loop）
定期的な復旧テストは、バックアップ戦略の有効性を確認する重要なプロセスです。
復旧テストシナリオ
PITR復旧テスト 週次で実施し、1時間前の時点への復旧を検証します。RTO目標の30分以内での復旧完了を確認します。
スナップショット復旧テスト 月次で実施し、日次スナップショットからの復旧を検証します。データ整合性とアプリケーション接続性を確認します。
クロスリージョン復旧テスト 四半期で実施し、別リージョンでの災害復旧能力を検証します。ネットワーク設定や権限設定も含めた総合テストです。
テスト自動化の仕組み
検証項目
| 検証項目 | 確認内容 | 合格基準 |
|---|---|---|
| 復旧時間 | 開始から完了まで | RTO目標内 |
| データ整合性 | レコード数・最新データ | 正常復旧 |
| 接続性 | アプリケーション接続 | 正常接続 |
| 機能性 | 基本操作の実行 | 全機能正常 |
災害復旧計画とBCP
1. 包括的DR戦略
災害復旧戦略は、システムの重要度に応じて階層化して設計します。
DR戦略の階層化
| システム階層 | RPO目標 | RTO目標 | アーキテクチャ | テスト頻度 | コスト影響 |
|---|---|---|---|---|---|
| Tier1 Critical | 5分以内 | 30分以内 | Multi-AZ + Cross-Region Read Replica | 月次 | 5倍 |
| Tier2 Important | 1時間以内 | 4時間以内 | Multi-AZ + Daily Cross-Region Snapshot | 四半期 | 3倍 |
| Tier3 Standard | 24時間以内 | 8時間以内 | Single-AZ + Weekly Cross-Region Snapshot | 年次 | 1.5倍 |
DR実行フェーズ
2. クロスリージョンDR実装
インフラ構成
ネットワーク設計 プライマリリージョン（東京）とDRリージョン（オレゴン）間でVPCピアリングを設定し、専用のネットワーク経路を確保します。
データベース設計 プライマリDBのRead Replicaを別リージョンに配置し、障害時には自動または手動でプライマリに昇格できるよう設定します。
DNS設定 Route 53のHealth Checkを活用して、障害検知時に自動的にDRリージョンのエンドポイントに切り替えます。
自動フェイルオーバー
障害検知から復旧完了まで：
- 健全性監視 - CloudWatch Alarms による継続監視
- 障害検知 - 5分間連続で応答なしの場合にアラート
- Read Replica昇格 - Lambda関数による自動昇格処理
- DNS切り替え - Route 53による自動トラフィック転送
- 通知送信 - SNSによる関係者への自動通知
3. コスト最適化とコンプライアンス
バックアップコストの最適化
バックアップ機能の利用には、ストレージ費用とデータ転送費用が発生します。適切な設定により、コストを最適化できます。
保持期間の最適化
| 環境種別 | 自動バックアップ | 手動スナップショット | 理由 |
|---|---|---|---|
| 本番環境 | 14日 | 必要に応じて長期保持 | 障害復旧・コンプライアンス |
| ステージング環境 | 7日 | 月次保存 | テスト・検証用 |
| 開発環境 | 3日 | 不要 | 開発作業のみ |
ストレージ階層の活用 長期保存が必要なスナップショットは、S3 ライフサイクルポリシーにより Glacier や Deep Archive に自動移行することで、大幅なコスト削減が可能です。
コスト計算の例
- 自動バックアップ（100GB、14日間）: 約$45/月
- 手動スナップショット（100GB）: 約$10/月 per スナップショット
- クロスリージョン転送（100GB）: 約$2 per 転送
コンプライアンス対応
主要な規制フレームワーク
GDPR（EU一般データ保護規則）
- データ最小化原則に基づく保持期間設定
- 転送時・保管時の暗号化必須
- 個人データの完全削除権対応
SOX法（サーベンス・オクスリー法）
- バックアップの改ざん防止措置
- アクセス制御と職務分離
- 7年間の監査ログ保存
HIPAA（医療保険の携行性と責任に関する法律）
- FIPS 140-2準拠の暗号化
- 最小権限アクセス制御
- インシデント通知（72時間以内）
PCI DSS（ペイメントカード業界データセキュリティ標準）
- カードデータの暗号化保存
- リアルタイム監視システム
- 定期的な脆弱性評価
運用ベストプラクティス
1. 監視とアラート
効果的な監視により、バックアップの健全性を継続的に確認します。
監視すべき主要項目
バックアップ成功率
- 自動バックアップの完了率（目標：99.9%以上）
- 手動スナップショットの成功率
- クロスリージョンコピーの成功率
- PITR機能の利用可能性
パフォーマンス指標
- バックアップ実行時間の監視
- 復旧時間の実測値（RTO実績）
- データ転送速度の測定
- ストレージ使用量の推移
セキュリティ要素
- バックアップデータの暗号化状態
- アクセス権限の定期監査
- 不正アクセスの検知
- バックアップ整合性の検証
2. 自動化とオーケストレーション
複雑なバックアップ処理は自動化により、人的エラーを防止し運用効率を向上させます。
自動化の対象
定期バックアップ EventBridge を使用して、業務時間外の定期スナップショット作成を自動化します。
クロスリージョンコピー 重要なスナップショットは、作成完了後に自動的に別リージョンにコピーされるよう設定します。
ライフサイクル管理 古いスナップショットの自動削除により、ストレージコストを最適化します。
障害時の自動復旧 Lambda 関数と Step Functions を組み合わせて、障害検知から復旧完了までの一連の処理を自動化できます。
まとめ
Amazon RDS のバックアップとディザスタリカバリは、データ保護と事業継続性の要となる重要な機能です。
重要なポイント
段階的な実装アプローチ システムの重要度に応じて、適切なRPO/RTO目標を設定し、段階的にバックアップ戦略を実装することが成功の鍵です。
定期的なテストの重要性 バックアップは作成するだけでなく、定期的な復旧テストにより実際の障害時に確実に機能することを確認する必要があります。
コストとセキュリティの両立 ビジネス要件を満たしながら、適切なコスト最適化とセキュリティ要件の遵守を両立させることが重要です。
次のステップ
- 要件定義 - ビジネス影響度分析に基づくRPO/RTO目標の設定
- 戦略設計 - 自動バックアップと手動スナップショットの組み合わせ設計
- 実装 - 段階的なバックアップ機能の実装
- テスト - 定期的な復旧テストの実施
- 最適化 - 継続的なコスト監視と設定見直し
適切に設計されたバックアップ戦略により、RPO 5分、RTO 30分以内の高可用性システムを実現し、ビジネスの継続性を確保できます。