アプリケーションの障害復旧シナリオ

この記事は、Google Cloud Platform(GCP)の障害復旧(DR)について説明したマルチパート シリーズの最後の部分です。ここでは、アプリケーションの一般的な障害復旧シナリオについて説明します。

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

はじめに

この記事では、障害イベントからどのようにしてアプリケーションを簡単に復旧できるかを示す DR パターンの観点から、アプリケーションの DR シナリオを説明します。DR の構成要素の記事で説明したコンセプトを使用して、復旧目標に適したエンド ツー エンドの DR 計画を実装する方法を説明します。

まず、典型的なワークロードを例にとり、復旧の目標とアーキテクチャがどのように DR 計画に直接的な影響を与えるかについて考察してみましょう。

バッチ処理のワークロード

バッチ処理のワークロードは、多くの場合ミッション クリティカルではありません。そのため、通常は稼働時間を最大化する HA(高可用)アーキテクチャの設計にコストをかける必要はありません。一般に、バッチ処理のワークロードは中断に対応できます。このタイプのワークロードには、通常のインスタンスよりはるかに低価格で作成、実行できるプリエンプティブ VM インスタンスのような、コスト効率の高いプロダクトを活用できます(ただし、このインスタンスは、他のタスクのリソースへのアクセスが必要な場合に、Compute Engine によって終了(プリエンプト)されます。また、起動してから最大 24 時間で終了されます)。

処理タスクの一環として定期的なチェックポイントを実装することにより、新しい VM が起動したときに処理ジョブを障害発生ポイントから再開できます。Cloud Dataproc を使用している場合、プリエンプト可能なワーカーノードを起動するプロセスは、マネージド インスタンス グループによって管理されます。これはウォーム パターンと見なすことができ、置き換え用 VM による処理の続行を待機するための短い一時停止が発生します。

e コマースサイト

e コマースサイトでは、アプリケーションのいくつかの部分の RTO 値を比較的大きくできる場合があります。たとえば、実際の購買パイプラインには高可用性が必要ですが、注文のお知らせを顧客に送信するメール処理は数時間の遅延を許容できます。顧客は確認メールが届くのを期待しますが、自分の購入内容は把握しているはずなので、この通知が購入プロセスに欠かせない部分というわけではありません。これは、ホット(購買)パターンとウォーム / コールド(通知)パターンを混合したものです。

アプリケーションのトランザクション部分には、高い稼働時間と最小限の RTO 値が求められます。そのため、この部分には HA を使用して可用性を最大限にします。このアプローチは、ホットパターンと見なすことができます。

この e コマース シナリオは、同じアプリケーション内でさまざまな RTO 値を設定する方法を示しています。

動画ストリーミング

動画ストリーミング ソリューションには、検索エクスペリエンスからユーザーにコンテンツをストリーミングする実際のプロセスまで、高可用性が要求される要素が多く存在します。さらに、ユーザーが満足できるエクスペリエンスを提供するには、システムのレイテンシを低くする必要があります。ソリューションのどの部分でも優れたエクスペリエンスを提供しないと、サプライヤにも顧客にも不満が生じます。さらに、昨今の顧客はすぐに他の競合製品に関心が移ってしまいます。

このようなシナリオでは、HA アーキテクチャは必須であり、RTO 値を小さくする必要があります。このシナリオでは、アプリケーション アーキテクチャ全体にホットパターンを適用して、障害発生時の影響を最小限に抑えることを保証する必要があります。

オンプレミスの本番環境用の DR および HA アーキテクチャ

このセクションでは、アプリケーションがオンプレミスで実行され、DR ソリューションが GCP 上にある場合に、コールド、ウォーム、ホットの 3 つのパターンを実装する方法について説明します。

コールド パターン: GCP への復旧

コールド パターンの場合、DR GCP プロジェクトのリソースは最小限に抑えられており、復旧シナリオの実現に必要なもののみとなっています。本番環境で本番のワークロードを実行できないような問題が発生した場合、フェイルオーバー機能は本番環境のミラーリングを GCP で開始するよう要求します。その後、クライアントは DR 環境のサービスを使用し始めます。

