災害復旧計画の設計方法

サービスが中断される事態はいつでも発生する可能性があります。ネットワークに障害が発生したり、最新のアプリケーションが重大なバグを引き起こしたり、まれに、自然災害への対処が必要になる場合があります。

状況が改善しない場合に備えて、堅牢で目的が明確、かつ十分にテストされた災害復旧計画を用意しておくことが重要です。このトピックでは、Google Cloud Platform を使用して災害復旧計画を作成し、テストするための一般的な原則について説明します。

災害復旧計画の基本

災害復旧計画は、事業継続計画のサブセットとして、事業に与える影響の分析から開始します。この分析の背景にある概念から、次の 2 つの主要な指標が明らかになります。

  • 復旧時間目標(RTO)。アプリケーションがオフラインであることが許容される最大時間です。この値は、通常、より大きなサービスレベル契約(SLA)の一部として定義されます。
  • 復旧時点目標(RPO)。重大な事故が原因でアプリケーションからデータが失われることが許容される最大期間です。この指標はデータがどのように使用されるかによって変化します。たとえば、頻繁に変更されるユーザーデータの RPO は数分ですが、あまり重要でなく、変更頻度の低いデータの RPO は数時間になります。この指標は期間を示すだけで、失われるデータの量や質には対応できません。

RTO と RPO を組み合わせて、利益に対するおおよその影響を算出することができます。一般的には、RTO 値と RPO 値が小さくなると、アプリケーション実行コストが増大します。

RTO/RPO のコスト比率
図 1: RTO/RPO のコスト比率

RTO 値と RPO 値が小さいと複雑さが増す傾向にあるため、関連する管理諸経費も同様の曲線を描きます。優れた可用性を備えたアプリケーションでは、2 つの物理的に分離したデータセンター間で分散して管理したり、複製を管理したりする方法が適切な場合があります。

Google Cloud Platform を選ぶ理由

Google Cloud Platform は RTO と RPO に関連するコストをどちらも大幅に削減することができます。たとえば、従来の災害復旧計画の策定では、次のような多くの要件を考慮する必要があります。

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

Google Cloud Platform は、世界規模の本番環境に高度に管理されたソリューションを提供することで、上記のような複雑な要因の大半を排除し、プロセス中の業務コストを大幅に削減できます。さらに、Google Cloud Platform は効率的な運用を重視しているため、複雑なアプリケーションの運用コストも削減されます。

Google Cloud Platform には、災害復旧計画策定に関して、次のような利点があります。

  • グローバル ネットワーク

    Google には最大級、および最先端のコンピュータ ネットワークがあります。Google のバックボーン ネットワークでは、数千マイルの光ファイバー ケーブルや先進的な SDN(Software Defined Network)が使用され、エッジ キャッシング サービスにより高速で安定したスケーラブルなパフォーマンスを提供しています。

  • 冗長性

    世界中に展開された拠点により、強力な冗長性が実現されています。データは複数の場所にあるストレージ デバイスに自動的にミラーリングされます。

  • スケーラビリティ

    Cloud Platform は、Google 独自のサービスと同様、トラフィックの急増に直面してもスケールできるように設計されています。App Engine、Compute Engine Autoscaler、Cloud Datastore などのマネージド サービスによって、アプリケーションを必要に応じて拡大したり、縮小したりできる自動スケーリングが実現します。

  • セキュリティ

    Google セキュリティ モデルはエンドツーエンドのプロセスであり、Gmail や G Suite をはじめとする Google アプリケーションでお客様のセキュリティを保護してきた 15 年以上の経験を基盤としています。さらに、Google のサイト信頼性エンジニアリング チームはプラットフォーム システムの運用状況を監視して高可用性を保証し、プラットフォーム リソースの悪用を防止します。

  • コンプライアンス

    Google は第三者による監査を定期的に実施し、Google Cloud Platform がセキュリティ、プライバシー、コンプライアンスの各規制とベスト プラクティスに適合しているか確認します。Cloud Platform は ISO 27001、SOC 2/3、PCI DSS 3.0 などの上位認証に準拠しています。

  • 低コスト

    Google Cloud Platform はムーアの法則を料金に適用しているため、ハードウェアのコストが下がると、さまざまな Google Cloud Platform コンポーネントのコストにもその削減が正確に反映されます。

災害復旧計画の設計

このセクションではご利用のサービス向けに災害復旧計画を設計する際のベスト プラクティスについて概説します。

復旧の目標に応じた設計

災害復旧計画を設計するときは、固有のユースケースに対処するように、目標を定めた方法を選択します。たとえば、履歴コンプライアンス指向データの場合、データに迅速にアクセスする必要がないかもしれません。ただし、サービス中断の事態に直面した場合は、できるだけ早くデータとアプリケーションの両方を復旧できることが望まれます。

