地域制限があるワークロードの障害復旧の設計

Last reviewed 2022-06-10 UTC

このドキュメントでは、Google Cloud を使用してロケーション固有の要件を満たすために障害復旧（DR）を設計する方法について説明します。一部の規制の厳しい業界では、ワークロードがそれらの要件を遵守している必要があります。このシナリオでは、次の 1 つ以上の要件が適用されます。

  • 保存データは、指定した国に限定する必要がある。
  • データは所在する国で処理される必要がある。
  • ワークロードには、事前定義されたロケーションからのみアクセスできる。
  • データは、顧客が管理する鍵で暗号化する必要がある。
  • クラウド サービスを使用している場合は、各クラウド サービスで少なくとも 2 つのロケーションが互いに冗長である必要がある。ロケーションの冗長性要件の例については、クラウド コンピューティングのコンプライアンス基準カタログ（C5）をご覧ください。

この記事は、Google Cloud の障害復旧（DR）について説明するシリーズのパート 5 です。このパートでは、DR 計画プロセスの概要、つまり、DR 計画を設計して実装するために必要な情報を紹介します。

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

用語

地域制限があるワークロードの DR の設計を始める前に、Google Cloud で使用する地域に関する用語を確認することをおすすめします。

Google Cloud は、南北アメリカ、ヨーロッパ、中東、アジア太平洋の全体のリージョンでサービスを提供しています。たとえば、ロンドン（europe-west2）はヨーロッパ内のリージョンであり、オレゴン（us-west1）は北米内のリージョンです。一部の Google Cloud プロダクトでは、複数のリージョンを特定のマルチリージョン ロケーションにグループ化しています。このロケーションには、リージョンと同じ方法でアクセスできます。

リージョンはさらにゾーンに分割され、それらのゾーンで仮想マシン、Kubernetes クラスタ、Cloud SQL データベースなどの特定の Google Cloud リソースをデプロイします。Google Cloud のリソースには、マルチリージョン、リージョン、ゾーンの区別があります。デフォルトでマルチリージョンとして指定されている一部のリソースとプロダクトを、1 つのリージョンに制限することもできます。さまざまなタイプのリソースについて、以下で説明します。

  • マルチリージョン リソースは冗長化され、リージョン内とリージョン間で分散されるように、Google Cloud により設計されています。マルチリージョン リソースは、単一リージョンの障害に対する回復力があります。
  • リージョン リソースは、リージョン内の複数のゾーンに重複してデプロイされ、リージョン内のゾーンの障害に対する回復力があります。
  • ゾーンリソースは、単一のゾーン内で動作します。ゾーンが利用不可能になった場合、そのゾーン内のすべてのゾーンリソースは、サービスが復旧するまで利用できなくなります。ゾーンは単一の障害発生ドメインとみなします。単一のゾーンが使用不能になった場合の影響を軽減するようにアプリケーションを設計する必要があります。

次の表は、ヨーロッパのリージョン、ゾーン、ロケーション間の現在の関係を示しています。

リージョン ゾーン ロケーション
europe-north1 a、b、c ハミナ（フィンランド）
europe-west1 b、c、d サンギスラン（ベルギー）
europe-west2 a、b、c ロンドン（イギリス）
europe-west3 a、b、c フランクフルト（ドイツ）
europe-west4 a、b、c エームスハーヴェン（オランダ）
europe-west6 a、b、c チューリッヒ（スイス）

詳細については、地域とリージョンをご覧ください。

地域制限があるワークロードの DR の計画

アプリケーションを設計する方法は、ワークロードのタイプと満たすべき地域の要件によって異なります。また、決定した内容は DR アーキテクチャに直接影響するため、前述の要件を満たす理由も考慮する必要があります。

まず、Google Cloud 障害復旧計画ガイドを確認してください。地域制限があるワークロードを検討する際は、この計画のセクションで説明された要件に焦点を当てます。

地域要件を定義する

