Google Cloud リージョン間の移行: Google Cloud で復元性に優れた単一リージョン環境を設計する

Last reviewed 2023-12-08 UTC

このドキュメントは、Google Cloud で復元性に優れた単一リージョン環境を設計する際に役立ちます。このドキュメントは、単一リージョン環境の移行を計画している場合や、将来移行する可能性を検討している場合に、その概要を把握するうえで有用です。

このドキュメントはシリーズの一部です。

このドキュメントは、Google Cloud で復元性に優れた単一リージョン環境を設計する方法のガイダンスを提供することを目的としており、次のアーキテクチャ コンポーネントを中心に説明します。

このドキュメントのガイダンスは、単一リージョン環境の設計と実装を前提としています。現在単一リージョン環境を使用している場合は、将来的にマルチリージョン環境に移行できます。ゾーン環境や単一リージョン環境からマルチリージョン環境への移行や進化を検討している場合は、Google Cloud リージョン間の移行: スタートガイドをご覧ください。

さまざまなデプロイ アーキタイプのプロパティ

Google Cloud は、世界中のさまざまなリージョンからサービスを提供しています。各リージョンは、物理的に独立した地理的エリアであり、ゾーンと呼ばれるデプロイエリアで構成されています。Google Cloud のリージョンとゾーンの詳細については、地域とロケーションをご覧ください。

Google Cloud 環境を設計する際は、次のデプロイ アーキタイプから選択できます。各アーキタイプは、信頼性と運用上のオーバーヘッドが大きい順に示されています。

  • ゾーン アーキタイプ: Google Cloud リソースをリージョン内の単一のゾーンにプロビジョニングし、利用可能なゾーンサービスを使用します。ゾーンサービスが利用できない場合は、リージョン サービスを使用します。
  • 単一リージョン アーキタイプ: Google Cloud リソースをリージョン内の複数のゾーンにプロビジョニングし、可能であればリージョン サービスを使用します。
  • マルチリージョン アーキタイプ: 異なるリージョンにまたがる複数のゾーンに Google Cloud リソースをプロビジョニングします。ゾーンリソースは、各リージョンの 1 つ以上のゾーンにプロビジョニングされます。

上記のデプロイ アーキタイプはそれぞれ信頼性の特性が異なり、それらを使用して、環境に必要な信頼性を保証できます。たとえば、マルチリージョン環境は、単一リージョンまたはゾーン環境と比較して、リージョンの停止後も存続できる可能性が高くなります。各アーキテクチャのアーキタイプが持つ信頼性の特性の詳細については、ゾーンとリージョンによる信頼性の実現および Google Cloud インフラストラクチャ信頼性ガイドをご覧ください。

これらのデプロイ アーキタイプに基づいて環境を設計、実装、運用する労力のレベルは、各アーキタイプの費用と複雑さの特性に応じて異なります。たとえば、ゾーン環境はリージョン環境やマルチリージョン環境と比べて、設計、実装、運用が低コストで容易になる可能性があります。ゾーン環境の労力と費用が削減される可能性があるのは、異なるリージョンに存在するワークロード、データ、プロセスを調整するために管理が必要になり、オーバーヘッドが追加されるためです。

次の表は、各アーキテクチャのアーキタイプのリソース分散、信頼性の特性、複雑さをまとめたものです。また、それぞれに基づいて環境を設計して実装するために必要な作業についても説明しています。

アーキテクチャのアーキタイプ名 リソースの分散 効果を発揮する障害 設計の複雑さ
ゾーン環境 単一ゾーン内 リソース障害 単一ゾーン内での調整が必要
単一リージョン環境 単一リージョン内の複数のゾーン リソースの障害、ゾーンの停止 単一リージョン内の複数のゾーン間での調整が必要
マルチリージョン環境 複数のゾーンにまたがる複数のリージョン リソースの障害、ゾーンの停止、リージョンの停止、マルチリージョンの停止 複数のゾーンにまたがる複数のリージョンに対して調整が必要

環境のデプロイ アーキタイプを選択する

ニーズに最適なアーキテクチャ アーキタイプは、次の手順で選択します。

  1. 保護する障害モデルを定義します。
  2. デプロイ アーキタイプを評価して、ニーズに最適なものを決定します。

障害モデルを定義する

