Spannerのバックアップと復元：分散トランザクションの「時間」をどう凍結するか
Cloud Spannerを単なる「マネージドなリレーショナルDB」と呼ぶ者は、その真髄を見誤っている。Spannerは、TrueTimeという物理的な時計の不確実性をAPIとして抽象化し、分散環境において「線形化可能性（Linearizability）」を保証する巨大なステートマシンだ。
このアーキテクチャにおいて、バックアップと復元を語ることは、単なるストレージのコピーではない。「グローバルに一貫した特定のミリ秒を、いかに凍結し、再起動するか」という高度な分散システム工学の話である。
—
1. バックアップの深層：SSTableとLSMツリーの「スナップショット」
Spannerのバックアップは、従来のRDBMSのような「ダンプファイル」を生成するような原始的な手段ではない。Spannerのストレージ層は、GoogleのColossus上で動作するログ構造化マージツリー（LSMツリー）ベースのSSTableで構成されている。
バックアップを実行した瞬間、Spannerは何を行っているのか？
- メタデータの凍結: 特定のタイムスタンプ（Commit Timestamp）におけるトランザクションログのポイントをマーキングする。
- 物理レイヤの共有: Colossus上のSSTableファイルはイミュータブル（不変）である。バックアップは、その時点のSSTableに対する「参照カウントを保持する」のと同義だ。ゆえに、数TBのDBであっても、バックアップ処理自体は即座に完了する。ストレージの物理的なコピーが発生しないからだ。
アーキテクトへの教訓: バックアップサイズが課金対象となるが、それは実データ量というよりも、バックアップ取得時点から削除されたSSTableの断片の積み上げに依存する。頻繁な更新（Compactionを誘発する）は、バックアップコストを最適化する観点からも注意深く監視せよ。
—
2. PITR（Point-in-Time Recovery）の真実：TrueTimeとの共生
PITRは、Spannerの分散トランザクションエンジンが持つ「バージョン管理メカニズム」を最大限に利用している。
— 特定の時刻（マイクロ秒単位）を指定した読み取り
— Spannerは内部的にTrueTimeを利用し、指定時刻の読み取り一貫性を保証する
SELECT FROM Users@{FORCE_INDEX=idx_users_id, VERSION_TIMESTAMPS=true}
AS OF SYSTEM TIME ‘2023-10-27T10:00:00Z’;
PITRは、バックアップという「点」とは異なり、「連続したログの履歴」を一定期間保持する機能だ。ここで重要なのは、「PITRの保持期間が長ければ長いほど、ストレージのCompactionが抑制される」という内部メカニズムである。
- 内部の競合: 通常、Spannerのバックアッププロセスは、不要になった古いバージョンのデータをCompactionによって排除する。しかし、PITRが有効な場合、その期間内は「古いバージョンを消すわけにはいかない」ため、ストレージ使用量は増大する。
- 設計の解: 不要なほど長いPITR設定は、単なるストレージコストの増大ではない。バックグラウンドのCompaction処理に負荷を与え、結果として読み取りパフォーマンスの安定性に微細な揺らぎを生む可能性がある。
—
3. 復元（Restore）における「分散ステート」の再構築
バックアップから復元を行う際、Spannerは単にデータを書き戻すのではない。
1. スプリットの再構成: 復元されたDBは、元のDBのキー範囲（Split）を継承する。しかし、復元先のノード構成が元のDBと異なる場合、Spannerは動的にデータを再配置（Rebalancing）する。
2. メタデータの更新: 各Splitのリーダー選出（Paxos Groupの再構築）が行われる。ここが復元処理において最もレイテンシが発生する箇所だ。
極限の運用テクニック:
大規模な復元を行う際、ノード数を最初から適正値（あるいはそれ以上）にスケールさせておくこと。復元処理の並列度はPaxos Groupの数に比例する。復元直後に「ノードを増やす」というオペレーションは、データ再配置とノード追加の負荷が重なり、復元完了時間を劇的に遅延させる。
—
4. ライフサイクル管理：エンジニアが守るべき鉄則
バックアップを自動化する際は、以下の「設計のアンチパターン」を避けよ。
- アンチパターン1：バックアップ頻度の過剰設定
- 前述の通り、ストレージのイミュータブルな特性上、頻繁なバックアップは不要なメタデータ維持コストを生む。RPO（目標復旧時点）をTrueTimeの精度に合わせて再定義せよ。
- アンチパターン2：復元テストの形骸化
- Spannerの復元は「論理的な一貫性」を保証するが、アプリケーション層のスキーマ変更と復元データの不整合を防ぐことはできない。CI/CDパイプラインに「復元後のスキーマ検証」を組み込むのは、現代のDBアーキテクトの最低限の教養だ。
結びに代えて
Spannerのバックアップと復元は、単なるストレージの保護ではない。それは、「時間軸を操作可能な分散データベース」における、過去へのタイムトラベルの許可証である。
「バックアップを取ったから安心」という言葉は、Spannerの世界では通用しない。そのバックアップが、現在のPaxos Groupのトポロジーとどう整合するのか、復元時にどの程度のスループットが要求されるのか。それら全てを設計に組み込める者だけが、この巨大な分散システムを真に御することができる。
次回の運用時には、ぜひ `gcloud spanner backups list` を打つ前に、その背後でうごめくColossusのSSTableと、TrueTimeが刻む一貫性の重みに思いを馳せてほしい。
コメント