Storage / Database ReplicationとReliability

ゴール

レプリケーション構成を見たときに、「コピーが存在する」という事実だけで信頼性要件を満たすと判断せず、

想定する障害
↓
障害時点でどこまでのデータが保護されているか
↓
コピー先へ転送済みか
↓
適用済み・永続化済みか
↓
障害後に利用できるデータ状態か
↓
要求されたデータ可用性を満たすか

まで確認できるようにします。

レプリケーションで重要なのは、コピーの個数ではありません。

障害が発生した瞬間に、必要なデータ状態が生存側へ残っているかが判断の中心です。

1. 「レプリカがある」だけでは判断できない

同じ「レプリカ」でも、サービスや構成によって障害時のデータ状態は異なります。

例えば、非同期レプリケーションでは、送信元で成功した書き込みがコピー先へまだ反映されていない可能性があります。

書き込み
↓
送信元では成功
↓
レプリケーション待ち
↓
送信元で障害
↓
コピー先には最新書き込みが存在しない可能性

一方、書き込み成功を返す前に別の障害ドメインへ永続化する方式なら、同じ障害でも保護できるデータ状態が変わります。

したがって、レプリケーションを見るときは次の順序で考えます。

この観点をAmazon S3、Amazon RDS、Amazon ElastiCacheへ当てはめます。

2. Amazon S3では、追加レプリケーションの前に標準の障害範囲を見る

Amazon S3では、ストレージクラスによって保護される障害範囲が異なります。

S3 Standard、S3 Intelligent-Tiering、S3 Standard-IAなどは複数のアベイラビリティーゾーンを使用します。

一方、S3 One Zone-IAとS3 Express One Zoneは、単一のアベイラビリティーゾーンへデータを保存します。AWSはS3 Standard-IAを再作成できないデータのプライマリまたは唯一のコピー向け、S3 One Zone-IAをAZ障害時に再作成可能なデータなどに適したクラスとして案内しています。

したがって、

要件
1つのAZを失っても
再作成できないオブジェクトを維持する

という条件だけなら、複数AZへ保存されるS3ストレージクラスですでに必要な障害範囲を満たせる可能性があります。

「信頼性を上げるためにクロスリージョンレプリケーションを追加する」と機械的に考えるのではなく、

要求する障害範囲
↓
サービス標準の保護範囲
↓
不足する場合だけ追加レプリケーション

の順に判断します。

3. S3ライブレプリケーションでは「いつ作成されたオブジェクトか」を確認する

S3のライブレプリケーションでは、レプリケーション設定後の対象オブジェクトを継続的にレプリケートします。

設定前から存在する既存オブジェクトを複製する場合は、S3 バッチレプリケーションを使用します。S3 バッチレプリケーションは、既存オブジェクトや以前レプリケーションに失敗したオブジェクトなどをオンデマンドで複製する用途に使用できます。

既存オブジェクト
    ↓
S3 バッチレプリケーション

レプリケーション設定後の
新規・更新オブジェクト
    ↓
ライブレプリケーション

例えば、10 TBの既存オブジェクトがあるバケットへ今日からクロスリージョンレプリケーションを設定した場合、

クロスリージョンレプリケーション = 有効

だけを見て、

10 TBを含む全オブジェクトが
すでに別リージョンへ複製されている

とは判断できません。

障害時に必要なデータが本当にコピー先に存在するかを確認する必要があります。

4. S3 RTCでは「設計値」と「SLAコミットメント」を分ける

通常のライブレプリケーションは非同期です。

ビジネス要件として予測可能なレプリケーション時間が必要な場合は、S3 Replication Time Control（S3 RTC）を評価します。

S3 RTCは、新規オブジェクトの99.99%を15分以内にレプリケートするよう設計されています。

一方、SLAのコミットメントは、リージョンペアごとの請求月について99.9%を15分以内にレプリケートすることです。

また、S3 RTCはS3 バッチレプリケーションには適用されません。

設計上
99.99%
↓
15分以内

SLAコミットメント
99.9%
↓
15分以内

この2つを混同しません。

したがって、

既存オブジェクトも含め
すべて15分のSLAで複製したい

という要件に対して、

