DeNAがCloud SQLのBackup Vault導入を解説 隔離保管と運用負荷削減を両立

DeNAがCloud SQLのBackup Vault導入を解説 隔離保管と運用負荷削減を両立

公開日:2026年10月31日

DeNAがCloud SQLのBackup Vault導入を解説 隔離保管と運用負荷削減を両立

3行解説

  • DeNAがCloud SQL移行に合わせ、Backup Vaultでバックアップ保管を見直しました。
  • 変更不可・消去不可の保護と、クロスプロジェクトの権限分離を組み合わせています。
  • GCSへの毎日エクスポート方式と比べ、試算では月額約77%削減でした。

ニュースの概要

DeNAのIT基盤部は2026年10月29日、Cloud SQLへ移行したMySQLのバックアップ方式として、Google Cloudの拡張バックアップ機能とBackup Vaultを採用した経緯を公開しました。記事では、IaaS時代のmysqldumpとGCSアップロードの運用から切り替えた理由、Backup Vaultの構成、クロスプロジェクトでの権限設計、GCSへのエクスポート方式とのコスト比較、運用上の注意点を整理しています。対象は、高い可用性が求められる大規模プロダクトのインフラ運用です。

何が新しいのか

新しい点は、単にCloud SQLへ移行したことではなく、隔離されたBackup Vaultに変更不可・消去不可の形で保存する運用へ切り替えたことです。DeNAは、内部不正や不正アクセスによる破壊、さらに災害時の事業継続を見据え、メイン環境とは権限的・地理的に分離された保管先を求めていました。IaaS時代のようなスクリプト運用をやめ、マネージド機能に寄せた点も実務上の変化です。

従来方式と今回の方式
mysqldump
→
GCS保存
→
手動運用

Cloud SQLでは拡張バックアップ機能を使い、Backup Vaultへ自動保存する構成に切り替えています。

また、記事はコスト面の比較も具体的です。論理容量150GiBのMySQLで、日次バックアップを7日保持した試算では、GCS方式が月24.05ドル、Backup Vault方式が月5.56ドルでした。差の主因は、GCS方式が毎日フルサイズのダンプ転送になるのに対し、Backup Vaultは変更ブロック中心で転送量が小さいことです。保持期間が長いほど、この差は広がる可能性があります。

グリットアーツ編集部の分析

この事例で実務上重要なのは、Backup Vaultの保護機能そのものより、権限分離と復旧手順まで含めて設計している点です。DeNAは、作業実施者に両プロジェクトでroles/backupdr.backupUserを付与し、復旧時だけroles/backupdr.restoreUserを付ける運用にしています。つまり、平常時と障害時で権限を分ける前提です。これは、侵害時にバックアップまで巻き込まれない設計として有効ですが、運用手順を文書化しないと復旧時の手戻りが起きやすい構成でもあります。

一方で、記事が明示するようにバックアッププランは後から変更できません。保持期間やスケジュールを頻繁に見直す現場では、最初の設計ミスがそのまま運用負荷につながる可能性があります。逆に、要件が固まっていて、長期にわたり同じ保護方針を維持したい環境には向いています。導入判断では、機能の強さだけでなく、変更しにくさを受け入れられるかが分岐点になります。

日本の現場で考えると

日本企業でこの方式を使う場合、まず確認したいのは、バックアップ保管先を本番環境からどこまで分離できるかです。記事のようにクロスプロジェクトで分ける設計は、権限管理を厳しくしたい企業に向きます。特に、運用担当と復旧担当を分けたい組織では相性がよいでしょう。

一方で、保持期間やバックアップ頻度を短いサイクルで変える現場には慎重さが必要です。Backup Vaultは設定変更ができないため、季節要因や業務変更で方針を見直すたびに作り直しが必要になる可能性があります。制作現場やECのように復旧要件が変わりやすい環境では、初期設計の詰めが重要です。

また、PITR用のトランザクションログ保存期間も費用に影響します。単に「バックアップを取る」だけでなく、どこまで戻せるかを含めて設計しないと、復旧時に必要な粒度が足りないことがあります。運用監査や権限申請の流れも、平時から整えておく必要があります。

導入・検討時に確認したいこと

  • バックアッププランの保持期間、スケジュール、PITRログ期間を初期設計で固定できるか。
  • 本番プロジェクトとBackup Vault側プロジェクトの権限分離を、監査可能な形で運用できるか。
  • 復旧時だけ付与する権限の申請・承認・解除手順を、障害時に回せるか。
  • 自社のデータ量と更新頻度で、GCS方式とBackup Vault方式の費用差がどう出るか。
  • バックアップからのリストア手順と、実際の停止時間の見込みを事前に確認できるか。

現時点で分かっていないこと

記事からは、DeNAの本番環境での実際の復旧時間や、障害時の運用手順の詳細までは分かりません。また、週次バックアップやPITRログを含めた総コストは、今回の比較には含まれていません。Cloud SQL以外のデータソースで同じ設計がどこまで使えるかも、この記事だけでは判断できません。

バックアップの隔離設計や復旧手順は、平時の運用だけでなく障害時の判断にも直結します。自社のデータ保全要件をどう設計するか迷う場合は、構成と運用の両面から整理しておく価値があります。

ITインフラの構築・保守をご検討の方へ

「自社の環境にはどんな構成・保守体制が合うのか」お悩みではありませんか。貴社の現場課題に合わせたご提案をいたします。まずはご相談からお気軽にどうぞ。

出典: DeNA Engineering