RDSの高可用性とバックアップ戦略を理解する

前回の記事では、RDSの基本概念からデータベースインスタンスの作成方法までを解説しました。本記事では、本番環境で欠かせないRDSの高可用性構成とバックアップ戦略について解説します。マルチAZ配置、リードレプリカ、自動バックアップ、ポイントインタイムリカバリを理解し、信頼性の高いデータベース運用を実現しましょう。

RDSの高可用性オプション

RDSでは、本番環境の要件に応じて複数の高可用性オプションを提供しています。それぞれの特徴を理解し、適切な構成を選択することが重要です。

高可用性オプションの比較

RDSで利用できる高可用性オプションを比較します。

graph TB
    subgraph "高可用性構成の選択"
        Start[要件の確認] --> Q1{高可用性が<br/>必要か?}
        Q1 -->|いいえ| SingleAZ[シングルAZ<br/>開発・テスト向け]
        Q1 -->|はい| Q2{読み取り負荷<br/>分散も必要か?}
        Q2 -->|いいえ| MultiAZ1[マルチAZ<br/>1スタンバイ]
        Q2 -->|はい| Q3{MySQL/PostgreSQL<br/>を使用?}
        Q3 -->|はい| MultiAZ2[マルチAZ<br/>2読み取り可能スタンバイ]
        Q3 -->|いいえ| MultiAZRead[マルチAZ +<br/>リードレプリカ]
    end

マルチAZ配置

マルチAZ配置は、RDSで最も重要な高可用性機能です。プライマリインスタンスに障害が発生した場合、スタンバイインスタンスに自動的にフェイルオーバーすることで、ダウンタイムを最小限に抑えます。

マルチAZ配置の仕組み

マルチAZ配置では、プライマリDBインスタンスのデータが同期的にスタンバイインスタンスにレプリケーションされます。

graph TB
    subgraph "AWS Cloud"
        subgraph "VPC"
            subgraph "AZ-a"
                Primary[(プライマリ<br/>DBインスタンス)]
            end
            subgraph "AZ-c"
                Standby[(スタンバイ<br/>DBインスタンス)]
            end
        end
        DNS[RDSエンドポイント<br/>DNS名]
    end
    
    App[アプリケーション] --> DNS
    DNS --> Primary
    Primary -->|同期レプリケーション| Standby

マルチAZ配置の主な特徴は以下のとおりです。

フェイルオーバーの動作

フェイルオーバーが発生する条件と、その際の動作を説明します。

フェイルオーバーが発生する条件

• プライマリインスタンスのホスト障害
• プライマリインスタンスのAZ障害
• プライマリインスタンスのネットワーク接続喪失
• プライマリインスタンスの変更（インスタンスクラス変更など）
• 手動でのフェイルオーバー実行

sequenceDiagram
    participant App as アプリケーション
    participant DNS as RDS DNS
    participant Primary as プライマリ
    participant Standby as スタンバイ
    
    App->>DNS: 接続
    DNS->>Primary: ルーティング
    Primary->>App: 応答
    
    Note over Primary: 障害発生
    
    Primary--xApp: 接続断
    
    Note over Standby: フェイルオーバー開始
    Standby->>Standby: プライマリに昇格
    DNS->>DNS: エンドポイント更新
    
    App->>DNS: 再接続
    DNS->>Standby: ルーティング（新プライマリ）
    Standby->>App: 応答

フェイルオーバーにかかる時間は、通常60秒から120秒程度です。この間、アプリケーションは一時的にデータベースに接続できなくなります。

マルチAZ配置の有効化

既存のシングルAZインスタンスをマルチAZに変更する方法を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# マルチAZへの変更
aws rds modify-db-instance \
    --db-instance-identifier my-database \
    --multi-az \
    --apply-immediately

# 変更状況の確認
aws rds describe-db-instances \
    --db-instance-identifier my-database \
    --query 'DBInstances[0].{MultiAZ:MultiAZ,Status:DBInstanceStatus}'

マルチAZへの変更時には、以下の点に注意が必要です。

• スナップショットが作成され、スタンバイインスタンスが構築される
• 変更中はI/Oの一時的な停止が発生する可能性がある
• メンテナンスウィンドウ内での適用を推奨（--apply-immediatelyを指定しない場合）

