Amazon DynamoDB Streamsとグローバルテーブル

Amazon DynamoDB Streamsは、DynamoDBテーブルのアイテムに起きた変更を、後続処理が読めるイベントとして記録する機能です。アプリケーションでレコードを追加・変更・削除したあと、その事実をLambda関数や別のデータ処理へ渡せます。データベースへの書き込みと後続処理を疎結合にできるため、通知、検索用データの更新、監査向けの処理などを構成できます。

たとえば、オンライン書店で注文アイテムの状態が「受付済み」から「出荷準備中」に変わったとき、変更イベントを受けて配送処理を開始したり、購入者へ通知したりできます。アプリケーションが注文テーブルへの書き込み後に複数の処理を同期的に呼び出す設計と比べ、Streamsを使うと変更を起点に後続処理を非同期で進められます。ただし、ストリームはトランザクションや恒久的なバックアップではありません。処理の失敗、再実行、保持期間を含めて設計します。

DynamoDB Streamsが記録する変更

Streamsを有効にすると、テーブルのアイテムに対する作成、更新、削除が変更レコードとしてストリームへ反映されます。レコードのイベント種別は、アイテムの追加を示す INSERT、変更を示す MODIFY、削除を示す REMOVE です。各レコードには変更の種類や対象キーなどが含まれ、設定に応じて変更前後のアイテム内容も含められます。

Streamsはテーブル単位で有効化し、レコードに含める情報をストリームビューの種類で選びます。

ストリームビュー	各変更レコードに含まれる情報	使い方の考え方
KEYS_ONLY	変更されたアイテムのキー属性	対象アイテムを特定できればよく、イベントのサイズを抑えたい
NEW_IMAGE	変更後のアイテム全体	新しい状態だけを使って通知や派生データを作る
OLD_IMAGE	変更前のアイテム全体	変更前の値を参照する処理が必要
NEW_AND_OLD_IMAGES	変更前と変更後のアイテム全体	変更差分の判定や、前後の状態を使う処理が必要

ストリームビューは、下流処理が必要とするデータに合わせて選びます。キーしか使わない処理に全アイテムを渡す必要はありません。一方、状態遷移を調べる処理では変更前と変更後のイメージが必要になる場合があります。保持する情報量、ペイロードの大きさ、後続処理の要件を合わせて判断します。

Streamsのレコード保持期間は最大24時間です。これは変更履歴を長期間保管する仕組みではありません。コンシューマーが停止している間に24時間を超えたレコードは読み取れなくなるため、長期保存、任意時点への復旧、監査証跡が必要なら、バックアップや別のストリーミング・保管先を組み合わせます。

ストリームを読み取るには、対象ストリームの識別子であるストリームARNを利用します。ストリーム設定を無効化して再度有効化すると、新しいストリーム記述子とARNが発行されるため、イベントソースマッピングなど下流の参照先も確認します。テーブルにStreamsを設定することは、既存データ全体を最初からイベントとして出力することを意味しません。変更が起きてストリームへ記録されたレコードを、利用可能な保持期間内に処理します。

順序の保証範囲

DynamoDB Streamsは、同じアイテムに対する変更の順序を追えるようにレコードを扱います。たとえば、ある注文アイテムの状態が「受付済み」から「支払い確認済み」、続いて「出荷準備中」へ変わったとき、同じアイテムの変更を順番に反映する処理を組み立てられます。

一方で、異なるアイテムの変更をすべて一つの厳密な全体順序に並べる仕組みではありません。異なるアイテムのイベント到着順を業務上の順序として扱わないようにします。下流側で全体の順序が必要な場合は、業務上の連番、時刻、状態遷移の条件などを別途設計します。

イベントの発生順と下流処理の完了順も区別が必要です。複数のシャードで処理が並行すれば、異なるアイテムの処理完了順は前後することがあります。アプリケーションが順序依存の状態更新を行うときは、対象キーごとの処理順や更新条件を明示します。

Lambdaによるイベント駆動処理

Lambda関数をStreamsに接続する場合、イベントソースマッピングがストリームをポーリングし、読み取ったレコードを関数へ渡します。テーブルへの変更を契機に関数が実行されるため、テーブルへ書き込むアプリケーション自身が通知先を直接呼び出す必要がありません。

たとえば、注文アイテムの変更をLambdaで処理し、購入者への通知をAmazon SNSへ送る、または検索用の別テーブルを更新する構成が考えられます。

アプリケーション
    │ PutItem / UpdateItem / DeleteItem
    ▼
DynamoDBテーブル
    │ 変更レコード
    ▼
DynamoDB Streams
    │ イベントソースマッピングが読み取り、バッチで渡す
    ▼
Lambda関数 ──► 通知・検索用データ・後続サービス

イベントソースマッピングはレコードをバッチで関数へ渡します。レコードごとに関数を呼び出す構成とは限らず、バッチの一部でエラーが起きた場合の再試行や、処理済みレコードの再実行も考慮します。障害復旧で同じイベントをもう一度処理しても二重請求や重複通知が起きないよう、イベントIDや業務キーを使った冪等性を設計します。バッチ失敗時の再試行、部分バッチ応答、最大試行回数などは、関数の処理特性とイベントソースマッピングの設定に合わせて選びます。