ここでは、上記のパターンの例を検証します。例では、GCP への接続を提供するために、Cloud VPN を使用して Cloud Interconnect が構成されています。データは、本番環境の一部として Cloud Storage にコピーされます。

DR の構成要素:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

次の図は、この例のアーキテクチャを示しています。

本番環境がオンプレミスの場合のコールド パターンのアーキテクチャ

この環境を構成する方法を次のステップで概説します

  1. VPC ネットワークを作成します
  2. オンプレミスのネットワークと GCP ネットワークとの接続を構成します
  3. データのバックアップ先として、Cloud Storage バケットを作成します
  4. 専用サービス アカウントのサービス アカウント キーを生成します。このファイルを使用して自動スクリプトに認証情報を渡します。
  5. データベースのバックアップをアップロードするスクリプトを実行するオンプレミス マシンに、サービス アカウント キーをコピーします(これはデータベース サーバーでもかまいませんが、使用するセキュリティ ポリシーによっては、データベース サーバーへの追加のソフトウェアのインストールが許可されない場合があります)。

  6. IAM ポリシーを作成して、バケットとそのオブジェクトにアクセスできるユーザーを制限します。この目的のために作成した専用サービス アカウントを含めます。また、オペレーターおよびシステム管理者のユーザー アカウントやグループをポリシーに追加して、これらすべての ID に適切なアクセス権を付与します。Cloud Storage へのアクセス権の詳細については、gsutil コマンドの IAM 権限をご覧ください。

  7. ターゲット バケットでファイルのアップロードとダウンロードをテストします。

  8. データ転送スクリプトを作成します

  9. このスクリプトを実行するようにスケジュール設定されたタスクを作成します。

  10. 本番環境内のサーバーごとに構成したカスタム イメージを作成します。各イメージは、オンプレミスと同じ構成である必要があります。

    データベース サーバーのカスタム イメージを構成する一環として起動スクリプトを作成します。このスクリプトで、Cloud Storage バケットからインスタンスに最新のバックアップを自動的にコピーして、復元プロセスを呼び出すようにします。

  11. インターネットに接続するウェブサービスを指すよう Cloud DNS を構成します

  12. 以前に構成したカスタムイメージを使用して GCP ネットワークにアプリケーション サーバーを作成する Deployment Manager テンプレートを作成します。このテンプレートには、必要とされる適切なファイアウォール ルールも設定する必要があります。

カスタム イメージのアプリケーション バージョンがオンプレミスと同じになるようにするプロセスを実装する必要があります。標準アップグレード サイクルの一環としてカスタム イメージへのアップグレードも実装するようにします。また、Cloud Deployment Manager テンプレートで最新のカスタム イメージが使用されるようにします。

フェイルオーバー プロセスと再起動後のタスク

障害が発生した場合は、GCP で稼働しているシステムに復旧できます。これを行うには、作成した Deployment Manager テンプレートを使用して復旧環境を作成する、修復プロセスを起動します。復旧環境のインスタンスで本番環境のトラフィックを受け入れる準備が整ったら、GCP のウェブサーバーを指すよう DNS を調整します。

一般的な復旧シーケンスは次のとおりです。

  1. GCP でデプロイメントを作成するには、Deployment Manager テンプレートを使用します。
  2. ご使用のデータベース システムのバックアップ ファイル復元手順に沿って、GCP で実行されているデータベース サーバーに、Cloud Storage にある最新のデータベース バックアップを適用します。
  3. Cloud Storage の最新のトランザクション ログを適用します。
  4. 復旧した環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおり動作することをテストします。
  5. テストが正常に完了したら、GCP 上のウェブサーバーを指すように Cloud DNS を構成します(たとえば、ロードバランサの内側に複数のウェブサーバーが存在する場合は、GCP ロードバランサの内側のエニーキャスト IP アドレスを使用できます)。

次の図は、復旧した環境を示しています。

本番環境がオンプレミスの場合のコールド パターンの復旧の構成

