障害復旧計画ガイド

この記事は、Google Cloud Platform(GCP)での障害復旧(DR)に関して説明する、複数のパートからなるシリーズの第 1 部です。ここでは、DR 計画プロセスの概要、つまり、DR 計画を設計して実装するために必要な情報を紹介します。以降のパートでは、GCP での実装例を使った具体的な DR の使用事例について説明します。

シリーズは次のパートで構成されています。

はじめに

サービスが中断される事態はいつでも発生する可能性があります。ネットワークに障害が発生したり、最新のアプリケーション更新が重大なバグを引き起こしたりすることがあり、自然災害への対処が必要になる場合もあります。予想外の事態が発生した場合に備え、十分に検証された、対象が明確で信頼性の高い DR 計画を作成することが重要です。

適切に設計され、十分に検証された障害復旧計画を準備することで、災害に遭遇した場合の業務上の利益への影響を最小限に抑えられます。Google Cloud Platform(GCP)が提供する、どのような DR のニーズにも対処できる信頼性と費用対効果の高いプロダクトや機能を柔軟に利用して、それぞれのお客様に合ったソリューションを構築または強化できます。

DR 計画の基本

DR は事業継続計画の一環です。DR 計画はビジネスへの影響の分析から着手します。この分析で次の 2 つの重要指標を定義します。

  • 復旧時間目標(RTO)。アプリケーションがオフラインである状態が許容される最大時間です。この値は、通常、より広範なサービスレベル契約(SLA)の一部として定義されます。
  • 復旧時点目標(RPO)。重大なインシデントが原因でアプリケーションからデータが失われている状態が許容される最大時間です。この指標はデータの用途によって異なります。たとえば、頻繁に変更されるユーザーデータの場合、RPO はわずか数分の可能性があります。対照的に、あまり頻繁に変更されない重大度が低いデータの場合、RPO は数時間ということもあり得ます(この指標は、失われたデータの量や質ではなく時間の長さのみを表します)。

通常、RTO と 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 を実現することで、平常時よりも多くの処理が発生した場合でも運用パフォーマンス(通常は稼働時間の長さ)の合意レベルを維持できます。GCP で本番環境のワークロードを実行する場合、グローバル分散システムを使用することで、1 つのリージョンで障害が発生しても、アプリケーションによるサービス提供は継続されます(サービスが提供されるリージョンは限定される場合があります)。要するに、そのアプリケーションによってそれ自体の DR 計画が開始されます。

GCP を選ぶ理由

GCP を使用すると、RTO と RPO の要件をオンプレミスで満たす場合に比べ、RTO と RPO の両方に関連するコストを大幅に削減できます。たとえば、従来の DR 計画では、次のような要件を満たす必要があります。

  • 容量: 必要に応じたスケーリングに十分なリソースを確保する。
  • セキュリティ: 資産を保護するための物理的なセキュリティ対策を実施する。
  • ネットワーク インフラストラクチャ: ファイアウォールやロードバランサなどのソフトウェア コンポーネントを含める。
  • サポート: 保守を実施し、問題に対処する熟練した技術者を配備する。
  • 帯域幅: 負荷のピークに対応可能な帯域幅を計画する。
  • 設備: 機器や電源などの物理的なインフラストラクチャを確保する。

GCP には、世界屈指の本番環境プラットフォームに基づく優れたマネージド ソリューションが用意されています。それにより、上記のような複雑な要件の大半は不要になり、さまざまな業務コストを削減できます。さらに、GCP では効率的な運用が重視されているため、複雑なアプリケーションの運用コストも削減されます。

