Cloud SpannerのTTL（Time To Live）：ガベージコレクションの深淵と物理ストレージの最適化
Cloud SpannerにおけるTTL（Time To Live）機能の実装は、単なる「行の自動削除」という機能的要件を超えた、分散データベースエンジンにおける「非同期ストレージ再利用」のマスターピースである。
多くのエンジニアがTTLを「期限が来たら消える魔法」と捉えるが、アーキテクトの視点で見れば、これはColossus上のSSTableライフサイクル管理と、分散トランザクションのMVCC（多版同時実行制御）の整合性をいかに低負荷で維持するかという極めて高度なエンジニアリングの結実だ。
本稿では、TTLの内部メカニズムを解剖し、大規模トラフィック下でなぜこれが「安全」なのかを論じる。
—
1. TTLのアーキテクチャ：削除は「イベント」ではない
従来のRDBMSであれば、`DELETE`文の発行はトランザクションのオーバーヘッドを生み、ロックの競合、そしてundo/redoログの肥大化を招く。しかし、SpannerのTTLは異なる。
SpannerのTTLは、行レベルのメタデータとして `expiration_timestamp` を保持する。重要なのは、「期限が来た瞬間に削除処理が走るわけではない」という点だ。
バックグラウンド・ガベージコレクション（GC）
TTLによって削除対象となった行は、即座に物理領域から抹消されるのではなく、Spannerの内部GCプロセスによって「墓石（Tombstone）」がマークされ、後のバックグラウンドプロセスでコンパクション（圧縮）と統合される。
- LSMツリーとの親和性: Spannerは内部的にLSM（Log-Structured Merge-tree）に近い構造を持つ。TTLによる行の廃止は、SSTableの階層における「無効化」として扱われ、次回のメジャーコンパクションのタイミングで物理的に除去される。
- 負荷の平滑化: この仕組みにより、削除処理がフロントエンドのクエリレイテンシに干渉することを防いでいる。つまり、TTLは「削除のための負荷」を、システムが最も効率的に処理できるタイミングまで遅延させているのである。
—
2. パフォーマンスへの影響とメモリ最適化
熟練のアーキテクトが懸念するのは、TTL設定によるスキャン効率の低下だ。
— TTL設定の例
ALTER TABLE Events
SET ON DELETE SET SPANNER_COMMIT_TIMESTAMP(ts) + INTERVAL 30 DAY;
この設定を行うと、クエリエンジンは実行計画の生成時に `expiration_timestamp` を考慮したプルーニングを行う。ここで重要な知見は、「TTL列はインデックスの一部として扱われるのが最も効率的」ということだ。
もしTTLの期限切れ判定が頻繁に発生するクエリを叩くのであれば、インデックス戦略を以下のように最適化すべきである。
— インデックスでのプルーニング効率化
CREATE INDEX EventsByTimestamp ON Events(ts DESC) STORING (metadata);
Spannerのクエリエンジンは、統計情報に基づいて「期限切れの行」をインデックススキャンから自動的に除外する。これにより、メモリ上のブロックキャッシュに期限切れの古いレコードが乗り続けることを防ぎ、キャッシュヒット率を物理的に最大化できる。
—
3. 分散トランザクションとの整合性：TrueTimeの役割
TTLが極めて強力なのは、分散システムでありながら「整合性を保ったまま削除」できる点にある。
SpannerのMVCCでは、各行はタイムスタンプを持つ。TTLによる行削除もまた、ある特定のタイムスタンプにおいて「存在しない」と定義される。TrueTimeの精度（信頼区間 $\epsilon$）のおかげで、グローバルに分散されたノード群が、どの行がTTLを過ぎているかという事実について、一切の通信オーバーヘッドなしに合意できる。
これが他のNoSQLデータベースにおける「TTLの実装」と一線を画す部分だ。 多くのNoSQLでは、読み取り時に期限判定を行うため、読み取りレイテンシにペナルティが発生する。Spannerは、読み取りパスにおいて「有効か無効か」を低レイテンシで判断し、バックグラウンドで物理削除を進める。この分業こそが、高可用性と低レイテンシを両立させる秘訣である。
—
4. アーキテクトへの提言：運用上の落とし穴
どれほど優れたメカニズムでも、使い方は重要だ。
1. コンパクション遅延を考慮する: TTL設定後、即座にストレージ使用量が減るわけではない。物理的なディスク解放には、コンパクションの実行サイクルという時間軸が存在する。急激なデータ増加に対し、TTLだけでストレージコストを制御しようとすると、スパイク時のバーストに耐えられない可能性がある。
2. インデックスの肥大化に注意: TTLを適用しているテーブルにインデックスを張りすぎると、インデックス側にもTombstoneが蓄積する。インデックスのメンテナンスコストが書き込みスループットを圧迫していないか、`spanner.googleapis.com/instance/cpu/utilization` を注視すること。
3. データ監査との兼ね合い: TTLで消えた行は、当然ながら `STALE READ` であっても取得できない。削除前後のデータ整合性や監査ログが必要な場合は、TTLとは別にCloud Storageへのエクスポート（Dataflowジョブ）を設計するのが定石である。
—
結論
Cloud SpannerのTTLは、単なる「便利な機能」ではない。それは、複雑な分散ストレージ層の裏側で、システムの整合性を損なうことなく、いかにしてストレージ効率を最大化させるかという、分散データベースエンジニアリングの回答そのものである。
この機能を使いこなすということは、Spannerのバックグラウンドプロセスを理解し、クエリエンジンが物理データにどうアクセスしているかを深く洞察するということだ。
アーキテクト諸君、TTLを設定して終わりではない。その下のコンパクションの挙動までを設計図に含めて初めて、君たちのシステムは真の「スケールする永続性」を手に入れることができる。
コメント