Cloud DatastoreのTTL(プレビュー)を試してみたのでご紹介したいと思います。
TTL(Time To Live)はざっくり言うと有効期限(TTL)ポリシーを設定することで有効期限が過ぎたエンティティをGCP側で自動で削除してくれる機能になります。
自分が担当しているプロジェクトでCloud Datastoreを導入してそろそろ一年になり古いデータの削除を検討していたのでとても有難くGAが楽しみな機能です。
実際有効期限をテストしてどんな挙動になったか以下に説明します。
先に公式ドキュメントをご覧になりたい方はこちら
1. テスト用エンティティを作成
「ttl_test」という種類を用意し一つのエンティティを作成しました。プロパティは2つ用意し、それぞれname(文字列)、created_at(タイムスタンプ)としました。
created_atには作成日時を入れています。
後にこの「created_at」をポリシーで指定するのですが指定したタイムスタンププロパティの日時を過ぎたデータが削除対象となりますので実際の運用では「deleted_at」のようなプロパティを用意してあげて未来の日時を設定してあげる形になるかと思います。
2. TTLのポリシーの作成
対応するTTLポリシーを作成します。種類(ttl_test)を選択しタイムスタンププロパティを「created_at」にしました。
TTL プロパティは、インデックス付きにすることも、インデックスなしにすることもできるようです。
ただ、タイムスタンプのプロパティはインデックス対象にするとホットスポットが発生する可能性があるためTTLポリシーのためだけ(検索条件としては必要ない)プロパティならインデックスなしにする方が良いかと思います。
タイムスタンププロパティについてのベストプラクティスについては以前のブログで紹介したのでそちらもよかったら読んでみてください。
また、これはあとで気がついたのですが、設定画面の画像を見ますと「有効期限が切れた後72時間以内に削除されます。」と明確に書いてありました。即時削除ではないのでその前提での運用に適しているようです。
3. ポリシー作成中
ステータスがビルディングになりました。
4. モニタリング用ダッシュボードの作成
ポリシーが作成されている間に削除の状況をモニタリングするためにダッシュボードを作成しておきます。Metrics Explorerから指標に「TTL delettion count」と「TTL expiration to deletion delays」を選んでダッシュボードを作成しておきます。 それぞれ以下のような定義になります。
- 「TTL delettion count」→ TTL ポリシーによって削除されたエンティティの合計数。
- 「TTL expiration to deletion delays」→ TTL ポリシーでエンティティが期限切れになってから、実際に削除されるまでの経過時間。
5. TTLポリシー作成完了
TTLポリシーの作成が完了しステータスがサービス提供中になりました。数分かかりました。
6. データ削除の確認
データの削除が確認できたのはおよそ24時間が経ってからでした。 エンティティの一覧からデータが消えているのが分かります。
まとめ
以下まとめになります。- タイムスタンプのプロパティをTTLの有効期限として設定できる。
- インデックスなしのタイムスタンプでOK。(タイムスタンプなのでインデックスない方が良い)
- 期限が切れたエンティティは72時間以内に削除される。
- 今回テストで削除が確認できたのはおよそ24時間後。
- Metrics Explorerから削除された数と削除までの時間がモニタリングできる。
不要データ削除時に便利に使えそうです。
- TTL による削除は短時間のプロセスではありません。
- 既存の種類に TTL ポリシーを適用すると、新しい TTL ポリシーに従って期限切れとなった、すべてのデータが一括削除されます。
- TTL では、有効期限のタイムスタンプと同じ順序でエンティティが削除されるとは限りません。この一括削除もまた、短時間のプロセスではありません。
- 削除はトランザクション的に行われるわけではありません。有効期限が同じエンティティが同時に削除されるとは限りません。この動作が必要な場合は、クライアント ライブラリを使用して削除を行います。
- TTL は他のデータベース アクティビティへの影響を最小限にするように設計されています。TTL による削除は、それよりも低い優先度で処理されます。また、TTL による削除が原因のトラフィックの急増を抑制するための戦略も実施されています。
以上となります。
ありがとうございました。
