Database Continuity Strategy

1. データベース継続性は要件から選ぶ

データベースサービスには複数のレプリケーション機能がありますが、目的とフェイルオーバー動作は同じではありません。

最初にサービス名を決めるのではなく、障害範囲、RTO/RPO、自動フェイルオーバーの必要性、読み取り/書き込みトポロジー、整合性要件から候補を絞ります。

2. RDS マルチAZには2つのデプロイタイプがある

Amazon RDSのマルチAZを1つのトポロジーとして覚えません。現在はマルチAZ DB インスタンスデプロイとマルチAZ DBクラスター デプロイを区別します。

「RDS マルチAZのスタンバイはすべて読み取り不可」と一般化しません。デプロイタイプまで確認します。

3. マルチAZ DB インスタンスは同期スタンバイで高可用性を高める

マルチAZ DB インスタンスデプロイでは、プライマリ DB インスタンスとは別のAZにスタンバイを維持します。

アプリケーション
    ↓
プライマリ DB インスタンス
    │
    │ 同期レプリケーション
    ↓
スタンバイ DB インスタンス
異なるAZ

プライマリやAZの障害時はRDSがフェイルオーバーを管理します。スタンバイの主目的は読み取りスケーリングではなく、同一-リージョンでの高可用性と自動フェイルオーバーです。

4. マルチAZ DBクラスターはライター + 2 リーダーの半同期構成

マルチAZ DBクラスター デプロイでは、1つのライターと2つのリーダー DB インスタンスを3つのAZへ配置します。

AZ-A              AZ-B              AZ-C
ライター  ───────→  リーダー
   └────────────→ リーダー

変更
↓
2 リーダーへ送信
↓
少なくとも1 リーダーから確認応答
↓
コミット

レプリケーションは準同期です。リーダーは読み取りトラフィックを処理でき、フェイルオーバー対象にもなります。

このデプロイはRDS for MySQL / RDS for PostgreSQLを対象とし、利用可否はリージョンとエンジンバージョンでも確認します。エンジン名だけで利用可能と決めません。

5. 読み取りレプリカはマルチAZ スタンバイとは役割が異なる

RDS 読み取りレプリカは、送信元データベースからレプリカへ変更を非同期レプリケーションします。

送信元データベース
      │
      │ 非同期レプリケーション
      ↓
読み取りレプリカ

読み取り負荷が高い ワークロードを分離する用途に加え、対応するエンジン / デプロイではDR 候補としても利用できます。ただし、読み取りスケーリングそのものの設計は別のパフォーマンス要件として扱い、ここでは継続性に必要な違いを押さえます。

6. 読み取りレプリカをDRに使うなら昇格と接続先切替を設計する

読み取りレプリカを復旧先として使う場合、レプリカが存在するだけでは自動フェイルオーバーになりません。

送信元障害
↓
復旧先レプリカを確認
↓
昇格
↓
書き込み可能なデータベース
↓
アプリケーション接続 / ルーティングを切替

昇格とアプリケーションの接続先切替に必要な時間もRTOへ含めます。クロスリージョン読み取りレプリカは対応するエンジン、送信元/宛先リージョン、デプロイ条件を確認して候補にします。

7. RDS マルチAZと読み取りレプリカを使い分ける

リージョン規模の障害が要件なら、同一-リージョンマルチAZだけで完結させずクロスリージョン候補を評価します。

8. Aurora グローバルデータベースはクロスリージョン継続性の候補

Aurora グローバルデータベースでは、プライマリリージョンのクラスターが書き込み権限を持ち、セカンダリリージョンへクロスリージョンレプリケーションします。

プライマリリージョン
Aurora プライマリクラスター
書き込み権限
        │
        │ クロスリージョンレプリケーション
        ↓
セカンダリリージョン
Aurora セカンダリクラスター
リモート読み取り

リージョン規模の障害への備えとリモート読み取りを必要とするリレーショナルデータベースアーキテクチャで有力な候補です。