設計を始める前に、次の質問に答えることで地域要件を定義します。

  • 保存データはどこにありますか？この答えにより、使用できるサービスと、RTO / RPO の値を達成するために使用できる高可用性（HA）および DR メソッドが決まります。Cloud のロケーション ページを使用して、スコープ内のプロダクトを決定してください。
  • 暗号化技術を使って要件を緩和できますか？Cloud External Key Manager と Cloud Key Management Service を使用した暗号化技術を採用することで地域要件を緩和できる場合、マルチリージョン サービスとデュアル リージョン サービスを使用でき、またデータの障害復旧シナリオで概説されている標準の HA / DR 手法を利用できます。

  • データはそのデータの保存場所の外側でも処理できますか？GKE Enterprise などのプロダクトを使用すると、要件に対応するハイブリッド環境を提供することや、リージョン内の複数のゾーンにまたがる負荷分散 Compute Engine インスタンスなどのプロダクト固有のコントロールを実装することが可能です。リソースのデプロイ先を制限するには、組織のポリシーのリソース ロケーションの制約を使用します。

    データが保管される必要がある場所以外での処理が可能な場合は、障害復旧構成ブロックおよびアプリケーションの障害復旧シナリオに沿って、アプリケーションの「処理」の部分を設計します。

    VPC セキュリティ管理境界を構成して、データにアクセスできるユーザーを制御し、データ処理を許可するリソースを制限します。

  • 複数のリージョンを使用できますか？複数のリージョンを使用できる場合は、障害復旧のシリーズで説明されている方法の多くを使用できます。Google Cloud プロダクトのマルチリージョンとリージョンの制約を確認してください。

  • アプリケーションにアクセスできるユーザーを制限する必要はありますか？Google Cloud には、アプリケーションにアクセスできるユーザーを制限できる複数のプロダクトと機能があります。

    • Identity-Aware Proxy（IAP）。ユーザーの ID を検証し、そのユーザーにアプリケーションへのアクセスを許可するかどうかを決定します。組織のポリシーで、ドメインで制限された共有制約を使用して、IAM ポリシーで許可される Cloud Identity または Google Workspace の ID を定義します。
    • プロダクトに固有の地域制御。適切な地域の制約については、アーキテクチャで使用する各プロダクトを参照してください。たとえば、GKE Enterprise 構成マネージャーを使用して、GKE Enterprise が管理する GKE クラスタに地域固有のポリシーを適用します。Cloud Storage を使用している場合は、指定したリージョンにバケットを作成します。

使用できるサービスを特定する

地域区分とリージョン粒度の要件に基づいて、使用できるサービスを特定します。地域制限が必要なアプリケーションを設計する際、どのプロダクトがどのリージョンで制限が必要か、またロケーション制約の要件を強制するのにどういう制御を適用できるかについて理解しておく必要があります。

アプリケーションとデータのリージョン粒度を特定する

次の質問に答えることで、アプリケーションとデータのリージョン粒度を特定します。

  • 設計では、マルチリージョン サービスを使用できますか？マルチリージョン サービスを使用することで、可用性が高く、復元性に優れたアーキテクチャを作成できます。
  • アプリケーションへのアクセスにロケーション制限が設定されていますか？これらの Google Cloud プロダクトを使用すると、アプリケーションにアクセスできるロケーションを強制できるようになります。
  • データの保存が特定のリージョンに制限されていますか？マネージド サービスを使用する場合、サービスに保存されるデータが特定のリージョンに制限されるよう、使用しているサービスを構成できることを確認してください。たとえば、BigQuery の地域制限を使用して、データセットの保存場所とバックアップ場所を指定します。
  • アプリケーションを制限する必要があるのはどのリージョンですか？一部の Google Cloud プロダクトには、地域制限がありません。Cloud のロケーションのページとプロダクト固有のページを使用して、プロダクトを使用できるリージョンと、アプリケーションを特定のリージョンに制限する際に利用できる緩和機能（ある場合）を検証します。