2つの読み取り可能スタンバイを備えたマルチAZ

2023年に登場した新しいマルチAZ配置オプションとして、「2つの読み取り可能スタンバイを備えたマルチAZ」があります。これはMySQL用RDSとPostgreSQL用RDSで利用可能です。

graph TB
    subgraph "AWS Cloud"
        subgraph "VPC"
            subgraph "AZ-a"
                Writer[(ライター<br/>インスタンス)]
            end
            subgraph "AZ-c"
                Reader1[(リーダー<br/>インスタンス 1)]
            end
            subgraph "AZ-d"
                Reader2[(リーダー<br/>インスタンス 2)]
            end
        end
        WriterEP[ライターエンドポイント]
        ReaderEP[リーダーエンドポイント]
    end
    
    AppWrite[書き込みアプリ] --> WriterEP
    WriterEP --> Writer
    AppRead[読み取りアプリ] --> ReaderEP
    ReaderEP --> Reader1
    ReaderEP --> Reader2
    Writer -->|同期レプリケーション| Reader1
    Writer -->|同期レプリケーション| Reader2

従来のマルチAZとの主な違いは以下のとおりです。

2つの読み取り可能スタンバイを使用する場合、専用のクラスターエンドポイントが提供されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# クラスターエンドポイントの確認
aws rds describe-db-clusters \
    --db-cluster-identifier my-cluster \
    --query 'DBClusters[0].{Writer:Endpoint,Reader:ReaderEndpoint}'

# 出力例
{
    "Writer": "my-cluster.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com",
    "Reader": "my-cluster.cluster-ro-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com"
}

リードレプリカ

リードレプリカは、読み取りトラフィックを分散させるための機能です。マルチAZとは目的が異なり、スケーラビリティの向上を主な目的としています。

リードレプリカの仕組み

リードレプリカは、ソースDBインスタンスから非同期でデータをレプリケーションします。

graph TB
    subgraph "AWS Cloud"
        subgraph "リージョン: ap-northeast-1"
            Source[(ソースDB<br/>インスタンス)]
            Replica1[(リードレプリカ 1)]
            Replica2[(リードレプリカ 2)]
        end
    end
    
    AppWrite[書き込みアプリ] -->|書き込み| Source
    Source -->|非同期レプリケーション| Replica1
    Source -->|非同期レプリケーション| Replica2
    AppRead1[読み取りアプリ 1] -->|読み取り| Replica1
    AppRead2[読み取りアプリ 2] -->|読み取り| Replica2

リードレプリカの主な特徴は以下のとおりです。

リードレプリカの作成

リードレプリカを作成する手順を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# リードレプリカの作成
aws rds create-db-instance-read-replica \
    --db-instance-identifier my-database-replica \
    --source-db-instance-identifier my-database \
    --db-instance-class db.t3.medium \
    --availability-zone ap-northeast-1c \
    --no-publicly-accessible

# リードレプリカの状態確認
aws rds describe-db-instances \
    --db-instance-identifier my-database-replica \
    --query 'DBInstances[0].{Status:DBInstanceStatus,ReplicaLag:StatusInfos}'

各エンジンで作成可能なリードレプリカの最大数は以下のとおりです。

リードレプリカのユースケース

リードレプリカは以下のようなユースケースで活用されます。

1. 読み取り負荷の分散

graph LR
    subgraph "アプリケーション層"
        Web[Webアプリ]
    end
    subgraph "データベース層"
        Source[(ソース<br/>書き込み用)]
        Replica1[(レプリカ1)]
        Replica2[(レプリカ2)]
    end
    
    Web -->|INSERT/UPDATE| Source
    Web -->|SELECT| Replica1
    Web -->|SELECT| Replica2

2. レポーティング・分析用途

graph LR
    subgraph "本番環境"
        Source[(ソースDB)]
    end
    subgraph "分析環境"
        Replica[(レプリカ)]
        BI[BIツール]
    end
    
    Source --> Replica
    Replica --> BI

3. クロスリージョンレプリケーション

