Data Replication Strategyを改善する

ゴール

既存環境について、

レプリケーション経路
+
障害ドメイン
+
同期 / 非同期
+
レプリケーション遅延
+
障害時に利用できるデータ状態

を対応付け、

コピーは存在する
しかし
必要な障害時に必要なデータを利用できない

という問題を特定できるようにします。

1. 最初に現在のレプリケーション経路を可視化する

改善前に、現在のプライマリとレプリカを整理します。

例えば、

リージョンA
├─ AZ-A
│  └─ プライマリ
│
└─ AZ-B
   └─ レプリカ1

リージョンB
└─ レプリカ2

という配置だけを記録しても不十分です。

を対応付けます。

レプリカ1
レプリカ2

という名前だけでは、それぞれが同じ役割を持つとは限りません。

2. 各レプリケーション経路の役割を明確にする

既存環境では、異なる目的で作られたコピーが、すべて「レプリカ」として一括管理されていることがあります。

例えば、

リージョンA

AZ-A
プライマリ

AZ-B
同期スタンバイ

        ↓

リージョンB
非同期レプリカ

という構成があるとします。

この場合に重要なのは、

コピーが2つある

ことではありません。

AZ単位の障害では
どのコピーを利用するか

リージョン単位の障害では
どのコピーを利用するか

それぞれのコピーには
どの時点のデータが存在するか

を区別することです。

改善時には、各コピーが受け持つ障害範囲とデータ状態を明確にします。

3. 「配置」と「データ状態」を別々に確認する

障害ドメインを分離できていても、必要なデータ状態を維持できているとは限りません。

反対に、レプリケーション遅延が小さくても、必要な障害ドメインの外側にコピーがなければ、想定障害に対するデータ可用性は満たせません。

したがって、

どこにコピーがあるか

と、

そのコピーが
どの時点のデータを持っているか

を別の軸として確認します。

障害ドメイン
+
データ状態

の両方が要求を満たして初めて、そのコピーを想定した障害時に利用できます。

4. サービス名だけでレプリケーション方式を推測しない

改善では、

リードレプリカ
マルチAZ
グローバル
クロスリージョン

などの名称だけから動作を判断しません。

現在利用しているAWSサービスについて、

どこへ複製するか

同期か非同期か

どのコピーが
どの目的に使われるか

現在の構成から
方式を変更できるか

を確認します。

同じマルチリージョン構成でも、利用するサービスや設定によってレプリケーションの性質は異なります。

5. 新しい方式へ既存構成をそのまま変更できるとは限らない

必要なレプリケーション方式が変わったとき、

現在の設定値を変更する

だけで対応できるとは限りません。

リソース作成時に決まる属性であれば、

新しい要件
↓
現在構成では変更不可
↓
要件を満たす新しい構成を作成
↓
データを移行

という対応が必要になります。

改善時には、

AWSがその方式を提供しているか

だけでなく、

現在のリソースを
その方式へ変更できるか

まで確認します。

6. DynamoDB Global Tablesでは整合性モードの変更制約を確認する

Amazon DynamoDBグローバルテーブルでは、

MREC
Multi-Region Eventual Consistency

と、

MRSC
Multi-Region Strong Consistency

を利用できます。

既存のMREC構成に対して新しい要件が追加され、

複数リージョンで
強い整合性が必要

となった場合、

既存MREC
↓
設定変更
↓
MRSC

とはできません。

グローバルテーブルの整合性モードは作成後に変更できないため、MRSCが必要なら、対応する新しい構成への移行を検討します。

ここでの判断点はMRECとMRSCの基本比較ではありません。

新しい要件
+
現在リソースの変更制約

から、既存構成を修正できるのか、新しい構成へ移行する必要があるのかを判断します。

7. 非同期経路では現在のデータ状態も記録する

非同期レプリケーションを既存構成の一部として利用しているなら、

レプリカが存在する

