【実務・中級編】マネージドバックアップと復元 – Cloud Spanner

SpannerのバックアップとPITR：本番障害を秒速で無かったことにする設計・運用アンチパターン

こんにちは。チーフアーキテクトの私だ。
これまで数々のミッションクリティカルな分散データベースシステムを構築・監査してきたが、いまだに「Spannerを使っているからバックアップは不要だよね？」という危険な誤解に出会うことがある。

確かに、Cloud Spannerはマルチリージョン構成であれば、データセンターが丸ごと吹き飛ぶような障害でも無停止で生き残る。しかし、「人間の手によるバグを含んだデプロイ」「悪意あるデータ改ざん」「バッチ処理の暴走による全レコードの意図しないUPDATE」といったアプリ層の災害を防ぐことはできない。これらを救う唯一の神の手が、マネージドバックアップとPITR（Point-in-Time Recovery：特定時点への復元）だ。

今回は、実務の現場でこの2つの機能をどう捉え、いかにして堅牢なリカバリ戦略を構築すべきか。その核心を授けよう。

—

1. マネージドバックアップ vs PITR：本質的な違いを理解する

まず、設計レビューで必ずと言っていいほど混同されるこの2つの違いを明確にしておく。

アーキテクチャの裏側：なぜSpannerのバックアップは速いのか？

Spannerのストレージは、分散ファイルシステム上にImmutable（不変）なデータの塊（SSTableのような構造）として存在している。
マネージドバックアップ実体は、その時点におけるメタデータのスナップショットと、ストレージレイヤでの参照ポインタの固定に過ぎない。したがって、数テラバイトある巨大なデータベースであっても、バックアップ作成・復元処理自体は驚異的な速度（数分以内）で完了する。インスタンス全体をコピーするような愚かな設計は今すぐ捨ててほしい。

—

2. マネージドバックアップの実務設計：ルーティンと罠

マネージドバックアップは、主に「ディザスタリカバリ（DR）」や「コンプライアンス（法的保持）」の文脈で使われる。

設計のベストプラクティス：スケジュールバックアップとリージョン間コピー

本番環境で手動バックアップ運用をしている現場を見ると、私は冷や汗が出る。バックアップは自動化されていて初めて信頼できる。
以下は、gcloud CLIを用いた堅牢なバックアップ取得の自動化スクリプトの例だ。

!/bin/bash
—
Spanner Production Backup Automation Script
実行頻度: 毎日深夜（Cloud Scheduler + Cloud Run / Workflows等からの呼び出しを想定）
—

INSTANCE_ID=”prod-spanner-instance”
DATABASE_ID=”core-ledger-db”
BACKUP_ID=”backup-${DATABASE_ID}-$(date +%Y%m%d-%H%M%S)”
レジリエンスを高めるため、別リージョン（例: US-CENTRAL1からUS-EAST1へ）にバックアップを保持する戦略も有効
PARENT_REGION=”us-central1″

echo “Starting backup for ${DATABASE_ID} at $(date)”

gcloud spanner backups create “${BACKUP_ID}” \
–instance=”${INSTANCE_ID}” \
–database=”${DATABASE_ID}” \
–expiration-date=”$(date -u -d ‘+30 days’ +%Y-%m-%dT%H:%M:%SZ)” \
–async

–async を付与することで、大規模DBのバックアップ作成コマンドのタイムアウトを防ぐ
実際の運用では、オペレーションIDをトラッキングして完了を検知する仕組みを挟むこと。

echo “Backup creation requested. Operation ID: ${BACKUP_ID}”

⚠️ チーフアーキテクトからの警告：バックアップからの復元時の「罠」

バックアップからデータを復元する際、復元先のデータベースは「全く新しい独立したインスタンス」として生成される。
ここでエンジニアがやりがちなミスが、復元後インスタンスのノード数（またはプロセッシングユニット）のサイジング漏れだ。

罠: 本番環境（100ノード）の巨大DBを、コスト削減のために最小構成（100 Processing Units）のインスタンスへ復元しようとする。
結末: 復元処理自体は成功するが、その後のトラフィックを全くさばけず、即座にCPU張り付きでスレッド枯渇、障害が再発する。

