このドキュメントは、Google Cloud の障害復旧（DR）について説明するシリーズのパート 1 です。ここでは、DR 計画プロセスの概要、つまり、DR 計画を設計して実装するために必要な情報を紹介します。以降のパートでは、Google Cloud での実装例を使った具体的な DR の使用事例について説明します。
このシリーズは、次のパートで構成されています。
- 障害復旧計画ガイド（このドキュメント）
- 障害復旧の構成要素
- データの障害復旧シナリオ
- アプリケーションの障害復旧シナリオ
- 地域制限があるワークロードの障害復旧の設計
- 障害復旧のユースケース: 地域制限のあるデータ分析アプリケーション
- クラウド インフラストラクチャの停止に対する障害復旧の設計
はじめに
サービスが中断される事態はいつでも発生する可能性があります。ネットワークに障害が発生することや、最新のアプリケーション更新が重大なバグを引き起こすことがあり、自然災害への対処が必要になる場合もあります。予想外の事態が発生した場合に備え、十分に検証された、対象が明確で信頼性の高い DR 計画を作成することが重要です。
適切に設計され、十分に検証された DR 計画を準備することで、災害に遭遇した場合の業務上の利益への影響を最小限に抑えられます。Google Cloud が提供する、どのような DR のニーズにも対処できる信頼性と費用対効果の高いプロダクトや機能を柔軟に利用して、それぞれのお客様に合ったソリューションを構築または強化できます。
DR 計画の基本
DR は事業継続計画の一環です。DR 計画はビジネスへの影響の分析から着手します。この分析で次の 2 つの主要な指標を定義します。
- 復旧時間目標（RTO）。アプリケーションがオフラインである状態が許容される最大時間です。通常、この値はサービスレベル契約（SLA）の一部として定義されます。
- 復旧時点目標（RPO）。重大なインシデントが原因でアプリケーションからデータが失われている状態が許容される最大時間です。この指標はデータの用途によって異なります。たとえば、頻繁に変更されるユーザーデータの場合、RPO はわずか数分になる可能性があります。対照的に、重要度が低く、変更頻度が低いデータの場合、RPO は数時間になることもあります（この指標は、失われたデータの量や質ではなく時間の長さのみを表します）。
通常、RTO と RPO の値が小さいほど（つまり、アプリケーションを中断状態から復旧する時間が急がれるほど）、アプリケーションの実行コストは高くなります。次のグラフは RTO / RPO に対するコストの割合を示しています。
RTO と RPO の値が小さいと管理の複雑性が増す傾向にあるため、それに伴う管理諸経費も同様の曲線を描きます。高可用性のアプリケーションを維持するには、地理的に離れた 2 つのデータセンター間でデータを分散したり、複製を実施したりすることが求められます。
RTO と RPO の値は通常、サービスレベル目標（SLO）という別の指標に含められます。SLO は SLA の測定可能な重要要素であり、多くの場合、SLA と SLO は併用されます。SLA は、提供されるサービスの内容、サービスのサポート方法、時間、ロケーション、コスト、パフォーマンス、ペナルティ、当事者の責任を包括的に規定する契約です。SLO は、SLA の個々の測定可能な特性（可用性、スループット、頻度、レスポンス時間、品質など）を表します。1 つの SLA に多数の SLO が含まれる可能性があります。RTO と RPO は測定可能であるため、SLO と見なされます。
SLO と SLA の詳細については、Google の書籍『Site Reliability Engineering』をご覧ください。
高可用性（HA）を確保するためのアーキテクチャの計画も必要になる場合があります。HA は DR とまったく同義というわけではありませんが、RTO と RPO の値を検討する際には、普通 HA も考慮する必要があります。HA を実現することで、平常時よりも多くの処理が発生した場合でも運用パフォーマンス（通常は稼働時間の長さ）の合意レベルを維持できます。Google Cloud で本番環境のワークロードを実行する場合、グローバル分散システムを使用することで、1 つのリージョンで障害が発生しても、アプリケーションによるサービス提供は継続されます（サービスが提供されるリージョンは限定される場合があります）。要するに、そのアプリケーションによってそれ自体の DR 計画が開始されます。
Google Cloud を選ぶ理由
Google Cloud を使用すると、RTO と RPO の要件をオンプレミスで満たす場合に比べ、RTO と RPO の両方に関連するコストを大幅に削減できます。たとえば、従来の DR 計画では、次のような要件を満たす必要があります。
- 容量: 必要に応じたスケーリングに十分なリソースを確保する。
- セキュリティ: 資産を保護するための物理的なセキュリティ対策を実施する。
- ネットワーク インフラストラクチャ: ファイアウォールやロードバランサなどのソフトウェア コンポーネントを含める。
- サポート: 保守を実施し、問題に対処する熟練した技術者を配備する。
- 帯域幅: 負荷のピークに対応可能な帯域幅を計画する。
- 設備: 機器や電源などの物理的なインフラストラクチャを確保する。
Google Cloud には、世界屈指の本番環境プラットフォームに基づく優れたマネージド ソリューションが用意されています。それにより、上記のような複雑な要件の大半は不要になり、さまざまな業務コストを削減できます。さらに、Google Cloud では効率的な運用が重視されているため、複雑なアプリケーションの運用コストも削減されます。
Google Cloud は、DR 計画に役立つ以下のような特長を備えています。
- グローバル ネットワーク。Google のコンピュータ ネットワークは、その規模、先進性ともに世界有数を誇ります。Google のバックボーン ネットワークでは、高度なソフトウェア定義ネットワーキングやエッジ キャッシング サービスを使用して、高速で安定したスケーラブルなパフォーマンスを実現しています。
- 冗長性。世界中に展開された拠点（PoP）により、優れた冗長性を実現しています。データは複数のロケーションにあるストレージ デバイスに自動的にミラーリングされます。
- スケーラビリティ。Google Cloud は、Google の他のプロダクト（検索や Gmail など）と同様に、トラフィックが急増してもスケールできるように設計されています。App Engine、Compute Engine オートスケーラー、Datastore などのマネージド サービスによって、アプリケーションを必要に応じて拡大および縮小できる自動スケーリングが実現します。
- セキュリティ。Google セキュリティ モデルは、Gmail や Google Workspace などの Google アプリケーションで 15 年以上にわたってお客様のセキュリティを保護してきた、豊富な経験に基づいて構築されています。さらに、Google のサイト信頼性エンジニアリング チームが、プラットフォーム リソースの高可用性を確保し、リソースの悪用を防止します。
- コンプライアンス。Google は独立した第三者による監査を定期的に実施し、Google Cloud がセキュリティ、プライバシー、コンプライアンスの各規制とベスト プラクティスに適合しているか確認します。Google Cloud は、ISO 27001、SOC 2/3、PCI DSS 3.0 などの認証規格に準拠しています。
DR のパターン
DR のパターンには、「コールド」、「ウォーム」、「ホット」があります。パターンは、障害が発生したときにシステムをどの程度簡単に復旧できるかを示しています。このパターンは、車の運転中にタイヤがパンクしたときの対処にたとえられます。
パンクに対処する方法は、どのような準備をしているかによって異なります。
- コールド: スペアタイヤを用意していないため、業者などに連絡して、現場で新しいタイヤに交換してもらう必要があります。タイヤの交換が済むまでは停車したままです。
- ウォーム: スペアタイヤと交換キットを車に搭載しているので、それを使用して自分でタイヤを交換し、運転を再開できます。ただし、いったん停車してタイヤを交換しなければなりません。
- ホット: 車にランフラット タイヤを装着しています。多少はスピードを緩める必要はありますが、行程に直接の影響はありません。このタイヤで引き続き走行できます（ただし、最終的にはタイヤの修理が必要です）。
詳細な DR 計画の作成
このセクションでは、DR 計画を作成する際の推奨事項を示します。
復旧の目標に応じた設計
DR 計画を策定する際は、アプリケーションとデータの復旧手法を組み合わせて、より大きな全体像を見る必要があります。一般的な方法として、まず RTO と RPO の値を見て、それぞれの値に合った適切な DR パターンを採用します。たとえば、過去のコンプライアンス関連データの場合、急いでデータにアクセスする必要はないと考えられます。したがって、RTO 値を大きめに設定し、コールド DR パターンを採用するのが妥当です。しかし、オンライン サービスが中断した場合は、データも、アプリケーションのお客様に表示される部分もできるだけ迅速に復旧できなければなりません。この場合は、ホット DR パターンが適切です。メール通知システムの場合、通常は業務に不可欠というわけではないため、ウォーム DR パターンが妥当と考えられます。
Google Cloud を使用して一般的な DR シナリオに対処する方法については、アプリケーションの復旧シナリオをご覧ください。このシナリオ集には、さまざまな使用事例を対象とした DR 手法が収録され、事例ごとに Google Cloud での実装例が紹介されています。
エンドツーエンドの復旧のための設計
データのバックアップやアーカイブの計画を作成するだけでは十分ではありません。DR 計画は復旧プロセス全体、つまり、バックアップから復旧へ、復旧からクリーンアップへと続くプロセスをすべて網羅している必要があります。これについては、DR のデータと復旧に関する関連ドキュメントをご覧ください。
タスクの具体化
DR 計画を実行に移す時点までに、各ステップの意味を明確にしておく必要があります。DR 計画の各タスクは、具体的かつ明確な 1 つ以上のコマンドとアクションで構成されるようにします。たとえば、「復元スクリプトを実行する」では大まかすぎます。それに対し、「Bash を開き、/home/example/restore.sh を実行する」という指示は正確で具体的です。
制御対策の導入
障害の発生を防ぎ、問題が表に現れる前に検出するための制御対策を組み込みます。たとえば、削除パイプラインなどのデータ破壊フローによって予想外の処理の急増や他の異常動作が発生したときにアラートを送信する、モニターを追加します。このモニターは、特定の削除しきい値に到達した場合に、取り返しのつかない事態が起こらないようにパイプライン プロセスを強制終了することもできます。
ソフトウェアの準備
DR 計画の一環として、利用するソフトウェアが復旧イベントに対応できる状態になっていることを確認します。
ソフトウェアがインストール可能かどうかの確認
アプリケーション ソフトウェアが提供元から、または構成済みイメージからインストールできることを確認します。Google Cloud にデプロイするソフトウェアのライセンスが適切に付与されていることを確認してください。ガイダンスが必要であれば、ソフトウェアのサプライヤーに問い合わせてください。
必要な Compute Engine リソースがリカバリ環境で使用可能であることを確認します。インスタンスの事前割り当てや予約が必要になることもあります。
復旧のための継続的デプロイの設計
継続的デプロイ（CD）のツールセットは、アプリケーションをデプロイする際に欠かせないコンポーネントです。復旧計画の一環として、復旧する環境のどこにアーティファクトをデプロイするかを検討する必要があります。CD 環境とアーティファクトは障害発生時に使用できる状態にしておく必要があるため、これらをホストする場所を計画してください。
セキュリティ管理とコンプライアンス管理の実装
DR 計画の策定ではセキュリティが重要です。本番環境に適用している管理手法を復旧した環境にも適用する必要があります。復旧した環境はコンプライアンス規制の対象になります。
DR 環境と本番環境での同一セキュリティの構成
現在使っているネットワーク管理で、元の本番環境と同じ分離機能とブロック機能が提供されることを確認します。デプロイのネットワーキングとセキュリティの集中管理、サブネットの構成、インバウンド トラフィックとアウトバウンド トラフィックの制御などを実施できるよう、共有 VPC とファイアウォールを適切に構成する方法を確認してください。サービス アカウントを使用して Google Cloud APIs にアクセスするアプリケーションに最小権限を適用する方法を確認します。サービス アカウントは必ずファイアウォール ルールに沿って使用してください。
ユーザーには、DR 環境でも元の本番環境のときと同じアクセス権を付与してください。2 つの環境間で権限を同期する方法を次のリストで示します。
本番環境が Google Cloud の場合、IAM ポリシーを DR 環境に複製すると簡単です。Terraform などの Infrastructure as Code（IaC）ツールを利用すると、IAM ポリシーを本番環境にデプロイ適用できます。さらに、同じツールを使用して、DR 環境の起動プロセスの中で、このポリシーを DR 環境内の対応するリソースにバインドします。
本番環境がオンプレミスの場合、ネットワーク管理者ロールや監査担当者ロールなどの職務上のロールを、相応の IAM ロールを含む IAM ポリシーにマッピングします。IAM のドキュメントには、職務上のロールの構成例が記載されています。たとえば、ネットワーキングや監査ロギングの職務上のロールの作成に関するドキュメントをご覧ください。
IAM ポリシーは、プロダクトに対する適切な権限を付与するように構成する必要があります。たとえば、特定の Cloud Storage バケットに対するアクセスを制限したいとします。
本番環境が別のクラウド プロバイダである場合は、そのプロバイダの IAM ポリシー内の権限を Google Cloud IAM ポリシーにマッピングします。
DR のセキュリティの確認
DR 環境の権限を構成した後は、すべての内容をテストする必要があります。そのためのテスト環境を作成してください。Terraform などの IaC ツールを使用して、Google Cloud ポリシーをテスト環境にデプロイします。ユーザーに付与する権限が、オンプレミスで付与されている権限と一致していることを確認します。
ユーザーが DR 環境にアクセスできることを確認する
障害の発生に備えて、ユーザーが DR 環境にアクセスできることを確認してください。組織内のユーザー、開発者、オペレーター、データ サイエンティスト、セキュリティ管理者、ネットワーク管理者といった役割に、それぞれ適切な権限を付与していることを確認します。代替の ID システムを使用している場合は、そのシステムのアカウントが Cloud Identity アカウントに同期されていることを確認します。しばらくの間は DR 環境が本番環境になるため、DR 環境にアクセスする必要があるユーザーがログインできるようにして、認証に問題があれば解決してください。DR 環境にログインするユーザーを、実施する通常の DR テストに組み込みます。
起動された仮想マシン（VM）への SSH アクセス権を持つユーザーを集中管理するには、DR 環境を構成する Google Cloud プロジェクトで OS Login 機能を有効にします。
ユーザーをトレーニングする
ユーザーが本番環境で慣れている、ログインや VM へのアクセスといった操作を Google Cloud で行う方法を、ユーザーに理解してもらう必要があります。テスト環境を使用して、システムのセキュリティを保護しながらこうした操作を行う方法のトレーニングを実施します。
DR 環境がコンプライアンス要件を満たしているかどうかの確認
DR 環境にアクセスする必要があるユーザーだけにアクセス権が付与されていることを確認してください。PII データは必ず編集し、暗号化してください。本番環境で通常のペネトレーション テストを実施する場合は、対象範囲に DR 環境を含めてください。DR 環境を起動して通常のテストを実施します。
DR 環境が稼働している間、収集したログがすべて本番環境のログアーカイブにバックフィルされることを確認してください。同様に、DR 環境の中で、Cloud Logging を通じて収集された監査ログをメインのログシング アーカイブにエクスポートできることも確認します。これにはエクスポート シンク機能を使用します。アプリケーション ログの場合は、オンプレミスのロギングとモニタリングの環境のミラーを作成します。本番環境が別のクラウド プロバイダの場合は、そのプロバイダのロギングとモニタリングの環境を同等の Google Cloud サービスにマッピングします。本番環境への入力をフォーマットするプロセスを作成してください。
日々のバックアップ ルーチンで Cloud Storage を使用する
バックアップの保存には Cloud Storage を使用します。バックアップを含むバケットに適切な権限が適用されていることを確認してください。
シークレットの適切な管理
アプリケーション レベルのシークレットと鍵を管理するには、Google Cloud を使用して鍵 / シークレット管理サービス（KMS）をホストします。Cloud KMS やサードパーティ ソリューション（HashiCorp Vault など）を Spanner や Cloud Storage といった Google Cloud バックエンドと一緒に使用できます。
復旧したデータを本番環境のデータと同等に扱う
本番環境のデータに適用するセキュリティ管理は、必ず復旧したデータにも適用してください。権限、暗号化、監査の要件はすべて同じものを適用します。
バックアップが格納されている場所と、データの復元権限を持つ担当者を把握してください。復旧プロセスは確実に監査可能でなければなりません。障害復旧後に、バックアップ データへのアクセス権を保有していた担当者や復旧を実施した担当者を明らかにできるようにしてください。
DR 計画の実効性の確認
障害が発生した場合に DR 計画が意図したとおりに機能することを確認してください。
複数のデータ復旧パスの保持
障害が発生すると、Google Cloud への接続手段が利用できなくなる可能性があります。データを確実に Google Cloud に転送できるように、Google Cloud への代替のアクセス手段を実装しておきます。そのバックアップ パスが機能するか、定期的にテストしてください。
計画の定期的なテスト
DR 計画を作成したら、定期的にテストし、発生した問題を記録して、それに応じて計画を調整します。Google Cloud を使用すると、最小コストで復旧のシナリオをテストできます。テストに役立つよう、以下を実装することをおすすめします。
- インフラストラクチャのプロビジョニングを自動化する。Terraform などの IaC ツールを使用すると、VM インスタンスやその他の Google Cloud インフラストラクチャのプロビジョニングを自動化できます。本番環境をオンプレミスで実行する場合は、モニタリング プロセスを用意する必要があります。このプロセスにより、障害が検出されると DR プロセスが開始され、適切な復旧アクションがトリガーされます。
- Cloud Logging と Cloud Monitoring によるテストのモニタリングとデバッグGoogle Cloud には、API 呼び出しによってアクセスできるロギングとモニタリング用の優れたツールが用意されています。こうしたツールを利用すると、指標に反応して、復旧シナリオのデプロイが自動的に行われます。テストを設計する際は、適切なモニタリング機能とアラート機能を用意して、状況に応じた復旧アクションがトリガーされるようにしてください。
これまで述べたテストを実行する。
- 権限とユーザーのアクセス権が DR 環境でも本番環境と同様に機能するかテストします。
- DR 環境でペネトレーション テストを実施します。
- Google Cloud への通常のアクセスパスのうち、どのパスが機能していないか確認するためのテストを実施します。
次のステップ
- Google Cloud の地域とリージョンを確認する。
- この DR シリーズの他のドキュメントを見る。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。