Amazon DynamoDB Accelerator(DAX)で異なるキーの同名テーブルを再作成する際はテーブル定義キャッシュ(仮)に注意

amazon dynamoDB

こんにちは、CTC の西田です。
今回は、『Amazon DynamoDB Accelerator(DAX)』についてです。このDAXを触っている際に意外な仕様を確認したので、今回はそれを共有します。

想定外の事象が発生するまでの経緯

  • DynamoDBのテーブル作成し、データ投入
  • JavaのSDK(2017/8現在、Java以外はSDK未対応)でDAXへGetItem

→成功

  • DynamoDBテーブル削除
  • 同名テーブルを『異なるキー(ソートキーあり→なし)』で再作成し、データ投入
  • DAXへGetItem

→エラー(このとき、DynamoDBへの直接のGetItemは成功)

→DAXに以前のテーブルのキャッシュ残ってるし、異なるキーでアクセスしたら、DAX側だけがエラーになるのは想定どおり。

ところが…

  • DAXのキャッシュを削除(TTL経過・ノード再起動)
  • DAXへGetItem

→エラー(もちろんDAX側だけ)

→ひょっとして、DAXはテーブル定義をキャッシュとは別に記憶してるのか?

原因

ビンゴだった

DAXには、項目キャッシュやクエリキャッシュとは『別に』テーブル定義キャッシュ(と勝手に命名)が存在する

このテーブル定義キャッシュは、TTLの影響を受けないし、ノード再起動しても消えない(インメモリキャッシュですらないのかも?)

対策

テーブル定義キャッシュは、『テーブルを削除後、(同名テーブルは作成せず)30分以上待つ』と自動で消える(AWSサポート確認済)

カッコにある通り、削除した後にすぐに新しいテーブルを先に作ってしまうと、30分待っても駄目だったので注意

要は、現状『能動的にテーブル定義キャッシュは消せない』ということ

運営は現状を認識しており、何らかの形で能動的に削除できるような仕組みを検討している模様

注意

同名かつ同じキー構成でテーブルを再作成する場合にはこのエラーは発生しない

エラーが発生するのは、同名かつ異なるキー構成でテーブルを再作成する場合のみ!

(誤解なきように一応)

 

西田 信輝
クラウド技術検証や業務改善アプリ開発を行うソフトウェアエンジニア
2016年より、AWS関連の業務に従事
AWS Certified DevOps Professional取得
お問い合わせ:business-on-it@ctc-g.co.jp

Pocket

コメント