障害モデルを定義するには、次の点を考慮してください。

  • 障害モデルが必要な環境のコンポーネント: 障害モデルは、Google Cloud でプロビジョニングまたはデプロイするすべてのものに適用できます。障害モデルを個別に適用することも、ゾーンまたはリージョン内のすべてのリソースに適用することもできます。ワークロード、データ、プロセス、Google Cloud リソースなど、価値をもたらすものすべてに障害モデルを適用することをおすすめします。
  • 各コンポーネントで求められる高可用性、ビジネスの継続性、障害復旧: 環境内の各コンポーネントには、そのコンポーネントで許容されるサービスレベルを定義する独自のサービスレベル目標（SLO）と独自の障害復旧要件があります。たとえば、Compute Engine SLA では、99.5% を超える月間稼働時間を達成する必要がある場合、単一リージョンの複数のゾーンにインスタンスをプロビジョニングする必要があることが示されています。詳細については、障害復旧計画ガイドをご覧ください。
  • 定義する必要がある障害モデルの数: 一般的な環境では、すべてのコンポーネントで同じ信頼性を保証する必要はありません。稼働時間の増加と復元力の向上を保証する場合、通常は、より多くの労力とリソースを費やす必要があります。障害モデルを定義する場合は、すべてのコンポーネントに対して同じ 1 つのモデルを定義するのではなく、コンポーネントごとに異なる複数の障害モデルを定義するアプローチを検討することをおすすめします。たとえば、ビジネス クリティカルなワークロードでは、より高い信頼性が求められるのが一般的ですが、他の重要性の低いワークロードについては信頼性の保証が低くても許容できる場合があります。
  • 障害から保護するために障害モデルが必要とするリソースの数: 定義した障害モデルから保護するには、保護メカニズムと自動プロセスを設計、プロビジョニング、構成するために必要な時間と費用などのリソースを費やすことになります。定義した各障害モデルに対する保護を提供するために必要なリソースの数を評価しておくことをおすすめします。
  • 障害の発生を検出する方法: 障害が発生している状況、または発生しそうな状況を検出できることは、軽減、復旧、調整のプロセスを開始するうえで重要です。たとえば、Google Cloud Observability を構成して、パフォーマンスの低下についてアラートを受け取ることができます。
  • 定義している障害モデルをテストする方法: 障害モデルを定義する場合は、各モデルを継続的にテストして、モデルが対象とする障害を効果的に保護できているか検証する方法について検討しておくことをおすすめします。たとえば、環境でフォールト インジェクションを行ったり、障害に対する環境の耐性を評価するために、カオス エンジニアリングを採用したりできます。
  • 特定の障害モデルが発生した場合に予想される影響: 障害がビジネスに与える影響を把握するには、障害モデルごとに、モデルの設計対象となる各障害の結果を推定することをおすすめします。これを把握しておくことで、お客様とお客様のプロセスが最も重要なコンポーネントに最初に対処できるように、優先順位と復旧順序を確立するのに役立ちます。
  • 定義している障害モデルで障害の持続が予想される時間: 障害の持続時間は、緩和策と復旧計画に大きく影響します。したがって、障害モデルを定義する場合は、障害が持続する時間を考慮することをおすすめします。障害が持続する時間を考慮する場合は、障害の特定、障害の調整、障害が発生したリソースの復元などにかかる時間も考慮してください。

障害モデルと信頼性の高い障害復旧計画の設計方法の詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。

デプロイ アーキタイプを評価する

保護する障害モデルを定義したら、デプロイ アーキタイプを評価して、ニーズに最適なものを決定します。デプロイ アーキタイプを評価する際は、次の点を考慮してください。

  • 必要なデプロイ アーキタイプの数: すべての環境に適合するアーキテクチャ アーキタイプを 1 つだけ選択する必要はありません。定義した各障害モデルから保護するために必要な信頼性に従って複数のデプロイ アーキタイプを選択するハイブリッド アプローチを実装できます。たとえば、ゾーン環境を必要とする障害モデルと、リージョン環境を必要とする障害モデルを定義した場合、障害モデルごとに保護を提供するために別々のデプロイ アーキタイプを選択できます。複数のデプロイ アーキタイプを選択する場合は、複数の環境の設計、実装、運用に伴って複雑さが増加する可能性について評価することをおすすめします。
  • デプロイ アーキタイプに基づいて環境を設計および実装するために必要なリソースの数: どのような環境でも、設計と実装にはリソースと労力が必要です。選択したアーキタイプに基づいて、各環境を設計および実装するために必要なリソースの数を評価することをおすすめします。必要なリソースの数を完全に把握しておくことで、各アーキテクチャ アーキタイプが提供する信頼性の保証と、そのアーキタイプに基づく環境の設計、実装、運用のコストと複雑さのトレードオフのバランスをとることができます。
  • あるアーキテクチャ アーキタイプに基づく環境を別のアーキタイプに基づく環境に移行することを想定しているか: 将来的には、ある Google Cloud 環境から別の Google Cloud 環境にワークロード、データ、プロセスを移行する可能性があります。たとえば、ゾーン環境からリージョン環境に移行するケースが考えられます。
  • 設計および実装する環境は、どの程度ビジネス クリティカルか: ビジネス クリティカルな環境では、より高い信頼性の保証が必要になるのが一般的です。たとえば、ビジネス クリティカルなワークロード、データ、プロセスにはマルチリージョン環境を設計して実装し、重要性の低いワークロード、データ、プロセスにはゾーン環境またはリージョン環境を設計できます。
  • 特定の環境向けに特定のアーキテクチャ アーキタイプで提供される機能が必要か: アーキタイプは、各アーキテクチャ アーキタイプが提供する信頼性の保証に加え、スケーラビリティ、地理的近接性、レイテンシ、データの局所性の保証も提供します。環境のデプロイ アーキタイプを選択する際は、これらの保証を考慮することをおすすめします。

前述のガイダンスに従って定義した障害モードの技術的側面とともに、規制、地域性、主権の要件など、機能以外の要件も考慮することをおすすめします。これらの要件により、使用可能なオプションが制限される場合があります。たとえば、特定のリージョンの使用を義務付ける規制要件を満たす必要がある場合は、単一リージョン環境を設計して実装するか、そのリージョンにゾーン環境を設計して実装する必要があります。

環境に応じた Google Cloud リージョンを選択する

単一リージョン環境の設計を開始するときは、各環境の要件に最適なリージョンを決定する必要があります。以降のセクションでは、次の 2 つのカテゴリの選択基準について説明します。

  • 機能面の基準: 特定のリージョンで提供される Google Cloud プロダクトと、特定のリージョンが Google Cloud 以外のユーザーや他の環境に対するレイテンシと地理的近接性を満たしているかどうかに関する基準です。たとえば、ワークロードとデータに Google Cloud 以外のユーザーやその他の環境に対するレイテンシ要件がある場合、そのレイテンシを最小限に抑えるために、ユーザーまたは他の環境に最も近いリージョンを選択する必要があります。
  • 機能面以外の基準: 特定のリージョンに関連するプロダクト価格、温室効果ガス排出量の要件、ビジネスに適用されている必須要件と規制に関する基準です。たとえば、銀行や公共部門などの規制の厳しい市場では、データとワークロードの局所性や、クラウド プロバイダのインフラストラクチャを他のユーザーと共有する方法について、非常に厳格で具体的な要件があります。

