災害復旧クックブック

災害復旧に特効薬はありません。つまり、1 つの復旧計画ですべてのユースケースをカバーすることはできません。この記事では、Google のクラウド インフラストラクチャを使って、さまざまな障害回復シナリオを扱うためのガイダンスを提供します。

用語

この記事では以下の用語を使用します。

  • 復旧時間目標(RTO)は、アプリケーションがオフラインであることが許容される最大時間です。この値は、通常、より広範なサービスレベル契約(SLA)の一部として定義されます。
  • 復旧時点目標(RPO)は、重大な事象によりデータが失われることが許容される期間を示す最大時間です。この指標は期間を示すだけで、失われるデータの量や質は扱わないことに注意してください。

これらの概念のより広範な議論と、災害復旧計画の作成のための一般的な原則については、Google Cloud Platform による災害復旧計画の作成をご覧ください。

シナリオ

ここでは、一般的な災害復旧シナリオについて掘り下げ、それぞれについて Google Cloud Platform での復旧戦略と実装例を説明します。

過去のデータの復旧

過去のデータは、ほとんどの場合コンプライアンス上の理由からアーカイブする必要がありますが、将来の履歴分析のためにも一般にアーカイブされます。どちらの場合も、関連するログとデータベース データを、容易にアクセスでき変換可能な形式で、耐久性のある方法でアーカイブすることが重要です。

一般に、過去のデータの RTO は中程度か大きくなります。しかし、完全かつ正確であることが期待されるため、過去のデータの RPO は小さくなる傾向があります。

ログデータのアーカイブ

ログデータは、通常は履歴トレンド分析とフォレンジック分析で使われます。一般に、このデータを何年も保管する必要はありません。ただし、前述のように、このデータを分析に便利な形式に容易にインポートできることが重要です。

Google Cloud Platform では、以下のように、ログデータをエクスポートするためのいくつかのオプションが用意されています。

  • Google Cloud Storage バケットへのストリーミングにより、ログを Cloud Storage に定期的に書き込みます。ファイルにはタイムスタンプが設定され、暗号化されて、適切な名前のフォルダに保存され、特定の期間のログを簡単に見つけることができるようになります。
  • BigQuery データセットへのストリーミングにより、ログを BigQuery データセットにストリーミングします。BigQuery は、変更不可能な読み取り専用でデータを保存します。

ログのエクスポートについて詳しくは、ログのエクスポートをご覧ください。

データベース データのアーカイブ

リレーショナル データベースのバックアップでは、多くの場合多層ソリューションを使用します。このソリューションでは、ライブデータがローカル ストレージ デバイスに保存され、バックアップは徐々に「よりコールドな」ストレージ ソリューションに保存されます。このソリューションでは、cron ジョブ(または同様のもの)によりライブデータが第 2 階層に定期的にバックアップされ、別のジョブを使ってその階層から別の階層に若干長い間隔でバックアップされます。

Google Cloud Platform 上でのこの戦略の考えられる実装の 1 つは、永続ディスクをライブデータ階層に使用し、標準の Cloud Storage バケットを第 2 階層に使用し、Cloud Storage Nearline バケットを最終階層に使用することです。この実装では、各階層は次のように接続されます。

  1. インスタンスに接続されている永続ディスクにデータをバックアップするようにアプリケーションを構成します。
  2. 一定期間後にデータを標準の Cloud Storage バケットに移動するように cron ジョブなどのタスクをセットアップします。
  3. 最後に、別の cron ジョブをセットアップするか、Cloud Storage Transfer Service を使って、標準バケットから Nearline バケットにデータを移動します。

次の図は、この実装例を示しています。

多層バックアップ
図 1: 多層バックアップ

これを完全な災害復旧ソリューションにするには、バックアップを互換性のあるバージョンのデータベースに復元するためのいくつかの方法も実装する必要があります。実現可能な 3 つのアプローチは以下のとおりです。

  • 適切なバージョンのデータベース システムがインストールされたカスタム イメージを作成します。

    次に、このイメージを使って新しい Compute Engine インスタンスを作成し、インポート処理をテストします。このアプローチには、定期的で厳格なテストが必要であるので注意してください。

  • データベース システムの定期的なスナップショットを取得します。

    データベース システムが Compute Engine 永続ディスク上にある場合は、アップグレードのたびにシステムのスナップショットを取得できます。データベース システムがダウンするか、前のバージョンにロールバックする必要がある場合は、目的のスナップショットから単に新しい永続ディスクを作成し、そのディスクを新たな Compute Engine インスタンスのブートディスクにできます。このアプローチでは、データ破壊を避けるために、スナップショットの作成中はデータベース システムを固定する必要があるので注意してください。

  • CSV、XML、JSON などの非常にポータブルなフラット形式にデータをエクスポートし、Cloud Storage Nearline に保存します。

    このアプローチは最大限の柔軟性を提供し、使用するよう選んだ任意のデータベース システムにデータをインポートできます。また、JSON と CSV を BigQuery に容易にインポートできるため、将来の分析が単純明快なものになります。

