Data Replication Strategy

1. レプリケーション戦略はビジネス要件から選ぶ

レプリケーションはデータコピーを別場所へ維持するための制御ですが、同期方式と非同期方式では書き込み経路、復旧ポイント、可用性への影響が異なります。

「同期の方が強い」「非同期の方が速い」だけではなく、シナリオの要件を満たす方式を選びます。

2. 同期レプリケーション

同期レプリケーションでは、アプリケーションへ書き込み成功を返す前に、サービスが要求する同期条件を満たします。

アプリケーション書き込み
↓
サービスが要求する同期条件を満たす
・レプリカへの反映
・確認応答
・クォーラムなど
↓
アプリケーションへ書き込み成功

必要なリモート処理やネットワーク 往復通信が書き込み経路へ入るため、レプリカやネットワークのレイテンシーが書き込みレイテンシーへ影響し得ます。一方で、対象障害に対するコミット済みデータの損失を小さくできる候補です。

内部のコミット順序やクォーラム方式はサービス実装によって異なるため、「プライマリコミットの後に必ずレプリカへ反映する」と一般化しません。

3. 非同期レプリケーション

非同期レプリケーションでは、リモート側への反映完了をアプリケーション書き込み成功の必須条件にしません。

アプリケーション書き込み
↓
書き込み元でサービス固有の書き込み成功条件を満たす
├─ アプリケーションへ成功
└─ リモート側へのレプリケーション / 適用が非同期に進行

レプリケーション処理そのものはアプリケーションへ成功を返す前から進行している場合もあります。重要なのは厳密な時間順序ではなく、リモート側の反映完了を書き込み成功の前提にしないことです。

この方式では書き込み経路へリモート完了待ちを入れずに済む一方、障害時にリモート側へ未反映の書き込みが残る時間幅を考慮します。

4. 同期と非同期を比較する

どちらかを常に優先するのではなく、ビジネス RPOとアプリケーション特性に合わせます。

5. クロスリージョンレプリケーションでは物理 距離を無視しない

リージョン間には地理的 距離があるため、クロスリージョンレプリケーションではネットワークレイテンシーを設計要素として扱います。

リージョン A
   │
   │ クロスリージョンネットワーク
   │
リージョン B

距離 / ネットワーク状態
↓
レプリケーション動作とレイテンシーへ影響

リモートリージョンとの調整を書き込み成功条件に含めるほど、書き込みレイテンシーやリモートリージョン障害の影響を受けやすくなります。非同期方式ならリモート完了待ちを避けやすい一方、リージョン障害時に未反映書き込みが残り得ます。

ただし、クロスリージョンだから必ず非同期とは限りません。現在のAWSにはマルチリージョンで強い整合性を提供するサービス機能もあるため、場所境界とレプリケーション タイミングを分離して判断します。

6. レプリケーション遅延はサービス固有の運用メトリクス

レプリケーション遅延は、送信元に対してレプリカがどの程度遅れているかを評価するためのサービス固有の運用メトリクスです。

レプリケーション遅延
≠
全AWSサービス共通の
「データ内容の差」を表す単一メトリクス

メトリクスの単位、計算方法、集約、どのステージの遅れを測っているかはサービスごとに確認します。例えば、あるサービスは書き込みから別リージョンへの到着時間を測り、別のサービスでは適用やRPOに関連する別メトリクスを提供することがあります。

7. RPOとレプリケーション遅延を同一視しない

RPOはビジネスが許容できるデータ損失の最大時間幅です。一方、レプリケーション遅延はサービス運用状態を評価するメトリクスです。

ビジネス RPO
↓
サービス固有の遅延 / RPO メトリクスの意味を確認
↓
レプリケーション正常性
適用進捗
最悪時 遅延
フェイルオーバー時の未反映書き込み
↓
復旧可能なデータポイントが
ビジネス RPO内か評価

レプリケーション遅延 < RPOという1つの比較だけでRPO達成を確定しません。平均メトリクスだけでは最悪時を表さない場合や、パイプラインが停止している場合もあるためです。

8. レプリケーション タイミングと整合性モデルは別の判断

レプリケーションが同期か非同期かだけで、読み取り整合性は決まりません。

レプリケーション タイミング
≠
整合性モデル

整合性動作はデータ保管先、書き込みトポロジー、読み取り場所、クォーラム、競合 処理、サービス 実装などで変わります。

9. マルチリージョン書き込みでは競合も評価する

複数リージョンから書き込みできるアーキテクチャでは、同じ論理データへ同時書き込みが発生する可能性があります。

リージョン A → 書き込み X
リージョン B → 書き込み Y
        ↓
同一データへ同時更新
        ↓
競合解決 / 整合性の保証内容を確認

マルチリージョン書き込みを選ぶときは、低レイテンシー書き込みや可用性だけでなく、競合をどのように扱うサービスなのかもアーキテクチャ判断へ含めます。

10. 可用性・整合性・レイテンシーのトレードオフ

マルチリージョンデータアーキテクチャでは、可用性、整合性、レイテンシーを同時に最大化できるとは限りません。

リモートリージョンとのコミット 調整を増やす
↓
整合性 / データ損失低減に有利になり得る
↓
書き込みレイテンシーやリモート障害の影響が増え得る

各リージョンで処理継続を優先する
↓
可用性 / ローカルレイテンシーに有利になり得る
↓
一時的なデータ差や整合性確認が必要になり得る

シナリオでは、どの要件を最優先するかを読み取り、トレードオフを受け入れられる候補を選びます。

11. 遅延だけでなくレプリケーション正常性と適用状況を監視する

レプリケーションが正常に進んでいるか判断するには、単一遅延値だけでは不足します。

最終目的はメトリクス値を見ることではなく、障害時に復旧可能なデータポイントがビジネス RPO内にあるか判断できることです。

12. 非同期フェイルオーバーでは未反映書き込みを扱う

非同期レプリケーションでは、書き込み元を失った時点でリモート側にすべての書き込みが反映済みとは限りません。

書き込み元
書き込み A
書き込み B
書き込み C

リモート側
書き込み A
書き込み B

障害
↓
書き込み Cが未反映の可能性

復旧時には復旧ポイントを確認し、ビジネスロジックに応じて不足トランザクションの再実行、データ保管先間の比較、整合性確認などが必要になる場合があります。

13. レプリケーションはバックアップではない

レプリケーションは復旧先へ現在に近いデータコピーを維持する制御です。しかし変更を継続的に伝播するため、論理エラーまで複製される可能性があります。

論理削除
論理破損
アプリケーションのバグ
悪意のある変更
↓
レプリカへも伝播し得る

そのため、レプリケーションはポイントインタイムのデータ保護の代替ではありません。レプリケーションとバックアップ / 復元は異なる障害モードを扱う制御として組み合わせます。

14. 障害モード

15. SAP-C02判断フロー

ビジネス RPOを確認
↓
障害範囲を確認
↓
書き込みレイテンシー要件を確認
↓
整合性要件を確認
↓
可用性要件を確認
↓
同期条件を書き込み経路に含められる？
├─ はい → 同期候補を評価
└─ いいえ → 非同期候補を評価
          ↓
        未反映書き込みの時間幅を評価
↓
クロスリージョンなら物理 距離 / ネットワーク影響を評価
↓
サービス固有遅延 / RPO メトリクスの意味を確認
+
レプリケーション正常性
+
適用進捗
↓
復旧可能なデータポイントがビジネス RPO内か
↓
整合性 / 競合 / 可用性を含め最終選択