graph LR
    subgraph "東京リージョン"
        Tokyo[(ソースDB)]
    end
    subgraph "バージニアリージョン"
        Virginia[(レプリカ)]
        USApp[米国向けアプリ]
    end
    
    Tokyo -->|クロスリージョン<br/>レプリケーション| Virginia
    USApp --> Virginia

マルチAZとリードレプリカの併用

本番環境では、マルチAZとリードレプリカを組み合わせることで、高可用性とスケーラビリティの両方を実現できます。

graph TB
    subgraph "AWS Cloud"
        subgraph "AZ-a"
            Primary[(プライマリ)]
        end
        subgraph "AZ-c"
            Standby[(スタンバイ<br/>マルチAZ)]
            Replica1[(リードレプリカ1)]
        end
        subgraph "AZ-d"
            Replica2[(リードレプリカ2)]
        end
    end
    
    Primary -->|同期レプリケーション| Standby
    Primary -->|非同期レプリケーション| Replica1
    Primary -->|非同期レプリケーション| Replica2

この構成のメリットは以下のとおりです。

• プライマリ障害時はスタンバイに自動フェイルオーバー
• 読み取りトラフィックはリードレプリカに分散
• リードレプリカ自体もマルチAZ構成にすることが可能

自動バックアップ

RDSは、DBインスタンスの自動バックアップ機能を標準で提供しています。これにより、データ損失のリスクを軽減し、障害発生時の復旧を容易にします。

自動バックアップの仕組み

自動バックアップは、以下の2つの要素で構成されます。

graph TB
    subgraph "自動バックアップの構成要素"
        DB[(DBインスタンス)]
        Snapshot[日次スナップショット]
        TxLog[トランザクションログ<br/>5分ごと]
        S3[(Amazon S3<br/>自動保存)]
    end
    
    DB -->|1日1回| Snapshot
    DB -->|5分ごと| TxLog
    Snapshot --> S3
    TxLog --> S3

バックアップの設定

自動バックアップの設定項目を説明します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# バックアップ設定の確認
aws rds describe-db-instances \
    --db-instance-identifier my-database \
    --query 'DBInstances[0].{
        BackupRetentionPeriod:BackupRetentionPeriod,
        PreferredBackupWindow:PreferredBackupWindow,
        LatestRestorableTime:LatestRestorableTime
    }'

# バックアップ設定の変更
aws rds modify-db-instance \
    --db-instance-identifier my-database \
    --backup-retention-period 14 \
    --preferred-backup-window "03:00-04:00" \
    --apply-immediately

主要なバックアップ設定は以下のとおりです。

バックアップ保持期間を0に設定すると、自動バックアップが無効になります。本番環境では、最低でも7日以上の保持期間を設定することを推奨します。

バックアップウィンドウの選択

バックアップウィンドウは、システムの負荷が低い時間帯を選択することが重要です。

gantt
    title 推奨バックアップスケジュール（日本時間）
    dateFormat HH:mm
    axisFormat %H:%M
    
    section トラフィック
    低負荷時間帯     :done, 02:00, 4h
    
    section バックアップ
    バックアップウィンドウ :active, 03:00, 1h
    
    section メンテナンス
    メンテナンスウィンドウ :04:00, 1h

バックアップ中はI/Oが一時的に停止する可能性があるため、以下の点に注意してください。

• シングルAZの場合：バックアップ中にI/Oの一時停止が発生する可能性がある
• マルチAZの場合：スタンバイからバックアップを取得するため、プライマリへの影響は最小限

手動スナップショット

自動バックアップに加えて、任意のタイミングで手動スナップショットを作成できます。手動スナップショットは、明示的に削除するまで保持されます。

手動スナップショットの作成

1
2
3
4
5
6
7
8
9

# 手動スナップショットの作成
aws rds create-db-snapshot \
    --db-instance-identifier my-database \
    --db-snapshot-identifier my-database-snapshot-20260125

# スナップショットの状態確認
aws rds describe-db-snapshots \
    --db-snapshot-identifier my-database-snapshot-20260125 \
    --query 'DBSnapshots[0].{Status:Status,CreateTime:SnapshotCreateTime,Size:AllocatedStorage}'