現在特定の Google Cloud リージョンを選択している場合でも、後で別のリージョンまたはマルチリージョン環境に移行できます。将来的に他のリージョンへの移行を検討している場合は、Google Cloud リージョン間の移行: スタートガイドをご覧ください。

機能面の基準を評価する

機能面の基準を評価するには、次の点を考慮してください。

  • 地理的な近接性に関する要件: Google Cloud リージョンを選択する場合は、ワークロード、データ、プロセスをユーザーの近く、またはオンプレミス環境など Google Cloud 以外の独自の環境の近くに配置することが必要になる場合があります。たとえば、特定の地域に集中しているユーザーベースをターゲットにする場合は、その地域に最も近い Google Cloud リージョンを選択することをおすすめします。地理的な近接性の要件に最適な Google Cloud リージョンを選択することで、ユーザーや Google Cloud 以外の環境からのリクエストに対するレイテンシの短縮と応答時間の短縮が保証されます。Google Cloud レイテンシ ダッシュボードなどのツール、GCPing や Google Cloud リージョン選択ツールなどの非公式ツールを使用すると、Google Cloud リージョンのレイテンシ特性の概要を把握できます。ただし、包括的な評価を実施して、レイテンシの特性が要件、ワークロード、データ、プロセスに適しているかどうかを評価することをおすすめします。
  • 必要なプロダクトを提供しているリージョン: 各 Google Cloud リージョンで利用可能なプロダクトと、環境の設計と実装に必要なサービスを提供しているリージョンを評価することをおすすめします。各リージョンで利用可能なプロダクトとその提供タイムラインの詳細については、Cloud のロケーションをご覧ください。また、プロダクトによっては、利用可能なリージョンであっても、すべての機能が提供されるとは限りません。たとえば、Compute Engine が使用可能なリージョンとゾーンでは、Google Cloud リージョンごとに提供されるマシンタイプが異なります。各リージョンの各プロダクトで提供される機能の詳細については、プロダクトのドキュメントをご覧ください。
  • 各 Google Cloud リージョンで必要なリソースは、リージョンごとの割り当て上限内か: Google Cloud では、割り当てを使用して、使用できる特定の共有 Google Cloud リソースの量を制限しています。一部の割り当てはグローバルに対応しており、Google Cloud のあらゆる場所でのリソースの使用に適用されますが、それ以外の割り当てはリージョンまたはゾーンに限定され、特定の Google Cloud リージョンでのリソースの使用に適用されます。たとえば、作成できる仮想マシンの数など、Compute Engine のリソース使用量の割り当てのほとんどはリージョン リソースです。割り当てと割り当てを増やす方法について詳しくは、割り当ての操作をご覧ください。

機能面以外の基準を評価する

機能面以外の基準を評価するには、次の点を考慮してください。

  • 温室効果ガス排出量の少ない環境を希望するか: Google Cloud は、Google Cloud の各リージョンに対するサステナビリティとカーボンフリー エネルギーに継続的に投資しており、すべてのクラウド リージョンでカーボンフリー エネルギーを実現できるように取り組んでいます。温室効果ガス排出量は、Google Cloud のリージョンごとに異なります。各 Google Cloud リージョンの温室効果ガス排出量と、ロケーション戦略にカーボンフリー エネルギーを組み込む方法については、Google Cloud の各リージョンにおけるカーボンフリー エネルギーの利用状況をご覧ください。
  • 環境が特定の規制を満たす必要があるか: 多くの場合、行政機関、国家機関、超国家機関は、特定の市場とビジネス分野（銀行や公共部門など）を厳格に規制しています。このような規制では、ワークロード、データ、プロセスを特定の地理的リージョンにのみ配置することが義務付けられている場合があります。たとえば、クラウド上で実行されるセンシティブ データやワークロードについて一定レベルの管理性と透明性を保証するために、お客様の環境がデータ主権、運用主権、ソフトウェア主権の要件を遵守しなければならない場合があります。環境で使用する Google Cloud リージョンを選択する際は、現在と今後の規制要件を評価し、規制要件に最適な Google Cloud リージョンを選択することをおすすめします。

単一リージョン環境を設計して構築する

単一リージョン環境を設計する手順は次のとおりです。

  1. Google Cloud における基盤を構築する。
  2. コンピューティング リソースをプロビジョニングして構成する。
  3. データ ストレージ リソースをプロビジョニングして構成する。
  4. データ分析リソースをプロビジョニングして構成する。

環境を設計する際は、次の一般的な設計原則を考慮してください。

  • リージョン リソースをプロビジョニングする: 多くの Google Cloud プロダクトは、リージョン内の複数のゾーンでのリソースのプロビジョニングをサポートしています。可能であれば、ゾーンリソースではなくリージョン リソースをプロビジョニングすることをおすすめします。理論的には、リージョン内の複数のゾーンにゾーンリソースをプロビジョニングし、それらを自分で管理することで、より高い信頼性を実現できる可能性はあります。ただし、そのような構成では、Google Cloud サービスの基盤となる Google インフラストラクチャのすべての信頼性機能のメリットを十分に享受することはできません。
  • 障害モデルを想定したうえで、環境が期待どおりに動作することを検証する: 単一リージョン環境を設計して実装する場合は、本番環境の一部としてプロモートさせる前に、検討している障害モデルに対する保護の要件を満たしているかどうか検証することをおすすめします。たとえば、ゾーン停止をシミュレートして、単一リージョン環境が最小限の中断で存続できることを確認できます。