BigQuery への直接アーカイブ

ユースケースが許す場合、ストリーミング挿入を使って、リアルタイム イベントデータを直接 BigQuery にアーカイブできます。これは、ビッグデータ分析を行う場合に特に便利です。誤った上書きを防ぐため、IAM を使用して、テーブルに書き込まれるデータに対する更新権限と削除権限を持つユーザーを管理する必要があります。

データ破損の復旧

データベースのデータが壊れた場合、データを容易に復旧して、素早く利用可能にする必要があります。その際の優れたアプローチは、壊れたデータベースのトランザクション ログ ファイルとバックアップを組み合わせて使用し、既知の良好な状態にロールバックすることです。

Google Cloud Platform の完全に管理された MySQL データベースである、Cloud SQL を使用することを選んだ場合、Cloud SQL インスタンスで自動的なバックアップとバイナリ ロギングを有効にする必要があります。これにより、ポイントインタイム リカバリを容易に実行しできます。データベースがバックアップから復元され、新しい Cloud SQL インスタンスに復旧されます。詳細は、Cloud SQL のバックアップと復旧をご覧ください。

Compute Engine を使って独自のリレーショナル データベースを管理する場合も原理は同じですが、各自が責任を持ってデータベース サービスを管理し適切なバックアップ プロセスを維持することになります。

BigQuery のような追加専用のデータストアを使用する場合は、採用できる軽減戦略がいくつかあります。

  • BigQuery からデータをエクスポートし、エクスポートしたデータを含むが壊れたデータを含まない、新しいテーブルを作成します。
  • 特定の期間向けの異なるテーブルにデータを保存します。この方法では、データセット全体ではなく、データの一部のみを新しいテーブルに復元するだけで済みます。
  • 元のデータを Cloud Storage に保存します。これにより、新しいテーブルを作成し、壊れていないデータを再読み込みできます。そこから、新しいテーブルを指すようにアプリケーションを調整できます。

また、RTO が許す場合、壊れていないデータが新しいテーブルに復元されるまでアプリケーションをオフラインのままにすることで、壊れたデータが格納されているテーブルへのアクセスを防ぐことができます。

アプリケーションの復旧

高いレベルの稼働時間を維持することは重要です。サーバーを利用できないとビジネスが失われていきます。ここでは、アプリケーションを別の場所にできるだけ迅速にフェイルオーバーするための方法について説明します。

ホット スタンバイ サーバー フェイルオーバー

このソリューションでは、常にオンラインのサーバーをスタンバイ状態にします。このサーバーは、メイン アプリケーション サーバーが機能している間はトラフィックを受信しません。

サービスが完全に Google Compute Engine で動作している場合、Compute Engine の HTTP 負荷分散サービスを使って、アプリケーションのフェイルオーバーを効率化できます。HTTP ロードバランサは単一のグローバル外部 IP アドレスからのトラフィックを受け入れ、このトラフィックを定義された転送ルールに従って配布します。このサービスは、適切に設定されれば、メインのインスタンスが正常稼働状態でなくなったときに、スタンバイ サーバーに自動的にフェイルオーバーします。

ウォーム スタンバイ サーバー フェイルオーバー

このソリューションは、ホット スタンバイ サーバー フェイルオーバーと同じですが、Compute Engine の HTTP 負荷分散サービスの使用が省略され、手動の DNS 調整が使用されます。ここでの RTO は、スタンバイ サーバーに切り替えるために DNS レコードをどれだけ迅速に調整できるかで決まります。

コールド スタンバイ サーバー フェイルオーバー

このソリューションでは、メイン アプリケーション サーバーと同じオフライン アプリケーション サーバーをスタンバイ状態にします。メイン アプリケーション サーバーがオフラインになったら、スタンバイ サーバーをインスタンス化します。スタンバイ サーバーがオンラインになったら、トラフィックがそこにフェイルオーバーします。