オンプレミスでの本番環境の稼働が再開され、本番のワークロードに対応できるようになったら、GCP 復旧環境へのフェイルオーバー時に使用したステップの逆を行います。本番環境に復帰するための一般的なシーケンスは次のとおりです。

  1. GCP 上で実行されているデータベースのバックアップをとります。
  2. バックアップ ファイルを本番環境にコピーします。
  3. 本番環境データベース システムにバックアップ ファイルを適用します。
  4. GCP 内のアプリケーションに接続できないようにします。たとえば、グローバル ロードバランサに接続できないようにします。この時点から本番環境の復元が完了するまで、アプリケーションは使用できなくなります。
  5. 本番環境にすべてのトランザクション ログファイルをコピーし、データベース サーバーに適用します。
  6. オンプレミスのウェブサービスを指すように Cloud DNS を構成します
  7. Cloud Storage にデータをコピーするために用意したプロセスが想定どおりに動作していることを確認します。
  8. デプロイメントを削除します

ウォーム スタンバイ: GCP への復旧

多くの場合、ウォーム パターンは、完全な HA 構成にかかる労力と費用を要することなく、RTO と RPO の値をできるだけ小さく維持するために導入されます。RTO と RPO の値を小さくすればするほど完全な冗長環境に近づき、2 つの環境からのトラフィックを処理できるようになりますが、コストは高くなります。そのため、DR シナリオにウォーム パターンを導入することは、予算と可用性とのトレードオフをバランスよく保つことになります。

このアプローチの一例は、Cloud VPN が構成された Cloud Interconnect を使用して GCP への接続を提供することです。オンプレミスで多層アプリケーションを実行すると同時に、GCP で最小限の復旧スイートを使用します。復旧スイートは、GCP 上の運用データベース サーバー インスタンスで構成されます。このインスタンスは、非同期または準同期のレプリケーション技術を使用してレプリケートされたトランザクションを受信できるよう、常に実行されている必要があります。コストを削減するには、データベース サービスを実行できる最小マシンタイプでデータベースを実行します。長時間実行インスタンスを使用できるため、継続利用割引が適用されます。

DR の構成要素:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Deployment Manager

Compute Engine のスナップショットを使用すれば、以前の状態にロールバックできるバックアップを作成できます。この例では、更新されたウェブページやアプリケーション バイナリが本番環境のウェブサーバーやアプリケーション サーバーに頻繁に書き込まれるため、スナップショットを使用します。これらの更新は、GCP 上の参照ウェブサーバーとアプリケーション サーバーのインスタンスに定期的にレプリケートされます(参照サーバーは本番環境のトラフィックを受け入れません。これらのサーバーはスナップショットの作成に使用されます)。

次の図は、このアプローチを実装するアーキテクチャを示しています。レプリケーションのターゲットは、図に表示されていません。

本番環境がオンプレミスの場合のウォーム パターンのアーキテクチャ

この環境を構成する方法を次のステップで概説します

  1. VPC ネットワークを作成します
  2. オンプレミスのネットワークと GCP ネットワークとの接続を構成します
  3. オンプレミス サーバーを GCP VM インスタンスに複製します。これには、パートナー ソリューションを使用する方法もあります。どの方法を採用するかは環境によって異なります。
  4. GCP 上のデータベース サーバーのカスタム イメージを、オンプレミスのデータベース サーバーと同じ構成で作成します。
  5. ウェブサーバー インスタンスとアプリケーション サーバー インスタンスのスナップショットを作成します
  6. 前の手順で作成したカスタム イメージを使用して、GCP でデータベース インスタンスを開始します。オンプレミスの本番環境データベースから複製されたデータを受け入れることができる最小マシンタイプを使用します。
  7. データベース ログとトランザクション ログを保管するために、GCP データベース インスタンスに永続ディスクを接続します
  8. ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと GCP のデータベース サーバーとの間のレプリケーションを構成します。
  9. データベース インスタンスに接続されている永続ディスクで、自動削除フラグを no-auto-delete に設定します。
  10. GCP 上のデータベース インスタンスの永続ディスクのスナップショットを定期的に作成するようスケジュール設定されたタスクを構成します。
  11. スナップショットからインスタンスを作成するプロセスと、永続ディスクのスナップショットを取得するプロセスをテストします。
  12. 前の手順で作成されたスナップショットを使用して、ウェブサーバーとアプリケーション サーバーのインスタンスを作成します。
  13. 対応するオンプレミス サーバーが更新されるたびに、ウェブ アプリケーションとアプリケーション サーバーに更新をコピーするスクリプトを作成します。更新されたサーバーのスナップショットを作成するスクリプトを作成します。
  14. オンプレミスでインターネットに接続するウェブサービスを指すように Cloud DNS を構成します。