信頼性の高い単一リージョンおよびマルチリージョン環境を設計するための一般的な設計原則と、Google がリージョン サービスとマルチリージョン サービスでどのように高い信頼性を実現するのかについては、クラウド インフラストラクチャの停止に対する障害復旧の設計: 共通のテーマをご覧ください。

Google Cloud における基盤を構築する

単一リージョン環境の基盤を構築するには、Google Cloud への移行: 基盤の計画と構築をご覧ください。このドキュメントのガイダンスは、ワークロード、データ、プロセスを Google Cloud に移行するための基盤を構築することを目的としていますが、単一リージョン環境の基盤構築にも適用できます。このドキュメントを読んだら、引き続き本ドキュメントをお読みください。

Google Cloud で基盤を構築したら、セキュリティ管理と境界を設計して実装します。これらのセキュリティ対策により、ワークロード、データ、プロセスをそれぞれのリージョン内に維持できます。また、このようなセキュリティ対策は、バグ、構成ミス、悪意のある攻撃によってリソースから他のリージョンに漏洩することがないようにするうえでも役立ちます。

コンピューティング リソースをプロビジョニングして構成する

単一リージョン環境の基盤を構築したら、コンピューティング リソースをプロビジョニングして構成します。以降の各セクションでは、リージョン デプロイをサポートする Google Cloud コンピューティング プロダクトについて説明します。

Compute Engine

Compute Engine は Google Cloud の IaaS（Infrastructure-as-a-Service）です。世界各地にある Google のインフラストラクチャを使用して、お客様に仮想マシン（および関連サービス）を提供しています。

Compute Engine リソースは、仮想マシンやゾーン Persistent Disk などのゾーンリソースか、静的外部 IP アドレスなどのリージョン リソース、または Persistent Disk スナップショットなどのグローバル リソースのいずれかになります。Compute Engine がサポートするゾーンリソース、リージョン リソース、グローバル リソースの詳細については、グローバル リソース、リージョン リソース、ゾーンリソースをご覧ください。

物理リソースの柔軟性とリソース管理を向上させるために、Compute Engine はゾーンを物理リソースから切り離します。この抽象化とそれが示唆する内容について詳しくは、ゾーンとクラスタをご覧ください。

Compute Engine を使用する環境の信頼性を高めるには、次の点を考慮してください。

  • リージョン マネージド インスタンス グループ（MIG）: Compute Engine の仮想マシンはゾーンリソースであるため、ゾーンが停止すると利用できなくなります。この問題を軽減するために、Compute Engine では、需要とリージョンの可用性に応じてリージョン内の複数のゾーンに仮想マシンを自動的にプロビジョニングするリージョン MIG を作成できます。ワークロードがステートフルの場合は、リージョン ステートフル MIG を作成して、ステートフル データと構成を保持することもできます。リージョン MIG は、ゾーン障害のシミュレーションをサポートしています。リージョン MIG を使用しているときにゾーン障害をシミュレートする方法について詳しくは、リージョン MIG のゾーンの停止をシミュレーションするをご覧ください。リージョン MIG と他のデプロイ オプションの比較について詳しくは、ワークロードに対する Compute Engine のデプロイ戦略を選択するをご覧ください。
  • ターゲット分配形態: リージョン MIG は、ターゲット分配形態に従って仮想マシンを分散します。リージョン内の任意の 2 つのゾーン間で仮想マシンの分散が 1 単位以上異ならないようにするには、リージョン MIG を作成するときに EVEN 分配形態を選択することをおすすめします。ターゲット分配形態の違いについては、形態の比較をご覧ください。
  • インスタンス テンプレート: プロビジョニングする仮想マシンを定義するために、MIG はインスタンス テンプレートと呼ばれるグローバル リソースタイプを使用します。インスタンス テンプレートはグローバル リソースですが、ゾーンリソースまたはリージョン リソースを参照する場合もあります。インスタンス テンプレートを作成する場合は、可能であれば、ゾーンリソースではなくリージョン リソースを参照することをおすすめします。ゾーンリソースを使用する場合は、その影響を評価することをおすすめします。たとえば、特定のゾーンでのみ使用可能な Persistent Disk ボリュームを参照するインスタンス テンプレートを作成した場合、その Persistent Disk ボリュームは他のゾーンでは使用できないため、他のゾーンでそのテンプレートを使用することはできません。
  • ロード バランシングとスケーリングを構成する: Compute Engine は、Compute Engine インスタンス間のトラフィックのロード バランシングをサポートしています。また、需要に応じて MIG から仮想マシンを自動的に追加または削除する自動スケーリングをサポートしています。環境の信頼性と柔軟性を高め、セルフマネージド ソリューションの管理の負担を回避するには、ロード バランシングと自動スケーリングを構成することをおすすめします。Compute Engine のロード バランシングとスケーリングの構成について詳しくは、負荷分散とスケーリングをご覧ください。
  • リソース予約を構成する: 環境で必要なリソースを確実に確保するには、リソース予約を構成して、ゾーンの Compute Engine の容量を確実に確保することをおすすめします。たとえば、ゾーンが停止した場合、それによって利用できなくなった分を補うための容量を提供するために、別のゾーンに仮想マシンをプロビジョニングする必要が生じることがあります。リソースを予約することで、追加の仮想マシンのプロビジョニングに使用できるリソースを確保できます。
  • ゾーン DNS 名を使用する: 複数リージョンにまたがるサービスの停止によるリスクを軽減するには、ゾーン DNS 名を使用して、環境内で DNS 名を使用する仮想マシンを一意に識別することをおすすめします。Google Cloud では、デフォルトで Compute Engine 仮想マシンにゾーン DNS 名が使用されます。Compute Engine の内部 DNS の仕組みの詳細については、内部 DNS をご覧ください。将来的なリージョン間の移行を容易にし、構成の保守性を高めるために、将来変更する可能性のある構成パラメータとしてゾーン DNS 名を検討することをおすすめします。
  • 適切なストレージ オプションを選択する: Compute Engine は、Persistent Disk ボリュームやローカル SSD（ソリッド ステート ドライブ）など、仮想マシン用に複数のストレージ オプションをサポートしています。
    • Persistent Disk ボリュームは複数の物理ディスクに分散され、仮想マシンとは独立して配置されます。永続ディスクはゾーンまたはリージョンのいずれかです。ゾーン永続ディスクではデータが単一のゾーンに格納されますが、リージョン永続ディスクでは 2 つの異なるゾーンにデータが複製されます。単一リージョン環境のストレージ オプションを選択する場合は、ゾーン障害が発生した場合にフェイルオーバー オプションが提供されるため、リージョン Persistent Disk を選択することをおすすめします。リージョン Persistent Disk を使用する場合にゾーン障害に対応する方法については、リージョン Persistent Disk を使用した高可用性オプションおよびリージョン Persistent Disk のフェイルオーバーをご覧ください。
    • ローカル SSD は高スループットですが、インスタンスが停止または削除されるとデータは保存されません。したがって、ローカル SSD は、他の方法で再構築できる一時データ、キャッシュ、データを保存するのに理想的です。永続ディスクは、物理ディスクと同様に仮想マシンがアクセスできる耐久性の高いストレージ デバイスです。
  • データ保護メカニズムを設計して実装する: 単一リージョン環境を設計する際は、ゾーン、リージョン、マルチリージョンの障害や、悪意のある第三者による意図的な攻撃などの有害なイベントが発生した場合にデータを保護するための自動化されたメカニズムを導入することをおすすめします。Compute Engine には、データを保護する複数のオプションが用意されています。これらのデータ オプション機能は、データ保護プロセスを設計して実装するための構成要素として使用できます。

