Cloud Spannerの心臓部：バックアップとリストアの「SSTableダイレクトアクセス」という深淵
エンジニア諸君。Cloud Spannerを単なる「SQLが使える分散DB」と捉えているなら、その認識は今日で捨ててほしい。
Spannerの真髄は、Googleが誇る分散ファイルシステム「Colossus」との蜜月関係にある。特に、多くのエンジニアが「魔法のように速い」と感じているバックアップとリストアの裏側には、単なるデータのコピーを超えた、極めて巧妙なSSTable（Sorted String Table）のハンドリングが存在する。
今日は、Spannerのバックアップがなぜ極めて軽量でありながら強固なのか、そのアーキテクチャの核心を解き明かそう。
—
1. SSTableという「不変性」の恩恵
Spannerのデータは、Colossus上にSSTableとして格納されている。SSTableは「一度書き込まれたら変更されない（Immutable）」という鉄則がある。
この不変性が、バックアップにおける最大の武器となる。
- 物理コピーの回避: バックアップ時、Spannerはデータベースの現時点のSSTableファイルを物理的に別の場所にコピーするのではなく、Colossusのメタデータを介して「参照（Reference）」を保持する。
- Copy-on-Writeの系譜: データが更新されても、既存のSSTableは壊されない。新しいデータは新しいSSTableに書き込まれる。バックアップは、特定のタイムスタンプ時点でのSSTableのツリー構造をスナップショットとして切り取るだけで完了する。
2. 増分バックアップの正体：メタデータのグラフ構造
エンジニアからよく受ける質問がこれだ。「増分バックアップはどうなっているのか？ 差分データだけをどうやって特定するのか？」
答えは、「SSTableの参照カウントとマニフェスト管理」にある。
Spannerのバックアップ処理は、以下のステップで進む。
1. マニフェストの凍結: 特定のタイムスタンプ時点における、全てのSSTableの参照リストを確定させる。
2. 参照カウントのインクリメント: Colossus上で、バックアップ対象となるSSTableファイルの参照カウントを上げる。これにより、ガベージコレクション（GC）が走っても、そのファイルは物理的に削除されなくなる。
3. メタデータの永続化: どのキー範囲が、どのSSTableに対応しているかという「メタデータ構造」を別途安全な領域（バックアップメタデータ）として保存する。
つまり、増分バックアップが効率的なのは、「過去のバックアップと共通するSSTableは、物理的に二重保存されないから」だ。ストレージの消費は「差分」のみに最適化される。
3. リストアの「魔法」：メタデータの再構成
リストア時、Spannerは何をしているか。実は、ここが最もエキサイティングな部分だ。
リストア命令が出されると、Spannerは以下のプロセスを高速で実行する。
1. メタデータの再読み込み: 保存されたマニフェストを参照し、どのSSTableを読み込むべきかという「地図」を再構築する。
2. 論理スライスの割り当て: 新しいデータベースインスタンスに対し、Colossus上のSSTableをマッピングする。
3. Ready-to-Serve: 全てのデータをコピーし終えるのを待つ必要はない。メタデータが再構成された時点で、SpannerのクエリレイヤーはSSTableに直接アクセス可能になる。
この「オンデマンド・データロード」により、大規模データベースであっても、メタデータのロードが完了すれば、データの実体はバックグラウンドでColossusからストリーミングされながら、クエリに応答できるようになる。これが、リストアが驚異的に速い理由だ。
—
実務上の設計パターンと注意点
アーキテクチャを理解した上で、我々が設計時に意識すべき「プロの作法」を3つ授けよう。
① バックアップ保持期間とストレージコスト
SSTableを共有している以上、古いバックアップを放置することは、Colossus上の古いSSTableファイルを「GCから守り続ける」ことを意味する。
- 設計指針: 不要なバックアップは即座に削除せよ。Spannerのバックアップ削除は、単にColossus上の参照カウントをデクリメントするだけの軽量な処理だ。
② 整合性確認の自動化
バックアップは「保険」だが、保険が有効かどうかを確認せずに設計を終えてはならない。
- 設計指針: リストアの自動テストパイプラインを組め。
— 定期的に検証用インスタンスへリストアする設計（Terraform/gcloudでのCI例）
gcloud spanner backups restore BACKUP_ID \
–destination-instance=VALIDATION_INSTANCE \
–destination-database=VALIDATION_DB
リストアにかかる時間を計測し、RTO（目標復旧時間）を満たしているか定期的に検証するのが、リードエンジニアとしての責務だ。
③ 読み取り専用レプリカとの併用
バックアップからのリストア中に発生するI/O負荷は、本番のクエリパフォーマンスに影響を与える可能性がある（特に共有リソースであるColossusの帯域）。
- 注意点: 大規模なリストアを行う際は、あらかじめインスタンスのノード数を一時的に増やす、あるいはオートスケーラーの設定を見直しておくのが、実務における安全策である。
—
結びに
Cloud Spannerのバックアップは、単なるバックアップ機能ではない。それはColossusという巨大な分散ファイルシステムを、Spannerというデータベースがどのように「論理的に支配しているか」を示す鏡だ。
このメカニズムを理解していれば、災害復旧の設計も、ストレージコストの最適化も、自信を持って意思決定できるようになるはずだ。
次は、クエリ実行計画の深淵に潜るか、それともトランザクションの直列化可能性の限界について語り合おうか。諸君の設計レビューを待っている。
コメント