【入門編】 マネージドバックアップと復元 – Cloud Spanner

こんにちは!Cloud Spannerの世界へようこそ。
チーフアーキテクトの私です。

今回は、システム運用において最も重要でありながら、どこか地味に見えがちなテーマ「マネージドバックアップと復元(PITR)」についてお話しします。

「バックアップって、要するにデータをコピーして保存しておくんでしょ?」
そう思ったそこのあなた。甘い、甘いです!世界中のデータを受け止め続けるCloud Spannerのバックアップと復元は、まるで「時を戻す魔法」であり、システムエンジニアの命綱です。

専門用語を極力排して、日常のたとえ話を交えながら、優しく、そして本質的なところまで一緒に紐解いていきましょう。ここをクリアすれば、Cloud Spannerの安心感の正体がバッチリ見えてきますよ!

—

1. なぜCloud Spannerのバックアップは「特別」なのか?

まずは、Cloud Spannerというデータベースの性質を少しだけ思い出してください。Cloud Spannerは、世界中にデータを分散させ、止まることなく超高速で読み書きをこなす、いわば「超巨大で不眠不休のスーパー金庫」です。

この金庫、あまりにも巨大でデータが絶えず動き続けているため、「すべてのデータをきれいに一瞬で写真に撮る」のがすごく難しいんです。

普通のデータベースでバックアップを取ろうとすると、データを一時的に止める必要があったり、膨大な時間がかかってシステムが重くなったりします。しかし、Cloud Spannerの「マネージドバックアップ」は、システムを止めることなく、裏側でこっそり、かつ完璧にデータの「瞬間写真(スナップショット)」を撮影して保存してくれます。

たとえ話:銀行の「全金庫の瞬間停止カメラ」

想像してください。世界中に支店がある巨大な銀行の全金庫の現金を、営業中に正確に数え直したいとします。普通なら「ちょっとお客さん、今から金庫を閉めるので外で待ってください!」となりますよね。

でも、Cloud Spannerのマネージドバックアップは、「お客さんがお金を出し入れしているまさにその瞬間を、一切止めずに、全金庫の様子を完全にフリーズさせたかのように写真に収める特殊なカメラ」を持っているようなものです。これが「マネージド(Googleが勝手にうまくやってくれる)」の本気です。

—

2. マネージドバックアップの基本と「保持期間」

バックアップを取る機能があるのは分かりましたが、では保存したデータはいつまで取っておけるのでしょうか?

ここで大切になるのが「保持期間(Retention Period)」という考え方です。

バックアップは、作ったはいいものの、ずっと放置していると保管場所(ストレージ代)が大変なことになりますよね。かといって、すぐに消えてしまうと、いざという時に使えません。

  • 手動バックアップ: ユーザーが「今だ!」と任意のタイミングで撮影し、明示的に削除するまでずっと取っておくことができます(※法律や社内規程で「〇年保管しなさい」と言われているデータに最適です)。
  • バックアップのコスト: 保存している容量に応じて費用がかかりますが、SpannerのデータはGoogleの強固なストレージに暗号化されて安全に守られます。

—

3. タイムマシン機能!特定の時点への復元(PITR)の仕組み

さて、ここからが本題であり、最もエキサイティングな機能です。それがPITR(Point-In-Time Recovery:特定時点への復元)です。

システムを運用していて、最悪の瞬間というのはいつ訪れるでしょうか?
そう、「やっちまった!」の瞬間です。

例えば、

  • うっかり間違ったSQLを実行して、顧客データをすべて消してしまった(午前10時15分)。
  • バグのあるプログラムがデプロイされて、データをめちゃくちゃに書き換えてしまった(午後2時30分)。

こんな時、昨日の夜のバックアップから復元するとどうなるでしょう?
「昨日の夜から今までの間にお買い物をしてくれたお客様のデータ」がすべて消えてしまいますよね。それは困ります。

そこで登場するのが PITR です。これは、簡単に言うと「データベースのタイムマシン」です。

たとえ話:ビデオの「巻き戻し再生」

PITRは、バックアップという「写真のアルバム」ではなく、「データベースのすべての動きを録画し続けた超高画質なビデオテープ」だと思ってください。

このビデオテープがあれば、次のような芸当が可能です。
> 「あ、やばい!午前10時14分59秒の時点の状態に、データベースの時間を巻き戻して、そこから新しく枝分かれした世界線を作ろう!」

Cloud SpannerのPITRを有効にしておくと(デフォルトで過去一定期間、最大7日間など設定可能)、その期間内であれば、「秒単位」で過去の任意の瞬間にデータベースをタイムスリップさせることができます。

間違った操作をしたその「1秒前」の状態を新品のデータベースとしてパッと復元し、そこから何食わぬ顔で業務を再開できるのです。これぞ、エンジニアの精神安定剤ですね。

—

4. 実務で役立つ!バックアップと復元をイメージするコード例

言葉だけだとフワッとしてしまうので、Google Cloudのコマンドライン(gcloud)を使って、実際にバックアップを取得し、そこから復元する流れをイメージしてみましょう。

実際の現場ではこのように操作します(※雰囲気をつかんでもらうための擬似的なコードと解説です)。

1. 現在稼働中のデータベース「production-db」のバックアップを手動で取得する
「backup-2023-1027」という名前のバックアップを保存します。
gcloud spanner backups create backup-2023-1027 \
–database=production-db \
–instance=my-spanner-instance \
–expiration-date=2023-11-27T00:00:00Z

【解説】
これにより、システムを止めずにバックアップがバックグラウンドで作成されます。
–expiration-date で「いつまで保持するか」を指定しているのがポイントです。

そして、万が一データが吹き飛んでしまったときは、こうして復元(リストア)します。

2. 取得したバックアップから、新しいデータベース「recovered-db」を復元する
gcloud spanner databases restore recovered-db \
–source=backup-2023-1027 \
–source-instance=my-spanner-instance \
–instance=my-spanner-instance

【解説】
壊してしまった元のデータベースとは別に、安全な別名(recovered-db)として
バックアップ当時の状態を完全に再現したデータベースがよみがえります。

PITR(特定時点への復元)を使う場合も、これと非常によく似たコマンドで、「〇月〇日の何時何分何秒の状態に戻して!」と指定して新しいデータベースを作り出すことができます。

—

5. まとめ:恐れず挑戦できる環境がここにある

いかがでしたでしょうか?

  • マネージドバックアップ: システムを止めずに、金庫の瞬間を切り取るスナップショット。
  • PITR(特定時点への復元): データの歴史を記録し続け、好きな秒数に巻き戻せるタイムマシン。

Cloud Spannerがこれほどまでに強力なバックアップと復元機能を持っているおかげで、私たちエンジニアは「もしデータを消してしまったらどうしよう…」という恐怖から解放され、アグレッシブに新しい機能の開発やチューニングに挑むことができます。

「失敗しても、あの秒数にタイムスリップすればいいさ」
そう思える余裕こそが、優れたシステム運用の第一歩です。

ここをクリアしたあなたなら、もうSpannerのデータ保護の概念は完璧です。自信を持って次のステップに進んでくださいね!それではまた、次の現場でお会いしましょう。

コメント

タイトルとURLをコピーしました