フェイルオーバー プロセスと再起動後のタスク

フェイルオーバーを管理するには、通常はモニタリングおよびアラート システムを使用して自動フェイルオーバー プロセスを起動します。オンプレミスのアプリケーションをフェイルオーバーする必要がある場合は、本番環境のトラフィックを受け入れられるように GCP 上のデータベース システムを構成します。また、ウェブサーバーおよびアプリケーション サーバーのインスタンスも開始します。

次の図は、GCP にフェイルオーバーし、GCP から本番環境のワークロードを提供できるようになった後の構成を示しています。

本番環境がオンプレミスの場合のウォーム パターンの復旧の構成

一般的な復旧シーケンスは次のとおりです。

  1. データベース サーバー インスタンスのサイズを変更して、本番環境の負荷を処理できるようにします。
  2. GCP 上のウェブサーバーとアプリケーションのスナップショットを使用して、新しいウェブサーバーとアプリケーションのインスタンスを作成します。
  3. 復旧した環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおり動作することをテストします。
  4. テストが正常に完了したら、GCP 上のウェブサービスを指すように Cloud DNS を構成します。

オンプレミスでの本番環境の稼働が再開され、本番のワークロードに対応できるようになったら、GCP 復旧環境へのフェイルオーバー時に使用したステップの逆を行います。本番環境に復帰するための一般的なシーケンスは次のとおりです。

  1. GCP 上で実行されているデータベースのバックアップをとります。
  2. バックアップ ファイルを本番環境にコピーします。
  3. 本番環境データベース システムにバックアップ ファイルを適用します。
  4. GCP 内のアプリケーションに接続できないようにします。たとえば、ファイアウォール ルールを変更して、ウェブサーバーに接続できないようにします。この時点から本番環境の復元が完了するまで、アプリケーションは使用できなくなります。
  5. 本番環境にすべてのトランザクション ログファイルをコピーし、データベース サーバーに適用します。
  6. 本番環境でユーザー シナリオをシミュレートし、アプリケーションが想定どおりに動作するかをテストします。
  7. オンプレミスのウェブサービスを指すように Cloud DNS を構成します
  8. GCP で実行されているウェブサーバーとアプリケーション サーバーのインスタンスを削除します。参照サーバーは実行したままにします。
  9. GCP 上のデータベース サーバーのサイズを変更して、オンプレミスの本番環境データベースから複製されたデータを受け入れられる最小限のインスタンス サイズに戻します。
  10. ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと GCP のデータベース サーバーとの間のレプリケーションを構成します。

オンプレミスと GCP との間でのホット HA 構成

RTO と RPO の値が非常に小さい場合、これらの値は、本番環境と GCP との間で同時に HA 構成を実行することでのみ達成可能です。このアプローチは、オンプレミスと GCP の両方が本番環境のトラフィックを処理するため、ホットパターンとなります。

ウォーム パターンとの主な違いは、両方の環境のリソースが本番環境モードで稼働し、本番環境のトラフィックを処理することです。

DR の構成要素:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • マネージド インスタンス グループ
  • Stackdriver
  • Cloud Load Balancing

次の図は、この例のアーキテクチャを示しています。このアーキテクチャを実装することで、障害発生時に最小限の介入で済む DR 計画を実現できます。

本番環境がオンプレミスの場合のホットパターンのアーキテクチャ

