ハイブリッドおよびマルチクラウドのネットワーク トポロジ

この記事は、ハイブリッドおよびマルチクラウドのデプロイ、アーキテクチャ パターン、ネットワーク トポロジについて説明する、マルチパート シリーズのパート 3 です。このセクションでは、ハイブリッドおよびマルチクラウドの設定に使用できる一般的なネットワーク トポロジについて説明します。この記事では、これらのトポロジに最適なシナリオとアーキテクチャ パターンについて説明し、Google Cloud を使用してそれらを実装するためのおすすめの方法を示します。

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

プライベート コンピューティング環境を安全かつ信頼できる方法で Google Cloud に接続することは、ハイブリッドまたはマルチクラウド デプロイの成功の鍵を握ります。ハイブリッドおよびマルチクラウドの設定のために選択するネットワーク トポロジは、エンタープライズ ワークロードの固有の要件を満たし、適用するアーキテクチャ パターンに適合する必要があります。各トポロジには調整が必要な場合がありますが、ブループリントとして使用できる共通のトポロジがあります。

ミラー型

ミラー型トポロジでは、クラウド コンピューティング環境とプライベート コンピューティング環境を互いにミラーリングします。このトポロジは、主に環境ハイブリッド パターンに従った設定に適用されます。この環境パターンでは、ある環境で開発ワークロードおよびテスト ワークロードを実行し、別の環境でステージング ワークロードおよび本番環境ワークロードを実行します。

テスト ワークロードと本番環境ワークロードは、互いに直接通信することが想定されていません。ただし、両方のワークロードのグループを一貫した方法で管理およびデプロイすることは可能です。したがって、次の要件を満たすように 2 つのコンピューティング環境を接続します。

  • 継続的インテグレーション / 継続的デプロイ(CI/CD)および管理システムが、コンピューティング環境をまたがってワークロードをデプロイおよび管理できる。
  • モニタリング ツールなどの管理ツールがコンピューティング環境をまたがって動作する。
  • ワークロードがコンピューティング環境をまたがって通信することはできない。

リファレンス アーキテクチャ

次の図は、これらの要件に一致するリファレンス アーキテクチャを示しています。

前述の要件を満たすリファレンス アーキテクチャ

  • Google Cloud 上で、2 つの別個の Virtual Private Cloud(VPC)を使用します。1 つは開発およびテスト ワークロード用の共有 VPC で、もう 1 つはすべての CI / CD および管理ツール用の VPC です。2 つの VPC はピアリングされるため、内部 IP アドレスを使用するクロス VPC 通信が可能になります。ピアリングにより、CI/CD および管理システムは、開発およびテスト ワークロードをデプロイして管理することが可能になります。
  • さらに、プライベート コンピューティング環境で本番環境ワークロードを実行しているネットワークに CI / CD VPC を接続します。この接続は、Cloud Interconnect または Cloud VPN のいずれかを使用して確立します。このように接続すると、本番環境ワークロードもデプロイして管理できます。
  • すべての環境は、重複のない共通の RFC 1918 IP アドレス空間を共有しています。
  • 必要に応じてファイアウォール ルールを設定し、本番環境ワークロードと開発 / テスト ワークロードで相互に通信できないようにします。

バリエーション

このトポロジのバリエーションとして、開発およびさまざまなテストの段階で別々の VPC を使用し、これらすべてを CI/CD VPC とピアリングできます。

VM ベースのワークロードを実行する場合は、各環境でデプロイを行うジョブを引き継ぐ CI エージェントを実行することが有益なこともあります。CI システムの機能に応じて、エージェントを使用することで、環境間の通信をさらに制限し、どのシステムが相互に通信できるかについての制御を強化できる場合もあります。

次の図は、このバリエーションの概略を示しています。

エージェントによるミラー型トポロジ

Kubernetes ワークロードを排他的に実行する場合、必ずしも 2 つの VPC をピアリングする必要はありません。Google Kubernetes Engine(GKE)コントロール プレーンは公開されているため、マスター承認済みネットワーク機能と RBAC を使用して、CI システムのみにデプロイの実行を許可できます。次の図は、このトポロジを示しています。

ミラー型トポロジ

