【実務・中級編】バックアップと復元 – Cloud Spanner

Cloud Spannerの生存戦略：バックアップとPITRを「保険」で終わらせないための設計哲学

Cloud Spannerを単なる「巨大なRDB」だと思っているなら、今すぐその認識を改めるべきだ。これは、地球規模の分散システムであり、データの一貫性を極限まで保証するモンスターだ。

多くのエンジニアがバックアップとPITR（Point-in-Time Recovery）を「いざという時の保険」と捉えている。だが、真のアーキテクトは違う。「バックアップをどう戦略的に活用し、リカバリ時間をどう最小化するか」という問いこそが、システムの信頼性を決める生命線だ。

今回は、SpannerのバックアップとPITRの深淵に触れ、実務レベルで「落ちない設計」を実現するための勘所を伝授する。

—

1. バックアップとPITRの「本質的な使い分け」

まず、言葉の定義を整理するのではなく、「どう使い捨てるか」という設計思想を共有しよう。

バックアップ（Backup & Restore）
用途： 破滅的なデータ損失（誤ってテーブルをDROPした、アプリケーションのバグで全行更新した等）、長期保存、コンプライアンス要件。
特徴： 独立したインスタンスとして復元できる。コスト効率が高いが、復元にはデータ量に応じた時間がかかる。
PITR (Point-in-Time Recovery)
用途： 直近の軽微な人的ミス、特定のタイムスタンプへの「戻り」。
特徴： 復元が爆速。既存のデータベースに対してバージョンを遡る形でクエリを投げられるため、物理的なコピーが不要。

結論： 「長期生存」にはバックアップ、「直近の過ちの修正」にはPITR。この二刀流こそが、Spanner運用における黄金律だ。

—

2. 実務で直面する「復元時間」の罠

バックアップからの復元は「時間がかかる」。これは物理法則だ。ペタバイト級のデータを復元しようとすれば、それ相応の時間がかかる。

ここで重要なのは、「復元先をどこにするか」という設計だ。

本番環境に直接戻すな： 復元中にサービスが停止するリスクを冒すな。
別インスタンスへの復元： 必ず検証用のインスタンスへ復元し、データ整合性をチェックしてから本番環境へマージ（もしくはエンドポイント切り替え）せよ。

復元自動化のテンプレート（gcloud）

手動操作は悪だ。CI/CDパイプラインに以下のロジックを組み込むのがプロの流儀だ。

特定のバックアップから新しいインスタンスへ復元する例
gcloud spanner databases restore \
–destination-database=recovered-db \
–source-backup=my-backup-id \
–source-instance=my-instance \
–destination-instance=recovery-instance
ポイント: 復元先インスタンスのノード数は、本番と同等以上を確保すること。
復元速度はインスタンスのノード数に依存する。

—

3. PITRを「ただの機能」から「開発の武器」へ

PITRを有効にすれば、`@` を用いたタイムスタンプ指定クエリが使えるようになる。これは最強のデバッグツールだ。

— 5分前の状態を確認する。本番データを壊さずに「なぜあの時あのアクションが発生したか」を調査できる。
SELECT FROM Users@{FORCE_INDEX=idx_users_id, VERSION_TIMESTAMPS=TRUE}
WHERE TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), MINUTE) – INTERVAL 5 MINUTE

堅牢な設計パターン：
本番環境で「過去の状態」を確認したい場合、PITRを使って別環境にデータを引き出す必要はない。`SNAPSHOT` クエリを使えば、本番のクエリ性能を落とすことなく、過去のデータにアクセスできる。

—

4. アーキテクトとして見落としてはいけない「ライフサイクル管理」

バックアップを「とりあえず保存」して、放置していないか？
クラウドにおいて「放置されたデータ」はコストの無駄であり、セキュリティリスクだ。

スケジュール戦略：
毎日：7日間保持
毎週：30日間保持
毎月：1年間保持

というように、バックアップの保持期間をビジネス要件と紐づけて自動化せよ。Cloud SchedulerとCloud Functions（またはWorkflows）を組み合わせ、`BackupScheduler` を自作するのが最もスマートだ。

パフォーマンス上の注意点：
バックアップ作成中、Spannerのパフォーマンスに影響は出ない（ここがマネージドDBの凄みだ）。しかし、インスタンスの負荷が極限状態にある時のバックアップ作成は、念のため監視しておけ。

—

5. 最後に：伝説のエンジニアからのアドバイス

「バックアップがあるから安心」と口にするメンバーがいたら、即座にこう問い返してほしい。

「で、そのバックアップから復元して、サービスが復旧するまで何分かかるのか？その間、ユーザーはどうなる？」

バックアップは手段であって目的ではない。「RTO（目標復旧時間）とRPO（目標復旧時点）をいかに短縮するか」、これこそがエンジニアの腕の見せ所だ。

設計レビューでは、必ず「リカバリ手順書」ではなく「リカバリ自動化スクリプト」を提出させよ。それができないシステムは、本番運用に値しない。

Spannerという最強の武器を持っていることを誇りに思え。だが、その武器の重みを理解し、正しくメンテナンスし続けること。それができる者だけが、真のアーキテクトとしてシステムを守り抜けるのだ。