Google Cloud プロダクトを使用した地域制限の遵守

このセクションでは、地域制限のあるワークロードの DR 戦略の一環として Google Cloud プロダクトを使用する際の機能と軽減手法について詳しく説明します。このセクションと一緒に障害復旧の構成要素を読むことをおすすめします。

組織のポリシー

組織のポリシーを使用すると、Google Cloud リソースを一元管理できます。組織のポリシーを使用すると、リソース階層全体にわたって制限を構成できます。地域制限のあるワークロードを設計する場合は、次のポリシー制約を考慮してください。

  • ドメインで制限された共有: デフォルトでは、すべてのユーザー ID を IAM ポリシーに追加できます。許可リストや拒否リストには、1 つ以上の Cloud Identity または Google Workspace のお客様 ID を指定する必要があります。この制約が有効な場合、許可リスト内の ID のみが IAM ポリシーに追加される対象になります。

  • ロケーション制限があるリソース: この制約は、ロケーション ベースの Google Cloud リソースを作成できる一連のロケーションを意味します。この制約に関するポリシーにより、アジアやヨーロッパなどのマルチリージョン、us-east1 や europe-west1 などのリージョン、europe-west1-b などの個々のゾーンを、許可または拒否するロケーションとして指定できます。サポートされているサービスの一覧については、リソース ロケーションのサポート対象サービスをご覧ください。

暗号化

データの地域要件でデータにアクセスできるユーザーを制限する場合、暗号化方法の実装が適切な方法になることがあります。外部の鍵管理システムを使用して Google Cloud の外部に提供する鍵を管理することで、地域要件を満たすためにマルチリージョン アーキテクチャをデプロイできる場合があります。鍵が利用できなければ、データを復号できません。

Google Cloud には、管理する鍵を使用できる 2 つのプロダクトがあります。

  • Cloud External Key Manager（Cloud EKM）: Cloud EKM では、Google のインフラストラクチャの外部にデプロイされたサードパーティの鍵管理システムで保存、管理されている暗号鍵を使用して、BigQuery と Compute Engine のデータを暗号化できます。

  • 顧客指定の暗号鍵（CSEK）: Cloud Storage と Compute Engine で CSEK を使用できます。Google は、お客様の鍵を使用して、データの暗号化と復号に使用される Google 生成鍵を保護します。

    顧客指定の暗号鍵を指定した場合、Google はお客様の鍵を Google のサーバーに永続的に保存することはなく、またお客様の鍵を管理することもありません。代わりに、Cloud Storage のオペレーションごとにお客様が自身の鍵を指定し、そのオペレーションが完了すると鍵は Google のサーバーから削除されます。

お客様独自の鍵インフラストラクチャを管理する場合は、レイテンシと信頼性の問題を慎重に検討し、外部鍵マネージャーの適切な HA プロセスと復旧プロセスを実装する必要があります。また、RTO 要件も理解する必要があります。鍵はデータの書き込みに不可欠であり、鍵なしでは安全に書き込みができないため、RPO は重大な問題ではありません。鍵がなければ、データの暗号化の解除やデータの安全な書き込みができないため、実際の懸念事項は RTO です。

ストレージ

地域制限があるワークロードの DR を設計する場合は、必要なリージョンに保存データを確実に配置する必要があります。要件に合わせて Google Cloud オブジェクトとファイル保存サービスを構成できます。

Cloud Storage

地域制限を満たす Cloud Storage バケットを作成できます。

障害復旧の構成要素に関する記事の Cloud Storage セクションで検討した機能以外に、地域制限があるワークロードの DR を設計する際は、マルチリージョンとデュアルリージョンに保存されるオブジェクトが、ストレージ クラスに関係なく、少なくとも地理的に離れた 2 つ以上の領域に保存される、リージョン間の冗長性が必要かを考慮しますこの地理的な冗長性により、天災などの大規模な災害が発生した場合でも、データの可用性が最大限確保されます。デュアルリージョンでは、選択したリージョンのペアを使用することで、この冗長性を実現します。マルチリージョンの場合は、特定のマルチリージョン内のデータセンターを組み合わせることで地理的な冗長性を実現します。利用できるリージョンとして明示的に一覧表示されていないデータセンターも使用できます。