ベスト プラクティス

  • 本番環境のデプロイまたはデプロイの再構成に必要な CI / CD システムが、可用性の高い方法でデプロイされるようにします。さらに、可用性の向上のために冗長なバーチャル プライベート ネットワーク(VPN)または相互接続リンクを使用することも検討してください。
  • 開発およびテスト用 VPC の VM インスタンスがパブリック IP アドレスを持つように構成して、これらのインスタンスがインターネットに直接アクセスできるようにします。または、同じ VPC に、下り(外向き)トラフィックを処理する Cloud NAT をデプロイします。
  • パブリック ネットワークを使用する場合は、限定公開の Google アクセスを使用して、VPC ワークロードと Google API の間の通信を回避します。
  • ハイブリッドおよびマルチクラウドのネットワーク トポロジを対象とした一般的なおすすめの方法も検討してください。

メッシュ型

メッシュ型トポロジでは、すべてのシステムが相互に通信できる複数のコンピューティング環境にまたがるフラットなネットワークを確立します。このトポロジは主に、階層型パーティション型、またはバースト型の設定に適用されます。このトポロジでは、次の要件を満たすようにコンピューティング環境を接続する必要があります。

  • ワークロードは、RFC 1918 のプライベート IP アドレスを使用することにより、UDP または TCP を介して環境の境界を越えて相互に通信できる。

  • ファイアウォール ルールを使用して、コンピューティング環境間とコンピューティング環境内でトラフィック フローをきめ細かく制限できる。

リファレンス アーキテクチャ

次の図は、これらの要件を満たすリファレンス アーキテクチャを示しています。

メッシュ型リファレンス アーキテクチャ

  • Google Cloud 側では、ワークロードを単一の共有 VPC にデプロイします。

  • プライベート コンピューティング環境では、Cloud Interconnect または Cloud VPN を使用して VPC をネットワークに接続します。この設定により、プライベート IP アドレスを使用して環境間の通信を行えるようになります。

  • Cloud Router を使用して、環境間のルートを動的に交換します。

  • すべての環境は、重複のない共通の RFC 1918 IP アドレス空間を共有しています。

バリエーション

Google Cloud ファイアウォール ルールの機能を超える詳細なパケット検査やその他の高度なファイアウォール機能を実装できます。これらのメカニズムを実装するには、次の図に示すように、すべてのクロス環境トラフィックがファイアウォール アプライアンスを通過するようにトポロジを拡張します。

拡張メッシュ型トポロジ

  • 専用のトランジット VPC とプライベート コンピューティング環境内の VLAN の間に VPN または相互接続リンクを確立します。

  • ファイアウォール アプライアンスを実行している VM を使用して、トランジット VPC とアプリケーション VPC の間の接続を確立します。これらの VM を IP 転送用に構成します。VM は複数のネットワーク インターフェースを使用します。1 つはトランジット VPC に接続し、別の 1 つはアプリケーション VPC に接続します。

  • ファイアウォール アプライアンスは、アプリケーション VPC にデプロイされている VM インスタンスの NAT ゲートウェイとしても機能します。このゲートウェイによって、それらのインスタンスはパブリック IP アドレスがなくてもインターネットにアクセスできるようになります。

ベスト プラクティス

下り(外向き)ゲート型

下り(外向き)ゲート型トポロジでは、プライベート コンピューティング環境内の一部の API を、公共のインターネットに公開することなく Google Cloud にデプロイされたワークロードに公開します。この制限された公開は、既存のワークロードのファサードとして機能する API ゲートウェイを介して容易に実現できます。ゲートウェイを境界ネットワーク(DMZ)内にデプロイする一方、ワークロードはプライベート コンピューティング環境内の高度に保護された専用ネットワークにデプロイします。

下り(外向き)ゲート型トポロジは、主に階層構成に適用され、次の要件を満たす方法でコンピューティング環境に接続する必要があります。

  • Google Cloud にデプロイするワークロードは、プライベート IP アドレスを使用して API ゲートウェイと通信できる。プライベート コンピューティング環境内の他のシステムに Google Cloud 内からアクセスすることはできない。

  • プライベート コンピューティング環境から Google Cloud にデプロイされたワークロードへの通信は許可されない。

リファレンス アーキテクチャ

次の図は、これらの要件を満たすリファレンス アーキテクチャを示しています。