StreamsとLambdaの組み合わせは非同期連携です。テーブルへの書き込み成功が、すべての後続処理の完了を意味するわけではありません。後続処理の遅延や失敗を監視し、必要であれば再処理、失敗記録、通知を追加します。また、Streamsを読む権限とLambdaの実行ロール、関数から通知先へアクセスする権限は個別に設定します。

グローバルテーブルとStreams

グローバルテーブルは、複数のAWSリージョンにDynamoDBテーブルのレプリカを配置する機能です。利用者に近いリージョンのレプリカへ読み書きさせる構成や、リージョン障害に備えて別リージョンにもデータを維持する構成に使えます。レプリカ間の変更複製にはDynamoDB Streamsが使われます。そのため、Streamsは単独の変更処理だけでなく、グローバルテーブルを成立させる基盤の一部でもあります。

グローバルテーブルを構成すると、レプリカはそれぞれ書き込みを受け付けられます。1つのリージョンを固定プライマリにして他リージョンを読み取り専用にする設計とは異なります。あるリージョンで行われた変更は他のレプリカへ複製されますが、複製の性質は選択した整合性モードによって異なります。

整合性モード	動作の要点	設計時の確認
マルチリージョン結果整合性（MREC）	変更を他のレプリカへ非同期に複製し、各リージョンの更新が収束する	複製遅延があり、同じアイテムに複数リージョンから同時に書き込むと競合が起き得る
マルチリージョン強整合性（MRSC）	対応するリージョン構成では、複数リージョンにまたがる強い整合性を提供する	利用可能なリージョン構成や機能上の制約があるため、採用前に公式要件を確認する

MRECでは、リージョン間の変更反映に遅延があり、短時間はレプリカごとに見える値が異なることがあります。同じアイテムに複数リージョンから競合する更新が行われた場合の解決規則も考慮しなければなりません。グローバルテーブルという名前だけから、すべての読み取りが常時同じ最新値を返すと考えないようにします。MRSCは一部のリージョン構成で選択できるモードですが、MRECと同じ適用条件ではありません。リージョン配置、対応機能、制約をAWSの最新ドキュメントで確認します。

レプリカ間の変更複製は、Streamsをコンシューマーとして読み取ってアプリケーション側で別リージョンへ手動コピーする構成と異なります。グローバルテーブルでは、DynamoDBがレプリカ管理と変更の複製を担います。別の下流システムへの通知やデータ連携が必要なら、各テーブルのストリーム処理を別途設計します。

Streamsと他の仕組みの使い分け

要件	適した仕組み	理由
テーブルの変更を契機にLambdaを実行する	DynamoDB StreamsとLambdaイベントソースマッピング	アイテム変更をイベントとして検出し、非同期の関数処理につなげられる
複数リージョンにDynamoDBレプリカを持ち、リージョン間で更新を複製する	DynamoDBグローバルテーブル	レプリカと変更複製をDynamoDBの機能として管理する
誤操作や削除の前のデータへ復元する	オンデマンドバックアップやポイントインタイムリカバリ	Streamsは24時間の変更処理用であり、復旧用バックアップではない
変更を24時間より長く保管・再生する	要件に合うストリーミングサービスや永続ストレージとの連携	Streams単体のレコード保持期間には上限がある
変更イベントを検索用データなどへ反映する	Streamsコンシューマーと冪等な投影処理	更新を契機に派生データを非同期で作れる

ストリームレコードの保持期間とバックアップ期間は別の性質です。Streamsは近リアルタイムの変更処理へ使い、復旧要件や監査要件には、それぞれ対応するバックアップ、エクスポート、ログ保管を選びます。

試験で押さえるポイント

• 変更データキャプチャが必要で、DynamoDBの追加・更新・削除をLambdaへ渡したい場合は、DynamoDB StreamsとLambdaのイベントソースマッピングを考える。
• ストリームビューの KEYS_ONLY、NEW_IMAGE、OLD_IMAGE、NEW_AND_OLD_IMAGES は、後続処理に必要な変更前後の情報に合わせて選ぶ。
• Streamsのレコードは最大24時間保持される。長期保管やバックアップの要件をStreamsだけで満たそうとしない。
• 同じアイテムの変更順と、全アイテムを通じたグローバルなイベント順序を混同しない。
• Lambdaはバッチ処理し、失敗時の再試行で同じレコードを処理する可能性がある。冪等性と障害監視を設計する。
• グローバルテーブルは複数リージョンに書き込み可能なレプリカを持ち、Streamsを変更複製に使う。MRECとMRSCの整合性やリージョン条件を区別する。
• Streamsは通知・同期処理の入口であり、リージョン間複製やバックアップと同じ機能ではない。

AWS公式ドキュメント

• DynamoDB Streams
• DynamoDB Streamsのストリームレコード
• LambdaでのDynamoDB Streamsイベントソースマッピング
• Lambdaイベントソースマッピングの動作
• DynamoDBグローバルテーブル
• グローバルテーブルの料金

関連トピック

• Amazon DynamoDBの基本とデータモデル
• Amazon DynamoDBのキャパシティモードと読み書き性能
• DynamoDBの整合性・ストリーム・グローバルテーブル・バックアップ（SAA）