GKE

GKE を使用すると、Kubernetes でコンテナ化されたワークロードのデプロイ、管理、スケーリングを行うことができます。GKE は Compute Engine 上に構築されているため、前のセクションで示した Compute Engine に関する推奨事項は、GKE にも部分的に当てはまります。

GKE を使用する環境の信頼性を高めるには、次の設計ポイントと GKE の機能を考慮してください。

  • リージョン GKE クラスタを使用して可用性を高める: GKE は、必要なクラスタのタイプに応じて、クラスタのさまざまな可用性タイプをサポートしています。GKE クラスタには、ゾーンまたはリージョンのコントロール プレーンを含めることができ、リージョン内の単一ゾーンまたは複数のゾーンで実行されるノードを設定できます。提供されるサービスレベル契約（SLA）は、クラスタのタイプによって異なります。環境の信頼性を高めるには、リージョン クラスタを選択することをおすすめします。GKE Autopilot 機能を使用している場合は、リージョン クラスタのみをプロビジョニングできます。
  • マルチクラスタ環境を検討する: 複数の GKE クラスタをデプロイすると、複雑になりますが、環境の柔軟性と可用性を高めることができます。たとえば、GKE クラスタの作成時にのみ有効にできる新しい GKE 機能を使用する必要がある場合は、新しい GKE クラスタをマルチクラスタ環境に追加し、新しいクラスタにワークロードをデプロイし、古いクラスタを破棄することで、ダウンタイムを回避し、移行の複雑さを軽減できます。マルチクラスタ GKE 環境の利点について詳しくは、マルチクラスタのユースケースをご覧ください。移行の複雑さを管理できるように、Google Cloud にはフリート管理が用意されています。これは、GKE クラスタのグループ、そのインフラストラクチャ、そしてそれらのクラスタにデプロイされたワークロードを管理する一連の機能です。
  • Backup for GKE を設定する: Backup for GKE は、ソース GKE クラスタ内のワークロード構成とボリュームをバックアップし、ターゲット GKE クラスタに復元するためのリージョン サービスです。ワークロードの構成とデータを損失から保護するには、Backup for GKE を有効にして構成することをおすすめします。詳細については、Backup for GKE の概要をご覧ください。

Cloud Run

Cloud Run は、コンテナ化されたワークロードを実行するためのマネージド コンピューティング プラットフォームです。Cloud Run はサービスを使用して、ワークロードを実行するためのインフラストラクチャを提供します。Cloud Run サービスはリージョン リソースであり、サービスはリージョン内の複数のゾーンに複製されます。リージョンは、Cloud Run サービスをデプロイするときに選択できます。サービスのインスタンスをデプロイするリージョン内のゾーンは、Cloud Run が自動的に選択します。Cloud Run は、サービス インスタンス間でトラフィックを自動的に分散し、ゾーン停止の影響を大幅に軽減するように設計されています。

VMware Engine