Google Cloud Platform を使用した、一般的な災害復旧計画のシナリオの取り組みについては、災害復旧クックブックをご覧ください。ここには、さまざまなユースケースに対応した目標別の災害復旧方法が記載されており、ユースケースごとの Google Cloud Platform での実装例も取り上げています。

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

データのバックアップまたはアーカイブ計画を用意しておくだけでは十分ではありません。災害復旧計画が、バックアップ~リストア~クリーンアップという完全復旧プロセスに対応できるようにしておく必要があります。

タスクの具体化

災害復旧計画を実行する状況になった場合、計画の各ステップの意味を推測して処置が遅れることのないようにしてください。災害復旧計画の各タスクは、1 つ以上の具体的で明確なコマンドや処置で構成されている必要があります。たとえば、「リストア スクリプトを実行する」は漠然としていますが、「Bash を開いて /home/foo/restore.sh を実行する」であれば明確で具体的です。

管理方法の実装

災害発生の可能性を最低限に抑えるための基準を実装します。災害事象の発生を抑え、発生前に問題を明らかにできるような管理運用を加えます。たとえば、削除パイプラインなどのデータ破壊フローによって、予想外のスパイクや他の異常現象が発生したときに、警告を送信するモニタを追加することができます。このモニタは、特定の削除しきい値に到達した場合、壊滅的な事態が発生しないようにパイプライン プロセスを強制終了することができます。

標準的なセキュリティ メカニズムの統合

本番環境に適用されるセキュリティ制御が、復旧計画にも考慮されるようにします。

ソフトウェア ライセンスを最新に保つ

復旧が問題なく実施されるには、災害復旧計画の一部としてデプロイの対象となるソフトウェアに適切なライセンスが付与されていることが必要です。ソフトウェアについてサプライヤーに確認してください。

RTO を反映したマシンイメージの構成

新しいインスタンスのデプロイに使用するマシンイメージを構成するときは、デプロイの速度に対して、構成が及ぼす影響を考慮してください。イメージの事前構成量、イメージを維持するためのコスト、デプロイ速度は相反する関係にあります。たとえば、マシンイメージの構成が最小限の場合、このイメージを使用するインスタンスでは依存関係のダウンロードとインストールが必要になるため、稼働開始までに時間を要することになります。マシンイメージが高度に事前構成されていると、このイメージを使用するインスタンスはすぐに稼働開始できますが、イメージの定期更新が頻繁になります。

さまざまなイメージ構成
図 2: さまざまなイメージ構成

顧客の大半は、この図のいずれかに適切な構成方法が含まれているはずです。アプリケーションと希望する RTO に適合する構成を選択します。通常は、RTO が小さいと、イメージへの事前構成が増大します。

複数のデータリカバリ パスの維持

用意したバックアップまたはリカバリ計画が 1 種類だけでは不十分です。メインのデータ復旧計画が失敗した場合に備えて、複数の計画を用意しておくことが重要です。

計画の定期的なテスト

災害復旧計画の策定後は、定期的にテストし、発生した問題を記録し、必要に応じて計画を調整します。Google Cloud Platform を使用すると、最低限のコストで復旧シナリオを簡単にテストすることができます。

  • Google Cloud Deployment Manager によるインフラストラクチャのプロビジョニングの自動化

    Google Cloud Deployment Manager を使用すると、仮想マシン インスタンスとその他の Google Cloud Platform インフラストラクチャのプロビジョニングを自動化することができます。本番環境をオンプレミスで実行している場合、適切な復旧処置を講じるため、モニタリング ソリューションを活用できることを確認する必要があります。

  • Stackdriver Logging や Stackdriver Monitoring によるテストのモニタリングとデバッグ

    Google Cloud Platform には、API 呼び出しを経由してアクセスできる、優れたログツールとモニタリング ツールが備わっており、指標に対処することで、復旧シナリオのデプロイメントを簡単に自動化することができます。テストを作成するときは、適切な復旧処置を講じることができるように、モニタとアラートを配置していることを確認してください。

災害復旧計画での Google Cloud Platform の活用

Google Cloud Platform には、災害復旧計画を作成し、テストする際に活用できる多くのサービスと機能が用意されています。このセクションでは、最も関係の深いサービスと機能を重点的に取り上げ、災害復旧計画にどのように組み込まれるかについて簡単に説明します。

データのバックアップとリカバリ

Google Cloud Platform はデータのバックアップと復旧をサポートする機能を持っています。

Cloud Storage

