結果整合性

結果整合性とは

結果整合性 (Eventual Consistency) は、分散システムで更新が全ノードに即座に反映されず、一定時間後に最終的に一貫した状態に収束するモデルである。DynamoDB のデフォルトの読み取りモデル。

強い整合性 vs 結果整合性

強い整合性と 結果整合性 の違いを図で示す。

強い整合性:
  書き込み → 全ノードに反映 → 読み取り (最新値を保証)
  遅い、可用性が低い

結果整合性:
  書き込み → 一部のノードに反映 → 読み取り (古い値の可能性)
  → 数ミリ秒〜数秒後に全ノードに反映
  速い、可用性が高い

DynamoDB の整合性

DynamoDB の整合性のコード例を示す。

// 結果整合性 (デフォルト、高速、低コスト)
const item = await db.get({
  TableName: 'users',
  Key: { id: '123' },
});

// 強い整合性 (やや遅い、コスト 2 倍)
const item = await db.get({
  TableName: 'users',
  Key: { id: '123' },
  ConsistentRead: true,
});

観点	結果整合性	強い整合性
レイテンシ	低い	やや高い
コスト	0.5 RCU	1 RCU
可用性	高い	やや低い
データの鮮度	通常 1 秒以内に収束	最新値を保証

結果整合性が問題になるケース

結果整合性が問題になるケースを図で示す。

1. ユーザーがプロフィールを更新
2. 直後にプロフィールページを表示
3. 結果整合性 → 古いプロフィールが表示される
→ 「更新したのに反映されない」とユーザーが混乱

対策: Read Your Own Writes

Read Your Own Writes のコード例を示す。

// 書き込み直後の読み取りは強い整合性を使う
await db.put({ TableName: 'users', Item: updatedUser });

// 直後の読み取り: ConsistentRead = true
const user = await db.get({
  TableName: 'users',
  Key: { id: updatedUser.id },
  ConsistentRead: true,
});

ただし ConsistentRead はどこでも使える札ではない。グローバルセカンダリインデックス (GSI) は強い整合性読み取りに対応しておらず、ConsistentRead: true を付けて GSI を Query すると ValidationException が返る。GSI は基本テーブルへの書き込みが非同期に射影される仕組みで、追いつくのは通常 1 秒未満だが、この経路には強制的に最新化する手段が無い。書き込み直後に最新値が必要な読み取りは、GSI ではなく基本テーブルのキー (両方の整合性を選べるローカルセカンダリインデックスも可) で引く設計へ寄せる。

AWS サービスの整合性モデル

AWS サービスの整合性モデルを以下にまとめる。

サービス	デフォルト
DynamoDB	結果整合性 (強い整合性もオプション)
S3	強い整合性 (2020 年 12 月以降)
ElastiCache	結果整合性 (非同期レプリケーション)
Aurora リードレプリカ	結果整合性 (レプリケーション遅延)

マルチリージョン構成ではもう一段の整合性が絡む。DynamoDB のグローバルテーブルは既定のマルチリージョン結果整合性 (MREC) では書き込みが非同期に複製され、他リージョンへの反映は通常 1 秒程度 (項目サイズ・書き込み量・リージョン間距離で変動)、同一項目への同時更新は項目のタイムスタンプによる後書き優先で解決される。ここで ConsistentRead が保証するのは同一リージョン内の最新値までで、他リージョンで直前に入った書き込みまでは追わない。リージョンをまたいで最新値が要るなら、書き込みを 1 リージョンに集約するか、マルチリージョン強整合性 (MRSC) を選ぶ (MRSC は書き込み応答前に別リージョンへ同期複製し、どのレプリカでも強い整合性読み取りができる。2026 年 8 月時点)。

結果整合性を受け入れる設計

書き込み成功を即座に UI に反映する楽観的 UI、一定間隔で最新データを取得するポーリング、DynamoDB Streams で変更を通知するイベント駆動の 3 つが代表的なパターンだ。

実務での活用方法は関連書籍にも詳しい。