VMware Engine は、Google Cloud 上で VMware プラットフォームを実行できるフルマネージド サービスです。VMware Engine を使用する環境の信頼性を高めるため、次のようにすることをおすすめします。

  • マルチノードの VMware Engine プライベート クラウドをプロビジョニングする: VMware Engine では、プライベート クラウドと呼ばれる分離された VMware スタックのプロビジョニングをサポートしており、プライベート クラウドを構成するすべてのノードは同じリージョン内に配置されます。プライベート クラウド ノードは、専用の分離されたベアメタル ハードウェア ノードで実行され、単一障害点を排除するように構成されています。VMware Engine は単一ノードのプライベート クラウドをサポートしていますが、これは概念実証とテストの目的でのみ使用することをおすすめします。本番環境では、デフォルトのマルチノードのプライベート クラウドを使用することをおすすめします。
  • VMware Engine 拡張プライベート クラウドをプロビジョニングする: 拡張プライベート クラウドは、ノードがリージョン内の複数のゾーンに分散されるマルチノードのプライベート クラウドです。拡張プライベート クラウドは、ゾーンの停止から環境を保護します。

VMware Engine の高可用性と冗長性に関する機能の詳細については、可用性と冗長性をご覧ください。

データ ストレージ リソースのプロビジョニングと構成

単一リージョン環境のコンピューティング リソースをプロビジョニングして構成したら、データを保存して管理するためのリソースをプロビジョニングして構成します。以降の各セクションでは、リージョン構成とマルチリージョン構成をサポートする Google Cloud のデータ ストレージ プロダクトおよび管理プロダクトについて説明します。

Cloud Storage

Cloud Storage は、不変のデータであるオブジェクトをバケット（データを格納する基本的なコンテナ）に保存するためのサービスです。バケットを作成するときに、可用性、規制、その他の要件に最適なバケットのロケーション タイプを選択します。ロケーション タイプによって可用性の保証が異なります。障害や停止からデータを保護するため、Cloud Storage では、リージョンのロケーション タイプを持つバケットの場合は少なくとも 2 つのゾーンに、デュアルリージョンのロケーションを持つバケットの場合は 2 つのリージョンに、マルチリージョンのロケーション タイプを持つバケットでは 2 つ以上のリージョンにわたってデータを冗長化します。たとえば、ゾーンが停止したときに Cloud Storage バケットを使用可能にする必要がある場合は、リージョンのロケーション タイプを使用して Cloud Storage バケットをプロビジョニングできます。

Cloud Storage に保存されているデータの障害メカニズムを設計する方法と、ゾーンやリージョンの停止に対する Cloud Storage の対応方法については、クラウド インフラストラクチャの停止に対する障害復旧の設計: Cloud Storage をご覧ください。

Filestore

Filestore は、Compute Engine インスタンス、GKE クラスタ、オンプレミス マシンに接続できるフルマネージド ファイル サーバーを Google Cloud 上で提供します。Filestore には、複数のサービスティアが用意されています。提供される可用性、スケーラビリティ、パフォーマンス、容量、データ復旧機能は、ティアごとに異なります。Filestore インスタンスをプロビジョニングする場合は、エンタープライズ ティアを選択することをおすすめします。これは、高可用性とリージョン内の複数のゾーンにわたるデータ冗長性がサポートされるためです。他のティアのインスタンスは、ゾーンリソースになります。

Bigtable

Bigtable はフルマネージドで高パフォーマンス、かつスケーラビリティに優れたデータベース サービスであり、大規模な分析ワークロードにも運用ワークロードにも対応できます。Bigtable インスタンスはゾーンリソースです。インスタンスの信頼性を高めるために、同じリージョン内の複数のゾーン、または複数のリージョン間でデータをレプリケートするように Bigtable を構成できます。レプリケーションが有効になっている場合、停止が発生すると、Bigtable はデータのレプリケート先である他の使用可能なインスタンスにリクエストを自動的にフェイルオーバーします。

Bigtable でレプリケーションが動作する仕組みの詳細については、レプリケーションについてとクラウド インフラストラクチャの停止に対する障害復旧の設計: Bigtable をご覧ください。

Firestore

Firestore は、Firebase と Google Cloud からのモバイル、ウェブ、サーバー開発に対応した、柔軟でスケーラブルなデータベースです。Firestore データベースをプロビジョニングする場合は、そのロケーションを選択します。ロケーションはマルチリージョンまたはリージョンのいずれかにすることができ、それぞれ異なる信頼性が保証されます。データベースにリージョンのロケーションがある場合、リージョン内の異なるゾーンにデータがレプリケートされます。マルチリージョン データベースの場合は、複数のリージョンにデータがレプリケートされます。

Firestore でレプリケーションが動作する仕組みと、Firestore がゾーンやリージョンの停止に対してどのように対応するかについては、Firestore のロケーションとクラウド インフラストラクチャの停止に対する障害復旧の設計: Firestore をご覧ください。

Memorystore

Memorystore を使用すると、スケーラブルで安全かつ可用性の高いインメモリ データ ストレージ サービスを構成できます。Redis と Memcached のデータ バックエンドがサポートされています。

Memorystore for Redis インスタンスのプロビジョニング時は、そのインスタンスのサービスティアを選択します。Memorystore for Redis は複数のインスタンス サービス ティアをサポートし、提供される可用性、ノードサイズ、帯域幅の機能はティアごとに異なります。Memorystore for Redis インスタンスをプロビジョニングする場合は、スタンダード ティアまたはリードレプリカを使用するスタンダード ティアを選択することをおすすめします。この 2 つのティアの Memorystore インスタンスは、リージョン内の複数のゾーンに自動的にデータをレプリケートします。Memorystore for Redis が高可用性を実現する方法の詳細については、Memorystore for Redis の高可用性をご覧ください。

