Cloud SpannerのTTL（Time To Live）という「諸刃の剣」を正しく使いこなすための設計哲学
エンジニア諸君、設計レビューお疲れ様。今回は「Cloud SpannerのTTL（Time To Live）」についてだ。
「古いデータを自動で消してくれるなら、運用負荷が下がってハッピー」——そう短絡的に考えているなら、一度立ち止まってほしい。Cloud SpannerのTTLは、ただの「自動削除機能」ではない。これは、分散データベースの整合性とパフォーマンスのバランスを、物理的な期限で強制的にコントロールする高度な仕組みだ。
今回は、この機能を単なる「お掃除」として終わらせず、システム全体の堅牢性を担保するための設計指針を授ける。
—
1. TTLのメカニズム：バックグラウンドで何が起きているか
TTLを有効にすると、Spannerは行単位で「削除期限」を追跡し、バックグラウンドのプロセスで該当行を物理削除する。ここで重要なのは、「削除処理がリソース（CPU/IO）を消費する」という事実だ。
- 非同期処理の代償: 削除は直ちに実行されるわけではない。ストレージ層でガベージコレクション（GC）が走るため、削除が集中すれば当然、当該ノードの負荷は跳ね上がる。
- ストレージの解放: 削除されたからといって、即座にノードのストレージ使用率が下がるわけではない。Spannerのマルチバージョン並行制御（MVCC）の特性を理解していれば分かる通り、古いタイムスタンプのデータが保持されている間は物理容量を占有し続ける。
2. 実践的設計パターン：TTLを「正しく」設定せよ
TTLを設定する際、以下の3点を徹底してくれ。
① 分割キー（Primary Key）との整合性
TTLの有効期限は、`ROW_DELETION_POLICY`としてテーブル定義に記述する。
— テーブル作成時のTTL設定例
CREATE TABLE AccessLogs (
LogId INT64 NOT NULL,
Timestamp TIMESTAMP NOT NULL,
Payload STRING(MAX),
) PRIMARY KEY (LogId)
TTL INTERVAL 30 DAY ON (Timestamp); — 30日経過した行を自動削除
教訓: `ON (Timestamp)` に指定するカラムは、可能な限り「データ生成時に決定し、更新されないカラム」を選ぶこと。更新頻度が高いカラムをTTLの起点にすると、メタデータの更新負荷が削除処理と競合し、パフォーマンスのボトルネックになる。
② 削除頻度のチューニング
大量のデータが一気に期限を迎える設計は避けるべきだ。「毎月1日に1億行消える」ような設定は、スパイクを引き起こす。可能な限り「データの生成時刻」に基づくTTLを設定し、削除処理が時間的に平滑化されるように設計せよ。
③ 過去読み取り（Staleness Read）への影響
Spannerの真骨頂である「過去の特定の時点を読み取る（Staleness Read）」機能とTTLは密接に関係している。TTLを短くしすぎると、分析クエリやバッチ処理で「必要な過去のデータ」を参照できなくなる。「TTLの保持期間 ＞ ビジネス上の参照可能期間」という不等式は、絶対的な設計ルールだ。
—
3. パフォーマンス上の注意点：レビューでここを突け
私がレビューで必ず確認するポイントを共有する。
- セカンダリインデックスの断片化:
TTLで主キー行が削除されても、セカンダリインデックスの削除も自動で行われる。しかし、インデックスが大量にあるテーブルで頻繁にTTL削除が発生すると、インデックスの「インデックス更新（削除）」が多発し、書き込みスループットを食いつぶす。
- 対策: インデックスは必要最小限に。TTL対象テーブルにインデックスを貼る際は、その維持コストを許容できるか再計算すること。
- 削除レートの監視:
Cloud Monitoringの「Spanner Storage」メトリクスを注視しろ。TTLによる削除が追いついているか、ノードのCPU負荷と相関関係を可視化しておく必要がある。もし「削除が追いつかない」というアラートが出たら、それはTTLの設計ミスではなく、キャパシティプランニングの失敗だ。
—
4. 最後に：アーキテクトとしての提言
「TTLがあるからデータ削除の実装が不要になった」と考えるのはジュニアレベルの思考だ。シニアエンジニアはこう考える。
「TTLはあくまで『最後の砦』であり、基本はアプリケーション層での論理削除か、あるいは生存期間を考慮したテーブル分割（Partitioning）を行うべきではないか？」
例えば、日次や週次で物理テーブルを切り替える運用の方が、TTLによる削除負荷を制御しやすく、またDrop Tableによる即時解放ができる場合もある。TTLは非常に強力だが、その「見えない負荷」を制御できて初めて、君たちは真のSpannerマスターと言える。
さあ、コードを開いてくれ。君たちの設計が、この「制御された負荷」を正しく扱えているか、今一度確認しよう。質問があればいつでも聞くぞ。
コメント