S3 バッチレプリケーション
+
S3 RTC

だけで既存データにも同じSLAが適用されるとは判断できません。

5. S3では「アクセス先」と「データ状態」を分ける

Amazon S3 マルチリージョンアクセスポイントのフェイルオーバーコントロールは、リクエストトラフィックを別のリージョンへ移す機能です。

しかし、それだけで各バケットのオブジェクトやメタデータが同期されるわけではありません。

AWSは、フェイルオーバーに備えてバケット間でオブジェクトとメタデータを維持する場合、双方向レプリケーションとレプリカ変更の同期を構成することを推奨しています。

アクセス先をどちらにするか
        │
        │ 別の制御
        ▼
どちらのバケットに
必要なデータ状態が存在するか

特に、障害後に別リージョン側へ書き込み、その変更も将来元のリージョンから利用する必要がある場合は、一方向ではなく双方向のデータ維持が必要です。

ここではアクセス切り替えの詳細手順ではなく、切り替え先として利用するバケットに必要なデータが存在するかを確認します。

6. Amazon RDSではReplicaLagを「障害時のデータ状態」として見る

Amazon RDSのマルチAZ DBクラスターでは、リーダーDBインスタンスにレプリカ遅延が発生する場合があります。

ReplicaLagは、ライターDBインスタンスの最新トランザクションと、リーダーDBインスタンスで最後に適用されたトランザクションとの時間差です。

マルチAZ DBクラスターでは、新しいライターへ昇格する前にレプリカ遅延を解消する必要があるため、レプリカ遅延はフェイルオーバー時間へ影響します。

ライター
最新トランザクション
        │
        │ レプリケーション
        ▼
リーダー
一部未適用
        │
        │ ReplicaLag
        ▼
障害発生
        │
        ▼
未適用トランザクションを解消
        │
        ▼
利用可能な新しいデータ状態

ここでの重要な判断は、

レプリカが存在する

ことではなく、

障害時点で
どこまでのトランザクションが
適用済みか

です。

レプリカ遅延が大きければ、障害後に利用可能な状態へ到達するまでの時間も長くなる可能性があります。

7. ElastiCacheでは最初に「失ってよいデータか」を確認する

Amazon ElastiCacheはキャッシュとして利用されることが多いため、保存されているすべてのデータへ同じ耐久性を要求する必要はありません。

例えば、

Amazon RDS
    ↓
正規データ

Amazon ElastiCache
    ↓
RDSから再生成可能なキャッシュ

であれば、ElastiCache内のデータが失われても、正規データから再生成できる可能性があります。

一方、

セッション状態
処理途中の状態
再生成できないアプリケーション状態

などを保存している場合は、ElastiCache内のデータ損失そのものが業務影響になります。

したがって最初に、

再生成可能か
        ↓
はい
→ 再生成時間と性能影響を評価

いいえ
→ 障害時にどの書き込みまで
   維持される必要があるか評価

と分けます。

信頼性とは、すべてのデータを同じ強度で保護することではありません。

データを失ったときの業務影響に合わせて必要な保護レベルを決めることが重要です。

8. 通常のElastiCacheレプリケーションを前提として扱う

ノードベースのElastiCache for Valkey / Redis OSSでは、通常のレプリケーションは非同期です。

そのため、プライマリで成功した最新書き込みがレプリカへまだ反映されていない時点で障害が発生すると、一部の最新データを失う可能性があります。

AWSは、通常のValkey / Redis OSSマルチAZ構成ではレプリケーションが非同期であり、レプリケーション遅延によって少量のデータを失う可能性があると説明しています。

プライマリ
書き込み成功
    │
    │ 非同期
    ▼
レプリカ
    ↑
まだ未反映

この非同期レプリケーション自体の性質は前提知識として扱います。

ここでは再度その仕組みを覚えるのではなく、この状態と現在利用できるElastiCache耐久性との違いを判断します。

9. Valkey 9.0以降では耐久性を別に評価する

Valkey 9.0以降の対応するノードベースクラスターでは、ElastiCache耐久性を利用できます。

耐久性を有効にすると、書き込みはマルチAZトランザクションログを使用します。

同期書き込み