下り(外向き)ゲート型トポロジ

バリエーション

インターネットにアクセスするには、アプリケーション VPC にデプロイする VM インスタンスに外部 IP アドレスが必要です。このような外部アドレスを設定しなくても済むように、次の図に示すように Cloud NAT を同じ VPC ネットワークにデプロイできます。

下り(外向き)ゲート型トポロジのバリエーション

ベスト プラクティス

  • Apigee for Private Cloud を API ゲートウェイ ソリューションとして使用することを検討してください。

  • ハイブリッドおよびマルチクラウドのネットワーク トポロジを対象とした一般的なおすすめの方法も検討してください。

上り(内向き)ゲート型

上り(内向き)ゲート型トポロジでは、Google Cloud 内で実行中のワークロードの一部の API を、公共のインターネットに公開することなく、プライベート コンピューティング環境に公開します。このトポロジは下り(外向き)ゲートのシナリオに対応するものであり、エッジ ハイブリッドのシナリオに適しています。

次のようにして、プライベート コンピューティング環境にアクセス可能にした API ゲートウェイ経由で、選択した API を公開します。

  • プライベート コンピューティング環境にデプロイするワークロードは、プライベート IP アドレスを使用して API ゲートウェイと通信できる。Google Cloud にデプロイされた他のシステムにはアクセスできない。

  • Google Cloud からプライベート コンピューティング環境への通信は許可されない。

リファレンス アーキテクチャ

次の図は、これらの要件を満たすリファレンス アーキテクチャを示しています。

上り(内向き)ゲート型トポロジ

  • Google Cloud 側では、ワークロードをアプリケーション VPC にデプロイします。

  • 専用のトランジット VPC とプライベート コンピューティング環境の間で Cloud Interconnect または Cloud VPN 接続を確立します。

  • API ゲートウェイを実行している VM を使用して、トランジット VPC とアプリケーション VPC の間の接続を確立します。これらの VM は 2 つのネットワーク インターフェースを使用します。1 つはトランジット VPC に接続し、もう 1 つはアプリケーション VPC に接続します。複数の API ゲートウェイ インスタンスにトラフィックを分散するには、トランジット VPC で内部ロードバランサを構成します。

  • アプリケーション VPC に Cloud NAT をデプロイして、ワークロードがインターネットにアクセスできるようにします。このゲートウェイにより、VM インスタンスに外部 IP アドレスを設定する必要がなくなります(API ゲートウェイの背後にデプロイされたシステムで外部 IP アドレスを設定することを避けられます)。

  • 必要であれば、Cloud Router を使用して、環境間のルートを動的に交換します。

  • すべての環境は、重複のない共通の RFC 1918 IP アドレス空間を共有しています。

ベスト プラクティス

  • Apigee for Private Cloud を API ゲートウェイ ソリューションとして使用することを検討してください。

  • ハイブリッドおよびマルチクラウドのネットワーク トポロジを対象とした一般的なおすすめの方法も検討してください。

上り(内向き) / 下り(外向き)ゲート型

上り(内向き)ゲート型と下り(外向き)ゲート型を組み合わせると、Google Cloud およびプライベート コンピューティング環境で実行されているワークロード間において、選択された API を双方向に使用できます。両方の側で、API ゲートウェイを使用して選択した API を公開し、オプションで呼び出しの認証、認可、監査を行います。

API 通信は次のように機能します。

  • Google Cloud にデプロイするワークロードは、プライベート IP アドレスを使用して API ゲートウェイと通信できる。プライベート コンピューティング環境内にデプロイされた他のシステムにはアクセスできない。

  • 逆に、プライベート コンピューティング環境にデプロイするワークロードは、プライベート IP アドレスを使用して Google Cloud 側の API ゲートウェイと通信できる。Google Cloud にデプロイされた他のシステムにはアクセスできない。

リファレンス アーキテクチャ

次の図は、上り(内向き) / 下り(外向き)ゲート型トポロジのリファレンス アーキテクチャを示しています。