バケット間のデータの同期は非同期的に行われます。RTO と RPO の値を満たすためにデータが別のリージョンに書き込まれるという高い信頼性が必要な場合は、2 つの単一リージョン バケットを使用します。その後、オブジェクトをデュアル書き込みするか、1 つのバケットに書き込み、Cloud Storage で 2 番目のバケットをコピー（rewriteTo）します。

Cloud Storage 使用時の単一リージョン緩和戦略

要件により、単一のリージョン（ロンドンやチューリッヒなど）のみを使用するように制限されている場合は、そのリージョンに制限され、Google Cloud のみを使用して地理的位置全体で冗長なアーキテクチャを実装することはできません。このシナリオでは、次の 1 つまたは複数の方法を使用することを検討してください。

  • マルチクラウド戦略またはハイブリッド戦略を採用する。この方法では、Google Cloud リージョンと同じ地理的領域に別のクラウド ソリューションまたはオンプレミス ソリューションを選択できます。データのコピーをオンプレミスの Cloud Storage バケットに保存することも、Cloud Storage をバックアップ データのターゲットとして使用することもできます。

    この方法を使用するには、次の手順を行います。

    • 距離の要件が満たされていることを確認します。
    • 他のクラウド プロバイダとして AWS を使用している場合、Cloud Storage の相互運用性ガイドをご覧になり、Google Cloud ツールを使用した Amazon S3 へのアクセスを構成する方法を参照してください。
    • 他のクラウドやオンプレミス ソリューションについては、minIO や Ceph などのオープンソース ソリューションを使用して、オンプレミス オブジェクト ストアを提供することを検討してください。
    • パートナー ソリューションを使用して、オンプレミス オブジェクト ストアを提供することを検討してください。
    • パートナー ソリューションを使用して、Cloud Storage と代替のクラウド オブジェクト ストア サービスにデータを書き込むワークフローを実装することを検討してください。
    • オンプレミス オブジェクト ストアから Cloud Storage にデータを転送するには、gsutil コマンドライン ユーティリティで Cloud Composer を使用することを検討してください。
    • オンプレミスに保存されているデータを Cloud Storage にコピーするには、Transfer Service for On Premises Data を使用します。

  • 暗号化技術を実装する。回避策として暗号化技術の使用が地域要件に牴触しなければ、マルチリージョン バケットまたはデュアルリージョン バケットを使用できます。

Filestore

Filestore は、地域制限要件に従ってリージョンとゾーンにデプロイできるマネージド ファイル ストレージを提供するものです。

マネージド データベース

