データ基盤のディザスタリカバリ設計――RPO/RTOから逆算するバックアップ戦略

「クラウドDWHを使っているから、バックアップはプロバイダが面倒を見てくれる」――半分は正解で、半分は致命的な誤解です。クラウドDWHは確かに物理障害に対しては強靭ですが、ユーザーの誤操作(テーブル削除)やリージョン全体の大規模障害、論理破損(悪意ある改竄やバグ)からはデフォルトで守ってくれません。本記事では、RPO/RTOから逆算するディザスタリカバリ(DR)設計の考え方と、SnowflakeやBigQuery別のDR機能、バックアップ戦略まで実務目線で解説します。

データ基盤にDR設計が必要な理由

データ基盤はビジネスの意思決定の土台であり、止まることの影響が日を追うごとに拡大する性質を持ちます。販売データが1日止まれば需要予測が遅延し、在庫補充が遅れ、売上機会を逸します。クラウドDWHは99.9%以上の可用性を保証していますが、残り0.1%が発生したときに「誰も手を動かせない」状態は許容できません。

加えて、最も多い障害は物理ではなく論理的なものです。誤ったDROP TABLE、間違った更新スクリプト、アプリケーションバグによる大量破損――これらに対する備えがDR設計の本質です。インシデント管理プロセスと合わせて、DR設計を位置づけましょう。

RPO/RTOの定義と設計方法

DR設計の起点は、RPO(Recovery Point Objective: 復旧時点目標)とRTO(Recovery Time Objective: 復旧時間目標)の定義です。RPOは「どこまでデータ損失を許容できるか(=何時間前までのデータに戻ればいいか)」、RTOは「どれだけの時間内に復旧する必要があるか」を意味します。

【RPO/RTOの概念図】

障害発生                   復旧完了
   |                          |
   v                          v
---+-----+--------------------+---> 時間軸
   |     |                    |
   |<RPO>|                    |
   |     |<------ RTO ------>|
   |
   ※ RPO: 復旧後に戻れる時点の差(データ損失量)
   ※ RTO: 障害発生から復旧までの所要時間

[RPO=1時間, RTO=4時間]
  障害の1時間前までのデータを
  4時間以内に復旧できる状態

RPO/RTOはデータの重要度に応じて階層化して定義します。ビジネスクリティカルなデータほど厳しい目標を、参考情報的なデータは緩い目標を設定します。全データに同じ目標を設定するとコストが膨大になるため、必ず階層化することが重要です。

データ種別	推奨RPO	推奨RTO	コスト影響
リアルタイム取引データ	1分以内	15分以内	高
日次販売・運用KPI	1時間	4時間	中
BIレポート用マート	24時間	24時間	中
履歴分析・アーカイブ	7日	72時間	低

目標を決めたら、それに合わせたバックアップ・レプリケーション構成を組みます。リアルタイム取引データにはクロスリージョンレプリケーションが必要ですが、アーカイブには日次スナップショットで十分、という具合です。

クラウドDWHのDR機能

主要クラウドDWHのDR関連機能を整理します。各製品とも基本機能は備えていますが、設定が必要なもの、デフォルトで有効なものが異なるため、要件に合わせた確認が必須です。

機能	Snowflake	BigQuery	Redshift
タイムトラベル	最大90日(Enterprise)	7日(固定)	バックアップに依存
フェイルセーフ	7日(自動)	7日(Deleted)	非該当
クロスリージョンレプリケーション	可(Replication + Failover)	マルチリージョン機能	スナップショットコピー
スナップショット	ゼロコピークローン	テーブルスナップショット	自動/手動スナップショット
RPO目安	秒〜分	分〜時間	スナップショット間隔次第
RTO目安	分	分〜時間	時間

Snowflakeはレプリケーションとフェイルオーバーグループにより、リージョン障害時でも別リージョンへ即座に切り替え可能です。BigQueryはマルチリージョンロケーションを選択することで、自動的に複数リージョンにデータが複製されます。Redshiftはスナップショットコピーで別リージョンにバックアップする設計が基本となります。Snowflake入門、BigQuery入門も参照してください。

