ミッション クリティカルなシステムのビジネスの継続性を検討する主な目的は、組織が障害発生時と障害発生後に復元力を確保し、ビジネス オペレーションを継続できるようにすることです。複数の地理的リージョンにわたってシステムとデータを複製し、単一障害点を回避することで、自然災害によるローカル インフラストラクチャへのリスクを最小限に抑えることができます。その他の障害シナリオとしては、深刻なシステム障害、サイバーセキュリティ攻撃、システム構成エラーなどがあります。
障害に耐えられるようにシステムを最適化することは、効果的な事業継続を確立するために不可欠です。システムの信頼性は、パフォーマンス、復元力、稼働時間の可用性、セキュリティ、ユーザー エクスペリエンスなど、さまざまな要因によって影響を受けます。Google Cloud で信頼性の高いサービスを設計して運用する方法の詳細については、Google Cloud アーキテクチャ フレームワークの信頼性の柱と Google Cloud における信頼性の構成要素をご覧ください。
このアーキテクチャ パターンは、複数のコンピューティング環境にわたるアプリケーションの冗長デプロイに依存します。このパターンでは、同じアプリケーションを複数のコンピューティング環境にデプロイし、信頼性を高めることを目指します。ビジネスの継続性とは、中断イベントの発生後も事前に定義された許容レベルで主要なビジネス機能やサービスを継続する組織の能力と定義できます。
障害復旧（DR）はビジネスの継続性のサブセットであると見なされ、重要なビジネス機能をサポートする IT システムが、中断後できるだけ早く運用されるようにすることに焦点を当てます。一般的に、DR 戦略と計画は、より広範なビジネス継続性戦略の形成に役立ちます。技術的な観点から、障害復旧戦略の作成を開始するときに、ビジネス インパクト分析で、2 つの主要な指標である目標復旧時点（RPO）と目標復旧時間（RTO）を定義する必要があります。Google Cloud を使用して障害復旧に対処する方法については、障害復旧計画ガイドをご覧ください。
RPO と RTO の目標値が小さいほど、中断から復旧する時間が短くなり、データ損失が最小限に抑えられます。ただし、冗長システムを構築する必要があるため、コストが高くなります。準リアルタイムのデータ複製を実行でき、障害イベント後に同じ規模で動作する冗長システムは、複雑さ、管理オーバーヘッド、コストの増加につながります。
DR 戦略または DR パターンを選択する決定は、ビジネス インパクト分析に基づいて行う必要があります。たとえば、金融サービス組織では、数分間のダウンタイムでも、経済的損失は DR システムの実装コストをはるかに上回る可能性があります。一方、他の業界の企業では、ビジネスに大きな影響を与えることなく、数時間のダウンタイムを許容できる場合があります。
ミッション クリティカルなシステムをオンプレミスのデータセンターで実行する場合、DR の 1 つのアプローチとして、別のリージョンにある第 2 のデータセンターにスタンバイ システムを確保する方法があります。しかし、より費用対効果の高い方法は、フェイルオーバーのためにパブリック クラウドベースのコンピューティング環境を使用することです。このアプローチは、ビジネス継続性ハイブリッド パターンの主な要因です。クラウドは、DR インフラストラクチャの一部を、使用していないときにオフにできるため、コストの観点で特に魅力的です。低コストの DR ソリューションを実現するために、クラウド ソリューションでは RPO と RTO の値が増加する可能性を許容できます。
上の図は、オンプレミス環境へのフェイルオーバーまたは障害復旧環境としてのクラウドの使用を示しています。
一般的ではなく、必要になることがまれなバリエーションとしては、ビジネス継続性マルチクラウド パターンがあります。このパターンでは、本番環境で 1 つのクラウド プロバイダを使用し、DR 環境で別のクラウド プロバイダを使用します。ワークロードのコピーを複数のクラウド プロバイダにデプロイすることで、マルチリージョン デプロイで提供される以上の可用性を実現できる場合があります。
複数のクラウドにまたがる DR と、異なるリージョンで 1 つのクラウド プロバイダを使用する場合の DR を評価するには、次のようないくつかの考慮事項を徹底的に分析する必要があります。
- 管理性
- セキュリティ
- 全体的な実現可能性
- 費用
- 複数のクラウド プロバイダからのアウトバウンドのデータ転送料金は、クラウド間の継続的な通信によって高額になる可能性があります。
- データベースを複製するときに、大量のトラフィックが発生する可能性があります。
- TCO とクラウド間ネットワーク インフラストラクチャの管理コスト。
規制要件を満たすためにデータが国内に保存される必要がある場合は、国内に DR として 2 つ目のクラウド プロバイダを使用する方法もあります。2 つ目のクラウド プロバイダを使用する場合、オンプレミス環境を使用してハイブリッド構成を構築するオプションがないことが前提となります。クラウド ソリューションの再設計を回避するには、2 つ目のクラウド プロバイダが、リージョン内で必要なすべての機能とサービスを提供することが理想的です。
設計上の考慮事項
- DR の期待値: ビジネスが達成したい目標を RPO と RTO に設定し、DR アーキテクチャと構築計画の指針とします。
- ソリューション アーキテクチャ: このパターンでは、DR の期待値を満たすために、オンプレミス環境の既存の機能を複製する必要があります。したがって、クラウド環境で同じ（またはより最適化された）機能とパフォーマンスを提供するために、アプリケーションの再ホスティング、リファクタリング、または再設計の実現可能性を評価する必要があります。
- 設計と構築: ランディング ゾーンの構築は、ほとんどの場合、クラウド環境にエンタープライズ ワークロードをデプロイするための前提条件です。詳細については、Google Cloud のランディング ゾーンの設計をご覧ください。
DR の呼び出し: DR の設計とプロセスでは、次の質問を検討することが重要です。
- 何によって DR シナリオがトリガーされますか？たとえば、プライマリ サイトの特定の機能またはシステムの障害によって DR がトリガーされる場合があります。
- DR 環境へのフェイルオーバーはどのように呼び出されますか？手動の承認プロセスですか、それとも RTO の目標を達成するように自動化できますか。
- 期待される RTO に合わせてフェイルオーバーを呼び出すように、システム障害検出メカニズムと通知メカニズムをどのように設計すればよいですか？
- 障害が検出された後、トラフィックは DR 環境にどのようにして再ルーティングされますか？
テストを通じて、これらの質問に対する回答を検証します。
テスト: DR へのフェイルオーバーを徹底的にテストして評価します。RPO と RTO の要件を満たしていることを確認します。これにより、必要なときに自信を持って DR を呼び出すことができます。プロセスや技術ソリューションに新しい変更や更新を加えるたびに、テストを再度実施します。
チームのスキル: 環境がサードパーティによって管理されている場合を除き、1 つ以上の技術チームが、クラウド環境で本番環境ワークロードを構築、運用、トラブルシューティングするためのスキルと専門知識を備えている必要があります。
利点
Google Cloud をビジネス継続性のために使用することには、多くの利点があります。
- Google Cloud には世界中に多数のリージョンがあり、同じ大陸内の別のサイトにデータをバックアップまたは複製できます。別の大陸のサイトにデータをバックアップまたは複製することもできます。
- Google Cloud では、Cloud Storage のデュアルリージョンまたはマルチリージョン バケットにデータを保存できます。データは、少なくとも 2 つの地理的に分離されたリージョンに冗長的に保存されます。デュアルリージョン バケットとマルチリージョン バケットに保存されたデータは、デフォルトのレプリケーションを使用して複数の地理的リージョンに複製されます。
- デュアルリージョン バケットは、ビジネスの継続性と DR 計画をサポートする地理的な冗長性を提供します。また、RPO を短縮して高速に複製するために、デュアルリージョンに保存されているオブジェクトは、必要に応じてリージョン間でターボ レプリケーションを使用できます。
- 同様に、マルチリージョン レプリケーションでは、マルチリージョンの地理的境界内にデータを保存することで、複数のリージョンにわたって冗長性を確保します。
- 次のオプションのうち 1 つ以上を提供して、DR を構築するための資本支出と運用支出を削減します。
- 停止した VM インスタンスは、ストレージの費用しか発生せず、実行中の VM インスタンスよりも大幅に低価格になります。つまり、コールド スタンバイ システムの保守の費用を最小限に抑えることができます。
- Google Cloud の従量課金モデルでは、実際に使用したストレージとコンピューティング容量に対してのみ料金が発生します。
- 自動スケーリングなどの弾力性の機能により、DR 環境を必要に応じて自動的にスケールアップまたはスケールダウンできます。
たとえば、次の図は、Compute Engine、Cloud SQL、Cloud Load Balancing を使用した Google Cloud 上の復元コンポーネントを使用する、オンプレミス環境（本番環境）で実行されているアプリケーションを示しています。このシナリオでは、VM ベースのデータベースまたは Google Cloud マネージド データベース（Cloud SQL など）を使用してデータベースを事前プロビジョニングし、継続的なデータ レプリケーションによる高速な復元を実現します。作成済みのスナップショットから Compute Engine VM を起動すると、通常のオペレーション時のコストを削減できます。この設定では、障害イベントが発生した後、DNS が Cloud Load Balancing の外部 IP アドレスを参照する必要があります。
アプリケーションをクラウドで動作させるには、ウェブ VM とアプリケーション VM をプロビジョニングする必要があります。目標とする RTO レベルと会社のポリシーに応じて、DR の呼び出し、クラウドへのワークロードのプロビジョニング、トラフィックの再ルーティングを行うプロセス全体を手動または自動で完了できます。
インフラストラクチャのプロビジョニングを高速化および自動化するには、インフラストラクチャをコードとして管理することを検討してください。継続的インテグレーション サービスである Cloud Build を使用して、Terraform マニフェストを環境に自動的に適用できます。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。
ベスト プラクティス
ビジネス継続性パターンを使用している場合は、次のベスト プラクティスを検討してください。
- フェイルオーバー手順と復旧手順とともにインフラストラクチャについて文書化した障害復旧計画を作成します。
- ビジネス インパクト分析と、特定された必要な RPO と RTO の目標に基づいて、次のアクションを検討してください。
- データのバックアップのみを行う場合は、ハンドオーバー パターンの使用を検討してください。それ以外の場合、メッシュ パターンは、既存の環境のネットワーク アーキテクチャを複製するのに適した方法です。
- 異なる環境で動作するシステム間の依存関係を最小限に抑えます（特に、通信が同期的に処理されている場合）。こうした依存関係は、パフォーマンスや全体的な可用性の低下の原因となります。
スプリット ブレインの問題を回避します。環境間で双方向にデータを複製すると、スプリット ブレインが発生する可能性があります。スプリット ブレインの問題は、データを双方向に複製する 2 つの環境が互いの通信を失う場合に発生します。この分割により、両方の環境のシステムが、他方の環境が利用できず自身がデータへの排他的アクセス権を持っていると判断する可能性があります。これにより、競合するデータ変更が発生する可能性があります。スプリット ブレインの問題を回避する一般的な方法は 2 つあります。
- 3 つ目のコンピューティング環境を使用する。この環境では、システムはデータを変更する前にクォーラムをチェックできます。
接続が復元された後、競合するデータ変更を調整できます。
SQL データベースでは、クライアントが新しいプライマリ インスタンスの使用を開始する前に、元のプライマリ インスタンスにアクセスできないようにすることで、スプリット ブレインの問題を回避できます。詳細については、Cloud SQL データベースの障害復旧をご覧ください。
CI / CD システムとアーティファクトのリポジトリが単一障害点にならないようにします。1 つの環境が利用できない場合でも、新しいリリースをデプロイしたり、構成の変更を適用したりできる必要があります。
スタンバイ システムを使用する場合は、すべてのワークロードの移植可能性を確保します。すべてのワークロードは、環境間でシステムの一貫性が維持されるように、移植可能（アプリケーションでサポートされており、実行可能）である必要があります。このアプローチは、コンテナと Kubernetes を検討することで実現できます。Google Kubernetes Engine（GKE）Enterprise エディションを使用すると、ビルドと運用を簡素化できます。
スタンバイ システムのデプロイを CI / CD パイプラインに統合します。この統合により、環境全体でアプリケーションのバージョンと構成の一貫性が確保されます。
DNS の変更が迅速に伝達されるように、DNS を適度に短い有効期間値で構成します。これにより、災害が発生したときにユーザーをスタンバイ システムに再ルーティングできます。
アーキテクチャとソリューションの動作に沿った DNS ポリシーとルーティング ポリシーを選択します。また、複数のリージョン ロードバランサと DNS ルーティング ポリシーを組み合わせて、ハイブリッド設定など、さまざまなユースケースに対応するグローバル ロード バランシング アーキテクチャを作成することもできます。
複数の DNS プロバイダを使用します。複数の DNS プロバイダを使用すると、次のことが可能になります。
- アプリケーションとサービスの可用性と復元力を向上させる。
マルチプロバイダの DNS 構成を使用すると、オンプレミス環境とクラウド環境の間で依存関係があるハイブリッド アプリケーションのデプロイや移行を簡素化できます。
Google Cloud には、複数の DNS プロバイダを使用する環境の設定と運用に役立つ、octoDNS に基づくオープンソース ソリューションが用意されています。詳細については、Cloud DNS を使用したマルチプロバイダのパブリック DNS をご覧ください。
スタンバイ システムを使用する場合は、ロードバランサを使用して自動フェイルオーバーを作成します。ロードバランサのハードウェアに障害が発生する可能性があるので注意してください。
ハードウェア ロードバランサではなく Cloud Load Balancing を使用すると、このアーキテクチャ パターンの使用時に発生する一部のシナリオに対応できます。内部クライアント リクエストまたは外部クライアント リクエストは、重み付けに基づくトラフィック分割などのさまざまな指標に基づいて、プライマリ環境または DR 環境にリダイレクトできます。詳細については、グローバル外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。
Google Cloud から他の環境へのアウトバウンド データ転送量が多い場合は、Cloud Interconnect または Cross-Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
Google Cloud Marketplace 上の希望するパートナー ソリューションを使用して、データのバックアップ、レプリケーション、RPO と RTO の目標などの要件を満たすその他のタスクを容易にすることを検討してください。
DR 呼び出しシナリオをテストして評価し、目標 RTO 値と比較してどのくらいすばやく障害イベントからアプリケーションを復旧できるかを把握します。
転送中の通信を暗号化します。機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec などがあります。