ゾーンの仮想化

このドキュメントでは、ゾーンの仮想化について説明します。これは、Google が一般公開ゾーンをデータセンター内の内部物理ハードウェアのクラスタにマッピングするために使用する方法です。ゾーンの仮想化により、お客様が影響を受けることなく、ゾーンのシームレスな拡張、ハードウェアのアップグレード、物理インフラストラクチャのデコミッションが可能になります。アプリが複数のプロジェクトに分散されている場合や、Google がゾーンを物理インフラストラクチャに分散させる方法について確認するには、このトピックをご覧ください。

Google Cloud のリソースは世界中の複数のリージョンでホストされています。各リージョンは 3 つまたは 4 つのゾーンで構成されています。ゾーンはリソースの論理グループであり、相関的な障害を回避するように設計されています。リージョン内の複数のゾーンにリソースを配置すると、物理インフラストラクチャとソフトウェア インフラストラクチャの相関的な障害がアプリに影響を及ぼすリスクを軽減できます。リソースを複数のリージョンに配置することで、障害からの隔離をさらに強化できます。

Google Cloud の地理的なロケーションの一覧については、リージョンとゾーンをご覧ください。復元力のあるアプリの構築について詳しくは、障害復旧計画に関する Google Cloud ソリューション シリーズをご覧ください。

クラスタ

すべての Google Cloud ハードウェアはクラスタに整理されています。クラスタは、ビルディング、電力、冷却のインフラストラクチャでサポートされている、コンピューティング、ネットワーク、ストレージの各リソースのセットを表します。通常、インフラストラクチャ コンポーネントは 1 つのクラスタをサポートしており、クラスタ間の依存関係はほとんどありません。

asia-east1 には 3 つのゾーンと 3 つのクラスタがあります。

図 1: asia-east1 リージョンには 3 つのゾーンがあります。各ゾーンには、個別のリソースを持つ独自のクラスタがあります。

ただし、信頼性とダウンストリームの冗長性を兼ね備えたコンポーネントはクラスタ間で共有できます。たとえば、電力系統のサブステーションは一般的に非常に信頼性が高く、各クラスタで冗長電源システムが使用されているため、複数のクラスタで共有されています。Google Cloud では、Google Cloud サービスのサービスレベル契約(SLA)とサービスレベル目標(SLO)をサポートするように、物理インフラストラクチャを設計しています。

ゾーンとクラスタのマッピング

プロジェクトで初めてリージョンを使用する場合、Google Cloud はプロジェクトのゾーンリソースに使用されるリージョン内のゾーンごとに単一のクラスタを選択します。この選択をゾーンとクラスタのマッピングといいます。デフォルトのゾーンとクラスタのマッピングは各プロジェクト ベースで選択されるため、すべてのお客様に同じ機能とパフォーマンスが提供されます。プロジェクト内では、論理ゾーンと物理クラスタ間のマッピングには一貫性がありますが、プロジェクトのゾーンリソースに基づいたゾーンとクラスタのマッピングがまったく異なるプロジェクトもあります。同じ物理クラスタに 2 つのゾーンがマッピングされることはありません。

Virtual Private Cloud(VPC)ネットワークを使用することで、プロジェクト間でゾーンとクラスタのマッピングを調整できます。Google Cloud は、VPC ネットワークを共有するすべてのプロジェクトに同じゾーンとクラスタのマッピングを割り当てようとします。これは、予測可能でアトミックなアプリケーション コンポーネントの障害に適しています。

仮想化されたゾーン

リージョンが拡大するにつれ、各ゾーンは複数のクラスタでサポートされるようになります。Google では、共有インフラストラクチャの障害による影響がリージョン内の 1 つのゾーンに限定されるように、ビルディングや冷却インフラストラクチャなどの共有インフラストラクチャを使用するクラスタを論理ゾーンにグループ化するように努めています。

asia-east1 ゾーン A と B はそれぞれ 2 つのクラスタに拡張されています。

図 2: asia-east1 の 3 つのゾーンのうち 2 つが拡張され、2 つのクラスタを持つようになりました。

お客様のワークロードは、できるだけ少数のクラスタ内で管理されています。ほとんどの場合、ゾーン ワークロードは 1 つのクラスタに含まれます。ただし、マップのプライマリ クラスタで追加の容量や特殊なハードウェアが利用できない場合は、ゾーンとクラスタのマッピングに追加のクラスタが含めることができます。

asia-east1 ゾーン A と B はそれぞれ 2 つのクラスタに拡張されています。

図 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 ネットワークを共有するすべてのプロジェクトに同じゾーンとクラスタのマッピングを割り当てます。これは、プロジェクトが異なる Google Cloud 組織にある場合でも同様です。プロジェクトと VPC の数によってネットワークの複雑さが増すため、ゾーン マッピングの一貫性を維持することはより困難になり、保証できなくなります。

次のステップ