← AWSサービスの内部原理 コース
14. TTLは即座に消さない — バックグラウンド削除の設計
DynamoDBのTTLは「期限が来たら即削除」ではなく「暇なときに数日以内で片づける」設計——その理由と、アプリ側が負う責任を図で追います。
① 仕組みは属性1つ — エポック秒をNumber型で書くだけ
アイテムexpiresAt: 1767193200
エポック秒(1970年からの秒数)型で運命が分かれる
DynamoDBのTTL処理属性の値 と 現在時刻 を比較
Number型期限を過ぎたら自動削除の対象
文字列型などTTL処理は単に無視
- 期限は未来でも過去でも指定できる
- ただし5年以上前の値は期限切れ判定の対象外
テーブルのTTL設定で「期限として見る属性」を1つ指定すると、DynamoDBはその値(Unixエポック秒)を現在時刻と比べて自動削除する。型タグ付きの値として保存されるため、Number型でなければTTL処理は単に無視する。
② 削除は即時ではない — 期限後も「見える」期間がある
期限時刻を過ぎるこの瞬間には消えない
バックグラウンド削除プロセスが巡回して順次削除
期限切れ・未削除の期間Query / Scan に普通に返ってくる
ストレージ料金も読み取り料金もカウントされ続ける自動削除書き込みスループットを消費しない
- 公式ドキュメントの明記:「書き込みスループットを消費することなく、期限から数日以内に自動削除」
期限を過ぎた瞬間に消えるのではなく、バックグラウンドの削除プロセスがテーブルを巡回して通常は数日以内に片づける。その間QueryやScanには期限切れアイテムが普通に返ってくる。
③ なぜ遅らせるのか — WCUを守るための設計
もし期限ちょうどに一斉削除したら何百万件の削除が大量のWCUを消費
本来ユーザーのリクエストに使うスループットを奪う同じ原理
ユーザーのWCU枠本番トラフィック専用のまま
別枠のバックグラウンド削除書き込みスループットを消費しない
ガベージコレクションその場で毎回解放せず、まとめて回収してアプリの速度を守る
- 「今すぐやる必要のない仕事は、暇なときにやる」— OSやランタイムに共通する遅延処理の考え方
- 見返り:削除が『期限ちょうど』ではなく『数日以内』になる
削除も原則WCUを消費するため、期限ちょうどに何百万件を一斉削除するとユーザーのスループットを奪ってしまう。だからTTL削除はキャパシティ別枠のバックグラウンド処理として「暇を見つけて」実行される。
④ アプリ側の責任 — FilterExpressionで期限切れを見せない
QueryFilterExpression: "#exp > :now"
:now = 現在のエポック秒返す前にフィルタで落とす
期限切れも含めて読むRCUは読んだ分だけ消費(ここは変わらない)
期限がまだ未来のアイテムだけ返る
- フィルタは料金を節約する仕組みではない
- 期限切れデータを『見せない』ための仕組み
遅延削除を受け入れる代わりに、読み取りに混ざる期限切れアイテムはアプリ側で除外する。フィルタは「返す前に落とす」処理なので、期限切れの読み取り自体は発生しRCUは読んだ分だけ消費される。
⑤ 消えたことの波及 — インデックスは普通、Streamsだけ印付き
TTLによる削除
GSI / LSI通常のDeleteItemとまったく同じに削除
特別扱いなしDynamoDB StreamsuserIdentity.type = "Service"
principalId = "dynamodb.amazonaws.com"- Streamsの印を使えば、TTL削除をトリガーにアーカイブ通知などの後続処理を組める
- まとめ:TTLは『いつ消えるかは保証しないが、消えたことは正しく波及させる』機能。その割り切りの見返りが、ユーザーのスループットを一切奪わない削除
GSI/LSIからは通常のDeleteItemと同じようにアイテムが取り除かれ、期限切れの残骸は残らない。DynamoDB Streamsに流れるときだけ「サービスによる削除」の印が付き、ユーザーの削除と識別できる。