同期書き込みでは、書き込みをマルチAZトランザクションログへ永続化してから、クライアントへ成功を返します。

書き込み
↓
マルチAZトランザクションログへ永続化
↓
成功応答

そのため、成功応答済みの書き込みを障害後にも維持する必要がある場合の重要な候補になります。

非同期書き込み

非同期書き込みでは、クライアントへ成功を返した後にマルチAZトランザクションログへ永続化します。

書き込み
↓
成功応答
↓
マルチAZトランザクションログへ永続化

障害発生時には、成功応答済みの書き込みのうち、まだトランザクションログへ永続化されていない最大10秒分を失う可能性があります。

したがって、

通常のレプリケーション
    ↓
非同期

耐久性 + 非同期書き込み
    ↓
成功応答済みでも
最大10秒分を失う可能性

耐久性 + 同期書き込み
    ↓
成功応答前に
マルチAZログへ永続化

と区別します。

10. ElastiCache耐久性には構成上の制約がある

耐久性は、すべてのElastiCache構成で利用できるわけではありません。

現在の主な条件は次のとおりです。

現行の対応インスタンスタイプファミリーは、

R8g / R7g / R6g
M8g / M7g / M6g
C8gn / C7gn

です。

インスタンスファミリー一覧そのものを丸暗記することが目的ではありません。

試験では、

Valkey 9.0だから使える

だけで決めず、

エンジンバージョン
+
デプロイ方式
+
インスタンスタイプ
+
マルチAZ
+
レプリカ
+
他機能との互換性

まで確認することが重要です。

耐久性はクラスター作成時に有効化する必要があります。

作成後は同期書き込みと非同期書き込みを切り替えられますが、耐久性自体を無効化することはできません。

また、既存の耐久性無効クラスターへ後から耐久性を有効化することもできません。

11. グローバルデータストアではクロスリージョンのデータ状態を見る

ElastiCacheのグローバルデータストアでは、プライマリリージョンから別リージョンのセカンダリクラスターへデータをレプリケートします。

セカンダリクラスターは通常、読み取り専用として動作し、プライマリクラスターから更新を自動的かつ非同期に受信します。

したがって、プライマリ側で書き込みが成功していても、障害発生時点では、その最新変更がセカンダリへまだ到達していない可能性があります。

プライマリリージョン
読み取り / 書き込み
        │
        │ 自動・非同期レプリケーション
        ▼
セカンダリリージョン
読み取り専用

ここで確認する中心は、

障害時点で
セカンダリへどこまでのデータが
到達しているか

です。

非同期レプリケーション一般の性質を再度覚えるのではなく、グローバルデータストアでは、その性質が「リージョン障害時に残るデータ状態」へどう影響するかを確認します。

さらに、現在のElastiCacheでは、グローバルデータストアと耐久性を組み合わせることはできません。

したがって、

クロスリージョン
+
グローバルデータストア
+
耐久性の同期書き込み

という構成を前提に判断してはいけません。

要求するデータ保護を、実際に組み合わせ可能な機能で満たせるか確認します。

12. 障害時のデータ状態を比較する

同じ「レプリケーション」という言葉でも、障害時に残るデータ状態は異なります。

13. シナリオ1：S3の切り替え先へ書き込みを継続する

要件

リージョンA
通常利用

リージョンB
待機

リージョンAを利用できなくなった後
リージョンBへ書き込みを継続

将来リージョンAを再び利用するときも
リージョンBで作成したデータを失いたくない

一方向のクロスリージョンレプリケーションだけでは、

リージョンA
    ↓
リージョンB

という方向のデータだけが維持されます。

リージョンBへ書き込んだ変更もリージョンAへ複製する必要があるため、

リージョンA
    ⇅
リージョンB

となる双方向レプリケーションを評価します。

Amazon S3 マルチリージョンアクセスポイントを使用する場合も、アクセス経路とバケット間のデータレプリケーションは別々に確認します。AWSもフェイルオーバー時の同期維持に双方向レプリケーションを案内しています。

14. シナリオ2：ElastiCacheへ再生成できない状態を保存する

要件

Valkey 9.0
ノードベース
R7g
マルチAZ
各シャードにレプリカあり