Memorystore for Memcached インスタンスをプロビジョニングする場合は、次の点を考慮してください。

  • ゾーンの選択: Memorystore for Memcached インスタンスをプロビジョニングするときに、インスタンスをデプロイするリージョンを選択します。次に、そのインスタンスのノードをデプロイするリージョン内のゾーンを選択します。また、Memorystore for Memcached によってゾーン間でノードが自動的に分散されるようにすることもできます。インスタンスを適切に配置し、すべてのノードを同じゾーン内に配置するなど、プロビジョニングの問題を回避するには、Memorystore for Memcached がリージョン内のゾーン間でノードを自動的に分散できるようにすることをおすすめします。
  • ゾーン間でのデータ レプリケーション: Memorystore for Memcached インスタンスは、ゾーン間またはリージョン間でデータをレプリケートしません。ゾーンまたはリージョンの停止が発生した場合の Memorystore for Memcached インスタンスの動作については、クラウド インフラストラクチャの停止に対する障害復旧の設計: Memorystore for Memcached をご覧ください。

Spanner

Spanner は、無制限のスケーリング、強整合性、最大 99.999% の可用性を備えたフルマネージド リレーショナル データベースです。Spanner を使用するには、Spanner インスタンスをプロビジョニングします。Spanner インスタンスをプロビジョニングする際は、次の点を考慮してください。

  • インスタンスの構成: インスタンスの構成では、Spanner インスタンス内のデータベースの地理的な配置とレプリケーションを定義します。Spanner インスタンスを作成するときは、リージョンまたはマルチリージョンとして構成します。
  • レプリケーション: Spanner はバイトレベルの自動レプリケーションをサポートしており、可用性、信頼性、スケーラビリティのニーズに応じたレプリカの作成が可能です。レプリカは、リージョンや環境間で分散できます。リージョン構成の Spanner インスタンスは、リージョン内のゾーンごとに 1 つの読み取り / 書き込みレプリカを維持します。マルチリージョン構成のインスタンスは、複数のリージョンの複数のゾーンにデータをレプリケートします。
  • インスタンスの移動: Spanner を使用すると、任意のインスタンス構成から他のインスタンス構成にインスタンスを移動できます。移動中にダウンタイムが発生したり、トランザクションの保証が中断されたりすることはありません。

Spanner レプリケーションと、Spanner がゾーンやリージョンの停止にどのように対応するかについて詳しくは、Spanner レプリケーションとクラウド インフラストラクチャの停止に対する障害復旧の設計: Spanner をご覧ください。

データ分析リソースをプロビジョニングして構成する

単一リージョン環境用のデータ ストレージ リソースをプロビジョニングして構成したら、データ分析リソースをプロビジョニングして構成します。以降の各セクションでは、リージョン構成をサポートする Google Cloud データ分析プロダクトについて説明します。

BigQuery

BigQuery は、ML、地理空間分析、ビジネス インテリジェンスなどの組み込み機能を使用してデータの管理と分析を支援する、フルマネージドのエンタープライズ データ ウェアハウスです。

BigQuery でデータへのアクセスを整理および管理するには、データセットと呼ばれるトップレベルのコンテナをプロビジョニングします。BigQuery データセットをプロビジョニングする場合は、次の点を考慮してください。

  • データセットのロケーション: データを保存する BigQuery のロケーションを選択するには、データセットのロケーションを構成します。ロケーションは、リージョンまたはマルチリージョンのどちらかです。どちらのロケーション タイプでも、BigQuery は選択したロケーション内の 2 つの異なるゾーンにデータのコピーを保存します。データセットの作成後にデータセットのロケーションを変更することはできません。
  • 障害対策: BigQuery はリージョン サービスであり、コンピューティングとデータに関してゾーン障害を自動的に処理します。ただし、リージョンの停止など、特定のシナリオについては自分で計画する必要があります。環境を設計する際は、これらのシナリオを考慮することをおすすめします。

BigQuery の障害復旧計画と機能の詳細については、BigQuery ドキュメントの信頼性について: 障害対策と、クラウド インフラストラクチャの停止に対する障害復旧の設計: BigQuery をご覧ください。

Dataproc

Dataproc は、オープンソースのデータツールを利用してバッチ処理、クエリ実行、ストリーミング、ML を行えるマネージド サービスです。Dataproc は Compute Engine 上に構築されているため、前のセクションで示した Compute Engine に関する推奨事項は、Dataproc にも部分的に当てはまります。

Dataproc を使用するには、Dataproc クラスタを作成します。Dataproc クラスタはゾーンリソースです。Dataproc クラスタを作成する際は、次の点を考慮してください。

  • 自動ゾーン プレースメント: クラスタを作成するときは、クラスタのノードをプロビジョニングするリージョン内のゾーンを指定します。また、Dataproc の自動ゾーン プレースメントを使って自動的にゾーンを選択することもできます。リージョン内のクラスタノードのゾーン配置を微調整する必要がない限り、自動ゾーン プレースメントを使用することをおすすめします。
  • 高可用性モード: クラスタを作成するときに、高可用性モードを有効にできます。クラスタの作成後に高可用性モードを有効にすることはできません。単一のコーディネーター ノードの障害や部分的なゾーンの停止に対してクラスタの復元性を確保する必要がある場合は、高可用性モードを有効にすることをおすすめします。高可用性 Dataproc クラスタはゾーンリソースです。

ゾーンとリージョンの停止に対する Dataproc の対応方法と、障害が発生した場合に Dataproc クラスタの信頼性を向上させる方法の詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計: Dataproc をご覧ください。

Dataflow

