Amazon DynamoDBの書き込みと読み込みの整合性

Amazon DynamoDBでは、書き込みを受け付けた後にどの読み取り要求からその変更を確認できるかを、読み取りの整合性で考えます。DynamoDBはデータをリージョン内の複数のアベイラビリティーゾーン（AZ）に複製し、可用性と耐久性を支えます。パーティションへの配置やAZ間の複製はサービスが管理するため、利用者が個々の複製先を指定することはありません。

複製先が複数あることと、どの読み取りでも同じ時点の値を直ちに返すことは同じではありません。読み取り側が直前の更新をすぐに確認する必要があるか、それとも短い反映遅延を許容できるかをアクセスパターンごとに決めます。

書き込みの完了とAZ間の複製

アプリケーションが PutItem、UpdateItem、DeleteItem などの書き込み操作を送ると、DynamoDBはプライマリキーに基づいて対象アイテムを配置・更新します。書き込みに成功した応答を返す前にデータは複数のAZに耐久性を持つ形で保存されます。物理的なデータ配置、複製の実装、障害時の切り替えはDynamoDBが担当します。

読み取り整合性の選択は、データの複製数を増減させる設定ではありません。どの鮮度保証で結果を返すかを指定するものです。たとえば、地域イベントの予約サービスで残席を減らした直後に同じ利用者へ確定結果を表示する場合は、更新後の値が必要かを検討します。一方、一覧画面に出す申込数の集計表示なら、わずかな反映遅延を許容できる場合があります。

結果整合性読み込み

結果整合性読み込み（eventually consistent read）は、DynamoDBで標準となる読み込み方式です。通常の読み取りリクエストでは、結果整合性が使われます。直前に成功した書き込みがすべての読み取り場所に反映されるまでの短い間は、読み込みが書き込み前の値を返すことがあります。

ここでいう「結果整合性」は、一定時間内に必ず新しい値が返るとアプリケーションが指定できる保証ではありません。短い反映遅延を許容し、読み込み性能やキャパシティ消費を抑えたい場面に適しています。画面表示、参照頻度の高い公開情報、多少古くても業務上の判断に影響しないデータなどが候補になります。

結果整合性読み込みを選んだだけで書き込みそのものが遅延したり、書き込みの成功が取り消されたりするわけではありません。更新はすでに成功していても、読み取り側がその直後の状態をまだ観測できない可能性がある、という読み取り上の性質です。

強い整合性読み込み

強い整合性読み込み（strongly consistent read）を選ぶと、読み取りを開始する前に正常終了した書き込みを反映した最新のアイテム値が返されます。結果整合性の反映途中だからという理由でエラーを返す仕組みではありません。強い整合性を使うと、更新直後の読み取りに古い値が返る可能性を避けられます。

強い整合性読み込みは、たとえば予約枠の更新後に確定状態を確認する、在庫の減算後に残数を表示するといった処理で役立ちます。ただし、これは読み取り要求に対する最新性の保証です。複数の独立した読み取りをまとめて一つの時点に固定する分離レベルや、複数アイテムにまたがるトランザクションを意味するわけではありません。

DynamoDBの読み取りAPIでは ConsistentRead パラメータを使って整合性を指定します。強い整合性が必要な操作だけで有効にし、すべての読み取りへ一律に適用する必要があるかを確認します。整合性を高めるほどキャパシティ消費が大きくなり、応答時間が長くなることもあるためです。

読み取り対象による制約

強い整合性読み込みが利用できるかどうかは、読み取り対象によって異なります。

読み取り対象	結果整合性読み込み	強い整合性読み込み
DynamoDBテーブル	利用可能	利用可能
ローカルセカンダリインデックス（LSI）	利用可能	利用可能
グローバルセカンダリインデックス（GSI）	利用可能	利用不可
DynamoDB Streams	ストリームのレコード取得として扱う	ConsistentRead の読み取り対象ではない