保存データは再生成できない

障害発生時にも
成功応答済みの書き込みを
失うことを許容できない

R7gは現在、ElastiCache耐久性に対応するインスタンスタイプファミリーです。

通常の非同期レプリケーションでは、成功応答済みの最新書き込みがレプリカへ反映される前に障害が起きる可能性があります。

また、耐久性を有効にしても、非同期書き込みでは成功応答後にトランザクションログへ永続化するため、最大10秒分を失う可能性があります。

したがって、

ElastiCache耐久性
+
同期書き込み

を選択します。

決定打は、

成功応答済みのデータを
障害後も維持する必要がある

ことです。

15. シナリオ3：ElastiCacheが再生成可能なキャッシュである

要件

Amazon RDS
    ↓
正規データ

Amazon ElastiCache
    ↓
RDSから再生成可能なキャッシュ

キャッシュ消失時
一時的な性能低下は許容

この場合、ElastiCache内のすべての書き込みに対してゼロデータ損失を要求する必要はありません。

必要なのは、

正規データ
    ↓
失わない

キャッシュ
    ↓
再生成時間と性能影響が
許容範囲か確認

という判断です。

例えば、キャッシュを再生成している間にRDSへの負荷が増大し、応答時間が許容値を超えるのであれば、ElastiCache側にもより高い可用性が必要になる可能性があります。

一方、キャッシュを短時間で再生成でき、性能低下も許容できるのであれば、正規データと同じ「成功応答済みデータ損失0」の要件をキャッシュへ一律に適用する必要はありません。

再生成可能かどうかと、再生成中の業務影響が決定打です。

16. 混同ポイント

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

守るデータは何か
↓
再生成可能か？
├─ はい
│   ↓
│   再生成時間と
│   性能影響を許容できるか？
│   ↓
│   必要な保護レベルを決定
│
└─ いいえ
    ↓
想定する障害範囲は？
ノード / AZ / リージョン
    ↓
サービス標準の冗長性で
要求を満たすか？
    ↓
不足する
    ↓
どこへ複製するか
    ↓
障害時点のデータは
コピー先まで到達済みか？
    ↓
利用可能な状態まで
適用・永続化済みか？
    ↓
成功応答済みのデータを
どこまで維持できるか？
    ↓
その機能を利用できる
構成条件を満たすか？
    ↓
要求された
データ可用性を満たすか

まとめ

レプリケーションを信頼性へ利用するときは、

コピーがある

で判断を終えません。

障害発生
↓
必要なデータが
どこまで転送済みか
↓
どこまで適用・永続化済みか
↓
障害後に必要な状態として残るか
↓
その保護機能を利用できる構成か
↓
データ可用性を満たすか

まで確認します。

Amazon S3では、ストレージクラスの障害範囲、ライブレプリケーションと既存オブジェクト、S3 RTC、双方向レプリケーションを区別します。

Amazon RDSでは、ReplicaLagによって障害時にどこまでトランザクションが適用されているかを確認します。

Amazon ElastiCacheでは、通常の非同期レプリケーション、Valkey 9.0以降の耐久性、同期書き込みと非同期書き込み、利用可能な構成条件、グローバルデータストアを分けて判断します。

さらに、ElastiCache内のデータが再生成可能な場合は、

再生成可能
↓
再生成時間
+
再生成中の性能影響
↓
必要な保護レベル

を判断します。

最終的に見るのは、

レプリケーション
↓
障害時点のデータ状態
↓
障害後に利用可能なデータ状態
↓
データ可用性

です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• Amazon S3 — Amazon S3 ストレージクラスの理解と管理
• Amazon S3 — リージョン内およびリージョン間でのオブジェクトのレプリケート
• Amazon S3 — S3 バッチレプリケーション
• Amazon S3 — S3 Replication Time Control
• Amazon S3 — マルチリージョンアクセスポイントのフェイルオーバーコントロール
• Amazon RDS — マルチAZ DBクラスターデプロイ
• Amazon ElastiCache — マルチAZによるダウンタイムの最小化
• Amazon ElastiCache — 耐久性
• Amazon ElastiCache — 耐久性の制限
• Amazon ElastiCache — グローバルデータストア