この環境を構成する方法を次のステップで概説します

  1. VPC ネットワークを作成します
  2. オンプレミス ネットワークと GCP ネットワークとの間の接続を構成します
  3. GCP に、オンプレミスの本番環境内のサーバーごとに構成したカスタム イメージを作成します。各 GCP イメージは、オンプレミスと同じ構成である必要があります。
  4. ご使用のデータベース ソフトウェアの手順に沿って、オンプレミスのデータベース サーバーと GCP のデータベース サーバーとの間のレプリケーションを構成します。

    多くのデータベース システムは、レプリケーションを構成する際に書き込み可能なデータベース インスタンスを 1 つしか許容していません。このため、データベース レプリカの 1 つを読み取り専用サーバーにする必要がある場合があります。

  5. アプリケーション サーバーとウェブサーバーのイメージを使用するインスタンス テンプレートを個々に作成します。

  6. アプリケーション サーバーとウェブサーバーのリージョン マネージド インスタンス グループを構成します。

  7. Stackdriver Monitoring を使用してヘルスチェックを構成します。

  8. 前の手順で構成したリージョン マネージド インスタンス グループを使用して、負荷分散を構成します。

  9. 永続ディスクのスナップショットを定期的に作成するようスケジュール設定されたタスクを構成します。

  10. オンプレミス環境と GCP 環境の間でトラフィックを分散する DNS サービスを構成します。

このハイブリッド アプローチでは、2 つの本番環境への重み付きルーティングをサポートする DNS サービスを使用して、双方で同じアプリケーションを処理できるようにする必要があります。

システムは、1 つの環境の一部分だけで発生する可能性のある障害(部分的な障害)に備えて設計する必要があります。その場合、トラフィックは、他方のバックアップ環境の同等のサービスに再ルーティングされることになります。たとえば、オンプレミスのウェブサーバーが使用不能になった場合、その環境への DNS ルーティングを無効化できます。DNS サービスがヘルスチェックをサポートする場合は、ヘルスチェックで一方の環境のウェブサーバーに到達できないと判定されると、この処理が自動的に行われます。

書き込み可能インスタンスが 1 つだけ許可されるデータベース システムを使用している場合、元の書き込み可能データベースとリードレプリカ(読み取りレプリカ)との間でハートビートの接続が失われると、多くの場合はデータベース システムによって読み取り専用レプリカが書き込み可能プライマリに自動的に昇格されます。障害発生後に介入が必要な場合に備えて、ご使用のデータベース レプリケーションにこのような側面があることを必ず理解しておいてください。

GCP のカスタム VM イメージのアプリケーション バージョンが、オンプレミスと同じバージョンになるように所定のプロセスを実装する必要があります。標準アップグレード サイクルの一環としてカスタム イメージへのアップグレードを実装し、Cloud Deployment Manager テンプレートで最新のカスタム イメージが使用されるようにします。

フェイルオーバー プロセスと再起動後のタスク

ここで説明するホットシナリオの構成では、障害とは単に 2 つの環境の一方が利用できなくなることを意味します。ウォーム シナリオやコールド シナリオのように、フェイルオーバー プロセスでデータや処理を第 2 の環境に移動する必要はありません。ただし、次の構成変更の処理が必要になる場合があります。

  • DNS サービスがヘルス チェック エラーに基づいて自動的にルーティングを変更しない場合は、DNS ルーティングを手動で再構成して、稼働中のシステムにトラフィックを送信する必要があります。
  • 障害発生時にデータベース システムが読み取り専用レプリカを書き込み可能プライマリに自動的に昇格しない場合は、レプリカが確実に昇格するように介入する必要があります。

第 2 の環境の稼働が再開され、本番環境のトラフィックの処理が可能になったら、データベースを再同期する必要があります。どちらの環境も本番環境のワークロードをサポートしているため、プライマリ データベースを変更する操作は必要ありません。データベースが同期したら、DNS 設定を調整して両方の環境に本番環境のトラフィックを再度分散できます。

GCP 上の本番環境用の DR および HA アーキテクチャ

GCP 上に本番環境ワークロード用のアプリケーション アーキテクチャを設計すると、プラットフォームの HA 機能が DR アーキテクチャに直接影響を及ぼします。

コールド: 復元可能なアプリケーション サーバー