Google Cloud Storage には、非構造化データとバイナリデータ用に、耐久性の高いバックアップまたはアーカイブ エンドポイントが用意されています。Cloud Storage には、4 つのストレージ クラス(Multi-Regional Storage、Regional Storage、Nearline Storage、Coldline Storage)があり、それぞれの可用性とレイテンシ特性を備え、固有のバックアップまたはアーカイブのニーズに対応します。すべてのストレージ クラスが同レベルの高い耐久性を提供します。

  • Multi-Regional Storage は低レイテンシ アクセスを必要とするデータ、または頻繁にアクセスされる(「ホット」オブジェクト)データ(ウェブサイト コンテンツ、インタラクティブなワークロード、ゲーム アプリケーションやモバイル アプリケーションなど)の格納に有効です。このストレージ クラスは地理的な冗長性を備えたデータコピーを維持しています。つまり、データは地理的に離れた複数の地域に保存されます。
  • Regional Storage も低レイテンシ アクセスを必要とするデータ、または頻繁にアクセスされるデータの格納に有効です。このクラス(およびすべてのクラス)が冗長性を備えたデータコピーを保存しますが、地理的な冗長性を備えているのは上記の Multi-Regional Storage クラスのみです。
  • Nearline Storage は通常のアクセス頻度が月に 1 回程度しかないデータ、特に最高レベルの可用性が必要ない場合に有効です。このストレージは複数層のストレージ ソリューションの一部として役立ちます。連続するそれぞれの層は、アクセス頻度が低い(コールド)ストレージの形式を示します。
  • Coldline Storage は安価な低可用性のソリューションで、通常のアクセス頻度が年に 1 回程度のデータ(コンプライアンス関連のデータや、主に将来の履歴分析に備えて格納されるデータなど)のアーカイブに適しています。おおまかに言うと、Coldline Storage はテープ バックアップに似ていて、従来はテープを使用していたあらゆるユースケースで使用できます。Coldline Storage とテープ バックアップの主な違いは、Coldline は必要に応じて即座にアクセスすることができ、他の Cloud Storage クラスと同じインターフェースを使用する点です。

Cloud SQL

Google Cloud SQL は分散型 MySQL データベースです。MySQL のほとんどの機能を持ち、同時に標準的な Google Cloud Platform の利点(ゾーンにまたがる組み込み型データ レプリケーションなど)も備えています。Cloud SQL は、MySQL データベースのホット スタンバイとして特に有効です。自動バックアップとバイナリログも Cloud SQL インスタンスで有効にすると、MySQL データのポイントインタイム リストアを簡単に実行することができます。

BigQuery

BigQuery は、大規模なデータ分析に対応した、高速で経済的なエンタープライズ向けフルマネージド データ ウェアハウスです。BigQuery は、標準的なコンピューティング ベースのログ集計方式の複雑さを大幅に緩和するため、災害が発生した際に大容量のログのリダイレクト先として最適です。BigQuery へのログの送信は、次のように簡単にできます。

  • アプリケーション全体が Google Cloud Platform で実行されている場合、チェックボックスをオンにすれば、Stackdriver Logging の出力を BigQuery にストリーミングするように設定することができます。
  • Fluentd のようなツールを使用して、カスタマイズされたオンプレミス型ログ集約ソリューションにログを送信している場合、このソリューションも同様に単純明快です。災害復旧計画に別の設定を簡単にセットアップして、BigQuery にログを送信することができます。オンプレミス型ログ ソリューションを仮想マシン インスタンスに再作成しなくても、一元化されたログを維持できます。

BigQuery は大規模データセットの分析向けに設計されているため、ログ分析の実行や、災害を引き起こす問題の診断プロセスの効率化に最適なソリューションです。ログデータを後日エクスポートする場合、BigQuery では CSV、JSON、Avro 形式へのエクスポートが可能です。

BigQuery はスタンドアロンのアーカイブ ソリューションとしても使用できます。

アプリケーションのバックアップとリカバリ

Google Cloud Platform にはアプリケーションのバックアップとリカバリをサポートする機能が用意されています。

HTTP 負荷分散

Google Compute Engine には HTTP 負荷分散サービスが用意されており、仮想マシンがダウンした場合の自動フェイルオーバーに使用できます。HTTP ロードバランサは単一のグローバル外部 IP アドレスからのトラフィックを受け入れ、このトラフィックを定義された転送ルールに従って配布します。災害復旧の場合、このサービスは、スタンバイ中の Compute Engine インスタンスへのオンプレミス ハードウェア ベースの負荷分散、インフラストラクチャとトラフィックのルーティングの代替として使用できます。

インスタンスのスナップショット

Compute Engine インスタンス スナップショットによって、起動ボリュームを含む、インスタンスに関連付けられた永続ディスクの差分ベースのバックアップを作成できます。スナップショットから新たな永続ディスクを作成し、このディスクは、失われる可能性のあるデータのバックアップと永続ディスクの再作成、永続ディスクのコピーに役立てることができます。スナップショットはさまざまなタイプの永続ディスクに適用できます。スナップショットはグローバルに使用でき、リージョンやゾーンに関係なくリストアできます。

