Google Cloud でのディザスタリカバリ計画の立て方

ディザスタリカバリの基本戦略

Google Cloud でのディザスタリカバリ（DR）計画は、ビジネスの継続性を確保する重要な要素です。主に以下の4つの戦略から、ビジネス要件に応じて選択します。

DR戦略タイプ	RPO	RTO	コスト
コールドスタンバイ	24時間以上	24時間以上	最小
ウォームスタンバイ	数時間	数時間	中程度
ホットスタンバイ	数分	数分	高
アクティブ-アクティブ	ゼロ	ゼロ	最大

RPO (Recovery Point Objective)

RPOは「目標復旧地点」と訳されます。

定義: 災害発生時に許容できるデータ損失の最大量を時間で表したものです。
測定対象: 最後のバックアップから災害発生時点までの時間を測定します。
例: RPOが4時間の場合、最大4時間分のデータ損失を許容することを意味します。
ビジネスへの影響: RPOが短いほど、データ損失は少なくなりますが、より頻繁なバックアップが必要となり、コストが高くなります。

RTO (Recovery Time Objective)

RTOは「目標復旧時間」と訳されます。

定義: 災害発生後、システムやサービスを復旧させるまでの目標時間です。
測定対象: 災害発生時点からシステムが再び稼働するまでの時間を測定します。
例: RTOが2時間の場合、災害発生後2時間以内にシステムを復旧させることを目標とします。
ビジネスへの影響: RTOが短いほど、ダウンタイムが短くなりますが、より高度な復旧システムが必要となり、コストが高くなります。

RPOとRTOは、組織のビジネス継続性計画において重要な役割を果たします。これらの値を適切に設定することで、災害時のデータ損失とダウンタイムを最小限に抑えつつ、コストとのバランスを取ることができます。組織の要件、リスク許容度、予算に応じて、適切なRPOとRTOを設定することが重要です。

リージョン選択の考え方

プライマリリージョンの選択基準

レイテンシーの最適化
- ユーザーの地理的分布を考慮
- 例：日本国内向けサービス → asia-northeast1（東京）
- 例：アジア全域向けサービス → singapore-southeast1（シンガポール）
法規制とデータレジデンシー
- 個人情報保護法への対応
- GDPR準拠の必要性
- 例：日本の金融機関 → データを国内に保持（東京/大阪リージョン）
利用可能なサービス
- リージョンによって利用できないサービスがある
- 例：Cloud Spanner → 東京は利用可能、大阪は制限あり
- [リージョン別の利用可能サービス一覧へのリンク]

セカンダリリージョンの選択基準

地理的分散
- 推奨パターン例：
  - 東京(Primary) ↔ 大阪(Secondary)：国内DR
  - 東京(Primary) ↔ ソウル(Secondary)：近距離国際DR
  - 東京(Primary) ↔ シンガポール(Secondary)：広域DR

リージョンペアの特性

東京(asia-northeast1) - 大阪(asia-northeast2):
  - レイテンシ: 約13ms
  - 転送コスト: 国内料金
  - メリット: 法規制対応が容易
  - デメリット: 自然災害の同時影響リスク

東京(asia-northeast1) - ソウル(asia-northeast3):
  - レイテンシ: 約34ms
  - 転送コスト: リージョン間料金
  - メリット: 災害影響の分散
  - デメリット: 国際間データ転送

東京(asia-northeast1) - シンガポール(asia-southeast1):
  - レイテンシ: 約81ms
  - 転送コスト: リージョン間料金（高）
  - メリット: 広域災害への対応
  - デメリット: レイテンシとコスト

ユースケース別推奨構成

金融系システム
- Primary: 東京リージョン
- Secondary: 大阪リージョン
- 理由：
  - データレジデンシー要件の充足
  - 低レイテンシでの同期レプリケーション
  - 金融庁ガイドラインへの対応
Eコマース
- Primary: 東京リージョン
- Secondary: ソウルリージョン
- 理由：
  - 適度な地理的分散
  - コスト効率の良いレプリケーション
  - アジア市場への展開可能性
グローバルSaaS
- Primary: 東京リージョン
- Secondary: シンガポールリージョン
- 理由：
  - グローバルな可用性
  - 広域災害への対応
  - アジア太平洋地域全体のカバー

リージョン選択時の注意点