コールド シナリオではサーバー インスタンスを 1 つしか必要としないため、ディスクに書き込みを行うインスタンスが 1 つになるようにする必要があります。オンプレミスでは、アクティブ / パッシブ クラスタを使用することでこれを実現することが多いです。一方、GCP で本番環境を稼働する場合、サーバー インスタンスはマネージド インスタンス グループに属し、このグループが内部負荷分散サービスのバックエンド サービスとして使用されます。

DR の構成要素:

  • Compute Engine
  • GCP 内部負荷分散

次の図は、この例のアーキテクチャを示しています。通常、外部クライアントはアプリケーション サーバーに直接接続することはないため、クライアント接続は示されていません。その代わり、アプリケーション サーバーの外側にはプロキシまたはウェブ アプリケーションが存在しています。

本番環境が GCP 上にある場合のコールド シナリオのアーキテクチャ

このシナリオを構成する方法を次のステップで概説します。

  1. VPC ネットワークを作成します
  2. アプリケーション サービスで構成されたカスタム イメージを作成します。イメージの一部として、次の構成を行います。

    1. アプリケーション サービスによって処理されたデータが、接続された永続ディスクに書き込まれるように、サーバーを構成します。
    2. 接続された永続ディスクからスナップショットを作成します
    3. 起動スクリプトを構成します。このスクリプトで、最新のスナップショットから永続ディスクを作成して、ディスクをマウントするようにします。このスクリプトは、ディスクの最新のスナップショットを取得できる必要があります。
  3. このイメージを使用するインスタンス テンプレートを作成します。

  4. 前の手順で作成したインスタンス テンプレートを使用して、ターゲット サイズが 1 であるリージョン マネージド インスタンス グループを構成します。

  5. モニタリングを使用してヘルスチェックを構成します。

  6. 前の手順で構成したリージョン マネージド インスタンス グループを使用して、内部負荷分散を構成します。

  7. 永続ディスクのスナップショットを定期的に作成する、スケジュール設定されたタスクを構成します。

このシナリオでは、GCP で利用可能な HA 機能の一部を活用しています。フェイルオーバー ステップは障害発生時に自動的に起動されるため、手動で開始する必要はありません。内部ロードバランサは、置換インスタンスが必要な場合でも、アプリケーション サーバーには同じ IP アドレスが使用されるようにします。インスタンス テンプレートとカスタム イメージによって、置換インスタンスは必ず置換前のインスタンスと同一の構成になります。

RPO は、最後に取得されたスナップショットによって決定されます。スナップショットの取得頻度が高いと、RPO 値は小さくなります。

リージョン マネージド インスタンス グループは、徹底的な HA を提供します。アプリケーション、インスタンス、またはゾーンのレベルの障害に対処するメカニズムを提供します。これらのシナリオのいずれかが発生した場合に、手動介入は必要ありません。ターゲット サイズを 1 に設定することで、実行されるインスタンスは常に 1 つだけになります。

永続ディスクはゾーン単位であるため、ゾーンの障害が発生した場合にディスクを再作成するにはスナップショットが必要になります。スナップショットはリージョン間でも使用できるため、同じリージョンに復旧する場合と同様に、別のリージョンに簡単にディスクを復旧できます。

フェイルオーバー プロセス

このシナリオでは、ゾーンの障害が発生した場合に、リージョン インスタンス グループによって、同じリージョン内の別のゾーン内の置換インスタンスが起動されます。新しい永続ディスクが最新のスナップショットから作成され、新しいインスタンスに接続されます。次の図は、この状態を示しています。

本番環境が GCP 上にある場合のコールド パターンの復旧の構成

この構成には、次のようなバリエーションがあります。

  • ゾーンの永続ディスクの代わりにリージョンの永続ディスクを使用する。このアプローチでは、復旧手順の一環としてスナップショットを使用して永続ディスクを復元する必要がありません。しかし、このバリエーションでは 2 倍のストレージが消費されるため、それに応じた予算が必要になります。
  • リージョン マネージド インスタンス グループではなくマネージド インスタンス グループを使用し、障害が発生したインスタンスと同じゾーンで開始される置換インスタンスに永続ディスクを接続する。このシナリオでは、永続ディスクの自動削除を no-auto-delete に構成する必要があります。

