このドキュメントは、Google Cloud の障害復旧（DR）について説明するシリーズの一部です。ここでは、アプリケーションの一般的な障害復旧シナリオについて説明します。
シリーズは次のパートで構成されています。
- 障害復旧計画ガイド
- 障害復旧の構成要素
- データの障害復旧シナリオ
- アプリケーションの障害復旧シナリオ（このドキュメント）
- 地域制限があるワークロードの障害復旧の設計
- 障害復旧のユースケース: 地域制限のあるデータ分析アプリケーション
- クラウド インフラストラクチャの停止に対する障害復旧の設計
はじめに
このドキュメントでは、障害イベントからどのようにしてアプリケーションを簡単に復旧できるかを示す DR パターンの観点から、アプリケーションの DR シナリオを説明します。DR の構成要素のドキュメントで説明したコンセプトを使用して、復旧目標に適したエンドツーエンドの DR 計画を実装する方法を説明します。
まず、典型的なワークロードを例にとり、復旧の目標とアーキテクチャがどのように DR 計画に直接的な影響を与えるかについて考察してみましょう。
バッチ処理のワークロード
バッチ処理のワークロードは、多くの場合ミッション クリティカルではありません。そのため、通常は稼働時間を最大化する高可用性（HA）アーキテクチャの設計にコストをかける必要はありません。一般に、バッチ処理のワークロードは中断に対応できます。このタイプのワークロードには、通常のインスタンスよりはるかに低料金で作成、実行できるSpot VM やプリエンプティブル VM インスタンスなどの、コスト効率の高いプロダクトを活用できます。（ただし、他のタスクがリソースへのアクセスを必要とする場合、Compute Engine がこれらのインスタンスをプリエンプティブに停止または削除する可能性があります）。
処理タスクの一環として定期的なチェックポイントを実装することにより、新しい VM が起動したときに処理ジョブを障害発生ポイントから再開できます。 Dataproc を使用している場合、プリエンプト可能なワーカーノードを起動するプロセスは、マネージド インスタンス グループによって管理されます。これはウォーム パターンと見なすことができ、置き換え用 VM による処理の続行を待機するための短い一時停止が発生します。
e コマースサイト
e コマースサイトでは、アプリケーションのいくつかの部分の RTO 値を比較的大きくできる場合があります。 たとえば、実際の購買パイプラインには高可用性が必要ですが、注文のお知らせを顧客に送信するメール処理は数時間の遅延を許容できます。顧客は確認メールが届くのを期待しますが、自分の購入内容は把握しているはずなので、この通知が購入プロセスに欠かせない部分というわけではありません。これは、ホット（購買）パターンとウォーム / コールド（通知）パターンを混合したものです。
アプリケーションのトランザクション部分には、高い稼働時間と最小限の RTO 値が求められます。そのため、この部分には HA を使用して可用性を最大限にします。このアプローチは、ホットパターンと見なすことができます。
この e コマース シナリオは、同じアプリケーション内でさまざまな RTO 値を設定する方法を示しています。
動画ストリーミング
動画ストリーミング ソリューションには、検索エクスペリエンスからユーザーにコンテンツをストリーミングする実際のプロセスまで、高可用性が要求される要素が多く存在します。さらに、ユーザーが満足できるエクスペリエンスを提供するには、システムのレイテンシを低くする必要があります。ソリューションのどの部分でも優れたエクスペリエンスを提供しないと、サプライヤにも顧客にも不満が生じます。さらに、昨今の顧客は他の競合製品に関心を移してしまう可能性があります。
このようなシナリオでは、HA アーキテクチャは必須であり、RTO 値を小さくする必要があります。このシナリオでは、アプリケーション アーキテクチャ全体にホットパターンを適用して、障害発生時の影響を最小限に抑えられるようにする必要があります。
オンプレミスの本番環境用の DR および HA アーキテクチャ
このセクションでは、アプリケーションがオンプレミスで実行され、DR ソリューションが Google Cloud 上にある場合に、コールド、ウォーム、ホットの 3 つのパターンを実装する方法について説明します。
コールド パターン: Google Cloud への復旧
コールド パターンの場合、DR Google Cloud プロジェクトのリソースは最小限に抑えられており、復旧シナリオの実現に必要なもののみとなっています。本番環境で本番のワークロードを実行できないような問題が発生した場合、フェイルオーバー機能は本番環境のミラーリングを Google Cloud で開始するよう要求します。その後、クライアントは DR 環境のサービスを使用し始めます。
ここでは、上記のパターンの例を検証します。この例では、Google Cloud への接続を提供するために、セルフマネージド（Google Cloud ではない）VPN ソリューションを使用した Cloud Interconnect が構成されています。データは、本番環境の一部として Cloud Storage にコピーされます。
このパターンでは、次の DR 構成要素を使用します。
- Cloud DNS
- Cloud Interconnect
- セルフマネージド VPN ソリューション
- Cloud Storage
- Compute Engine
- Cloud Load Balancing
- Deployment Manager
次の図は、この例のアーキテクチャを示しています。
この環境を構成する方法を次のステップで概説します
- VPC ネットワークを作成します。
- オンプレミス ネットワークと Google Cloud ネットワーク間の接続を構成します。
- データのバックアップ先として、Cloud Storage バケットを作成します。
- サービス アカウントを作成します。
- IAM ポリシーを作成して、バケットとそのオブジェクトにアクセスできるユーザーを制限します。この目的のために作成した専用サービス アカウントを含めます。また、オペレーターおよびシステム管理者のユーザー アカウントやグループをポリシーに追加して、これらすべての ID に適切なアクセス権を付与します。Cloud Storage へのアクセス権限の詳細については、Cloud Storage に適用される IAM 権限をご覧ください。
- サービス アカウントの権限借用を使用して、ローカルの Google Cloud ユーザー（またはサービス アカウント）にアクセス権を付与し、先ほど作成したサービス アカウントの権限を借用できるようにします。または、この目的専用の新しいユーザーを作成することもできます。
- ターゲット バケットでファイルのアップロードとダウンロードをテストします。
- データ転送スクリプトを作成します。
- このスクリプトを実行するようにスケジュール設定されたタスクを作成します。Linux
crontabや Windows タスク スケジューラなどのツールを使用できます。 本番環境内のサーバーごとに構成したカスタム イメージを作成します。各イメージは、オンプレミスと同じ構成である必要があります。
データベース サーバーのカスタム イメージを構成する一環として、起動スクリプトを作成します。このスクリプトで、Cloud Storage バケットからインスタンスに最新のバックアップを自動的にコピーして、復元プロセスを呼び出すようにします。
インターネットに接続するウェブサービスを指すよう Cloud DNS を構成します。
以前に構成したカスタム イメージを使用して Google Cloud ネットワークにアプリケーション サーバーを作成する Deployment Manager テンプレートを作成します。このテンプレートには、必要とされる適切なファイアウォール ルールも設定する必要があります。
カスタム イメージのアプリケーション バージョンがオンプレミスと同じになるようにするプロセスを実装する必要があります。標準アップグレード サイクルの一環としてカスタム イメージへのアップグレードも実装するようにします。また、Cloud Deployment Manager テンプレートで最新のカスタム イメージが使用されるようにします。
フェイルオーバー プロセスと再起動後のタスク
障害が発生した場合は、Google Cloud で稼働しているシステムに復旧できます。これを行うには、作成した Deployment Manager テンプレートを使用して復旧環境を作成する、修復プロセスを起動します。復旧環境のインスタンスで本番環境のトラフィックを受け入れる準備が整ったら、Google Cloud のウェブサーバーを指すよう DNS を調整します。
一般的な復旧シーケンスは次のとおりです。
- Google Cloud でデプロイメントを作成するには、Deployment Manager テンプレートを使用します。
- ご使用のデータベース システムのバックアップ ファイル復元手順に沿って、Cloud Storage で実行されているデータベース サーバーに、Cloud Storage にある最新のデータベース バックアップを適用します。
- Cloud Storage の最新のトランザクション ログを適用します。
- 復旧した環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおり動作することをテストします。
- テストが正常に完了したら、Google Cloud 上のウェブサーバーを指すように Cloud DNS を構成します。（たとえば、ロードバランサの内側に複数のウェブサーバーが存在する場合は、Google Cloud ロードバランサの内側のエニーキャスト IP アドレスを使用できます。）
次の図は、復旧した環境を示しています。
オンプレミスでの本番環境の稼働が再開され、本番のワークロードに対応できるようになったら、Google Cloud 復旧環境へのフェイルオーバー時に使用したステップの逆を行います。本番環境に復帰するための一般的なシーケンスは次のとおりです。
- Google Cloud 上で実行されているデータベースのバックアップをとります。
- バックアップ ファイルを本番環境にコピーします。
- 本番環境データベース システムにバックアップ ファイルを適用します。
- Google Cloud 内のアプリケーションに接続できないようにします。たとえば、グローバル ロードバランサに接続できないようにします。この時点から本番環境の復元が完了するまで、アプリケーションは使用できなくなります。
- 本番環境にすべてのトランザクション ログファイルをコピーし、データベース サーバーに適用します。
- オンプレミスのウェブサービスを指すように Cloud DNS を構成します。
- Cloud Storage にデータをコピーするために用意したプロセスが想定どおりに動作していることを確認します。
- デプロイを削除します。
ウォーム スタンバイ: Google Cloud への復旧
多くの場合、ウォーム パターンは、完全な HA 構成にかかる労力と費用を要することなく、RTO と RPO の値をできるだけ小さく維持するために導入されます。RTO と RPO の値を小さくすればするほど完全な冗長環境に近づき、2 つの環境からのトラフィックを処理できるようになりますが、コストは高くなります。そのため、DR シナリオにウォーム パターンを導入することは、予算と可用性とのトレードオフをバランスよく保つことになります。
このアプローチの一例は、セルフマネージド VPN ソリューションで構成された Cloud Interconnect を使用して、Google Cloud への接続を提供することです。オンプレミスで多層アプリケーションを実行すると同時に、Google Cloud で最小限の復旧スイートを使用します。復旧スイートは、Google Cloud 上の運用データベース サーバー インスタンスで構成されます。このインスタンスは、非同期または準同期のレプリケーション技術を使用してレプリケートされたトランザクションを受信できるよう、常に実行されている必要があります。コストを削減するには、データベース サービスを実行できる最小マシンタイプでデータベースを実行します。長時間実行インスタンスを使用できるため、継続利用割引が適用されます。
このパターンでは、次の DR 構成要素を使用します。
- Cloud DNS
- Cloud Interconnect
- セルフマネージド VPN ソリューション
- Compute Engine
- Deployment Manager
Compute Engine のスナップショットを使用すれば、以前の状態にロールバックできるバックアップを作成できます。この例では、更新されたウェブページやアプリケーション バイナリが本番環境のウェブサーバーやアプリケーション サーバーに頻繁に書き込まれるため、スナップショットを使用します。これらの更新は、Google Cloud 上の参照ウェブサーバーとアプリケーション サーバーのインスタンスに定期的にレプリケートされます（参照サーバーは本番環境のトラフィックを受け入れません。これらのサーバーはスナップショットの作成に使用されます。）
次の図は、このアプローチを実装するアーキテクチャを示しています。 レプリケーションのターゲットは、図に表示されていません。
この環境を構成する方法を次のステップで概説します
- VPC ネットワークを作成します。
- オンプレミス ネットワークと Google Cloud ネットワーク間の接続を構成します。
- オンプレミス サーバーを Google Cloud VM インスタンスに複製します。これには、パートナー ソリューションを使用する方法もあります。どの方法を採用するかは環境によって異なります。
- Google Cloud 上のデータベース サーバーのカスタム イメージを、オンプレミスのデータベース サーバーと同じ構成で作成します。
- ウェブサーバー インスタンスとアプリケーション サーバー インスタンスのスナップショットを作成します。
- 前の手順で作成したカスタム イメージを使用して、Google Cloud でデータベース インスタンスを開始します。オンプレミスの本番環境データベースから複製されたデータを受け入れることができる最小マシンタイプを使用します。
- データベース ログとトランザクション ログを保管するために、Google Cloud データベース インスタンスに永続ディスクをアタッチします。
- ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと Google Cloud のデータベース サーバーとの間のレプリケーションを構成します。
- データベース インスタンスにアタッチされている永続ディスクで、自動削除フラグを
no-auto-deleteに設定します。 - Google Cloud 上のデータベース インスタンスの永続ディスクのスナップショットを定期的に作成するようスケジュール設定されたタスクを構成します。
- 必要に応じて、ウェブサーバーとアプリケーション サーバーの容量を確保するために予約を作成します。
- スナップショットからインスタンスを作成するプロセスと、永続ディスクのスナップショットを取得するプロセスをテストします。
- 前の手順で作成されたスナップショットを使用して、ウェブサーバーとアプリケーション サーバーのインスタンスを作成します。
- 対応するオンプレミス サーバーが更新されるたびに、ウェブ アプリケーションとアプリケーション サーバーに更新をコピーするスクリプトを作成します。更新されたサーバーのスナップショットを作成するスクリプトを作成します。
- オンプレミスでインターネットに接続するウェブサービスを指すように Cloud DNS を構成します。
フェイルオーバー プロセスと再起動後のタスク
フェイルオーバーを管理するには、通常はモニタリングおよびアラート システムを使用して自動フェイルオーバー プロセスを起動します。オンプレミスのアプリケーションをフェイルオーバーする必要がある場合は、本番環境のトラフィックを受け入れられるように Google Cloud 上のデータベース システムを構成します。また、ウェブサーバーおよびアプリケーション サーバーのインスタンスも開始します。
次の図は、Google Cloud にフェイルオーバーし、Google Cloud から本番環境のワークロードを提供できるようになった後の構成を示しています。
一般的な復旧シーケンスは次のとおりです。
- データベース サーバー インスタンスのサイズを変更して、本番環境の負荷を処理できるようにします。
- Google Cloud 上のウェブサーバーとアプリケーションのスナップショットを使用して、新しいウェブサーバーとアプリケーションのインスタンスを作成します。
- 復旧した環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおり動作することをテストします。
- テストが正常に完了したら、Google Cloud 上のウェブサーバーを指すように Cloud DNS を構成します。
オンプレミスでの本番環境の稼働が再開され、本番のワークロードに対応できるようになったら、Google Cloud 復旧環境へのフェイルオーバー時に使用したステップの逆を行います。本番環境に復帰する一般的なシーケンスは次のとおりです。
- Google Cloud 上で実行されているデータベースのバックアップをとります。
- バックアップ ファイルを本番環境にコピーします。
- 本番環境データベース システムにバックアップ ファイルを適用します。
- Google Cloud 内のアプリケーションに接続できないようにします。たとえば、ファイアウォール ルールを変更して、ウェブサーバーに接続できないようにします。この時点から本番環境の復旧が完了するまで、アプリケーションは使用できなくなります。
- 本番環境にすべてのトランザクション ログファイルをコピーし、データベース サーバーに適用します。
- 本番環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおりに動作するかをテストします。
- オンプレミスのウェブサービスを指すように Cloud DNS を構成します。
- Google Cloud で実行されているウェブサーバーとアプリケーション サーバーのインスタンスを削除します。参照サーバーは実行したままにします。
- Google Cloud 上のデータベース サーバーのサイズを変更して、オンプレミスの本番環境データベースから複製されたデータを受け入れられる最小限のインスタンス サイズに戻します。
- ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと Google Cloud のデータベース サーバーとの間のレプリケーションを構成します。
オンプレミスと Google Cloud との間でのホット HA 構成
RTO と RPO の値が非常に小さい場合、これらの値は、本番環境と Google Cloud との間で同時に HA 構成を実行することでのみ達成可能です。このアプローチは、オンプレミスと Google Cloud の両方が本番環境のトラフィックを処理するため、ホットパターンとなります。
ウォーム パターンとの主な違いは、両方の環境のリソースが本番環境モードで稼働し、本番環境のトラフィックを処理することです。
このパターンでは、次の DR 構成要素を使用します。
- Cloud Interconnect
- Cloud VPN
- Compute Engine
- マネージド インスタンス グループ
- Cloud Monitoring
- Cloud Load Balancing
次の図は、この例のアーキテクチャを示しています。このアーキテクチャを実装することで、障害発生時に最小限の介入で済む DR 計画を実現できます。
この環境を構成する方法を次のステップで概説します
- VPC ネットワークを作成します。
- オンプレミス ネットワークと Google Cloud ネットワーク間の接続を構成します。
- Google Cloud に、オンプレミスの本番環境内のサーバーごとに構成したカスタム イメージを作成します。各 Google Cloud イメージは、オンプレミスと同じ構成である必要があります。
ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと Google Cloud のデータベース サーバーとの間のレプリケーションを構成します。
多くのデータベース システムは、レプリケーションを構成する際に書き込み可能なデータベース インスタンスを 1 つしか許容していません。このため、データベース レプリカの 1 つを読み取り専用サーバーにする必要がある場合があります。
アプリケーション サーバーとウェブサーバーのイメージを使用するインスタンス テンプレートを個々に作成します。
アプリケーション サーバーとウェブサーバーのリージョン マネージド インスタンス グループを構成します。
Cloud Monitoring を使用してヘルスチェックを構成します。
前の手順で構成したリージョン マネージド インスタンス グループを使用して、ロード バランシングを構成します。
永続ディスクのスナップショットを定期的に作成するようスケジュール設定されたタスクを構成します。
オンプレミス環境と Google Cloud 環境の間でトラフィックを分散する DNS サービスを構成します。
このハイブリッド アプローチでは、2 つの本番環境への重み付きルーティングをサポートする DNS サービスを使用して、双方で同じアプリケーションを処理できるようにする必要があります。
システムは、1 つの環境の一部分だけで発生する可能性のある障害（部分的な障害）に備えて設計する必要があります。その場合、トラフィックは、他方のバックアップ環境の同等のサービスに再ルーティングされることになります。たとえば、オンプレミスのウェブサーバーが使用不能になった場合、その環境への DNS ルーティングを無効化できます。DNS サービスがヘルスチェックをサポートする場合は、ヘルスチェックで一方の環境のウェブサーバーに到達できないと判定されると、この処理が自動的に行われます。
書き込み可能インスタンスが 1 つだけ許可されるデータベース システムを使用している場合、元の書き込み可能データベースとリードレプリカ（読み取りレプリカ）との間でハートビートの接続が失われると、多くの場合はデータベース システムによって読み取り専用レプリカが書き込み可能プライマリに自動的に昇格されます。障害発生後に介入が必要な場合に備えて、ご使用のデータベース レプリケーションにこのような側面があることを必ず理解しておいてください。
Google Cloud のカスタム VM イメージのアプリケーション バージョンが、オンプレミスと同じバージョンになるように所定のプロセスを実装する必要があります。標準アップグレード サイクルの一環としてカスタム イメージへのアップグレードを実装し、Cloud Deployment Manager テンプレートで最新のカスタム イメージが使用されるようにします。
フェイルオーバー プロセスと再起動後のタスク
ここで説明するホットシナリオの構成では、障害とは 2 つの環境の一方が利用できなくなることを意味します。ウォーム シナリオやコールド シナリオのように、フェイルオーバー プロセスでデータや処理を第 2 の環境に移動する必要はありません。ただし、次の構成変更の処理が必要になる場合があります。
- DNS サービスがヘルス チェック エラーに基づいて自動的にルーティングを変更しない場合は、DNS ルーティングを手動で再構成して、稼働中のシステムにトラフィックを送信する必要があります。
- 障害発生時にデータベース システムが読み取り専用レプリカを書き込み可能プライマリに自動的に昇格しない場合は、レプリカが確実に昇格するように介入する必要があります。
第 2 の環境の稼働が再開され、本番環境のトラフィックの処理が可能になったら、データベースを再同期する必要があります。どちらの環境も本番環境のワークロードをサポートしているため、プライマリ データベースを変更する操作は必要ありません。データベースが同期したら、DNS 設定を調整して両方の環境に本番環境のトラフィックを再度分散できます。
Google Cloud 上の本番環境用の DR および HA アーキテクチャ
Google Cloud 上に本番環境ワークロード用のアプリケーション アーキテクチャを設計すると、プラットフォームの HA 機能が DR アーキテクチャに直接影響を及ぼします。
バックアップと DR サービスは、クラウド ワークロードとハイブリッド ワークロードのバックアップと復元のための一元化されたクラウドネイティブ ソリューションです。迅速なデータ復元が可能で、重要なビジネス オペレーションを迅速に再開できます。
Google Cloud のアプリケーション シナリオで Backup and DR Service を使用する方法については、以下をご覧ください。
Compute Engine のバックアップと DR サービスでは、Google Cloud バックアップと DR サービスを使用して、インスタンスレベルで Persistent Disk からデータを増分バックアップするコンセプトと詳細について説明します。
Google Cloud VMware Engine のバックアップと DR サービスでは、Google Cloud のバックアップと DR サービスを使用して VMDK から VM レベルでデータを増分バックアップするコンセプトと詳細について説明します。
Filestore とファイル システムの Backup and DR サービスでは、Google Cloud Backup and DR サービスを使用して本番環境の SMB、NFS、Filestore ファイル システムからデータをキャプチャしてバックアップするコンセプトと詳細について説明します。
コールド: 復元可能なアプリケーション サーバー
コールド フェイルオーバーのシナリオでは、アクティブなサーバー インスタンスを 1 つしか必要としない場合、ディスクに書き込む必要があるインスタンスは 1 つだけです。オンプレミス環境では、アクティブ / パッシブ クラスタがよく使用されます。Google Cloud で本番環境を稼働する場合、VM は、1 つのインスタンスのみを実行するマネージド インスタンス グループに作成できます。
このパターンでは、次の DR 構成要素を使用します。
- Compute Engine
- マネージド インスタンス グループ
このコールド フェイルオーバーのシナリオを次のサンプル アーキテクチャ イメージに示します。
このコールド フェイルオーバーのシナリオを構成する方法を次の手順で概説します。
- VPC ネットワークを作成します。
- アプリケーション ウェブサービスで構成されたカスタム VM イメージを作成します。
- アプリケーション サービスによって処理されたデータが、接続された永続ディスクに書き込まれるように VM を構成します。
- 接続された永続ディスクからスナップショットを作成します。
- ウェブサーバーのカスタム VM イメージを参照するインスタンス テンプレートを作成します。
- 起動スクリプトを構成します。このスクリプトで、最新のスナップショットから永続ディスクを作成して、ディスクをマウントするようにします。このスクリプトは、ディスクの最新のスナップショットを取得できる必要があります。
- インスタンス テンプレートを参照するターゲット サイズが 1 のマネージド インスタンス グループとヘルスチェックを作成します。
- 永続ディスクのスナップショットを定期的に作成するスケジュール設定されたタスクを作成します。
- 外部アプリケーション ロードバランサを構成します。
- サービスに障害が発生したときにアラートを送信するように、Cloud Monitoring を使用してアラートを構成します。
このコールド フェイルオーバーのシナリオでは、Google Cloud で利用可能な HA 機能の一部を活用しています。VM に障害が発生した場合、マネージド インスタンス グループは VM を自動的に再作成しようとします。このフェイルオーバーの手順を開始する必要はありません。外部アプリケーション ロードバランサでは、代替 VM が必要な場合でも、アプリケーション サーバーの前に同じ IP アドレスが使用されます。インスタンス テンプレートとカスタム イメージは、代替 VM が置換対象のインスタンスと必ず同じ構成になるようにします。
RPO は、最後に取得されたスナップショットによって決定されます。スナップショットの取得回数が多いほど、RPO 値は小さくなります。
リージョン マネージド インスタンス グループは、徹底的な HA を提供します。マネージド インスタンス グループは、アプリケーション レベルまたは VM レベルで障害に対処する方法を提供します。これらのシナリオのいずれかが発生した場合に、手動介入は必要ありません。ターゲット サイズが 1 の場合、マネージド インスタンス グループで実行されているトラフィックを処理するインスタンスは 1 つだけです。
永続ディスクはゾーン単位であるため、ゾーンの障害が発生した場合は、スナップショットを作成してディスクを再作成する必要があります。スナップショットはリージョンをまたいで使用できるため、ディスクは同じリージョンに復元する場合と同様に、別のリージョンに復元できます。
万一ゾーンに障害が発生した場合は、次のセクションで概説するように、手動介入して復元する必要があります。
フェイルオーバー プロセス
VM に障害が発生すると、マネージド インスタンス グループは自動的に同じゾーンに VM の再作成を試みます。インスタンス テンプレートの起動スクリプトは、最新のスナップショットから永続ディスクを作成し、新しい VM にアタッチします。
ただし、サイズ 1 のマネージド インスタンス グループは、ゾーンに障害が発生しても復元されません。ゾーンに障害が発生した場合、Cloud Monitoring アラートやその他のモニタリング プラットフォームに応じて、サービスに障害が発生し、別のゾーンにインスタンス グループを手動で作成する必要があります。
この構成のバリエーションは、ゾーン永続ディスクではなくリージョン永続ディスクを使用することです。このアプローチでは、復旧手順の一環としてスナップショットを使用して永続ディスクを復元する必要がありません。しかし、このバリエーションでは 2 倍のストレージが消費されるため、それに応じた費用が必要になります。
どのバリエーションを選択するかは、予算および RTO と RPO の値によって決まります。
ウォーム: 静的サイト フェイルオーバー
Compute Engine インスタンスに障害が発生した場合、Cloud Storage ベースの静的サイトをスタンバイとして設定することで、サービスの中断を緩和できます。 このパターンは、ウェブ アプリケーションがほとんど静的である場合に適しています。
このシナリオでは、プライマリ アプリケーションが Compute Engine インスタンス上で実行されます。これらのインスタンスは、マネージド インスタンス グループにまとめられ、これらのインスタンス グループが HTTPS ロードバランサのバックエンド サービスとして機能します。HTTP ロードバランサは、ロードバランサの構成、各インスタンス グループの構成、そして各インスタンスのヘルス状態に応じて、着信トラフィックをインスタンスに誘導します。
このパターンでは、次の DR 構成要素を使用します。
- Compute Engine
- Cloud Storage
- Cloud Load Balancing
- Cloud DNS
次の図は、この例のアーキテクチャを示しています。
このシナリオを構成する方法を次のステップで概説します。
- VPC ネットワークを作成します。
- アプリケーション ウェブサービスで構成されたカスタム イメージを作成します。
- ウェブサーバー用のイメージを使用するインスタンス テンプレートを作成します。
- ウェブサーバーのマネージド インスタンス グループを構成します。
- モニタリングを使用してヘルスチェックを構成します。
- 前の手順で構成したマネージド インスタンス グループを使用してロード バランシングを構成します。
- Cloud Storage ベースの静的サイトを作成します。
本番環境の構成では、このプライマリ アプリケーションを指すように Cloud DNS が構成され、スタンバイの静的サイトは休眠状態になります。Compute Engine アプリケーションが停止した場合は、Cloud DNS がこの静的サイトを指すように構成します。
フェイルオーバー プロセス
1 つ以上のアプリケーション サーバーが停止した場合、静的なウェブサイトを指すように Cloud DNS を構成します。次の図は、復旧モードのアーキテクチャを示しています。
アプリケーションの Compute Engine インスタンスの実行が再開され、本番環境のワークロードへの対応が可能になったら、復旧ステップの逆を行い、このインスタンスの外側にあるロードバランサを指すように Cloud DNS を構成します。
または、Persistent Disk 非同期レプリケーションを使用することもできます。クロスリージョンのアクティブ / パッシブ DR 向けに、低い目標復旧時点（RPO）と低い目標復旧時間（RTO）のブロック ストレージ レプリケーションを提供します。このストレージ オプションを使用すると、Compute Engine ワークロードのレプリケーションをワークロード レベルではなくインフラストラクチャ レベルで管理できます。
ホット: HA のウェブ アプリケーション
本番環境を Google Cloud 上で稼働している場合のホットパターンは、適切に設計された HA デプロイを確立することです。
このパターンでは、次の DR 構成要素を使用します。
- Compute Engine
- Cloud Load Balancing
- Cloud SQL
次の図は、この例のアーキテクチャを示しています。
このシナリオでは、Google Cloud の HA 機能を活用しています。フェイルオーバー ステップは障害発生時に自動的に起動されるため、手動で開始する必要はありません。
図に示されているように、このアーキテクチャでは、グローバルな負荷分散および Cloud SQL とともに、リージョン マネージド インスタンス グループが使用されています。この例では、リージョン マネージド インスタンス グループが使用されているため、インスタンスが 3 つのゾーンに分散されています。
このアプローチでは、徹底的な HA を実現できます。リージョン マネージド インスタンス グループによって、アプリケーション、インスタンス、またはゾーンのレベルの障害に対処するメカニズムが提供されるため、これらのシナリオの発生時に手動による介入は必要がありません。
アプリケーション レベルの復旧を処理するには、マネージド インスタンス グループの設定の一環として、そのグループ内のインスタンスでサービスが正常に実行されていることを確認する HTTP ヘルスチェックを構成します。ヘルスチェックによりいずれかのインスタンスでサービスに障害が発生していると判定されると、グループによってそのインスタンスが自動的に再作成されます。
Google Cloud でスケーラブルで復元力のあるアプリケーションを構築する方法については、スケーラブルで復元力のあるアプリのパターン をご覧ください。
次のステップ
- Google Cloud の地域とリージョンを読む。
この DR シリーズの他のドキュメントを見る。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。