データの障害復旧シナリオでは、Google Cloud マネージド データベース サービスのバックアップと復旧の戦略を実装する方法を説明しています。これらのメソッドを使用するだけでなく、アーキテクチャで使用するマネージド データベース サービスごとに地域制限を考慮する必要があります。次に例を示します。

  • Bigtable は、リージョン内のゾーンのロケーションで利用できます。本番環境インスタンスには 2 つ以上のクラスタがあります。これらのクラスタは、リージョン内の一意のゾーンに存在する必要があります。Bigtable インスタンス内のクラスタ間のレプリケーションは、Google によって自動的に管理されます。Bigtable は、クラスタ間でデータを同期し、インスタンスにクラスタがある各ゾーンに個別の独立したデータのコピーを作成します。レプリケーションにより、受信トラフィックを同じインスタンスの別のクラスタにフェイルオーバーできます。

  • BigQuery には、データセットの保存場所を指定する地域制限があります。データセットのロケーションは、リージョンまたはマルチリージョンになります。リージョンの障害発生時の復元力を確保するには、データを別の地理的位置にバックアップする必要があります。BigQuery マルチリージョンの場合、マルチリージョンのスコープ内のリージョンへのバックアップを行わないことをおすすめします。EU マルチリージョンを選択した場合、チューリッヒとロンドンはマルチリージョン構成から除外されます。リージョンの物理的な損失という万が一の事態に備えるための、BigQuery の DR ソリューションを実装する方法については、リージョンの損失をご覧ください。

    シングルリージョンまたはマルチリージョンの BigQuery 構成を使用する場合の影響については、BigQuery のドキュメントをご覧ください。

  • Firestore を使用して、Firestore データをマルチリージョンのロケーションまたはリージョンのロケーションに保存できます。マルチリージョン ロケーションのデータは、マルチゾーンとマルチリージョンの複製構成で処理されます。地域制限の要件で許容され、データベースの可用性と耐久性を最大化する場合は、マルチリージョン ロケーションを選択します。マルチリージョン ロケーションでは、リージョン全体が消失しても、データを失うことなく可用性を維持できます。リージョナル ロケーションのデータは、マルチゾーンの複製構成で処理されます。

  • 高可用性対応の Cloud SQL を構成できます。HA 向けに構成された Cloud SQL インスタンスは「リージョン インスタンス」とも呼ばれ、構成されたリージョン内のプライマリ ゾーンとセカンダリ ゾーンに配置されます。リージョン インスタンスはプライマリ インスタンスとスタンバイ インスタンスで構成されます。プライマリ インスタンスからスタンバイ インスタンスへの一般的なフェイルオーバー時間を理解しておいてください。

    要件に牴触しない場合は、クロスリージョン レプリカを使用して Cloud SQL を構成できます。障害が発生した場合、別のリージョンのリードレプリカを昇格できます。リードレプリカは事前に HA 用に構成できるため、HA 用の昇格後に追加の変更を行う必要はありません。また、リードレプリカを構成して、それ自身のクロスリージョン レプリカを持つことで、レプリカ昇格後のリージョンの障害から即座に保護することができます。

  • Spanner は、リージョンまたはマルチリージョンとして構成できます。どのリージョン構成についても、Spanner によって 3 つの読み取り / 書き込みレプリカが維持されます。それぞれのレプリカは、そのリージョン内の異なる Google Cloud ゾーンに維持されます。各レプリカには本番環境のデータベースの完全なコピーが含まれ、読み取り / 書き込みリクエストと読み取り専用リクエストを実行できます。

    Spanner は、異なるゾーンのレプリカを使用し、1 つのゾーンで障害が発生しても、データベースの可用性を維持します。Spanner のマルチリージョン デプロイでは、2 つの読み取り / 書き込みリージョンと、ウィットネス レプリカを持つ 1 つのウィットネス リージョンを含む、複数のリージョンにわたって一貫した環境が提供されますすべてのリージョンのロケーションが地域制限を満たしていることを確認する必要があります。

Compute Engine

Compute Engine リソースには、グローバル、リージョン、ゾーンがあります。Compute Engine のリソース（仮想マシン インスタンスまたはゾーン永続ディスク）は、ゾーンリソースと呼ばれます。静的外部 IP アドレスなど、それ以外のリソースはリージョン リソースです。リージョン リソースは、ゾーンを問わずそのリージョン内のすべてのリソースで使用できます。ゾーンリソースは、同じゾーンにある他のリソースでのみ使用できます。

リージョン内の異なるゾーンにリソースを置くことで、ほとんどのタイプの物理インフラストラクチャの障害、インフラストラクチャ ソフトウェアの障害から、リソースを切り離すことができます。また、異なるリージョンにリソースを置くことで、障害からの独立性を高めることができます。この方法により、複数の障害発生ドメインにリソースを分散させた堅牢なシステムを設計できます。

詳細については、リージョンとゾーンをご覧ください。

