メッシュ パターンは、ハイブリッド ネットワーク アーキテクチャの確立に基づいています。このアーキテクチャは複数のコンピューティング環境にまたがっており、こうした環境ではすべてのシステムが相互に通信できます。アプリケーションのセキュリティ要件に応じて、システムが一方向通信に制限されることはありません。このネットワーク パターンは主に、階層型ハイブリッド アーキテクチャ、パーティション分割されたマルチクラウド アーキテクチャ、バースト アーキテクチャに適用されます。また、Google Cloud に障害復旧（DR）環境をプロビジョニングするために、ビジネス継続性の設計に適用することもできます。いずれの場合も、次の通信要件に沿ってコンピューティング環境を接続する必要があります。
- RFC 1918 のプライベート IP アドレスを使用して、ワークロードが環境の境界を越えて相互に通信できること。
- どちら側からでも通信を開始できること。通信モデルの詳細は、後述の設計オプションで説明する通信モデルなど、アプリケーションとセキュリティ要件によって異なる場合があります。
- パターンが設計されるアプリケーションの要件に基づき、使用するファイアウォール ルールで特定の IP アドレスの送信元と宛先間のトラフィックを許可すること。理想的には、多層セキュリティ アプローチを使用して、コンピューティング環境間とコンピューティング環境内で行われるトラフィック フローをきめ細かく制限します。
アーキテクチャ
次の図は、メッシュ パターンのリファレンス アーキテクチャの概要を示しています。
- すべての環境で、重複のない RFC 1918 IP アドレス空間を使用する必要があります。
- Google Cloud 側では、ワークロードを 1 つまたは複数の共有 VPC または非共有 VPC にデプロイできます。このパターンの他の設計オプションについては、以下の設計バリエーションをご覧ください。選択した VPC 構造は、組織のプロジェクトとリソース階層の設計に沿っている必要があります。
- Google Cloud の VPC ネットワークは、他のコンピューティング環境に拡張できます。オンプレミスの環境でも、別のクラウド内の環境でも構いません。ビジネスとアプリケーションの要件に応じて、ハイブリッド クラウドとマルチクラウドのネットワーキング接続オプションのいずれかを使用してください。
送信元と宛先の許可された IP アドレスに通信を限定します。次のいずれかの機能を使用するか、複数の機能を組み合わせて使用します。
次世代ファイアウォール（NGFW）検査機能を備え、ネットワーク パスに配置されたネットワーク仮想アプライアンス（NVA）。
侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise。ネットワークの設計やルーティングを変更せずに、脅威防止のための詳細なパケット検査を実装します。
バリエーション
メッシュ型アーキテクチャ パターンを他のアプローチと組み合わせると、パターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。次のセクションでは、パターンのオプションについて説明します。
環境ごとに 1 つの VPC
環境ごとに 1 つの VPC のオプションを検討する一般的な理由は次のとおりです。
- クラウド環境では、組織のリソース階層の設計に沿って、VPC ネットワークとリソースをネットワーク レベルで分離する必要があります。管理ドメインの分離が必要な場合は、このオプションと一緒に、環境ごとに個別のプロジェクトを使用することもできます。
- 共通ネットワーク内のネットワーク リソースを一元管理し、異なる環境間でネットワークを分離するには、Google Cloud にある開発環境、テスト環境、本番環境といった各環境の共有 VPC ネットワークを使用します。
- 単一の VPC またはプロジェクトの VPC 割り当てを超えるスケーリング要件があることがあります。
次の図に示すように、環境ごとに 1 つの VPC を使用する設計では、VPN を使用するか、複数の VLAN アタッチメントを備えた Cloud Interconnect を使用して、各 VPC をオンプレミス環境または他のクラウド環境に直接統合できます。
上の図に示されているパターンは、ランディング ゾーンのハブアンドスポーク ネットワーク トポロジに適用できます。このトポロジでは、1 つ（または複数）のハイブリッド接続をすべてのスポーク VPC と共有できます。この共有は、トランジット VPC を使用してハイブリッド接続と他のスポーク VPC の両方を終端することで行われます。次のセクション「一元化されたアプリケーション レイヤ ファイアウォールを使用する」で説明されているように、次世代ファイアウォール（NGFW）検査機能を備えた NVA をトランジット VPC に追加して、この設計を拡張することもできます。
一元化されたアプリケーション レイヤ ファイアウォールを使用する
技術要件により、Cloud Next Generation Firewall の機能を超える高度なファイアウォール機能によるアプリケーション レイヤ（レイヤ 7）と詳細なパケット検査が必要な場合は、NVA でホストされている NGFW アプライアンスを使用できます。ただし、この NVA は組織のセキュリティ要件を満たしている必要があります。これらのメカニズムを実装するには、次の図に示すように、すべてのクロス環境トラフィックが一元化された NVA ファイアウォールを通過するようにトポロジを拡張します。
一元管理されたアプライアンスを使用するハブアンドスポーク トポロジを使用すると、次の図のパターンをランディング ゾーン設計に適用できます。
上の図に示すように、NVA は境界セキュリティ レイヤとして機能し、インライン トラフィック検査を有効にするための基盤の役割を果たします。また、厳格なアクセス制御ポリシーも適用されます。east-west と north-south の両方のトラフィック フローを検査するために、一元化された NVA の設計には、セキュリティ アクセス制御のレベルが異なる複数のセグメントが含まれる場合があります。
マイクロサービス ゼロトラスト分散型アーキテクチャ
コンテナ化されたアプリケーションを使用する場合、ミラーリング パターンのセクションで説明されているマイクロサービス ゼロトラスト分散型アーキテクチャも、このアーキテクチャ パターンに適用できます。
このパターンがミラーリング パターンと大きく異なる点は、Google Cloud のワークロードと他の環境のワークロード間の通信モデルをどちら側からでも開始できることです。サービス メッシュ を使用して、アプリケーション要件とセキュリティ要件に基づいてトラフィックをきめ細かく制御する必要があります。
メッシュ パターンのベスト プラクティス
- 他の操作を行う前に、リソース階層の設計と、プロジェクトおよび VPC をサポートするために必要な設計を決定します。これにより、Google Cloud プロジェクトの構造に沿った最適なネットワーキング アーキテクチャを選択できます。
- プライベート コンピューティング環境と Google Cloud 内で Kubernetes を使用する場合は、ゼロトラスト分散型アーキテクチャを使用します。
- 一元化された NVA を設計で使用する場合は、セキュリティ アクセス制御とトラフィック検査ポリシーのレベルが異なる複数のセグメントを定義する必要があります。これらの制御とポリシーは、アプリケーションのセキュリティ要件に基づいて決定します。
- NVA を含むソリューションを設計する際は、すべての通信をブロックする可能性のある単一障害点を回避するために、NVA の高可用性（HA）を考慮することが重要です。NVA の供給元である Google Cloud セキュリティ ベンダーが提供する、HA と冗長性の設計と実装に関するガイダンスに従ってください。
- プライバシー、データの整合性、制御された通信モデルを強化するために、エンドツーエンドの mTLS が備わっている Apigee や Apigee ハイブリッド などの API ゲートウェイを使用して、API を介してアプリケーションを公開します。同じ組織リソースで、Apigee による共有 VPC を使用することもできます。
- ソリューションの設計の要件として、Google Cloud ベースのアプリケーションを公共のインターネットに公開する必要がある場合は、インターネットに接続するアプリケーションの配信のためのネットワーキングで紹介している設計推奨事項を検討してください。
- プロジェクト内の Google Cloud サービスを保護してデータ漏洩のリスクを軽減するために、VPC Service Controls を使用して、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定します。また、承認済みの VPN または Cloud Interconnect 経由でハイブリッド環境にサービス境界を拡張することもできます。サービス境界の利点については、VPC Service Controls の概要をご覧ください。
- ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認します。
Google Cloud でホストされているアプリケーションと他の環境のアプリケーションの間で、より厳密な分離ときめ細かいアクセスを適用する場合は、このシリーズの他のドキュメントで説明しているゲートパターンの使用を検討してください。