コスト考慮事項
- リージョン間データ転送料金
- 各リージョンのリソース料金差
- バックアップストレージのコスト
パフォーマンス要件
- アプリケーションの許容レイテンシ
- データ同期の頻度要件
- フェイルオーバー時の性能要件
運用面の考慮
- 監視とオペレーション体制
- 技術者の対応可能時間帯
- 現地サポートの必要性

コンポーネント別の DR 戦略

Compute Engine

スナップショットバックアップ
カスタムイメージの複製
インスタンステンプレートの活用

Cloud Storage

マルチリージョン構成
オブジェクトのライフサイクル管理
バージョニングの活用

Cloud SQL

クロスリージョンレプリケーション
自動バックアップ
読み取りレプリカの配置

その他のサービス

BigQuery：テーブルの複製
Cloud Spanner：マルチリージョン構成
Cloud Filestore：バックアップ計画

DR テストの包括的アプローチ

テストタイプと実施方法

テーブルトップテスト（机上演習）
- 目的: チームの準備状態と計画の論理的検証
- 参加者:
  - インフラチーム
  - アプリケーションチーム
  - 運用チーム
  - ビジネス部門代表
- 実施内容:
```
シナリオ例:
- プライマリデータセンターの火災
- ランサムウェア攻撃
- 重要サービスの広域障害
```
- 所要時間: 2-4時間
- 頻度: 四半期ごと

ウォークスルーテスト（コンポーネントテスト）

目的: 個別コンポーネントの復旧手順の検証

テスト対象:

コンポーネント別テスト項目:
Compute Engine:
  - スナップショットからの復元
  - インスタンステンプレートの検証
  - カスタムイメージの確認

Cloud SQL:
  - フェイルオーバーの実行
  - バックアップからの復元
  - レプリケーションの健全性確認

Cloud Storage:
  - バケットの複製検証
  - オブジェクトのライフサイクル確認
  - バージョニングの動作確認

所要時間: コンポーネントごとに2-8時間
頻度: 月次または隔月

フルスケールテスト（実環境テスト）
- 目的: 本番環境に近い条件での完全な切り替え検証
- 実施手順:
  1. 準備フェーズ
    - チェックリストの確認
    - 監視体制の確立
    - ロールバック手順の確認
  2. 実行フェーズ
```
手順:
- トラフィック転送の準備
- データ同期の最終確認
- アプリケーション切り替え
- DNS切り替え
- 監視システムの確認
```
  3. 検証フェーズ
    - 全機能の動作確認
    - パフォーマンス測定
    - データ整合性の確認
- 所要時間: 8-24時間
- 頻度: 半年または年次

テスト実施のベストプラクティス

事前準備

ドキュメント整備
- 手順書の最新化
- 連絡先リストの更新
- チェックリストの準備

環境準備

確認項目:
- バックアップの最新性
- 必要なツールのインストール
- アクセス権限の確認
- 監視システムの準備

テスト実施時の注意点
- コミュニケーション
  - 定期的なステータス報告
  - 問題発生時の即時報告
  - 完了判定の明確化
- メトリクス測定
```
測定項目:
- RTO（実測値）
- RPO（実測値）
- エラー発生数
- 復旧成功率
```
事後評価
- レポート作成
  - 実施結果のサマリー
  - 発見された課題
  - 改善提案
- フィードバックループ
```
アクション項目:
- 手順書の更新
- 自動化の検討
- トレーニング計画の見直し
```

テスト結果の評価基準

定量的指標

基準値:
重要度High:
  RTO: 4時間以内
  RPO: 15分以内
  成功率: 99%以上

重要度Medium:
  RTO: 8時間以内
  RPO: 1時間以内
  成功率: 95%以上

定性的指標
- チーム間連携の効率性
- 問題解決の迅速性
- ドキュメントの正確性

継続的改善のサイクル

テスト結果の分析
- パターン分析
- ボトルネックの特定
- リスク評価
改善計画の策定
- 自動化の拡大
- 手順の簡素化
- 新技術の導入検討

インシデント対応計画

役割と責任

インシデントコマンダー
テクニカルリード
コミュニケーションリード

エスカレーションフロー

検知と評価
初期対応
エスカレーション判断
リカバリ実行

コミュニケーション計画

内部関係者への通知
顧客への通知
規制当局への報告

モニタリングと改善

主要な監視指標

RPO/RTO の達成状況
フェイルオーバー成功率
リカバリ時間の実測値

継続的な改善

インシデント後のレビュー
定期的な計画の見直し
新技術の評価と導入

参考リソース

公式ドキュメント：