← AWSサービスの内部原理 コース
13. DynamoDB Streamsは変更のログである — CDCという発想
DynamoDB Streamsは「テーブルへの全変更を時系列ログとして外へ流す」機能です。CDCという1つの発想が、順序保証からLambdaトリガーまでを支える流れを図で追いましょう。
① 変更を「ログ」として外へ流す — CDCという発想
アプリケーション作成・更新・削除
変更1件 = レコード1件を末尾に追記
DynamoDBテーブル
DynamoDB Streams時系列順のログ
保持は最大24時間- 24時間より古いレコードは自動的にトリミング(削除)される
- WALと同じ「ログ」というデータ構造だが目的が違う: WALは復旧のため、Streamsは変更を他所へ伝えるため
テーブルへの変更1件が、そのままストリームレコード1件としてログの末尾に追記されます。この「変更をログとして外へ流す」発想がCDC(Change Data Capture)です。
② 2つの保証 — 「ちょうど1回」と「同一アイテム内の順序」
価格をAに更新同一アイテム
価格をBに更新同一アイテム
異なるアイテム間の全体順序は保証されない
アイテムX の変更
アイテムY の変更
- 各ストリームレコードはストリームの中にちょうど1回だけ現れる
- PutItem/UpdateItemでも実際に1バイトも変わらなければレコードは書かれない(差分が起きたときだけ追記)
同じアイテムへの変更は起きた順にログへ並ぶので、消費側は「A→B」の更新を取り違えません。ただし順序保証は同一アイテムの中だけで、異なるアイテム間の全体順序は保証されません。
③ StreamViewType — レコードに何を載せるか、4つから選ぶ
KEYS_ONLYキー属性だけ
NEW_IMAGE変更後の全体像
OLD_IMAGE変更前の全体像
NEW_AND_OLD_IMAGES変更前後の両方
- ストリーム作成時に指定し、後から変更できない
- 変更したい場合: 既存ストリームを無効化 → 新しいストリームを作り直す
キーだけで足りるのか、差分計算のために変更前後の像が要るのかで選びます。一度設定したら後から変更できず、変えるには既存ストリームを無効化して作り直しです。
④ シャード分裂と親子リネージ — 順序とスケールの両立
親シャードストリームレコードの箱
親を処理し終えてから子へ進む(親→子の順)
子シャード 1
子シャード 2
消費側(コンシューマー)正しい順序で処理できる
- ログは内部的に単一の連なりではなくシャード単位で格納される
- DynamoDB Streams Kinesisアダプターを使えば、新旧シャードの出現・期限切れ・分裂の処理も含めて順序を自動で管理してくれる
書き込みが増えるとシャードは子シャードへ自動分裂して並列読み取りに対応します。消費側が「親を処理し終えてから子へ進む」規則を守るから、分裂をまたいでも順序が保たれます。
⑤ 非同期のログが、イベント駆動の共通の土台になる
DynamoDBテーブル通常どおり読み書き(性能影響なし)
同じCDCの発想の上に載る
Streams(変更のログ)CDCの1枚を足しただけ
Lambdaトリガー新規アイテムでコードを自動実行
データレプリケーションリージョン内・間(グローバルテーブルの基盤)
- DynamoDBの中身はSSD・ハッシュ・B木・ログといった基礎の組み合わせ。Streamsはそこに「変更を外へ流すログ」を1枚足しただけ
Streamsは非同期に動くのでテーブル本体の性能に影響せず、変更ログは裏側でニアリアルタイムに流れます。「変更を1本の追記型ログにする」という1つの決断が、Lambdaトリガーもレプリケーションも支える下地です。