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

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

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

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

ミラー型

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

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

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

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

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

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

  • GCP 上で、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 に、下りトラフィックを処理する NAT ゲートウェイをデプロイします。
  • パブリック ネットワークを使用する場合は、限定公開の Google アクセスを使用して、VPC ワークロードと Google API の間の通信を回避します。
  • ハイブリッドおよびマルチクラウドのネットワーク トポロジを対象とした一般的なおすすめの方法も検討してください。

メッシュ型

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

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

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

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

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

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

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

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

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

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

バリエーション

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

拡張メッシュ型トポロジ

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

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

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

おすすめの方法

下りゲート型

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

下りゲート型トポロジは、主に階層型の設定に適用されます。次の要件を満たすようにコンピューティング環境に接続する必要があります。

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

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

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

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

下りゲート型トポロジ

バリエーション

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

下りゲート型トポロジのバリエーション

おすすめの方法

上りゲート型

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

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

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

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

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

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

上りゲート型トポロジ

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

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

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

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

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

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

おすすめの方法

上り / 下りゲート型

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

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

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

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

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

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

上り / 下りゲート型トポロジ

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

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

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

  • 両方の VPC に接続する NAT ゲートウェイとして機能する VM インスタンスも使用します。これらのインスタンスにより、ワークロードはインターネットにアクセスし、プライベート コンピューティング環境で実行されている API ゲートウェイと通信できます。

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

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

おすすめの方法

ハンドオーバー型

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

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

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

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

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

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

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

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

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

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

おすすめの方法

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

  • Google Cloud Platform 側で、共有 VPC の利点を活かします。共有 VPC は、複数の Google Cloud Platform プロジェクトで使用できる VPC であり、多数の VPC を個別に管理する必要がありません。また、共有 VPC を使用すると、ピアリング構成、サブネット、ファイアウォール ルール、権限を集中管理できます。

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

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

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

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

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

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...