こんにちは！Cloud Spannerの世界へようこそ。
チーフアーキテクトの私です。
「世界中のユーザーが同時にアクセスしても絶対に止まらない、しかも無限に大きくなるデータベース」なんて聞くと、なんだか魔法のようですよね。Cloud Spannerは、まさにその魔法を実現したGoogleの最高傑作の一つです。
今回は、そんなSpannerの心臓部を支える「バックアップとリストア（復元）」の仕組みについてお話しします。
「バックアップって、データを全部コピーするから時間がかかるし、その間重くなるんでしょ？」
そう思ったそこのあなた。実は、Spannerのバックアップは、一般的なデータベースの常識を覆す「一瞬で終わり、システムに負荷をかけない」驚異的な仕組みで作られているんです。
ここをクリアすれば、あなたもSpannerのアーキテクチャの核心をマスターできますよ！さあ、コーヒー片手に、優しくその裏側を覗いてみましょう。
—
1. 日常で例えるなら：究極の「瞬間記憶カメラ」
まず、データベースのバックアップがどう行われるのか、身近な例で考えてみましょう。
例えば、あなたがものすごく分厚い百科事典（データ）を丸ごとコピーしたいとします。
昔ながらのやり方はこうです。
1. コピー機に1ページずつセットする。
2. コピーが終わるまで、誰もその事典に触ってはいけない（システムを止める、または重くなる）。
3. 何時間もかけて、全ページを書き写す。
これでは大変ですよね。システムを止められない現代のWebサービスでは致命的です。
では、もし「一瞬でその瞬間のすべてのページの写真を撮り、頭の中に完璧に焼き付ける魔法のカメラ」があったらどうでしょう？
写真（スナップショット）は一瞬で撮れますよね。しかも、写真を撮ったあとも、あなたは自由にその事典に書き込みを続けられます。
Cloud Spannerのバックアップは、まさにこの「魔法のカメラ」のような仕組みを使っています。
—
2. 裏側の主役：ストレージの巨人「Colossus（コロッサス）」
では、Spannerはこの「魔法のカメラ」をどうやって実現しているのでしょうか？
Spannerの下層には、Googleが誇る巨大な分散ファイルシステム「Colossus（コロッサス）」という強力なストレージ基盤が存在します。Spannerのデータは、実はこのColossusという底知れず巨大な倉庫の中に綺麗に整理されて保管されています。
ここでポイントなのが、Spannerのバックアップは、データを別の場所にコピーしているわけではないということです。
バックアップの命令を出した瞬間、SpannerはColossusに対してこう言います。
> 「ねえ、今のこの瞬間のデータの状態に、『タイムスタンプのラベル（目印）』を貼っておいて！」
そう、バックアップの本質は「データのコピー」ではなく「特定の瞬間を指し示す目印（ポインタ）の保存」なのです。
テラバイト級、ペタバイト級のデータであっても、目印を貼るだけなら数秒（実質一瞬）で終わります。これが、Spannerのバックアップが爆速である理由です。
—
3. 書き込みはどうなるの？「コピー・オン・ライト」の知恵
ここで一つの疑問が浮かびませんか？
「目印を貼ったあとに、データが書き換えられたり消されたりしたら、過去のバックアップはどうなっちゃうの？」
ご明察です。そこで登場するのが「コピー・オン・ライト（Copy-on-Write）」という、これまた天才的な技術です。
先ほどの事典の例で言うと、写真を撮った（バックアップを取った）あとに、あなたが「3ページ目に新しいメモを書き込んだ」とします。
そのとき、Spannerは古い3ページ目のデータを消したり上書きしたりしません。
- 古い3ページ目：バックアップ用の「写真」のために、そのままそっと残しておく。
- 新しい3ページ目：別の場所に新しく書き込んで、今のシステム用として使う。
つまり、バックアップを取ったあとにデータがどれだけ変更されても、過去の「写真」に必要なデータはColossusの中にちゃんと守られ続けます。だからこそ、いつでも過去の正確な状態に戻せるわけですね。
—
4. タイムマシン機能：「ポイントインタイムリカバリ（PITR）」
このアーキテクチャの究極の進化系が、PITR（Point-in-Time Recovery：ポイントインタイムリカバリ）です。
これは、バックアップのボタンをわざわざ押していなくても、Spannerが裏側で勝手に「過去のすべての瞬間のスナップショット」を一定期間（最大7日間など）保持し続けてくれる機能です。
例えば、こんなヒヤッとする場面を想像してください。
- 「ああっ！間違えて本番データベースの大事なテーブルを全部消しちゃった！！（午前10時15分）」
そんな時でも、PITRが有効であれば、慌てる必要はありません。
> 「じゃあ、事故が起きる直前の【午前10時14分59秒】の状態に戻して！」
とSpannerにお願いするだけで、その瞬間にタイムスリップした新しいデータベースを秒速で生み出すことができます。管理者の強い味方であり、夜も安心して眠れるようになる素晴らしい機能です。
—
5. 実務で使うときのコード例とポイント
仕組みが分かったところで、実際にCloud Spannerでバックアップを作成・リストアする際のコード（Google Cloud CLI）を見てみましょう。非常にシンプルです。
① バックアップの作成（一瞬で完了）
データベース ‘production-db’ のバックアップを ‘backup-20231025’ という名前で作成する
gcloud spanner backups create backup-20231025 \
–database=production-db \
–instance=my-instance \
–expiration-date=2023-11-25T00:00:00Z
# ※裏側で目印を貼るだけなので、巨大なDBでも数秒〜数分で完了します！
② リストア（復元）の実行
バックアップから新しいデータベース ‘restored-db’ を復元する
gcloud spanner databases restore restored-db \
–destination-instance=my-instance \
–backup=backup-20231025
# ※こちらもColossus上で参照を切り替えるため、高速に処理されます。
> 💡 プロからのワンポイントアドバイス
> バックアップからのリストアや、PITRによる過去時点への復元を行う際、復元先のデータベースは「新しい別のデータベース」として作成されます。そのため、既存のシステムを壊すことなく、安全にデータの中身を検証してから切り替えるといった柔軟な運用が可能です。
—
まとめ
いかがでしたでしょうか？
Cloud Spannerのバックアップとリストアは、ただの「データのコピー」ではなく、分散ストレージColossusとスナップショット（目印）技術を組み合わせた、美しく洗練された仕組みによって成り立っています。
- バックアップはデータをコピーするのではなく、「瞬間の目印」をつけること。
- 変更されたデータは「コピー・オン・ライト」で安全に管理されること。
- だからこそ、巨大なデータでも一瞬でバックアップでき、過去の好きな時点（PITR）へタイムスリップできること。
この本質を知っていれば、今後どれほど大規模なシステムを任されても、データの安全性を自信を持って担保できるようになります。
Cloud Spannerの基本、これでバッチリマスターできましたね！
それでは、次の冒険（アーキテクチャの探求）でお会いしましょう。チーフアーキテクトでした！
コメント