という情報だけでは十分ではありません。

棚卸し時には、

レプリケーション遅延
+
レプリケーションが正常に継続しているか

も確認します。

例えば、

通常
数秒の遅延

高負荷時
数十分の遅延

であれば、障害時に利用するコピーとして評価するとき、その差を無視できません。

ここではレプリケーション監視そのものを独立して設計するのではなく、既存構成を評価するために現在のデータ状態を把握することが目的です。

8. 既存構成の信頼性ギャップを整理する

確認した内容を、

現在の構成
↓
想定障害
↓
残るコピー
↓
そのコピーのデータ状態
↓
不足しているもの

として整理します。

新しいレプリカを追加する前に、何が不足しているのかを特定します。

9. 改善後は「どの障害でどのコピーを使うか」を再確認する

構成変更後も、

レプリカを追加できた

だけで完了にしません。

AZ障害
↓
どのコピーを利用するか

リージョン障害
↓
どのコピーを利用するか

そのコピーは
どのデータ状態を持っているか

を再確認します。

改善結果は、

レプリカ数

ではなく、

必要な障害が発生したとき
必要な場所に
必要なデータ状態が残る

ことで評価します。

10. 改善の順序

既存環境では次の順序で確認します。

現在のプライマリとレプリカを特定
↓
各レプリケーション経路を特定
↓
AZ / リージョン配置を確認
↓
同期 / 非同期を確認
↓
各コピーの利用目的を確認
↓
非同期経路の遅延と現在状態を確認
↓
障害時に利用できるデータ状態を確認
↓
要求とのギャップを特定
↓
必要な構成だけ改善

最初から、

レプリカ追加
マルチAZ化
マルチリージョン化

を選ぶのではありません。

どのギャップを
どの変更で解消するか

を先に決めます。

11. 混同ポイント

12. SAP-C02での判断フロー

既存データ構成
↓
プライマリ / レプリカを特定
↓
各コピーはどこにある？
↓
どの障害で利用する？
↓
同期 / 非同期は？
↓
非同期なら
現在の遅延と状態は？
↓
障害時に必要なデータ状態を持つ？
│
├─ はい
│   ↓
│   その経路は要件を満たす
│
└─ いいえ
    ↓
    不足内容を特定
    ├─ 障害ドメイン
    ├─ レプリケーション方式
    ├─ 遅延
    └─ 既存構成の変更制約
        ↓
        必要な部分だけ改善

問題文に、

マルチAZ
マルチリージョン
レプリカ

という単語があっても、それだけでは十分と判断しません。

そのコピーを
どの障害で使うのか

その時点で
どのデータ状態なのか

まで確認します。

13. このページで扱わないこと

ここでは、

RTO / RPOからDR方式を選択する

復旧テストを設計する

復旧サイトを切り替える

フェイルバックを設計する

ことは扱いません。

このページで完成させるのは、

既存のレプリケーション戦略
↓
現在の構成とデータ状態を把握
↓
要求とのギャップを特定
↓
必要なレプリケーション戦略だけ改善

という判断です。

まとめ

既存環境のレプリケーション改善では、

レプリカがある

ことを確認して終わりません。

レプリケーション経路
+
障害ドメイン
+
同期 / 非同期
+
レプリケーション遅延
+
障害時のデータ状態

を一つの構成として評価します。

特に、

コピーが存在する
≠
必要な障害時に利用できる

別リージョンにある
≠
必ず必要なデータ状態を持つ

新しい機能が存在する
≠
既存リソースをそのまま変更できる

です。

最終的には、

想定する障害が発生したとき
必要な場所に
必要なデータ状態が残る

ように、既存のレプリケーション構成を改善します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected Framework — Reliability Pillar
• Amazon RDS — Multi-AZ deployments
• Amazon RDS — Read replicas
• Amazon DynamoDB — Global tables
• Amazon DynamoDB — Multi-Region strong consistency