バックアップ戦略

DR機能の活用に加え、明示的なバックアップ戦略が必要です。Snowflakeのレプリケーション設定例を示します。

-- プライマリ側: データベースのレプリケーション有効化
ALTER DATABASE prod_db ENABLE REPLICATION TO ACCOUNTS ('org.dr_account');

-- セカンダリ側: レプリカデータベース作成
CREATE DATABASE prod_db AS REPLICA OF 'org.primary_account.prod_db';

-- 定期的に同期実行(タスクで自動化)
ALTER DATABASE prod_db REFRESH;

重要なのは「3-2-1ルール」の考え方です。3つのコピー、2つの異なるストレージメディア、1つはオフサイト。クラウド時代でも本質は変わりません。プライマリと同じクラウドアカウントだけでは「アカウント単位での事故」(認証情報漏洩による全削除等)に対応できません。別アカウント、別リージョンへのバックアップが最低条件です。オブジェクトストレージへのデータエクスポートも併用し、クラウドプロバイダ障害時の独立した復旧パスを確保しましょう。

DR訓練の設計

DR設計は「作って終わり」ではなく「訓練して初めて機能する」ものです。実際にフェイルオーバーを実行する訓練を定期的に行い、RTOが目標内に収まるかを計測します。手順書が古くなっていないか、担当者が交代しても実行可能か、アラートの鳴動ルートが正しいか――これらは実際に動かしてみないと検証できません。

推奨の訓練頻度は、ビジネスクリティカルなシステムで四半期に1回、一般的なシステムで半年〜年1回です。訓練では「机上訓練(手順確認のみ)」と「実地訓練(実際にフェイルオーバー実行)」の2種類を組み合わせます。訓練シナリオには「DWH全体停止」「特定リージョン障害」「誤操作による大量データ削除」「認証情報漏洩」など複数のパターンを用意し、チームの対応力を多面的に高めていきます。訓練後の振り返りで、手順書の改訂ポイントをログとして残すことも重要です。

コストとのバランス

DR構成はコストとトレードオフの関係にあります。すべてのデータを最高水準で守ろうとすると、コストは2〜3倍に膨らみます。データ重要度別に構成を変えることで、費用対効果を最大化できます。

DR構成	RPO	RTO	追加コスト	適用範囲
タイムトラベルのみ	1日〜90日	数分	+5〜10%	一般データ
定期スナップショット	1日	数時間	+10〜20%	重要データ
クロスリージョンレプリケーション	分単位	分単位	+50〜100%	ミッションクリティカル
アクティブ-アクティブ	秒単位	即時	+100%超	極めて限定的

まとめ

データ基盤のDR設計は、RPO/RTOを起点とした階層的な設計が鍵です。クラウドDWHの標準機能をベースに、クロスリージョンレプリケーションと外部バックアップを組み合わせ、コストとのバランスを取りながら実装します。そして最も重要なのは、定期的な訓練で手順と対応力を維持することです。マルチクラウドの観点も加えると、より強靭な基盤になります。データSLAの設計と合わせて取り組みましょう。

よくある質問(FAQ)

Q. クラウドDWHにバックアップは必要ですか?

クラウドDWHは自動的にデータを冗長化していますが、ユーザーの誤操作(テーブル削除等)からの復旧にはタイムトラベル機能やクロスリージョンレプリケーションが必要です。論理的な破損に対する備えは利用者側の責任です。

Q. データ基盤のRPOの目安は?

BI/レポーティング用途なら24時間、リアルタイム分析なら1時間以内が一般的な目安です。ビジネスインパクトから逆算して設定することが大切で、データ種別ごとに階層化するのが現実的な設計です。

Q. DR訓練はどのくらいの頻度で行うべきですか?

最低でも年1回、理想は四半期ごとの実施です。フェイルオーバーの手順確認とRTO実測を目的とし、机上訓練と実地訓練を組み合わせることで、実効性の高いDR体制を構築できます。