オンプレミスまたは別のクラウドを本番環境サイトとして使用する

DR アーキテクチャで、デュアル リージョンまたはマルチリージョンの組み合わせを使用できない Google Cloud リージョンを使用している場合があります。この場合、地域制限を満たすため、独自のデータセンターまたは別のクラウドを本番環境サイトまたはフェイルオーバー サイトとして使用することを検討してください。

このセクションでは、ハイブリッド ワークロード用に最適化された Google Cloud プロダクトについて説明します。オンプレミスと Google Cloud を使用する DR アーキテクチャは、アプリケーションの障害復旧シナリオで説明されています。

GKE Enterprise

Google Cloud のオープン ハイブリッドおよびマルチクラウドのアプリケーション プラットフォームである GKE Enterprise は、コンテナベースのワークロードをどこからでも安全に実行できます。GKE Enterprise を使用するとオンプレミス環境とクラウド環境との間の一貫性を維持でき、一貫した運用モデルと Google Kubernetes Engine（GKE）クラスタの単一のビューを利用できるため、どの場所からでも運用が可能です。

DR 戦略の一環として GKE Enterprise を使用すると、異なる環境（Google Cloud とオンプレミス、または Google Cloud と別のクラウド間）にまたがる HA とフェイルオーバー アーキテクチャの構成と運用を簡素化できます。本番環境の GKE Enterprise クラスタはオンプレミスで実行でき、障害が発生した場合は、フェイルオーバーして Google Cloud の GKE Enterprise クラスタで同一のワークロードを実行できます。

Google Cloud 上の GKE Enterprise には、次の 3 種類のクラスタがあります。

  • シングルゾーン クラスタ。シングルゾーン クラスタには、1 つのゾーンで動作する 1 つのコントロール プレーンが含まれています。このコントロール プレーンは、同じゾーンで動作するノード上のワークロードを管理します。
  • マルチゾーン クラスタ。マルチゾーン クラスタには、1 つのゾーンで動作するコントロール プレーンの 1 つのレプリカと、複数のゾーンで動作する複数のノードが含まれています。
  • リージョン クラスタ。リージョン クラスタは、1 つのリージョン内の複数のゾーンにクラスタ プライマリとノードを複製します。たとえば、us-east1 リージョン内のリージョン クラスタは、3 つの us-east1 ゾーン（us-east1-b、us-east1-c、us-east1-d）でコントロール プレーンとノードのレプリカを作成します。

リージョン クラスタは、ゾーンの停止に対して最も回復力があります。

Google Cloud VMware Engine

Google Cloud VMware Engine を使用すると、クラウドで VMware ワークロードを実行できます。オンプレミス ワークロードが VMware ベースである場合は、オンプレミスで実行しているのと同じ仮想化ソリューション上で動作するように DR ソリューションを設計できます。地域要件を満たすリージョンを選択できます。

ネットワーキング

DR 計画が、オンプレミスから Google Cloud へのデータ移動、または他のクラウド プロバイダから Google Cloud へのデータ移動を伴う場合、ご自身のネットワーク戦略に対応する必要があります。詳細については、「障害復旧の構成要素」ドキュメントの Google Cloud との間でデータを転送するのセクションをご覧ください。

VPC Service Controls

DR 戦略を立案する際は、本番環境に適用されるセキュリティ管理をフェイルオーバー環境にも拡大する必要があります。VPC Service Controls を使用すると、オンプレミス ネットワークから Google Cloud のプロジェクトへのセキュリティ境界を定義できます。

VPC Service Controls では、クラウド リソースの管理にコンテキストアウェア アクセス アプローチを使用できます。ユーザー ID や IP アドレスなどの属性に基づいて、Google Cloud できめ細かいアクセス制御ポリシーを作成できます。これらのポリシーにより、オンプレミス環境と Google Cloud 環境に適切なセキュリティ管理を確実に適用できます。

次のステップ