このドキュメントでは、Google Distributed Cloud（GDC）エアギャップのデプロイ階層について説明します。これには、ユニバース、リージョン、ゾーンが含まれます。エアギャップ リソースとインフラストラクチャの高可用性を実現するには、環境をホストするロケーションと、アプリケーションで使用可能な構成を適用する戦略的境界を理解する必要があります。
このドキュメントは、次のユーザーを対象としています。
- GDC ゾーンとグローバル インフラストラクチャのデプロイと管理を担当するインフラストラクチャ オペレーター。
- マルチゾーン サービスを構成するネットワーク管理者や IT 管理者などのプラットフォーム管理者。
- GDC ユニバースでアプリケーションの開発と管理を担当するアプリケーション オペレーター。
詳細については、 GDC エアギャップ ドキュメントの対象読者をご覧ください。
デプロイ階層の概要
GDC エアギャップ デプロイは、ユニバース、リージョン、ゾーンで構成される階層構造に従います。
ユニバースは、ネットワーク接続とコントロール プレーンを共有する相互接続されたゾーンの高度なグループです。 ゾーンは地理的に離れていても、個別のゾーンが低レイテンシ通信が可能なほど物理的に近い場合は、リージョン境界が確立されます。
ゾーンは、GDC エアギャップ デプロイの構成要素です。 各ゾーンは自己完結型の実装であり、 に接続する必要はありません。 Google Cloud ゾーンは、ローカル コントロール プレーンを介して独自のインフラストラクチャ、サービス、API、ツールを管理します。
たとえば、次の図は GDC マルチゾーン ユニバースを示しています。
この図には 2 つのリージョンがあり、それぞれが 1 つのユニバース内に存在します。リージョン 1 は、仮想マシン（VM）やコンテナ アプリケーションなど、さまざまなゾーンサービスを運用する 3 つのゾーンを示しています。また、Identity and Access Management（IAM）やロード バランシングなど、ユニバース内のすべてのゾーンとリージョンにまたがるグローバル サービスもあります。
たとえば、広範囲の地理的リージョンにまたがる GDC ユニバースを使用できます。米国バージニア州に 3 つのゾーンがあるリージョン 1 を考えてみましょう。
- ゾーン A（
us-virginia1-aなど） - ゾーン B（
us-virginia1-bなど） - ゾーン C（
us-virginia1-cなど）
同様に、オランダにリージョン 2 を配置し、アムステルダムにゾーンを含めることができます。
- ゾーン A（
eu-ams1-aなど） - ゾーン B（
eu-ams1-bなど） - ゾーン C（
eu-ams1-cなど）
リージョン内のゾーンは地理的に互いに近い必要がありますが、リージョンは広範囲にまたがることができます。たとえば、ゾーン間のファイバー距離の上限は同じリージョン内の別のゾーンまで 50 km ですが、リージョンは別のリージョンから 100 km 以上離れることができます。特定のレイテンシ要件について詳しくは、インフラストラクチャ オペレーター グループにお問い合わせください。
ゾーンについて
ゾーンには、 またはパブリック インターネットに接続しなくても独立して動作できる 4 つのレイヤが含まれています。 Google Cloud
- ハードウェア: データセンターのラックに完全に統合された基盤となる機器。このレイヤは、システムと統合ワークロードのコンピューティング、ストレージ、ネットワーク、GPU 容量を提供します。
- インフラストラクチャ: 基盤となるハードウェア管理システム。このレイヤは、ハードウェア固有の構成を必要とせずにソフトウェアを実行できるインターフェースを提供します。
- サービス プラットフォーム: GDC でサービスを構築するためのフレームワーク。このレイヤは、マネージド サービスと Marketplace サービスの一貫性を提供します。
- マネージド サービスと Marketplace サービス: GDC で実行される顧客向けのクラウド サービス。このレイヤは、ワークロードとサービスのデータプレーンの一貫した実装を提供します。
これらのコンポーネントにより、独自の可用性と復元性の要件を満たすようにゾーン構成を柔軟に調整できます。この構造を理解することで、一般的なエアギャップ ゾーン構成を理解するための基盤ができます。
デプロイ構成
次のセクションでは、GDC エアギャップで使用できる一般的なデプロイ構成について説明します。
シングルゾーン構成
シングルゾーン構成では、1 つのゾーンが唯一のリージョンとして機能するユニバースをデプロイできます。 この構成が可能なのは、各ゾーンが独立して動作するためです。通常、この設定は、初期デプロイや、高可用性や堅牢な障害復旧を必要としないワークロードに使用します。
シングルゾーン ユニバースの主な制限は、単一障害点が発生し、システムが停止しやすくなることです。単一障害点は、リソースを 1 つのゾーンにのみデプロイした場合に発生します。 ゾーンリソース は、特定のゾーンで停止やサービスの中断が発生すると、グループとして影響を受けます。
マルチゾーン構成
マルチゾーン構成では、アプリケーションとサービスを複数のゾーンに戦略的に分散できます。 この設定により、地理的に分散されたリソースが提供されるため、システムの復元性とフォールト トレランスが向上します。
この構成では、高可用性も実現します。これにより、 ゾーンで停止が発生した場合でも、 アプリケーションやサービスに継続的にアクセスして運用できます。高可用性は、ユニバース内の複数のゾーンにリソースをデプロイして管理することで、冗長性を実現します。 GDC は、グローバル機能を提供するサービスの サブセットを提供します。そのため、リソースは手動レプリケーションなしで、ユニバース内の複数のゾーンでデフォルトで管理されます。 グローバル リソース はデフォルトで複数のゾーンにまたがるため、ゾーンの 停止時でも使用できます。
マルチゾーン構成の主なメリットは、各ゾーンが個別の障害ドメインとして機能できることです。障害ドメインは、物理的なロケーションや依存関係を共有しているため、同時に障害が発生しやすいリソースのグループです。 ゾーンを十分に離して配置することで、システムは広範囲にわたる障害に対する復元力を高めることができます。
ゾーンの非対称性により、GDC ユニバースのゾーン間で組織とハードウェアの構成を異なるものにできます。 ゾーンの 非対称性は、プレビュー版の機能 です。バージョン 1.14.4 以降。
マルチゾーン構成の主な機能
マルチゾーン構成では、各ゾーンが個別の障害ドメインとして機能するため、復元性の高いアーキテクチャを確立できます。これらの独立した障害ドメインにリソースを分散することで、次のセクションで説明する主な機能をエアギャップ システムに追加できます。
高可用性
停止に耐えられる永続的なサービスを提供するために、可用性の高いアプリケーションを作成できます。ロード バランシングやデータ レプリケーションなどの高可用性戦略により、脆弱なゾーン アプリケーションを復元性と信頼性の高いグローバル サービスに変換できます。詳細については、 アプリの高可用性をご覧ください。
データ保護
マルチゾーン構成を使用すると、地理的に分離されたバックアップを作成するためにデータ レプリケーションを設定できるデータ保護戦略を使用して、停止が発生した場合でもデータを安全にアクセスできるように維持できます。詳細については、 マルチゾーン ストレージによるデータ保護をご覧ください。
ネットワーク トラフィックの管理
可用性の高い GDC システムを作成するには、耐久性のあるネットワークを構築することが不可欠です。複数のゾーンにわたってネットワーキング戦略を構成して、ゾーンの停止が発生した場合のフェイルオーバー手順を計画できます。ゾーン間でネットワーク トラフィックを分散すると、アプリケーションのパフォーマンスにプラスの影響を与えることもできます。詳細については、 複数のゾーンのネットワーク トラフィックの管理をご覧ください。
権限の管理
クロスゾーン ロールを実装して、グローバル スケールでアクセス制御戦略を適用できます。これにより、ゾーン固有の権限管理が不要になり、管理が煩雑になるのを防ぐことができます。同様に、グローバル アクセス アカウントを使用して、ユーザーとサービスのゾーン間の認証をシームレスに管理できます。詳細については、 マルチゾーン ユニバースの権限管理をご覧ください。
制限事項
GDC エアギャップ ユニバースには次の制限があります。
- 2 つのゾーンを持つユニバースは、リージョン構成に関係なく、自動復旧戦略を提供できないため、手動で復旧する必要があります。 3 つ以上のゾーンを持つユニバースは、復旧手順を自動的にトリガーできます。
- GDC はリージョンをグループ化の概念としてのみ提供し、リージョン サービスは提供しません。GDC ユニバースのリージョンは、パブリック Google Cloud アーキテクチャとの緊密な連携、今後の開発と計画のために提供されます。
次のステップ
- GDC ユニバースで使用可能なグローバル リソースタイプとゾーンリソースタイプ について学習する。
- 高可用性ガイドを確認して、アプリケーションがローカル ゾーンの障害に対して復元力があることを確認する。
- リソースがゾーン内で階層的に管理される方法について詳しくは、リソース階層 のドキュメントをご覧ください。