9. セカンダリからの書き込み転送でも書き込み権限はプライマリにある

対応するAurora バージョンでは、グローバル書き込み転送を有効化するとセカンダリクラスターで受けた書き込みステートメントをプライマリクラスターへ転送できます。

セカンダリリージョンアプリケーション
↓
セカンダリクラスター
↓  グローバル書き込み転送
プライマリクラスター
↓  実際のデータ変更
セカンダリへレプリケーション

セカンダリ自身が独立してデータをコミットするマルチアクティブライターではありません。Aurora グローバルデータベースの単一プライマリの書き込み権限と、書き込みリクエストをセカンダリから送れることを分離して理解します。

10. Auroraでは切り替えとフェイルオーバーを分離する

計画された運用と予期しない障害では復旧動作が異なります。

「Aurora グローバルデータベースならどの切替でもRPO 0」とは判断しません。

11. DynamoDB グローバルテーブルはマルチリージョンマルチアクティブ

DynamoDB グローバルテーブルでは、アプリケーションは各レプリカリージョンのDynamoDB エンドポイントへアクセスし、そのレプリカで読み取り / 書き込みできます。

リージョン A                          リージョン B
アプリケーションアプリケーション
    ↓                                ↓
レプリカテーブル  ←→ グローバルテーブル ←→ レプリカテーブル
読み取り / 書き込み読み取り / 書き込み

RDS 読み取りレプリカのようにスタンバイをプライマリへ昇格することを基本モデルにしません。リージョン規模の障害時は、正常リージョンのアプリケーションへユーザートラフィックを切り替え、そのリージョンのレプリカテーブルを利用します。

12. DynamoDB グローバルテーブルはMRECとMRSCを選択する

MRECでは同じ項目が複数リージョンで同時更新された場合、内部タイムスタンプに基づく最後の書き込みが優先で競合を解決します。

13. MRSCは3リージョンちょうどとリージョンセット制約を確認する

MRSCは任意のリージョン組み合わせで利用できるわけではありません。

3リージョンちょうど

3 レプリカ
   または
2 レプリカ + 1 監視

かつ
同じMRSCリージョンセット内

現在のリージョンセットは次のとおりです。

リージョンセットをまたぐMRSC グローバルテーブルは構成できません。監視は可用性アーキテクチャへ参加しますが、アプリケーションから読み取り / 書き込みするレプリカではありません。

14. フェイルオーバーの意味はサービスごとに異なる

同じ「レプリカがある」アーキテクチャでも、復旧運用は異なります。

15. データベースだけでなくエンドツーエンド復旧を確認する

復旧先データベースが利用可能でも、アプリケーションがそこへ到達できなければビジネスサービスは復旧しません。

データベース復旧
+
アプリケーション
DNS / ルーティング
ネットワーク
シークレット / KMS
認証
依存サービス
        ↓
エンドツーエンドサービス復旧

データベースフェイルオーバー完了時刻だけをRTOとせず、アプリケーション接続とトラフィックルーティングまで含めて復旧経路を確認します。

16. 要件から候補を選ぶ

17. 判断フロー

ビジネス RTO / RPO
↓
障害範囲
├─ インスタンス / AZ 障害
│   └─ RDS マルチAZを評価
└─ リージョン規模の障害
    └─ クロスリージョン候補を評価
↓
自動フェイルオーバーが必要か
↓
昇格を許容できるか
↓
読み取り / 書き込みトポロジー
↓
整合性要件
↓
エンジン / リージョン / バージョン機能
↓
RDS マルチAZ
読み取りレプリカ
Aurora グローバルデータベース
DynamoDB グローバルテーブル
↓
フェイルオーバー / 昇格 / ルーティングを確認
↓
アプリケーションが復旧先へ到達可能か
↓
ビジネス RTO / RPOを満たすか評価

18. 障害モード