このドキュメントでは、ゾーンの仮想化について説明します。これは、Google が一般公開ゾーンをデータセンター内の内部物理ハードウェアのクラスタにマッピングするために使用する方法です。ゾーンの仮想化により、お客様が影響を受けることなく、ゾーンのシームレスな拡張、ハードウェアのアップグレード、物理インフラストラクチャのデコミッションが可能になります。アプリケーションが複数のプロジェクトに分散されている場合や、Google がゾーンを物理インフラストラクチャに分散させる方法について確認するには、このトピックをご覧ください。
Google Cloud のリソースは世界中の複数のリージョンでホストされています。各リージョンは 3 つまたは 4 つのゾーンで構成されています。ゾーンはリソースの論理グループであり、相関的な障害を回避するように設計されています。リージョン内の複数のゾーンにリソースを配置すると、物理インフラストラクチャとソフトウェア インフラストラクチャの相関的な障害がアプリケーションに影響を及ぼすリスクを軽減できます。リソースを複数のリージョンに配置することで、障害からの隔離をさらに強化できます。
Google Cloud の地理的なロケーションの一覧については、リージョンとゾーンをご覧ください。復元力のあるアプリケーションの構築について詳しくは、障害復旧計画に関する Google Cloud ソリューション シリーズをご覧ください。
クラスタ
すべての Google Cloud ハードウェアはクラスタに整理されています。クラスタは、ビルディング、電力、冷却のインフラストラクチャでサポートされている、コンピューティング、ネットワーク、ストレージの各リソースのセットを表します。通常、インフラストラクチャ コンポーネントは 1 つのクラスタをサポートしており、クラスタ間の依存関係はほとんどありません。
図 1: asia-east1 リージョンには 3 つのゾーンがあります。各ゾーンには、個別のリソースを持つ独自のクラスタがあります。
ただし、信頼性とダウンストリームの冗長性を兼ね備えたコンポーネントはクラスタ間で共有できます。たとえば、サブステーションは信頼性が非常に高く、クラスタは冗長電源システムを使用するため、通常は複数のクラスタで電力網のサブステーションを共有します。Google Cloud では、Google Cloud サービスのサービスレベル契約（SLA）とサービスレベル目標（SLO）をサポートするように、物理インフラストラクチャを設計しています。
ゾーンとクラスタのマッピング
プロジェクトで初めてリージョンを使用する場合、Google Cloud はリージョン内のゾーンごとに一意のクラスタを選択します。これが、そのプロジェクトのゾーンリソースのデフォルト クラスタです。ただし、ハードウェアの制約のために、そのゾーンに追加のクラスタが使用される場合があります。この選択をゾーンとクラスタのマッピングといいます。デフォルトのゾーンとクラスタのマッピングは各プロジェクト ベースで選択されるため、すべてのお客様に同じ機能とパフォーマンスが提供されます。プロジェクト内では、論理ゾーンと物理クラスタ間のマッピングには一貫性がありますが、プロジェクトのゾーンリソースに基づいたゾーンとクラスタのマッピングがまったく異なるプロジェクトもあります。同じ物理クラスタに 2 つのゾーンがマッピングされることはありません。
Virtual Private Cloud（VPC）ネットワークを使用することで、プロジェクト間でゾーンとクラスタのマッピングを調整できます。Google Cloud は、VPC ネットワークを共有するすべてのプロジェクトに同じゾーンとクラスタのマッピングを割り当てようとします。プロジェクト全体でゾーンとクラスタを一貫してマッピングすると、アプリケーション コンポーネントにアトミックで予測可能な障害が発生しやすくなります。
仮想化されたゾーン
リージョンが拡大するにつれ、各ゾーンは複数のクラスタでサポートされるようになります。Google では、共有インフラストラクチャの障害による影響がリージョン内の 1 つのゾーンに限定されるように、ビルディングや冷却インフラストラクチャなどの共有インフラストラクチャを使用するクラスタを論理ゾーンにグループ化するように努めています。
図 2: asia-east1 の 3 つのゾーンのうち 2 つが拡張され、2 つのクラスタを持つようになりました。
お客様のワークロードは、できるだけ少数のクラスタ内で管理されています。通常、ゾーンのワークロードは 1 つのクラスタに含まれています。ただし、マップのプライマリ クラスタで追加の容量や特殊なハードウェアが利用できない場合は、ゾーンとクラスタのマッピングに追加のクラスタが含めることができます。
図 3: 2 つのプロジェクトのゾーンとクラスタのマッピングを示す図
- Project Fizz には、2 つのクラスタが
asia-east1-aにマッピングされています。クラスタ z のみが GPU ワークロードをサポートし、クラスタ y のみが TPU ワークロードをサポートしているためです。 - Project Fizz と Project Buzz には、
asia-east1-bにマッピングされている異なるクラスタがあります。
ゾーンとクラスタのマッピングはほとんど変更されませんが、容量のニーズと基盤となるハードウェア サービスの進化に合わせて変更されます。たとえば、クラスタは、容量を増やすためにゾーンに追加されますが、廃止される際にゾーンから削除されます。Google では、メンテナンス イベント中、可能であればライブ マイグレーションを使用してダウンタイムを制限しようとします。
クラスタが停止すると、そのクラスタに関連付けられている論理ゾーンのサービスが停止したことが Google Cloud ステータス ダッシュボードで報告されます。ただし、ゾーンは複数のクラスタで構成されている場合があるため、すべてのお客様のリソースが影響を受けるわけではありません。そのため、1 つのクラスタが停止しても影響を受けないお客様もいます。サービス停止の影響を最小限に抑えるために、マルチゾーン アーキテクチャの採用を強くおすすめします。
共有ネットワークと仮想化されたゾーン
Virtual Private Cloud（VPC）ネットワークは、プロジェクト内のリソース間の接続を提供する仮想ネットワークです。複数のプロジェクトで VPC ネットワークを共有してプロジェクト間の接続を可能にし、組織は共有 VPC ネットワークをピアリングして組織間の接続を可能にします。Google のゾーン仮想化マッピング アルゴリズムでは、VPC ネットワークを共有するすべてのプロジェクトに同じゾーンとクラスタのマッピングを割り当てるか、VPC ピアリングを介して VPC ネットワークを拡張します。これは、プロジェクトが異なる Google Cloud 組織にある場合でも同様です。プロジェクトと VPC の数によってネットワークの複雑さが増すため、ゾーン マッピングの一貫性を維持することはより困難になり、保証できなくなります。
次のステップ
- グローバル リソース、リージョン リソース、ゾーンリソースについて学習する。
- 地域とゾーンについて学習する。