自動バックアップと手動スナップショットの違い

スナップショットのユースケース

手動スナップショットは以下のようなシーンで活用します。

1. 重要な変更前のバックアップ

1
2
3
4

# スキーマ変更前にスナップショットを作成
aws rds create-db-snapshot \
    --db-instance-identifier my-database \
    --db-snapshot-identifier pre-schema-migration-20260125

2. 本番環境のコピーを開発環境に作成

1
2
3
4
5
6

# スナップショットから新しいインスタンスを作成
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier my-database-dev \
    --db-snapshot-identifier my-database-snapshot-20260125 \
    --db-instance-class db.t3.medium \
    --no-multi-az

3. クロスリージョンへのコピー

1
2
3
4
5
6

# 別リージョンにスナップショットをコピー
aws rds copy-db-snapshot \
    --source-db-snapshot-identifier arn:aws:rds:ap-northeast-1:123456789012:snapshot:my-database-snapshot-20260125 \
    --target-db-snapshot-identifier my-database-snapshot-us-east-1 \
    --source-region ap-northeast-1 \
    --region us-east-1

ポイントインタイムリカバリ

ポイントインタイムリカバリ（PITR）は、バックアップ保持期間内の任意の時点にデータベースを復元できる機能です。誤ったデータ削除や更新からの復旧に非常に有効です。

ポイントインタイムリカバリの仕組み

PITRは、日次スナップショットとトランザクションログを組み合わせて、指定した時点の状態を再現します。

graph LR
    subgraph "バックアップデータ"
        Snap1[日次スナップショット<br/>1/23 03:00]
        TxLog1[トランザクションログ<br/>1/23 03:00-]
        Snap2[日次スナップショット<br/>1/24 03:00]
        TxLog2[トランザクションログ<br/>1/24 03:00-]
        Snap3[日次スナップショット<br/>1/25 03:00]
        TxLog3[トランザクションログ<br/>1/25 03:00-現在]
    end
    
    Snap1 --> TxLog1
    TxLog1 --> Snap2
    Snap2 --> TxLog2
    TxLog2 --> Snap3
    Snap3 --> TxLog3

指定時点（例：1/25 10:30）への復元手順は以下のとおりです。

1. 直近のスナップショット（1/25 03:00）を復元
2. トランザクションログを適用して10:30まで再生
3. 新しいDBインスタンスとして作成

復元可能な時間範囲

復元可能な時間範囲は、LatestRestorableTimeで確認できます。

1
2
3
4
5
6
7

# 復元可能な時間範囲の確認
aws rds describe-db-instances \
    --db-instance-identifier my-database \
    --query 'DBInstances[0].LatestRestorableTime'

# 出力例
"2026-01-25T14:25:00+00:00"

復元可能な範囲は以下のとおりです。

• 最古の復元可能時点: バックアップ保持期間の開始時点
• 最新の復元可能時点: 通常、現在時刻の5分前まで

ポイントインタイムリカバリの実行

PITRを実行する手順を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 特定の時点に復元（UTC時刻で指定）
aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier my-database \
    --target-db-instance-identifier my-database-restored \
    --restore-time "2026-01-25T10:30:00Z" \
    --db-instance-class db.t3.medium \
    --vpc-security-group-ids sg-xxxxxxxx \
    --db-subnet-group-name my-db-subnet-group \
    --no-multi-az \
    --no-publicly-accessible

# 最新の復元可能時点に復元
aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier my-database \
    --target-db-instance-identifier my-database-restored \
    --use-latest-restorable-time \
    --db-instance-class db.t3.medium

PITRの注意点は以下のとおりです。

• 復元先は新しいDBインスタンスとして作成される（元のインスタンスは影響を受けない）
• セキュリティグループ、パラメータグループは別途設定が必要
• 復元にかかる時間はデータ量に依存する

障害復旧のシナリオ

PITRを使用した障害復旧の典型的なシナリオを示します。

