このドキュメントは、データセンターのワークロードを Google Cloud に移行する企業向けのネットワーキング アーキテクチャとセキュリティ アーキテクチャについて説明するシリーズの一部です。
このシリーズは、次のドキュメントで構成されています。
- エンタープライズ ワークロードを移行するためのネットワーク設計: アーキテクチャのアプローチ
- 安全なクラウド内アクセスのためのネットワーク: リファレンス アーキテクチャ
- インターネットに接続するアプリケーションの配信のためのネットワーキング: リファレンス アーキテクチャ
- ハイブリッドおよびマルチクラウドのワークロードのネットワーキング: リファレンス アーキテクチャ（このドキュメント）
このドキュメントでは、ワークロードがオンプレミスとクラウド、または複数のクラウド環境など、複数の場所で実行される場合のネットワーキングについて説明します。
リフト＆シフト アーキテクチャ
最初のハイブリッド ワークロード アクセス シナリオは、リフト＆シフト アーキテクチャです。
プライベート接続の確立
Dedicated Interconnect または Partner Interconnect を使用して、オンプレミス ネットワークへの接続を確立できます。図 1 に示すトポロジでは、2 つの異なる大都市圏と異なるエッジ アベイラビリティ ドメインで 4 つの Interconnect 接続を使用して、Dedicated Interconnect で 99.99% の可用性を実現する方法を紹介しています。詳細な情報と推奨事項については、エンタープライズ基盤ブループリントのオンプレミス環境と Google Cloud 間のハイブリッド接続をご覧ください。
図 1. 99.99% の可用性を実現するための冗長 Cloud Interconnect 接続の構成
Network Connectivity Center を使用すると、複数のオンプレミス サイトやクラウドにホストされているサイト間でのデータ移転に Google のネットワークを使用できます。この方法により、データの移動が必要なときは、Google のネットワークの広範性と信頼性を利用できます。図 2 のように、既存の Cloud VPN ネットワーク、Cloud Interconnect、SD-WAN ルーター アプライアンスを、Network Connectivity Center のスポークとして使用して、オンプレミス ネットワークとブランチサイト間のデータ移転をサポートできます。
図 2. Google のバックボーン ネットワークを使用して、Google Cloud の外部にあるオンプレミス エンタープライズ ネットワークや他のクラウド ネットワークを接続する Network Connectivity Center の構成。
Network Connectivity Center の設定の詳細については、Network Connectivity Center のドキュメントの考慮事項をご覧ください。
SD-WAN アプライアンス
Network Connectivity Center を使用すると、サードパーティ ネットワーク仮想アプライアンスをネットワーク接続センターのスポークとして使用して、外部サイトと VPC ネットワーク リソース間の接続を確立できます。ルーター アプライアンスは、いずれかの Google パートナーがサポートするサードパーティの SD-WAN ルーターまたは Cloud Router インスタンスとルートを交換できる別の仮想アプライアンスです。これらのアプライアンス ベースのソリューションは、Cloud VPN と Cloud Interconnect をスポークとして利用できる、現在のサイトツークラウド接続オプションに追加されます。図 3 は、SD-WAN アプライアンスを使用するトポロジを示しています。
図 3. ルーター アプライアンスを使用して SD-WAN 実装を Google のネットワークと統合する Network Connectivity Center の構成。
サードパーティ製アプライアンスを使用してセキュリティ機能を実行できます。アプライアンスのセキュリティ機能は、図 3 に示すようにルーター アプライアンスに統合できます。また、ネットワーク仮想アプライアンスを使用する一般的なパターンで、オンプレミスからのトラフィックがトランジット VPC ネットワークに到達し、アプライアンスがワークロード VPC ネットワークとの接続を確立します（図 4 を参照）。
Network Connectivity Center の設定の詳細については、Network Connectivity Center のドキュメントの考慮事項をご覧ください。
ハイブリッド サービス アーキテクチャ
安全なクラウド内アクセスのためのネットワーキング: リファレンス アーキテクチャで説明したように、クラウド内ユースケースの場合と同様に、Network Connectivity Center によってブランチサイトとオンプレミス・ネットワークから Google Cloud への接続が有効になります。Private Service Connect は、Google マネージド サービスへのプライベート アクセスを提供します。また、クラウドで構築およびデプロイされた他のサービスを利用できます。
図 4 に示すように、VPC Service Controls、Google Cloud ファイアウォール、ネットワーク仮想アプライアンスを組み合わせてネットワーク セキュリティを実装することもできます。
図 4. 安全なデータプレーンを提供するように設計された、リフト＆シフト パターンとハイブリッド サービス設計パターンの両方を使用するアーキテクチャを持つネットワーク。
ゼロトラスト分散型アーキテクチャ
ハイブリッド環境では、さまざまなクラウド プロバイダやオンプレミス環境にデプロイされたサービス メッシュでマイクロサービスが実行されます。mTLS と認可ポリシーを使用して、マイクロサービス間の通信を保護できます。クラウドにサービス メッシュを構築し、そのメッシュをオンプレミスに拡張することは、一般的な手法です。図 5 は、オンプレミスにデプロイされたサービスがクラウド内のサービスにアクセスする例を示しています。サービス間のエンドツーエンドの mTLS は、east-west ゲートウェイと SNI ベースのルーティングを使用して有効化されます。Anthos Service Mesh ではサービス間通信を保護でき、サービスの承認ポリシーの構成や、マネージド認証局によって提供される証明書と鍵のデプロイが可能になります。
ハイブリッド環境では一般的に、複数の GKE クラスタなど、複数のメッシュ デプロイメントが採用されます。このフローの重要なコンポーネントは SNI ルーティングです。これは、各クラスタの GKE east-west ゲートウェイで使用されます。この構成により、エンドツーエンドの mTLS 接続を維持しながら、ゲートウェイによってワークロードに直接 mTLS ルーティングを行うことができます。
図 5. オンプレミス環境と Google Cloud 全体にデプロイされたゼロトラスト サービス メッシュ。
企業は Anthos Service Mesh を使用して複数のクラウドにデプロイできます。クラウド プロバイダ間での ID と証明書の管理の課題に対処するため、Anthos Service Mesh は CA サービス（CA サービス）を使用して、Workload Identity と中間クラスタ内の認証局（CA）を提供します。中間 CA は、外部 CA にチェーン化することも、Google でホストすることもできます。企業所有の HSM と Cloud HSM の両方を使用して、リージョンや署名アルゴリズムなどの CA 属性をカスタマイズできます。
Workload Identity により、クラスタ内のマイクロサービスごとに詳細に設定した個別の ID と認可を割り当てることができます。Anthos Service Mesh では、通信を中断することなく、証明書を発行し、鍵と証明書を自動的にローテーションするプロセスが管理されます。また、GKE クラスタ間で単一のルート オブ トラストを提供します。
図 6 は、Anthos Service Mesh を使用して ID と認可を管理するアーキテクチャを示しています。
メッシュ内のサービスは、Workload Identity 連携を使用して Google Cloud サービスにアクセスできます。この機能により、サービスは Google Cloud APIs を呼び出すときに Google サービス アカウントの権限を使用して動作します。また、Workload Identity 連携を使用すると、他のクラウド プロバイダにインストールされているサービス メッシュが Google Cloud APIs にもアクセスできるようになります。
図 6. クラウド間でデプロイされたゼロトラスト サービス メッシュ。
Traffic Director を使用して、メッシュからオンプレミスまたは他のクラウドにトラフィックを転送できます。
たとえば、Traffic Director で on-prem-service と other-cloud-service というサービスを作成し、エンドポイント 10.1.0.1:80 と 10.2.0.1:80 を持つハイブリッド接続のネットワーク エンドポイント グループ（NEG）を追加できます。Traffic Director は、そのクライアント（アプリケーションとともに実行されるメッシュ サイドカー プロキシ）にトラフィックを送信します。つまりアプリケーションがリクエストを on-prem-service サービスに送信すると、Traffic Director クライアントがそのリクエストを検査し、10.0.0.1:80 エンドポイントに誘導します。図 7 は、この構成を示しています。
図 7. Traffic Director を使用してサービス メッシュからステアリングされたトラフィック。
図 8 に示すように、重みベースのトラフィック ステアリングなどの高度な機能を組み込むこともできます。この機能により、クラウドへの移行などの重要な企業ニーズに対応できます。Traffic Director は、サービス メッシュの多用途でグローバルに管理されるコントロール プレーンとして機能します。
図 8. Traffic Director を使用してステアリングされた重み付けトラフィック。
次のステップ
- 安全なクラウド内アクセスのためのネットワーク: リファレンス アーキテクチャ。
- インターネットに接続するアプリケーションの配信のためのネットワーキング: リファレンス アーキテクチャ
- Google Cloud への移行が、ワークロードを Google Cloud に移行するプロセスを計画、設計、実装する際に役立つ可能性があります。
- Google Cloud のランディング ゾーンの設計では、ランディング ゾーン ネットワークを作成するためのガイダンスを説明しています。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。