上り(内向き) / 下り(外向き)ゲート型トポロジ

  • Google Cloud 側では、ワークロードを共有 VPC にデプロイし、インターネットには公開しません。

  • 専用のトランジット VPC とプライベート コンピューティング環境の間で Cloud Interconnect または Cloud VPN 接続を確立します。

  • API ゲートウェイを実行している VM を使用して、トランジット VPC とアプリケーション VPC の間の接続を確立します。これらの VM は 2 つのネットワーク インターフェースを使用します。1 つはトランジット VPC に接続し、もう 1 つはアプリケーション VPC に接続します。複数の API ゲートウェイ インスタンスにトラフィックを分散するには、トランジット VPC で内部ロードバランサを構成します。

  • Cloud NAT も使用します。Cloud NAT を使用すると、ワークロードはインターネットにアクセスし、プライベート コンピューティング環境で実行されている API ゲートウェイと通信できます。

  • 必要であれば、Cloud Router を使用して、環境間のルートを動的に交換します。

  • すべての環境は、重複のない共通の RFC 1918 IP アドレス空間を共有しています。

ベスト プラクティス

  • Apigee for Private Cloud を API ゲートウェイ ソリューションとして使用することを検討してください。
  • ハイブリッドおよびマルチクラウドのネットワーク トポロジを対象とした一般的なおすすめの方法も検討してください。

ハンドオーバー

ハンドオーバー型トポロジでは、Google Cloud が提供するストレージ サービスを使用して、プライベート コンピューティング環境を Google Cloud のプロジェクトに接続します。このトポロジは、分析パターンに従っている設定に主に適用され、次のように機能します。

  • プライベート コンピューティング環境で実行されるワークロードでは、共有ストレージのあるロケーションにデータがアップロードされます。使用状況に応じて、一括または少量のメッセージでアップロードが行われます。

  • Google Cloud でホストされるワークロードでは、そのロケーションのデータを使用して、ストリーミング方式またはバッチ方式で処理します。

リファレンス アーキテクチャ

次の図は、ハンドオーバー型トポロジのリファレンス アーキテクチャを示しています。

ハンドオーバー型トポロジのためのリファレンス アーキテクチャ

  • Google Cloud 側では、ワークロードをアプリケーション VPC にデプロイします。こうしたワークロードには、データ処理、分析、分析関連のフロントエンド アプリケーションが含まれます。

  • フロントエンド アプリケーションを企業ユーザーに安全に公開するために、Identity-Aware Proxy を使用できます。

  • Cloud Storage バケットまたは Pub/Sub キューのセットを使用して、プライベート コンピューティング環境からデータをアップロードし、Google Cloud にデプロイされたワークロードでそのデータを処理できるようにします。IAM ポリシーを使用して、信頼できるワークロードのみにアクセスを制限できます。

  • 環境間にプライベート ネットワーク接続がないので、RFC 1918 IP アドレス空間は環境間で重複してもかまいません。

ベスト プラクティス

ハイブリッドおよびマルチクラウドのネットワーク トポロジのベスト プラクティス

  • Google Cloud 側では共有 VPC を利用します。共有 VPC は、複数の Google Cloud プロジェクトで使用できる VPC で、多くの個別の VPC を維持する必要がなくなります。共有 VPC を使用すると、ピアリングの構成、サブネット、ファイアウォール ルール、および権限を集中管理することもできます。

  • ファイアウォール ルールを管理する場合は、ネットワーク タグベースのフィルタリングよりもサービス アカウント ベースのフィルタリングを使用することをおすすめします。

  • VPC を使用して個々のワークロードを互いに隔離することは避けてください。代わりに、サブネットとファイアウォール ルールを使用することをおすすめします。GKE を使用する場合は、ネットワーク ポリシーを使用してこの方法を補うことができます。

  • Cloud VPN では環境間のトラフィックが暗号化されますが、Cloud Interconnect では暗号化されません。ワークロード間の通信を保護するには、Transport Layer Security(TLS)の使用を検討してください。

  • 高スループットな VPN を作成するためのおすすめの方法を実施します。

  • 既存の RFC 1918 IP アドレス空間内に、クラウドでホストされているすべてのシステムに対応できる十分なアドレス空間を確保します。

  • GKE を使用する場合は、限定公開クラスタの使用を検討し、ネットワーク サイズの要件に注意してください。

  • Google Cloud で実行されており、外部 IP アドレスが割り当てられていない VM インスタンスを Google サービスにアクセスできるようにするには、限定公開の Google アクセスを使用します。

次のステップ