次の図は、考えられる 1 つの実装を示しています。

コールド スタンバイ サーバーの例
図 2: コールド スタンバイ サーバーの例

この例では以下のものを実行することになります。

  • サービスを提供するインスタンス。このインスタンスはインスタンス グループの一部であり、そのグループは HTTP ロードバランサのバックエンド サービスとして使用されます。
  • 以下の機能を実行する最低限のインスタンス。

    • サービスを提供するインスタンスのスナップショットを定期的に取得するための cron ジョブを実行する。
    • サービスを提供するインスタンスの稼働状態を定期的にチェックする。

この最低限のインスタンスはマネージド インスタンス グループの一部であり、このグループは Compute Engine オートスケーラーによって制御されます。オートスケーラーは、常に 1 つの最小限のインスタンスを動作させるように構成され、現在動作しているインスタンスが使用不能になった場合には、インスタンス テンプレートを使用して新しいインスタンスを作成します。

最小限のインスタンスは、サービスを提供しているインスタンスが規定の時間応答しないことを検出した場合、最新のスナップショットを使って新しいインスタンスを作成し、新しいインスタンスをマネージド インスタンス グループに追加します。新しいインスタンスがオンラインになると、図に示すように、HTTP ロードバランサがそのインスタンスへのトラフィックの送信を開始します。

コールド スタンバイ サーバーの例
図 3: コールド スタンバイの復旧後の状態

ウォーム スタティック サイト フェイルオーバー

Compute Engine インスタンスからアプリケーションのサービスを提供できないまれな状況が発生した場合は、Cloud Storage ベースのスタティック サイトをスタンバイにしておくことで、サービスの中断を軽減できます。このソリューションは非常に経済的であり、ウェブサイトに動的な要素がほとんどないかまったくない場合に特に効果的です。障害発生時には、DNS 設定を変更するだけで、すぐにサービスを提供できます。

次の図に実装例を示します。

ウォーム スタティック サイトの例
図 4: ウォーム スタティック サイトの例

上の例で、プライマリ アプリケーションは Compute Engine インスタンス上で動作しています。これらのインスタンスは、マネージド インスタンス グループにグループ化され、これらのインスタンス グループが HTTP ロードバランサのバックエンド サービスとしての役割を果たします。HTTP ロードバランサは、ロードバランサの構成、インスタンス グループの各、各インスタンスの稼働状態に従って受信トラフィックをインスタンスに送信します。

通常の構成では、Cloud DNS はこのプライマリ アプリケーションを指すように構成され、スタンバイ スタティック サイトは休眠状態になっています。Compute Engine アプリケーションがサービスを提供できない場合は、このスタティック サイトを指すように Cloud DNS を構成します。

リモート復旧

本番環境がオンプレミスまたは別のクラウド プロバイダ上にある場合、バックアップ先およびアーカイブ先として Google Cloud Platform が適切である場合があります。ダイレクト インターコネクトダイレクト ピアリングCloud VPN を利用することで、前述の災害復旧戦略を実際の状況に合わせて容易に調整できます。ここでは、Google Cloud Platform をリモート災害復旧戦略に統合する方法について説明します。

Google Cloud Platform を使ったストレージの複製

オンプレミス ストレージ アプライアンスから複製する場合は、ダイレクト インターコネクトかダイレクト ピアリングを使用して Google Cloud Platform との接続を確立してから、任意のストレージ ソリューションにデータをコピーできます。その後、データをオンプレミス ストレージや Google Cloud Platform 上の格納場所にデータを復元できます。

次の図は、このソリューションの考えられる 1 つの実装を示しています。

オンプレミス ストレージから Google Cloud Storage へのレプリケーション
図 5: オンプレミス ストレージから Google Cloud Storage へのレプリケーション

他のクラウド サービスから複製する場合は、Google Cloud Storage XML API を使用できる可能性があります。この API は、Amazon Simple Storage Service(Amazon S3)や HP Helion Eucalyptus Storage(Walrus)といったサービスと連携する、いくつかのクラウド ストレージ ツールやライブラリと相互運用可能です

Google Cloud Platform を使用したアプリケーション データの複製

このシナリオでは、本稼働ワークロードはオンプレミスにあり、Google Cloud Platform が災害復旧フェイルオーバー先となります。