Dataflow は、ストリーミングとバッチのデータ処理パイプラインを実行するためのフルマネージド サービスです。Dataflow を使用するには、Dataflow パイプラインを作成します。Dataflow は、これらのパイプラインのインスタンスであるジョブをワーカーノード上で実行します。ジョブはゾーンリソースであるため、Dataflow リソースを使用する場合は、次の点を考慮する必要があります。

  • リージョン エンドポイント: Dataflow でジョブを作成するときは、リージョン エンドポイントを構成する必要があります。ジョブのリージョン エンドポイントを構成することで、コンピューティングとデータリソースの配置を特定のリージョンに制限できます。
  • ゾーンへの配置: Dataflow は、ジョブタイプに応じて、リージョン内のすべてのゾーンまたはリージョン内の最適なゾーンにワーカーノードを自動的に分散します。Dataflow では、すべてのワーカーノードをリージョン内の同じゾーンに配置することで、ワーカーノードのゾーンへの配置をオーバーライドできます。ゾーンの停止による問題を軽減するために、ワーカーノードを特定のゾーンに配置する必要がない限り、Dataflow に最適なゾーンへの配置を自動的に選択させることをおすすめします。

ゾーンとリージョンの停止に対する Dataflow の対応方法と、障害が発生した場合に Dataflow クラスタの信頼性を向上させる方法の詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計: Dataflow をご覧ください。

Pub/Sub

Pub/Sub は、メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービスです。Pub/Sub はメッセージをトピック別に整理します。パブリッシャー（メッセージを生成するサービス）はトピックにメッセージを送信し、サブスクライバーはトピックからメッセージを受信します。Pub/Sub は、各メッセージを単一のリージョンに保存し、そのリージョン内の少なくとも 2 つのゾーンに複製します。詳細については、Pub/Sub のアーキテクチャの概要をご覧ください。

Pub/Sub 環境を構成する場合は、次の点を考慮してください。

  • グローバル エンドポイントとリージョン エンドポイント: Pub/Sub は、メッセージをパブリッシュするエンドポイントとして、グローバル エンドポイントとリージョン エンドポイントをサポートしています。パブリッシャーがグローバル エンドポイントにメッセージを送信すると、Pub/Sub は最も近いリージョンを自動的に選択して、そのメッセージを処理します。プロデューサーがリージョン エンドポイントにメッセージを送信すると、Pub/Sub はそのリージョンでメッセージを処理します。
  • メッセージ ストレージ ポリシー: Pub/Sub では、メッセージ ストレージ ポリシーを構成することで、リクエストの送信元やパブリッシャーがメッセージの発行に使用したエンドポイントに関係なく、Pub/Sub がメッセージを処理および保存する場所を制限できます。メッセージが単一リージョン環境の外に出ることがないように、メッセージ ストレージ ポリシーを構成することをおすすめします。

Pub/Sub がゾーンとリージョンの停止を処理する方法の詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計: Pub/Sub をご覧ください。

単一リージョン環境にワークロードを適応させる

環境のプロビジョニングと構成が完了したら、ゾーン障害とリージョン障害に対するワークロードの復元力を高める方法を検討する必要があります。ワークロードごとに独自の可用性と信頼性の要件とプロパティを設定できますが、適用できる設計原則と、万が一ゾーン障害やリージョン障害が発生した場合に備えて全体的な復元体制を改善するために採用できる戦略がいくつかあります。ワークロードを設計して実装する際は、次の点を考慮してください。

  • サイト信頼性エンジニアリング（SRE）の手法と原則を実装する: 自動化と広範なモニタリングは、SRE の基本原則の一部です。Google Cloud は、環境の復元力と信頼性を高め、トイルを削減するために、SRE を実装するためのツールとプロフェッショナル サービスを提供しています。
  • スケーラビリティと復元性を考慮した設計: クラウド環境を対象としたワークロードを設計する場合は、ワークロードが尊重すべき固有の要件として、スケーラビリティと復元性を考慮することをおすすめします。このような種類の設計の詳細については、スケーラブルで復元性の高いアプリのためのパターンをご覧ください。
  • クラウド インフラストラクチャの停止から復旧するための設計: Google Cloud の可用性保証は、Google Cloud サービスレベル契約で定義されています。万一ゾーンまたはリージョンの障害が発生した場合でも、ゾーンやリージョンの障害に対する復元力を確保できるようにワークロードを設計することをおすすめします。
  • 負荷制限とグレースフル デグラデーションを実装する: クラウド インフラストラクチャの障害や、ワークロードの他の依存関係の障害が発生した場合に備え、ワークロードが復元力を持つように設計することをおすすめします。ワークロードは、障害が発生しても明確に定義された一定レベルの機能を維持（グレースフル デグラデーション）し、負荷状態近づくにつれて負荷の一部を軽減する（負荷制限）必要があります。
  • 定期的なメンテナンスを計画する: デプロイ プロセスと運用プロセスを設計する際は、環境の定期的なメンテナンスの一環として実行する必要があるすべてのアクティビティについても検討することをおすすめします。定期的なメンテナンスには、ワークロードとその依存関係に対する更新や構成変更の適用などのアクティビティと、それらのアクティビティが環境の可用性に与える影響を含める必要があります。たとえば、Compute Engine インスタンスに対してホスト メンテナンス ポリシーを構成できます。
  • テスト駆動開発手法を採用する: ワークロードを設計する際は、ワークロードが意図したとおりに動作することをあらゆる角度から確認するために、テスト駆動開発手法を採用することをおすすめします。たとえば、ワークロードとクラウド インフラストラクチャが、必要とされる機能面の要件、機能面以外の要件、セキュリティの要件を満たしているかどうかをテストできます。

次のステップ

寄稿者

著者: Marco Ferrari | クラウド ソリューション アーキテクト

その他の寄稿者:

  • Henry Bell | クラウド ソリューション アーキテクト
  • Elliot Eaton | クラウド ソリューション アーキテクト
  • Grace Mollison | ソリューション リード
  • Ido Flatow | クラウド ソリューション アーキテクト