この記事は、Google Cloud の障害復旧（DR）について説明するシリーズの一部です。ここでは、アプリケーションの一般的な障害復旧シナリオについて説明します。
シリーズは次のパートで構成されています。
- 障害復旧計画ガイド
- 障害復旧の構成要素
- データの障害復旧シナリオ
- アプリケーションの障害復旧シナリオ（この記事）
- 地域制限があるワークロードの障害復旧の設計
- 障害復旧のユースケース: 地域制限のあるデータ分析アプリケーション
- クラウド インフラストラクチャの停止に対する障害復旧の設計
はじめに
この記事では、障害イベントからどのようにしてアプリケーションを簡単に復旧できるかを示す DR パターンの観点から、アプリケーションの DR シナリオを説明します。DR の構成要素の記事で説明したコンセプトを使用して、復旧目標に適したエンドツーエンドの DR 計画を実装する方法を説明します。
まず、典型的なワークロードを例にとり、復旧の目標とアーキテクチャがどのように DR 計画に直接的な影響を与えるかについて考察してみましょう。
バッチ処理のワークロード
バッチ処理のワークロードは、多くの場合ミッション クリティカルではありません。そのため、通常は稼働時間を最大化する高可用性（HA）アーキテクチャの設計にコストをかける必要はありません。一般に、バッチ処理のワークロードは中断に対応できます。この種類のワークロードには、通常のインスタンスよりはるかに低料金で作成、実行できるプリエンプティブル VM インスタンスのような、コスト効率の高いプロダクトを活用できます（ただし、このインスタンスは、他のタスクのリソースへのアクセスが必要な場合に、Compute Engine によって終了（プリエンプト）されます。また、起動してから最大 24 時間で終了されます）。
処理タスクの一環として定期的なチェックポイントを実装することにより、新しい 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 権限をご覧ください。
ターゲット バケットでファイルのアップロードとダウンロードをテストします。
データ転送スクリプトを作成します。
このスクリプトを実行するようにスケジュール設定されたタスクを作成します。
本番環境内のサーバーごとに構成したカスタム イメージを作成します。各イメージは、オンプレミスと同じ構成である必要があります。
データベース サーバーのカスタム イメージを構成する一環として起動スクリプトを作成します。このスクリプトで、Cloud Storage バケットからインスタンスに最新のバックアップを自動的にコピーして、復元プロセスを呼び出すようにします。
インターネットに接続するウェブサービスを指すよう Cloud DNS を構成します。
以前に構成したカスタム イメージを使用して Google Cloud ネットワークにアプリケーション サーバーを作成する Deployment Manager テンプレートを作成します。このテンプレートには、必要とされる適切なファイアウォール ルールも設定する必要があります。
カスタム イメージのアプリケーション バージョンがオンプレミスと同じになるようにするプロセスを実装する必要があります。標準アップグレード サイクルの一環としてカスタム イメージへのアップグレードも実装するようにします。また、Cloud Deployment Manager テンプレートで最新のカスタム イメージが使用されるようにします。
フェイルオーバー プロセスと再起動後のタスク
障害が発生した場合は、Google Cloud で稼働しているシステムに復旧できます。これを行うには、作成した Deployment Manager テンプレートを使用して復旧環境を作成する、修復プロセスを起動します。復旧環境のインスタンスで本番環境のトラフィックを受け入れる準備が整ったら、Google Cloud のウェブサーバーを指すように DNS を調整します。
一般的な復旧シーケンスは次のとおりです。
- Google Cloud でデプロイメントを作成するために、Deployment Manager テンプレートを使用します。
- ご使用のデータベース システムのバックアップ ファイル復元手順に沿って、Google Cloud で実行されているデータベース サーバーに、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 アーキテクチャに直接影響を及ぼします。
コールド: 復元可能なアプリケーション サーバー
コールド フェイルオーバーのシナリオでは、アクティブなサーバー インスタンスを 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 の値によって決まります。
ウォーム: 静的サイト フェイルオーバー
Cloud Storage ベースの静的サイトをスタンバイとして設定することによって、Compute Engine インスタンスに障害が発生した場合にサービスの中断を緩和できます。静的サイトの使用は、ウェブ アプリケーションがほとんど静的である場合の選択肢です。このシナリオでは、プライマリ アプリケーションが Compute Engine インスタンス上で実行されます。そのインスタンスは、マネージド インスタンス グループにまとめられ、これらのインスタンス グループが HTTPS ロードバランサのバックエンド サービスとして機能します。HTTP ロードバランサは、ロードバランサの構成、各インスタンス グループの構成、そして各インスタンスのヘルス状態に応じて、着信トラフィックをインスタンスに誘導します。
DR の構成要素:
- Compute Engine
- Cloud Storage
- Cloud Load Balancing
- Cloud DNS
次の図は、この例のアーキテクチャを示しています。
このサンプル シナリオをデプロイして障害からの復旧をテストする方法の詳細については、Cloud DNS と Compute Engine および Cloud Storage を使用して、復元可能なウォーム ウェブサーバーをデプロイするをご覧ください。
このシナリオを構成する方法を次のステップで概説します。
- VPC ネットワークを作成します。
- アプリケーション ウェブサービスで構成されているカスタム イメージを作成します。
- ウェブサーバー用のイメージを使用するインスタンス テンプレートを作成します。
- ウェブサーバーのマネージド インスタンス グループを構成します。
- モニタリングを使用してヘルスチェックを構成します。
- 前の手順で構成したマネージド インスタンス グループを使用して負荷分散を構成します。
- Cloud Storage ベースの静的サイトを作成します。
本番環境の構成では、このプライマリ アプリケーションを指すように Cloud DNS が構成され、スタンバイの静的サイトは休眠状態になります。Compute Engine アプリケーションが停止した場合は、Cloud DNS がこの静的サイトを指すように構成します。
フェイルオーバー プロセス
1 つ以上のアプリケーション サーバーが停止した場合、静的なウェブサイトを指すように Cloud DNS を構成します。次の図は、復旧モードのアーキテクチャを示しています。
アプリケーションの Compute Engine インスタンスの実行が再開され、本番環境のワークロードへの対応が可能になったら、復旧ステップの逆を行い、このインスタンスの外側にあるロードバランサを指すように Cloud DNS を構成します。
Cloud DNS の代わりに外部アプリケーション ロードバランサを使用してフェイルオーバーを制御する代替方法については、Compute Engine と Cloud Storage を使用して復元可能なウォーム ウェブサーバーをデプロイするをご覧ください。このパターンは、Cloud DNS がない場合や、使用しない場合に有用です。
ホット: HA のウェブ アプリケーション
本番環境が Google Cloud 上で稼働している場合のホットパターンは、適切に設計された HA デプロイを構築することです。
DR 構成要素:
- Compute Engine
- Cloud Load Balancing
- Cloud SQL
次の図は、この例のアーキテクチャを示しています。
このシナリオでは、Google Cloud の HA 機能を活用しています。フェイルオーバー手順は障害発生時に自動的に始まるため、手動で開始する必要はありません。
図に示されているように、このアーキテクチャでは、グローバルな負荷分散および Cloud SQL とともに、リージョン マネージド インスタンス グループが使用されています。この例では、リージョン マネージド インスタンス グループが使用されているため、インスタンスが 3 つのゾーンに分散されています。
このアプローチでは、徹底的な HA を実現できます。リージョン マネージド インスタンス グループによって、アプリケーション、インスタンス、またはゾーンのレベルの障害に対処するメカニズムが提供されるため、これらのシナリオの発生時に手動による介入は必要がありません。
アプリケーション レベルの復旧を処理するには、マネージド インスタンス グループの設定の一環として、そのグループ内のインスタンスでサービスが正常に実行されていることを確認する HTTP ヘルスチェックを構成します。ヘルスチェックによりいずれかのインスタンスでサービスに障害が発生していると判定されると、グループによってそのインスタンスが自動的に再作成されます。
Google Cloud 上で HA のウェブ アプリケーションを構成する方法の詳細な手順については、Google Cloud のスケーラブルで復元力を備えたウェブ アプリケーションをご覧ください。
次のステップ
- Google Cloud の地域とリージョンを読む。
この DR シリーズの他の記事を読む:
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。