考えられる 1 つのソリューションは、最小限の復旧スイート(コールド スタンバイ アプリケーション サーバーと、ホット / アクティブ データベース)を Google Cloud Platform 上にセットアップし、本番環境ワークロードを実行する必要が生じた場合に、前者を素早くスケールアップするように構成することです。この状況では、データベースを最新の状態に維持する必要がありますが、アプリケーション サーバーは、本番環境に切り替える必要がある場合にのみインスタンス化することになります。RTO に応じて、適切なイメージ開始ポイントを使って、動作するインスタンスを起動および構成します。

次の図は、多層アプリケーションがオンプレミスで動作し、Google Cloud Platform では最小限の復旧スイートを使用している様子を示しています。

オンプレミスから Google Cloud Platform への復旧計画
図 6: オンプレミスから Google Cloud Platform への復旧プラン

Google Cloud Platform 側ではデータベース サーバー インスタンスのみが動作していることに注意してください。前述のように、このインスタンスは、複製データを受信できるように、常に動作している必要があります。

コストを低減するため、データベース サービスを実行できる最小のマシンタイプでデータベースを実行できます。オンプレミス アプリケーションをフェイルオーバーする必要がある場合、データベース システムを本稼働できる状態にするには、次のようにします。

  1. データベース システムを含む永続ディスクをそのままの状態に維持しながら、最小限のインスタンスを破棄します。システムがブートディスク上にある場合は、ディスクの自動削除状態を false に設定してから、このインスタンスを破棄する必要があります。
  2. 本番環境負荷を処理するための適切なリソースを備えたマシンタイプを使用して、新しいインスタンスを作成します。
  3. データベース システムが含まれている永続ディスクを新しいインスタンスに接続します。

災害発生時には、モニタリング サービスが起動され、ウェブ階層とアプリケーション階層のインスタンスが Google Cloud Platform で立ち上がります。その後、Cloud DNS レコードを調整して、ウェブ階層を指すようにするか、Compute Engine HTTP 負荷分散サービスを使っている場合には、ロードバランサの外部 IP を指すようにします。次の図は、災害復旧計画を実行した後の、全体的な本稼働環境の状態を示しています。

復旧後の状態
図 7: 復旧後の状態

RTO 値をより小さくするには、すべての Compute Engine インスタンスを稼働状態にしつつトラフィックを受信しないように保つことで、上記の戦略を調整できます(ウォーム スタンバイ サーバー フェイルオーバーをご覧ください)。この戦略は、一般にコスト効率が高くありません。RTO が、最小限の構成から初期設定するために要する時間を許容できない場合は、次の図に示すように、オンプレミスと Google Cloud Platform の両方からのトラフィックを処理する、完全に動作する環境を実装することを検討してください。

アクティブ/アクティブ ハイブリッド本稼働環境(オンプレミスおよび Google Cloud Platform)
図 8: アクティブ / アクティブ ハイブリッド本稼働環境(オンプレミスと Google Cloud Platform)

このハイブリッド アプローチを実装する場合は、2 つの本稼働環境にトラフィックをルーティングするときに、重み付きルーティングをサポートしている DNS サービスを必ず使用し、両方から同じアプリケーションを提供できるようにしてください。一方の環境が使用不能になった場合は、使用不能な環境への DNS ルーティングを無効にできます。

マシンイメージの一貫性の維持

オンプレミス / クラウドまたはクラウド / クラウドのハイブリッド ソリューションを実装する場合、ほぼ必ず複数の本稼働環境間の一貫性を維持するための方法を見つけることが必要になります。

Packer などのオープンソース ユーティリティを使った、イメージを常に構築するための自動化されたパイプラインの作成方法については、Jenkins、Packer、Kubernetes を使った自動的なイメージ構築をご覧ください。

完全に構成されたイメージが必要な場合は、Packer などのソフトウェアの使用を検討してください。このソフトウェアを使えば、1 つの構成ファイルから複数のプラットフォーム向けの同じマシンイメージを作成できます。Packer の場合、構成ファイルをバージョン管理に格納し、本番環境にデプロイするバージョンを追跡できます。

もう 1 つの方法として、Chef、Puppet、Ansible、Saltstack などの構成管理ツールを使って、より細かくインスタンスを構成し、必要に応じてベースイメージ、最小限の構成がなされたイメージ、完全な構成がなされたイメージを作成できます。これらのツールを効果的に使う方法については、Puppet、Chef、Salt、Ansible を使った Compute Engine の管理をご覧ください。

さらに、Amazon AMI、Virtualbox イメージ、RAW イメージなどの既存のイメージを手動で変換し、Compute Engine にインポートすることもできます。

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

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