GCP は、DR 計画に役立つ以下のような特長を備えています。

  • グローバル ネットワーク。Google のコンピュータ ネットワークは、その規模、先進性ともに世界有数を誇ります。Google のバックボーン ネットワークでは、数千キロの光ファイバー ケーブルや先進的な SDN(Software Defined Network)が使用されており、エッジ キャッシング サービスにより高速で安定したスケーラブルなパフォーマンスを実現します。
  • 冗長性。世界中に展開された拠点(PoP)により、優れた冗長性を実現しています。データは複数のロケーションにあるストレージ デバイスに自動的にミラーリングされます。
  • スケーラビリティ。GCP は、Google の他のプロダクト(検索や Gmail など)と同様に、トラフィックが急増してもスケールできるように設計されています。App Engine、Compute Engine オートスケーラー、Cloud Datastore などのマネージド サービスによって、アプリケーションを必要に応じて拡大したり縮小したりできる自動スケーリングが実現します。
  • セキュリティGoogle セキュリティ モデルは、Gmail や G Suite などの Google アプリケーションで 15 年以上にわたってお客様のセキュリティを保護してきた、豊富な経験に基づいて構築されています。さらに、Google のサイト信頼性エンジニアリング チームが、プラットフォーム リソースの高可用性を確保し、リソースの悪用を防止します。
  • コンプライアンス。Google は第三者による監査を定期的に実施し、GCP がセキュリティ、プライバシー、コンプライアンスの各規制とベスト プラクティスに適合しているか確認します。GCP は、ISO 27001、SOC 2/3、PCI DSS 3.0 などの認証規格に準拠しています。

DR のパターン

DR のパターンには、「コールド」、「ウォーム」、「ホット」があります。パターンは、障害が発生したときにシステムをどの程度簡単に復旧できるかを示しています。このパターンは、車の運転中にタイヤがパンクしたときの対処にたとえられます。

車のタイヤがパンクしたシナリオの 3 枚の写真(スペアタイヤがない場合、スペアタイヤとタイヤ交換用の工具がある場合、ランフラット タイヤを使っている場合)。

パンクに対処する方法は、どのような準備をしているかによって異なります。

  • コールド: スペアタイヤを用意していないため、業者などに連絡して、現場で新しいタイヤに交換してもらう必要があります。タイヤの交換が済むまでは停車したままです。
  • ウォーム: スペアタイヤと交換キットを車に搭載しているので、それを使用して自分でタイヤを交換し、運転を再開できます。ただし、いったん停車してタイヤを交換しなければなりません。
  • ホット: 車にランフラット タイヤを装着しています。多少はスピードを緩める必要はありますが、行程に直接の影響はありません。このタイヤで引き続き走行できます(ただし、最終的にはタイヤの修理が必要です)。

詳細な DR 計画の作成

このセクションでは、DR 計画を作成する際の推奨事項を示します。

復旧の目標に応じた設計

DR 計画を策定する際は、アプリケーションとデータの復旧手法を組み合わせて、より大きな全体像を見る必要があります。一般的な方法として、まず RTO と RPO の値を見て、それぞれの値に合った適切な DR パターンを採用します。たとえば、過去のコンプライアンス関連データの場合、急いでデータにアクセスする必要はないと考えられます。したがって、RTO 値を大きめに設定し、コールド DR パターンを採用するのが妥当です。しかし、オンライン サービスが中断した場合は、データも、アプリケーションのお客様に表示される部分もできるだけ迅速に復旧できなければなりません。この場合は、ホット DR パターンが適切です。メール通知システムの場合、通常は業務に不可欠というわけではないため、ウォーム DR パターンが妥当と考えられます。

GCP を使用して一般的な DR シナリオに対処する方法については、アプリケーションの復旧シナリオをご覧ください。このシナリオ集には、さまざまな使用事例を対象とした DR 手法が収録され、事例ごとに GCP での実装例が紹介されています。

エンドツーエンドの復旧のための設計

データのバックアップやアーカイブの計画を作成するだけでは十分ではありません。DR 計画は復旧プロセス全体、つまり、バックアップから復旧へ、復旧からクリーンアップへと続くプロセスをすべて網羅している必要があります。これについては、DR のデータと復旧に関する関連ドキュメントをご覧ください。

タスクの具体化

DR 計画を実行に移す時点までに、各ステップの意味を明確にしておく必要があります。DR 計画の各タスクは、具体的かつ明確な 1 つ以上のコマンドとアクションで構成されるようにします。たとえば、「復元スクリプトを実行する」では大まかすぎます。それに対し、「Bash を開き、/home/example/restore.sh を実行する」という指示は正確で具体的です。

制御対策の導入

障害の発生を防ぎ、問題が表に現れる前に検出するための制御対策を組み込みます。たとえば、削除パイプラインなどのデータ破壊フローによって予想外の処理の急増や他の異常動作が発生したときにアラートを送信する、モニターを追加します。このモニターは、特定の削除しきい値に到達した場合に、取り返しのつかない事態が起こらないようにパイプライン プロセスを強制終了することもできます。