sequenceDiagram
    participant User as ユーザー
    participant App as アプリケーション
    participant DB as 本番DB
    participant Restored as 復元DB
    
    User->>App: 誤ったDELETE文を実行
    App->>DB: DELETE FROM users WHERE ...
    Note over DB: データ消失（10:30）
    
    User->>User: 障害を検知
    
    Note over Restored: PITR実行（10:29に復元）
    
    User->>Restored: データを確認
    Restored->>User: 消失データを発見
    
    User->>DB: データを手動で復旧
    
    Note over Restored: 復元DBを削除

バックアップとリカバリのベストプラクティス

本番環境で信頼性の高いバックアップ戦略を実現するためのベストプラクティスを紹介します。

バックアップ戦略の設計

graph TB
    subgraph "多層バックアップ戦略"
        Auto[自動バックアップ<br/>保持期間: 14日]
        Daily[日次スナップショット<br/>自動]
        Weekly[週次スナップショット<br/>手動・4週間保持]
        Monthly[月次スナップショット<br/>手動・12ヶ月保持]
        CrossRegion[クロスリージョン<br/>コピー]
    end
    
    Auto --> Daily
    Daily --> Weekly
    Weekly --> Monthly
    Monthly --> CrossRegion

推奨設定は以下のとおりです。

リカバリ手順の文書化

障害発生時に迅速に対応するため、リカバリ手順を文書化しておくことが重要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# リカバリ手順書のテンプレート

## 1. 障害の確認
# - 障害の種類（データ破損、誤操作、インスタンス障害）
# - 影響範囲の特定
# - 復旧目標時点の決定

## 2. 復旧方法の選択
# - PITRが必要か、スナップショットからの復元で十分か
# - 復旧先（同一リージョン/別リージョン）

## 3. 復旧の実行
aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier production-db \
    --target-db-instance-identifier production-db-restored \
    --restore-time "YYYY-MM-DDTHH:MM:SSZ" \
    --db-instance-class db.r6g.large \
    --vpc-security-group-ids sg-production \
    --db-subnet-group-name production-subnet-group

## 4. 復旧確認
# - データの整合性確認
# - アプリケーションからの接続テスト

## 5. 切り替え
# - アプリケーションの接続先を変更
# - DNSの更新（必要な場合）

RTO/RPOの設計

復旧目標を明確に設定し、それに適した構成を選択します。

graph LR
    subgraph "RTO/RPOと構成の関係"
        High[高可用性要件<br/>RTO: 分単位<br/>RPO: 0]
        Medium[標準要件<br/>RTO: 時間単位<br/>RPO: 5分]
        Low[コスト重視<br/>RTO: 日単位<br/>RPO: 24時間]
    end
    
    High --> MultiAZ[マルチAZ +<br/>同期レプリケーション]
    Medium --> PITR[シングルAZ +<br/>自動バックアップ]
    Low --> Snapshot[シングルAZ +<br/>日次スナップショット]

コストの最適化

高可用性とバックアップにはコストがかかります。要件に応じて適切な構成を選択し、コストを最適化します。

コスト要素

コスト削減のヒント

• 開発環境: シングルAZ、自動バックアップ保持期間を最小限に
• ステージング環境: シングルAZ、本番のスナップショットから定期的に再作成
• 本番環境: マルチAZは必須、バックアップ保持期間は要件に応じて設定

まとめ

本記事では、RDSの高可用性構成とバックアップ戦略について解説しました。

主なポイントをまとめます。

• マルチAZ配置により、プライマリ障害時に自動フェイルオーバーで高可用性を実現
• 2つの読み取り可能スタンバイは、高可用性と読み取りスケーリングを同時に提供
• リードレプリカは読み取り負荷分散とクロスリージョンレプリケーションに活用
• 自動バックアップとトランザクションログにより、5分以内のRPOを実現
• ポイントインタイムリカバリで、バックアップ保持期間内の任意の時点に復元可能
• RTO/RPOの要件に応じて、適切な構成を選択することが重要

これでRDSの基礎シリーズは完了です。次回からは、ELB（Elastic Load Balancing）とAuto Scalingについて解説し、負荷分散とスケーリングの実現方法を学びます。

参考リンク

• Amazon RDS マルチ AZ
• Amazon RDS リードレプリカ
• Amazon RDS のバックアップと復元
• 特定の時点への DB インスタンスの復元
• Amazon RDS のベストプラクティス