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

この記事は、ハイブリッドおよびマルチクラウドのデプロイ、アーキテクチャパターン、ネットワークトポロジについて説明する、マルチパートシリーズのパート 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 アドレスがなくてもインターネットにアクセスできるようになります。

ベストプラクティス

クラウドコンピューティング環境とプライベートコンピューティング環境を厳密に隔離する場合は、ゲート型トポロジの使用を検討してください。
プライベートコンピューティング環境内で Kubernetes を使用する場合は、Open Service Broker を使用して、Google プラットフォームのサービスとリソースのプロビジョニングとアクセスを一元的に処理します。
ハイブリッドおよびマルチクラウドのネットワークトポロジを対象とした一般的なおすすめの方法も検討してください。

下り（外向き）ゲート型

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

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

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

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

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

下り（外向き）ゲート型トポロジ

Google Cloud 側では、ワークロードを共有 VPC にデプロイします。
Cloud Interconnect または Cloud VPN のいずれかを使用して、VPC をプライベートコンピューティング環境内の境界ネットワークに接続し、API ゲートウェイへの呼び出しを許可します。
ファイアウォールルールを使用して、VPC への着信接続を拒否します。
必要であれば、Cloud Router を使用して環境間のルートを動的に交換します。
すべての環境は、重複のない共通の RFC 1918 IP アドレス空間を共有しています。

バリエーション

インターネットにアクセスするには、アプリケーション 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 アドレス空間は環境間で重複してもかまいません。