ソフトウェアの準備

DR 計画の一環として、利用するソフトウェアが復旧イベントに対応できる状態になっていることを確認します。

ソフトウェアがインストール可能かどうかの確認

アプリケーション ソフトウェアが提供元から、または構成済みイメージからインストールできることを確認します。GCP にデプロイするソフトウェアのライセンスが適切に付与されていることを確認してください。ガイダンスが必要であれば、ソフトウェアのサプライヤーに問い合わせてください。

復旧のための継続的デプロイの設計

継続的デプロイ(CD)のツールセットは、アプリケーションをデプロイする際に欠かせないコンポーネントです。復旧計画の一環として、復旧する環境のどこにアーティファクトをデプロイするかを検討する必要があります。CD 環境とアーティファクトは障害発生時に使用できる状態にしておく必要があるため、これらをホストする場所を計画してください。

セキュリティ管理とコンプライアンス管理の実装

DR 計画の策定ではセキュリティが重要です。本番環境に適用している管理手法を復旧した環境にも適用する必要があります。復旧した環境はコンプライアンス規制の対象になります。

DR 環境と本番環境での同一セキュリティの構成

現在使っているネットワーク管理で、元の本番環境と同じ分離機能とブロック機能が提供されることを確認します。デプロイのネットワーキングとセキュリティの集中管理、サブネットの構成、インバウンド トラフィックとアウトバウンド トラフィックの制御などを実施できるよう、共有 VPCGCP ファイアウォールを適切に構成する方法を確認してください。サービス アカウントを使用して GCP API にアクセスするアプリケーションに最小限の権限を適用する方法を確認します。サービス アカウントは必ずファイアウォール ルールに沿って使用してください。

ユーザーには、DR 環境でも元の本番環境のときと同じアクセス権を付与してください。2 つの環境間で権限を同期する方法を次のリストで示します。

  • 本番環境が GCP の場合、IAM ポリシーを DR 環境に複製すると簡単です。Infrastructure as Code(IAC)方式を使用し、Cloud Deployment Manager などのツールを利用すると、Cloud IAM ポリシーを本番環境にデプロイできます。さらに同じツールを使用して、DR 環境の起動プロセスの中で、このポリシーを DR 環境内の対応するリソースにバインドします。

  • 本番環境がオンプレミスの場合、ネットワーク管理者役割や監査担当者役割などの職務役割を、相応の IAM 役割を含む IAM ポリシーにマッピングします。IAM のドキュメントに、職務役割の構成例が記載されています。たとえば、ネットワーキング監査ロギングの職務的な役割の作成に関するドキュメントをご覧ください。

  • IAM ポリシーを、プロダクトに対する適切な権限を付与するように構成する必要があります。たとえば、特定の Cloud Storage バケットに対するアクセスを制限します。

  • 本番環境が別のクラウド プロバイダである場合は、そのプロバイダの IAM 内の権限を GCP の IAM ポリシーにマッピングします。たとえば、本番環境が AWS である場合は、その詳細について AWS プロフェッショナルのための Google Cloud Platform: 管理をご覧ください。

DR のセキュリティの確認

DR 環境の権限を構成した後は、すべての内容をテストする必要があります。そのためのテスト環境を作成してください。Cloud Deployment Manager などのツールを利用する IAC 方式を使用して、IAM ポリシーをテスト環境にデプロイします。ユーザーに付与したアクセス権で、オンプレミスと同じ権限がユーザーに適用されることを確認してください。

ユーザーが DR 環境にログインできるかどうかの確認

障害の発生に備えて、ユーザーが DR 環境にアクセスできることも確認してください。組織内のユーザー、開発者、オペレータ、データ サイエンティスト、セキュリティ管理者、ネットワーク管理者といった役割に、それぞれ適切な権限を付与していることを確認します。代替の ID システムを使用している場合は、そのシステムのアカウントが Cloud Identity アカウントに同期されていることを確認します。しばらくの間は DR 環境が本番環境になるため、DR 環境にアクセスする必要があるユーザーがログインできるようにして、認証に問題があれば解決してください。DR 環境にログインするユーザーを、実施する通常の DR テストに組み込みます。

