はじめに

こんにちは、DeNA の IT 基盤部の izawa です。主に高い可用性が求められる大規模プロダクトのインフラを担当しています。

私たちが担当するプロダクトでは、IaaS 上で運用していた MySQL を Cloud SQL へ移行しました。その進め方については、前回の記事で紹介しています。

移行にあたって検討が必要になったテーマのひとつが、バックアップ戦略です。IaaS 時代の運用をそのまま持ち込むのではなく、Cloud SQL の拡張バックアップ機能を使い、Backup Vault へバックアップを保存する方式へ切り替えました。

本記事では、この Backup Vault について、その概要と具体的な構成、従来方式とのコスト比較、そして利用上の注意点をご紹介します。Google Cloud の Cloud SQL 利用を検討しているインフラエンジニアや、データベースのマネージドサービスに興味のあるインフラエンジニアの皆さんの参考になれば幸いです。

バックアップ要件と Cloud SQL 移行時の課題

DeNA では、データ保全に関する厳しい要件を設けています。これは、内部の悪意ある操作や不正アクセスによるデータ破壊に備えるとともに、大規模災害時における事業継続（DR）を目的としたものです。

この要件では、メインのデータベース環境とは権限的・地理的に隔離された別環境にバックアップを取得することが求められます。さらに、この隔離されたバックアップ環境へのアクセスは、社内でもごく一部の限られたメンバーのみに限定され、厳重に管理されています。これは、万が一、サービス運用中の環境が侵害されたとしても、バックアップ データが安全に保護されることを確実にするためです。

IaaS 環境では、mysqldump と GCS へのアップロードスクリプトでこのバックアップを取得していました。しかし Cloud SQL では、同じ方式を踏襲しようとするとエクスポート機能による定期実行になり、インスタンスへの負荷とコスト、そしてスクリプト運用の継続という課題が残ります。マネージドサービスに移行しながら、この要件をどう満たすかが検討のポイントでした。

Backup Vault を選んだ理由

Backup Vault は、Google Cloud の Backup and DR Service が提供するストレージリソースです。ランサムウェア攻撃や悪意のあるデータ破壊からデータを守るため、変更不可・消去不可なバックアップを保存できます。

Compute Engine や AlloyDB などさまざまなデータソースに対応しており、Cloud SQL では拡張バックアップ機能を通じて利用できます。拡張バックアップ機能は 2025 年 12 月 17 日に一般提供（GA）が開始され、さらにマルチリージョンバックアップへの対応も 2026 年 3 月 17 日に GA されました。私たちのバックアップ要件を検討するタイミングと重なったことも、採用を後押ししました。

拡張バックアップでは、隔離された Backup Vault に変更不可・消去不可の状態でデータが保存されます。これは先に述べたバックアップ要件を満たすものでした。さらにマネージドサービスであるため、IaaS 時代から続いていたスクリプトの運用が不要となりました。

Backup Vault の構成と設定

構成に必要な 3 つのリソース

バックアップ構成で定義するのは、Backup Vault 本体、バックアップ プラン、そしてバックアップ プランの関連付けという 3 つのリソースです。

1 つ目は、バックアップ データの保存先となる Backup Vault 本体のリソースです。通常のストレージと異なり、保存したバックアップを保護することに特化している点が特徴です。たとえば最小強制保持期間を設定すると、その期間内はバックアップを削除できなくなります。さらにロック機能を適用すると、以後は最小強制保持期間を短縮できなくなり、データ保護がより確実になります。

2 つ目は、バックアップのスケジュールや保持ルールを定義するバックアップ プランです。どの Backup Vault にバックアップを保存するかを指定して作成します。Cloud SQL の場合は、Point-in-Time Recovery（PITR）に必要なトランザクションログの保存期間もここで設定します。

3 つ目は、Cloud SQL インスタンスとバックアップ プランを結び付けるバックアップ プランの関連付けです。これにより拡張バックアップ機能が有効化され、指定したスケジュールでバックアップが自動実行されるようになります。

バックアップ スケジュールの設定

今回の構成では、これまでのバックアップ運用よりも攻撃に対して柔軟に復旧できるよう、以下のようなバックアップ スケジュールを設定しました。

• 日次バックアップ: 直近 7 日間のデータを保持します。
• 週次バックアップ: 直近 98 日間（14 週間）のデータを保持します。

Backup Vault では、Cloud SQL の標準バックアップと同様に増分バックアップが取得されます。複数のスケジュールを設定でき、異なるスケジュールで取得されたバックアップも同一のバックアップ チェーン上に蓄積されるため、ストレージの効率性も保たれます。

また、直近の状態への迅速な復旧に備え、PITR に必要なトランザクションログの保存期間は 3 日間としました。ログの保存期間はバックアップの保持期間の範囲内で延長できますが、バックアップの保持期間もログの保存期間も、長くするほど費用が増えます。要件と費用のバランスはデータ量や更新頻度によって変わるため、導入前に自身の環境で試算しておくことをオススメします。

クロス プロジェクト構成と権限設計

セキュリティと管理を強化するため、Backup Vault はクロス プロジェクト構成で運用しています。これは、サービス運用中のプロジェクトが万が一侵害された場合に備えた権限分離の考え方に基づいています。

基本的な設定方法は同一プロジェクトの場合と変わりませんが、権限設定には特別な配慮が必要です。

• 作業実施者には、Backup Vault が存在するプロジェクトと Cloud SQL が存在するプロジェクトの両方で roles/backupdr.backupUser を付与します。
• Backup Vault のサービス エージェントには、Cloud SQL が存在するプロジェクトで roles/backupdr.cloudSqlOperator を付与します。