どのアプローチを選択するかは、予算および RTO と RPO の値によって決まります。

ウォーム: 静的サイト フェイルオーバー

Compute Engine インスタンスに障害が発生した場合、Cloud Storage ベースの静的サイトをスタンバイとして設定することで、サービスの中断を緩和できます。 静的サイトの使用は、ウェブ アプリケーションがほとんど静的である場合のオプションです。このシナリオでは、プライマリ アプリケーションが Compute Engine インスタンス上で実行されます。これらのインスタンスは、マネージド インスタンス グループにまとめられ、これらのインスタンス グループが HTTP ロードバランサのバックエンド サービスとしての役割を果たします。HTTP ロードバランサは、ロードバランサの構成、各インスタンス グループの構成、そして各インスタンスのヘルス状態に応じて、着信トラフィックをインスタンスに誘導します。

DR の構成要素:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

次の図は、この例のアーキテクチャを示しています。

本番環境が GCP 上にある場合の静的サイトへのウォーム フェイルオーバーのアーキテクチャ

このシナリオを構成する方法を次のステップで概説します。

  1. VPC ネットワークを作成します
  2. アプリケーション ウェブサービスで構成されているカスタム イメージを作成します。
  3. ウェブサーバー用のイメージを使用するインスタンス テンプレートを作成します。
  4. ウェブサーバーのマネージド インスタンス グループを構成します。
  5. モニタリングを使用してヘルスチェックを構成します。
  6. 前の手順で構成したマネージド インスタンス グループを使用して負荷分散を構成します。
  7. Cloud Storage ベースの静的サイトを作成します。

本番環境の構成では、このプライマリ アプリケーションを指すように Cloud DNS が構成され、スタンバイの静的サイトは休眠状態になります。Compute Engine アプリケーションが停止した場合は、Cloud DNS がこの静的サイトを指すように構成します。

フェイルオーバー プロセス

1 つ以上のアプリケーション サーバーが停止した場合、静的なウェブサイトを指すように Cloud DNS を構成します。次の図は、復旧モードのアーキテクチャを示しています。

本番環境が GCP 上にある場合の静的サイトへのフェイルオーバー後の構成

アプリケーションの Compute Engine インスタンスの実行が再開され、本番環境のワークロードへの対応が可能になったら、復旧ステップの逆を行い、このインスタンスの外側にあるロードバランサを指すように Cloud DNS を構成します。

ホット: HA のウェブ アプリケーション

本番環境を GCP 上で稼働している場合のホットパターンは、適切に設計された HA デプロイを確立することです。

DR の構成要素:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

次の図は、この例のアーキテクチャを示しています。

本番環境が GCP 上にある場合のホットパターンのアーキテクチャ

このシナリオでは、GCP の HA 機能を活用しています。フェイルオーバー ステップは障害発生時に自動的に起動されるため、手動で開始する必要はありません。

図に示されているように、このアーキテクチャでは、グローバルな負荷分散および Cloud SQL とともに、リージョン マネージド インスタンス グループが使用されています。この例では、リージョン マネージド インスタンス グループが使用されているため、インスタンスが 3 つのゾーンに分散されています。

このアプローチでは、徹底的な HA を実現できます。リージョン マネージド インスタンス グループによって、アプリケーション、インスタンス、またはゾーンのレベルの障害に対処するメカニズムが提供されるため、これらのシナリオの発生時に手動による介入は必要がありません。

アプリケーション レベルの復旧を処理するには、マネージド インスタンス グループの設定の一環として、そのグループ内のインスタンスでサービスが正常に実行されていることを確認する HTTP ヘルスチェックを構成します。ヘルスチェックによりいずれかのインスタンスでサービスに障害が発生していると判定されると、グループによってそのインスタンスが自動的に再作成されます。

GCP 上で HA のウェブ アプリケーションを構成する方法の詳細な手順については、GCP のスケーラブルで復元力を備えたウェブ アプリケーションをご覧ください。

次のステップ

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

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