Cloud DNS

Google Cloud DNS には大容量の高パフォーマンス DNS があり、Anycast ネームサーバーの Google のネットワークを経由して、世界中のどこからでも、信頼性の高い、低レイテンシ アクセスが実現します。Compute Engine の HTTP 負荷分散サービスの災害復旧への活用がユースケースで許容されない場合でも、Cloud DNS を利用してアプリケーションのフェイルオーバーを管理することは可能であり、gcloud ツールから手動で行うことも、Cloud DNS API からプログラムで行うこともできます。

復旧計画のテストとデプロイ

Google Cloud Platform には、災害復旧計画のテスト、デバッグ、デプロイ向けに複数の有用なツールが用意されています。

Stackdriver Logging

Stackdriver Logging は Google Cloud Platform で実行されているアプリケーションとサービスからログを収集し、保管します。ログは Google Cloud Platform Console に表示するか、Google Cloud Storage、Google BigQuery、Google Cloud Pub/Sub にストリーミングできます。

Stackdriver Monitoring

Stackdriver Monitoring には、アプリケーション向けのダッシュボードとアラートが用意されています。Stackdriver Monitoring を利用すると、さまざまな Google Cloud Platform サービスのパフォーマンス指標のレビューが可能になります。また、モニタリング エージェントを経由して、数多くの普及型オープンソース サービスにサービス固有のモニタフックを提供します。Stackdriver Monitoring API を使用して、モニタリング データにアクセスし、カスタム指標を作成することもできます。

Cloud Deployment Manager

Google Cloud Deployment Manager はインフラストラクチャ管理サービスで、Google Cloud Platform リソースの作成とデプロイをシンプルに自動化します。Google Cloud Platform 環境の構成について説明する静的テンプレートまたは動的テンプレートを作成し、次に Deployment Manager を使用して、リソースを単一デプロイメントとして作成します。

リモート接続

Google Cloud Platform をリモート リカバリ ソリューションとして、オンプレミス型の本番環境向けに、または別のクラウド サービスから使用することもできます。Google Cloud Platform には、本番環境と Google のクラウド間にシームレスな接続を確保する際に役立つ、複数のサービスが用意されています。

Cloud Interconnect

Google Cloud Interconnect を利用すると、Google のネットワーク エッジへのエンタープライズ グレードの接続を経由して、インフラストラクチャから Google への接続が可能になります。この接続は、Cloud Interconnect サービス プロバイダによって提供されます。Cloud Interconnect と接続すると、インフラストラクチャから、Google Cloud Platform に高可用性かつ低レイテンシの接続が可能になります。

ダイレクト ピアリング

Google の技術的ピアリング要件を満たしていると、お客様の業務用ネットワークと Google のネットワークの間でダイレクト ピアリング接続を確立できます。この接続では、Google の広範なエッジ ネットワーク拠点を利用して、お客様のネットワークと Google のネットワークの間でインターネット トラフィックの送受信を行えるようになります。

Compute Engine VPN

Google Compute Engine VPN を使用すると、既存のネットワークを IPsec 接続を使用して Compute Engine ネットワークに接続できます。または、Compute Engine VPN を使用して、2 つの異なる Compute Engine VPN ゲートウェイを接続することもできます。

まとめ

適切に設計され、十分のテストされた災害復旧計画を設定すると、災害に遭遇した場合の業務上の利益に対する影響を最低限に抑えることができます。災害復旧のニーズがどのようなものであっても、Google Cloud Platform には、堅牢で柔軟、かつコスト効率の高いサービスと機能の選択肢が用意されており、この中から最も適したものを選択して、適切なソリューションの構築または増強に活用することができます。

次のステップ

災害復旧クックブックを確認する
災害復旧クックブックでは、数多くの一般的な災害復旧シナリオを調査し、Google Cloud Platform を使用して堅牢なソリューションを実装するための的確な助言を提供します。
Google Cloud Platform でスケーラビリティと復元性の高いアプリをビルドする
スケーラビリティと復元性の高いウェブ アプリケーションの構築では、サンプル アプリケーションのデプロイについて説明し、スケーラビリティと耐久性に優れ、コスト効率の高いアプリケーションにする方法を示します。
いくつかの実装例を試す
Percona XtraBackup と Google Cloud Storage を使用した MySQL のホット バックアップの実行Cassandra 災害復旧での Cloud Storage の使用で、MySQL と Cassandra のためのエンドツーエンド復旧方法をそれぞれ説明しています。
このページは役立ちましたか?評価をお願いいたします。

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