テーブルの最新状態を強く整合性のある読み取りで確認できても、GSIに対するクエリでは強い整合性を指定できません。GSI経由の読み取りが直近のテーブル更新をすぐ反映する必要がある場合は、検索方法をテーブルまたはLSIで実現できるか、アプリケーションで読み取り後の確認・再試行が必要かを設計します。インデックスのキー構造と役割はDynamoDBのキー設計とセカンダリインデックスも参照してください。

レイテンシーと読み込みキャパシティ

同じサイズのアイテムを読む場合、強い整合性読み込みは結果整合性読み込みより多くの読み込みキャパシティを消費します。プロビジョンドキャパシティでは、最大4 KBまでの読み込みで結果整合性読み込みが0.5 RCU、強い整合性読み込みが1 RCUです。アイテムが4 KBを超える場合は読み取りサイズを4 KB単位で切り上げます。オンデマンドモードでも整合性によって読み取りリクエストユニットの消費が変わります。

強い整合性読み込みでは、より最新の結果を保証するために応答時間が増えることがあります。実際のレイテンシーはリクエスト、アイテムサイズ、負荷などに左右されるため、常に一定量遅くなるとは限りません。最新性が不要な読み取りまで強い整合性にすると、要求キャパシティや費用が増える一方で、アプリケーションが利用しない保証にコストをかけることになります。

要件	選択の目安
書き込み直後に更新済みの値が必要	テーブルまたはLSIへの強い整合性読み込みを検討する
古い値が短時間返る可能性を許容できる	標準の結果整合性読み込みを使う
GSIを使って検索し、書き込み直後の最新値を必要とする	GSIでは強い整合性を指定できないため、キー設計や読み取りフローを見直す
最新性が必要な読み取りと不要な読み取りが混在する	要求ごとに整合性を選び、キャパシティと応答時間を評価する

RCUやオンデマンドの読み取りリクエストユニットの計算はAmazon DynamoDBのキャパシティモードと読み書き性能を参照してください。DynamoDB Accelerator（DAX）を使う場合も、強い整合性読み取りはDAXのキャッシュから返さず、DynamoDBへ送られます。DAXのキャッシュ動作と整合性要件を合わせて考えます。

単一リージョンの整合性とグローバルテーブル

ここで扱った ConsistentRead は、テーブルやインデックスへの各読み取り要求に対する指定です。グローバルテーブルでは別途、リージョン間の複製方式と整合性モードを考慮します。単一リージョンの強い整合性読み込みを設定したことだけで、異なるリージョンにあるレプリカ間の即時反映まで保証されるわけではありません。

グローバルテーブルのマルチリージョン結果整合性（MREC）とマルチリージョン強整合性（MRSC）は、対応リージョンや構成、書き込み・読み込みの振る舞いが異なります。リージョン間の更新可視性を要件にする場合は、テーブルの整合性モードとサポート条件を個別に確認します。詳しくはAmazon DynamoDBグローバルテーブルを参照してください。

試験で押さえるポイント

• 結果整合性読み込みは標準の読み取り方式であり、直前の書き込みが一時的に見えないことがある。
• 強い整合性読み込みは、読み取り開始前に完了した書き込みを反映した最新値を返す。反映を待つ間のエラーを前提にしない。
• 強い整合性読み込みはテーブルとLSIで使えるが、GSIでは使えない。
• 同じ読み込みサイズなら強い整合性のほうが多くの読み込みキャパシティを消費し、レイテンシーも増える場合がある。
• 強い整合性読み込みは、複数アイテムの読み取り全体を一つの時点に固定する仕組みではない。
• グローバルテーブルのリージョン間整合性は、各リクエストの ConsistentRead と分けて考える。

AWS公式ドキュメント

• Amazon DynamoDBの読み取り整合性
• DynamoDBでの読み取りおよび書き込み操作
• Amazon DynamoDBの読み取りおよび書き込みキャパシティユニットの計算
• DynamoDBグローバルテーブルの整合性モード