【対策】 復元スクリプトやDR手順書には、必ず「本番同等のキャパシティを持つインスタンスへのリストア、あるいはリストア直後のスケールアップ手順」をセットでコード化しておけ。

—

3. PITR（Point-in-Time Recovery）：秒単位のタイムトラベル

次に、現場の開発者が最も恩恵を受けるPITRだ。
「やばい、管理画面のバッチで全ユーザーのステータスを `INACTIVE` に書き換えてしまった……！」
こんな絶望的な状況でも、PITRが有効であれば過去の任意のタイムスタンプ（例: 10分前）へ瞬間的に戻すことができる。

PITRの仕組みとストレージコストのトレードオフ

SpannerのPITRは、内部のマルチバージョンコンカレンシーコントロール（MVCC）の仕組みを拡張している。過去のタイムスタンプを指定したクエリ（Stale Read）をさらに強力にし、データベース全体を指定した時点の状態として再生（復元）する機能だ。

保持期間: デフォルトで最大7日間。
コスト: PITRを有効にすると、過去7日間の変更差分（Mutation）を保持し続けるため、ストレージ使用量が増加する（通常のストレージ料金に加え、PITR分の保持コストが発生）。

チーフアーキテクトの判断基準:
ミッションクリティカルな本番DBにおいて、「PITRをオフにする理由」は存在しない。 コストをケチって数百万件のデータをロストした時の損失を考えれば、PITRのストレージ代など微々たるものだ。全本番環境で即座に有効化せよ。

PITRを用いたリストアの実行例

TerraformやgcloudでPITRからのリストアを行う場合、ターゲットとする正確なタイムスタンプ（RFC 3339形式）を指定する。

202X年10月15日 12:00:00 UTC の時点へデータベースを復元する
gcloud spanner databases restore \
–destination-instance=”prod-spanner-instance” \
–destination-database=”core-ledger-db-recovered” \
–source-backup-instance=”prod-spanner-instance” \
–source-database=”core-ledger-db” \
–restore-time=”202X-10-15T12:00:00Z”

—

4. 堅牢なリカバリ設計：本番障害に備えるチェックリスト

最後に、実際のプロジェクトで私が必ずレビューする「バックアップ・リカバリの要件定義チェックリスト」を授けよう。君たちの設計がこれ満たしているか、今すぐ確認してほしい。

1. RPO（目標復旧時点）とRTO（目標復旧時間）の定義はあるか？

PITRがあるため、RPOは実質「数秒〜数分前」を達成できる。RTOはリストア対象のデータ量ではなく、「リストア後のアプリの切り替え時間（DNS切り替えやコネクションプールの再接続）」で決まる。ここをドキュメント化しているか？

2. 「リストア訓練」を四半期ごとに実施しているか？

バックアップを取っているだけで、一度もリストアしたことがないバックアップは「ゴミ」と同義である。ステージング環境へ定期的に自動リストアし、データが健全に読み込めるか検証するパイプラインを組め。

3. IAM権限の最小化（セパレーション・オブ・コンサー。関心の分離）

アプリケーションのサービスアカウントから、バックアップの削除やリストア権限を剥奪しているか？悪意ある攻撃者や乗っ取られたコンテナからバックアップが全消去される最悪のシナリオを防ぐため、バックアップの管理権限は特権管理者に限定されているべきだ。

—

結びにかえて

Cloud Spannerは、現代における最強クラスの可用性を持つデータベースだ。しかし、インフラストラクチャの堅牢性と、アプリケーションを運用する人間のエラーに対する耐性は別問題である。

マネージドバックアップとPITRは、単なる「保険」ではない。攻めの開発を行うエンジニアが、「万が一ミスをしても、数分前の完璧な世界へ巻き戻せる」という圧倒的な安心感を持ってコードを書くための、最強の盾なのだ。

設計レビューで妥協するな。今すぐ君たちのSpannerのバックアップポリシーを確認し、万全の要塞を築き上げたまえ。