先日、ついに DynamoDB に TTL が実装されました。

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について|Amazon Web Services ブログ

仕事では Rails4 のセッションストアに ElastiCache for Redis を使っ
ているのですが、[2016-10-24-1] に書いたとおり、スケールが辛いです。

作業自体もそうですし、ElastiCache for Redis はスケールアップのみで
スケールアウトが出来ません。CPU パワーじゃなくてストレージが欲しい
のじゃ…。

DynamoDB はインスタンスの管理が不要なため、もし移行出来たらとって
もうれしいです。お値段も ElastiCache よりずっと安そうです。

https://aws.amazon.com/jp/dynamodb/pricing/

いろんな期待を込めて、ちょっと触ってみました。

準備

こちらの記事を参考にして、Rails4 のセッションストアを DynamoDB に
します。

Rails4 でセッションストアに DynamoDB を使う | Developers.IO

2013年11月05日と古めの記事ですが、現在も動くことを確認しました。
当時はまだ TTL が実装されていないので、

$ bundle exec rake db:sessions:cleanup
で期限切れのデータを削除する方式です。

なぜか migration ファイルに拡張子 .rb が付かず、db:migrate で
DynamoDB のテーブルが作られませんでした。適当にリネームして下さい。

DynamoDB に expired_at を追加

DynamoDB で expired_at フィールドを追加する修正をしてみました。
動けば良いレベルです。

https://github.com/aws/aws-sessionstore-dynamodb-ruby/compare/master...masutaka:expired_at?expand=1

こいつを元の gem の代わりに指定します。

gem 'aws-sessionstore-dynamodb'
↓
gem 'aws-sessionstore-dynamodb', github: 'masutaka/aws-sessionstore-dynamodb-ruby', branch: 'expired_at'

すでに config/sessionstore/dynamodb.yml が作られていると思うので、
max_stale を設定します。今回は動作確認のため 60 にしました。単位は
秒です。

max_stale: 60

すでに DynamoDB に sessions Table が出来ていると思うので、今回追加
した expired_at フィールドに TTL を設定します。

DynamoDB TTL

あとは Rails を動かしてログインとかすれば、expired_at 付きのセッショ
ンが作られていると思います。

DynamoDB Item

このアイテムは expired_at から 30 分程度で削除されました。

TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、
DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自
動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込
みトラフィックには影響しません。

初めの AWS のブログに書かれているように、expired_at ピッタリで削除
されるわけではないようです。この辺は Redis も似た動作だったような。
いずれにせよ、セッションストアとしては十分な動作だと思います。

心配なこと

  • aws-sessionstore-dynamodb gem の aws-sdk は v1 です。
    v2 にしたいとは思っているようです。

  • そもそも DynamoDB をセッションストアにして、本当に大丈夫かな?
    速度面、コスト面など、調べる必要があります。

  • 開発環境はどうしようか。開発者ごとに DynamoDB の Table を作れば
    良いかもしれません。工夫が必要そう。

追記(2017-03-03):
DynamoDB のダウンロード可能バージョン を教えてもらいました。開発環
境はこれを使えば良さそうです。