起動された仮想マシン(VM)への SSH アクセス権を持つユーザーを集中管理するには、DR 環境を構成する GCP プロジェクトで OS ログイン機能を有効にします。

ユーザーのトレーニング

ユーザーが本番環境で慣れている、ログインや VM へのアクセスといった操作を GCP で行う方法を、ユーザーに理解してもらう必要があります。テスト環境を使用して、システムのセキュリティを保護しながらこうした操作を行う方法のトレーニングを実施します。

DR 環境がコンプライアンス要件を満たしているかどうかの確認

DR 環境にアクセスする必要があるユーザーだけにアクセス権が付与されていることを確認してください。PII データは必ず編集し、暗号化してください。本番環境で通常のペネトレーション テストを実施する場合は、対象範囲に DR 環境を含めてください。DR 環境を起動して通常のテストを実施します。

DR 環境が稼働している間、収集したログがすべて本番環境のログアーカイブにバックフィルされることを確認してください。同様に、DR 環境の中で、Stackdriver を通じて収集された監査ログをメインのログシング アーカイブにエクスポートできることも確認します。これにはエクスポート シンク機能を使用します。アプリケーション ログの場合は、オンプレミスのロギングとモニタリングの環境のミラーを作成します。本番環境が別のクラウド プロバイダの場合は、そのプロバイダのロギングとモニタリングの環境を同等の GCP サービスにマッピングします。本番環境への入力をフォーマットするプロセスを作成してください。

日々のバックアップ ルーチンでの Cloud Storage の使用

バックアップの保存には Cloud Storage を使用します。バックアップを含むバケットに適切な権限が適用されていることを確認してください。

シークレットの適切な管理

アプリケーション レベルのシークレットと鍵を管理するには、GCP を使用して鍵 / シークレット管理サービス(KMS)をホストします。Cloud KMS やサードパーティ ソリューション(HashiCorp Vault など)を Cloud SpannerCloud Storage といった GCP バックエンドと一緒に使用できます。

復旧したデータを本番環境のデータと同等に扱う

本番環境のデータに適用するセキュリティ管理は、必ず復旧したデータにも適用してください。権限、暗号化、監査の要件はすべて同じものを適用します。

バックアップが格納されている場所と、データの復元権限を持つ担当者を把握してください。復旧プロセスは確実に監査可能でなければなりません。障害復旧後に、バックアップ データへのアクセス権を保有していた担当者や復旧を実施した担当者を明らかにできるようにしてください。

DR 計画の実効性の確認

実際に障害が起こった場合にすべての計画が想定どおりに実施されるかを確かめて、その計画の実効性を確認します。

複数のデータ復旧パスの保持

障害が発生すると、GCP への接続手段が利用できなくなる可能性があります。データを確実に GCP に転送できるように、GCP への代替のアクセス手段を実装しておきます。そのバックアップ パスが機能するか、定期的にテストしてください。

計画の定期的なテスト

DR 計画を準備したら、定期的にテストし、発生した問題を調べて計画を適宜調整します。GCP を使用すると、最小コストで復旧のシナリオをテストできます。テストに役立つよう、以下を実施することをおすすめします。

  • Deployment Manager によってインフラストラクチャのプロビジョニングを自動化する。VM インスタンスやその他の GCP インフラストラクチャのプロビジョニングを自動化するには、Cloud Deployment Manager を使用します。本番環境をオンプレミスで実行している場合は、モニタリング プロセスを用意する必要があります。このプロセスにより、障害が検出されると DR プロセスが開始され、適切な復旧アクションがトリガーされます。
  • Stackdriver Logging や Stackdriver Monitoring によってテストのモニタリングとデバッグを行う。GCP には、API 呼び出しによってアクセスできるロギングとモニタリング用の優れたツールが用意されています。こうしたツールを利用すると、指標に反応して、復旧シナリオのデプロイが自動的に行われます。テストを設計する際は、適切なモニタリング機能とアラート機能を用意して、状況に応じた復旧アクションがトリガーされるようにしてください。
  • これまで述べたテストを実行する。

    • 権限とユーザーのアクセス権が DR 環境でも本番環境と同様に機能するかテストします。
    • DR 環境でペネトレーション テストを実施します。
    • GCP への通常のアクセスパスのうち、どのパスが機能していないか確認するためのテストを実施します。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...