DynamoDBのストレージをTTLでS3にバックアップ作りながら削減する
DynamoDBにデータが溜まってくると月額$0.285USD/GBでストレージコストもかかってきて無視はできなくなってくる。特に時系列データなんかを扱っているとうまいことGSIなんかを使いつつ、PKの振り分けをしておかないとパーティションの偏りも発生してくる。(まだ未確認ではあるのだが、ストレージ削減できれば時系列データの場合に起こってくるパーティションの偏りも多少は改善する?時系列データでSortKeyにtimestampとか使ってるとPKの増加よりSKの増加でストレージ増えていきがちで、さらに読み書きは直近のデータに対して行うことが多い)
(追記: ストレージの削減が確実にパーティションの偏りを一定水準に収めるとまでは言い切れなさそうです)
とはいうもののDeleteItemをしつつバックアップを取ってるとそこのWriteCapacityもネックになってくる。
そこでTTLでDDBの機能としてデータを削除しつつ(一項目のUpdateなのでWriteCapacityもかなり抑えられる)、DynamoDB Streams経由でLambdaで拾ってFirehoseでバッファリングしてS3に復元可能な形で保存する、というのを作ってみた。
S3には以下みたいなJSONシリアライズされたものが改行されて入っている。復元を考えたときにはDynamoDBの型も入ってるほうが良いかなと思い。。
{"ID":{"S":"1111"},"ExpiredAt":{"N":"1553355676"},"Timestamp":{"N":"8"}}
{"ID":{"S":"1111"},"ExpiredAt":{"N":"1553355729"},"Timestamp":{"N":"10"}}
{"ID":{"S":"1111"},"ExpiredAt":{"N":"1553355756"},"Timestamp":{"N":"9"}}
今後のTODOとして
- サンプルのterraform作成
- S3のprefix指定で復元する
ようなものもレポジトリに含めておこうかなと
補足
ちなみにDynamoDBとBackupのマネージドサービスの連携としてはバックアップの作成はするが、ストレージは減らない。ただバックアップ取りたいときはそちらを使うほうが良いです
この記事が気に入ったらサポートをしてみませんか?