サービス エージェントは Backup Vault の作成と同時に発行されるため、Backup Vault の作成後に権限を付与する流れになります。

なお、バックアップからリストアする場合は、作業実施者に Backup Vault が存在するプロジェクトで roles/backupdr.restoreUser を付与する必要があります。この権限は平常時には不要なため、今回の構成ではリストアの作業が発生したタイミングで付与し、作業後に解除する運用としています。

GCS へのエクスポート方式とのコスト比較

Backup Vault の採用にあたっては、IaaS 時代の方式を Cloud SQL に置き換えた場合とのコストも比較しました。つまり、エクスポート機能で取得したダンプを別リージョンの GCS バケットへ毎日保存する方式です。ここでは、テスト環境で取得した実測値をもとに試算した結果を紹介します。

試算の前提

試算に使ったのは、論理容量 150 GiB の MySQL インスタンスです。バックアップは日次で取得し、GCS 方式では北米内の別リージョンのバケットへ、Backup Vault 方式では US マルチリージョンの Backup Vault へ保存しました。保持期間はいずれも 7 日間です。それぞれの方式で実測したデータ量は次のとおりです。

料金単価には、北米の正規価格を用いました。

試算結果

継続して運用した場合の月額は次のとおりです。

毎日フルサイズのダンプを転送する GCS 方式では、月 975 GiB の転送が発生し、これが費用の大半を占めます。一方の Backup Vault は変更されたブロックだけを転送するため、転送量は月 45 GiB 程度に収まります。ストレージ単価は GCS より高く管理料金も加わりますが、保持するデータ量そのものが小さいため、合計では約 77% の削減となりました。なお、初月のみ初回のフルバックアップ分として、約 $0.80 の転送費が上乗せされます。

この試算は 7 日間保持のみの条件であり、前述した週次バックアップや PITR 用のトランザクションログの費用は含んでいません。保持期間を延ばすと、GCS 方式では保持する世代数に比例してフルダンプの容量が増えるのに対し、Backup Vault では増分が蓄積されるだけなので、差はさらに広がる傾向にあります。実際の費用はデータ量や更新頻度で大きく変わるため、あくまで一つの目安としてご覧ください。

Backup Vault 導入における留意点

バックアップ プランの設定変更ができない

Backup Vault を導入する上でとくに注意が必要なのが、バックアップ プランを後から変更できないという制約です。2026 年 9 月現在、データソースとして Cloud SQL を指定した場合、作成したバックアップ プランの設定内容（バックアップ ルールなど）を変更することはできません。

Google Cloud Console の編集画面では、一見ルールの追加や変更ができそうに見えますが、変更を保存しようとすると失敗します。コンソール上では具体的なエラーメッセージが表示されないことがありますが、Terraform で変更を試みた際には、以下のようなエラーが返却されました。

│ Error: Error updating BackupPlan "projects/<project>/locations/<location>/backupPlans/<backup_plan_id>": googleapi: Error 400: Invalid resource state for "projects/<project>/locations/<location>/backupPlans/<backup_plan_id>": Backup plan update for Cloud SQL is not supported.
│ Details:
│ [
│   {
│     "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
│     "violations": [
│       {
│         "description": "Backup plan update for Cloud SQL is not supported.",
│         "subject": "projects/<project>/locations/<location>/backupPlans/<backup_plan_id>",
│         "type": "BACKUP_PLAN_UPDATE_FOR_CLOUD_SQL_NOT_SUPPORTED"
│       }
│     ]
│   }
│ ]

このため、バックアップ日数やスケジュールを変更したい場合は、新しい設定のバックアップ プランをあらためて作成し、関連付け先をそのプランへ切り替えるという手順が必要になります。

Billing のラベルでバックアップ費用を判別できない

今回の構成では、バックアップ専用のプロジェクトを1つ用意し、その中にプロダクトごとの Backup Vault を作成しています。プロダクトごとにプロジェクトを分けるよりも、限られたメンバーによるアクセス管理を一元化しやすいためです。こうした集約構成では、従来は各リソースにラベルを付与することで、プロダクトごとの費用を判別していました。

しかし 2026 年 9 月現在、Backup Vault は Billing のラベルフィルターに非対応です。

プロダクトごとの費用を把握するには、実際の使用量をもとに按分する仕組みを別途用意する必要があります。今回の構成では、Backup Vault ごとのストレージサイズを日々記録し、その容量の比率でバックアップ用プロジェクトに計上されるストレージ費と転送費を按分する仕組みを作成して運用しています。導入の際は、こうした費用配分の方法もあわせて検討しておくとスムーズです。

まとめ

本記事では、Cloud SQL のバックアップ戦略として Backup Vault を採用した事例をご紹介しました。

Backup Vault の導入によって、スクリプトによるバックアップ運用を手放しつつ、変更不可・消去不可という特性でバックアップ要件を満たせるようになりました。増分のみを転送・保持する仕組みのため、ダンプを毎日フルサイズで保存していた従来方式と比べて費用も抑えられています。日次と週次を組み合わせたスケジュール設定とクロス プロジェクト構成により、復旧の柔軟性と権限分離を両立できた点も大きな成果です。

一方で、バックアップ プランを変更できない点や、Billing のラベルフィルターに非対応である点など、導入前に把握しておきたい制約もあります。これらを事前に織り込んでおけば、より円滑に導入と運用を進められるはずです。

Cloud SQL で高いデータ保全性や運用効率を求める場合、Backup Vault は有力な選択肢になります。私たちにとってもまだ導入して間もない仕組みのため、今後は実際の運用を通して得られた知見も共有していければと思います。