ミラーリング パターンは、特定の既存の環境の設計を新しい環境に複製することを前提としています。そのため、このパターンは主に、環境ハイブリッド パターンに従うアーキテクチャに適用されます。このパターンでは、ある環境で開発ワークロードとテスト ワークロードを実行し、別の環境でステージング ワークロードと本番環境ワークロードを実行します。
ミラーリング パターンでは、テスト ワークロードと本番環境ワークロードが互いに直接通信しないことが前提とされています。ただし、両方のワークロードのグループを一貫した方法で管理およびデプロイすることは可能です。
このパターンを使用する場合は、次の要件を満たすように 2 つのコンピューティング環境を接続します。
- 継続的インテグレーション / 継続的デプロイ（CI / CD）により、すべてのコンピューティング環境または特定の環境でワークロードをデプロイおよび管理できる。
- モニタリング、構成管理、その他の管理システムは、コンピューティング環境全体で機能する。
- ワークロードはコンピューティング環境をまたいで直接通信できない。必要に応じて、通信はきめ細かく制御される。
アーキテクチャ
次のアーキテクチャ図は、CI / CD、モニタリング、構成管理、その他の管理システム、ワークロード通信をサポートするこのパターンのリファレンス アーキテクチャの概要を示しています。
上に示した図のアーキテクチャの説明は次のとおりです。
- ワークロードは、機能環境（開発、テスト、CI / CD、管理ツール）に基づいて、Google Cloud 側の個別の VPC に分散されます。
- 共有 VPC は、ワークロードの開発とテストに使用されます。CI / CD と管理ツールには、追加の VPC が使用されます。共有 VPC の場合:
- アプリケーションは、環境とサービス プロジェクトごとに異なるチームによって管理されます。
- ホスト プロジェクトは、開発環境とテスト環境間、および VPC の外部とのネットワーク通信とセキュリティ管理を制御します。
- CI / CD VPC は、プライベート コンピューティング環境で本番環境ワークロードを実行しているネットワークに接続されます。
- ファイアウォール ルールは、許可されたトラフィックのみを許可します。
- 侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise を使用して、設計やルーティングを変更せずに、脅威防止のための詳細なパケット検査を実装することもできます。Cloud Next Generation Firewall Enterprise は、パケット インターセプト テクノロジーを使用して、構成された脅威シグネチャを使用してワークロードを透過的に検査する Google 管理のゾーン ファイアウォール エンドポイントを作成します。また、ワークロードを脅威から保護します。
- 内部 IP アドレスを使用してピアリングされた VPC 間の通信を有効にします。
- このパターンのピアリングにより、CI / CD と管理システムは、開発ワークロードとテスト ワークロードをデプロイして管理できます。
- 一般的なベスト プラクティスを検討してください。
この CI / CD 接続を確立するには、ビジネスとアプリケーションの要件を満たす、前述のハイブリッド クラウドとマルチクラウドのネットワーキング接続オプションのいずれかを使用します。本番環境ワークロードをデプロイして管理できるように、この接続により、さまざまなコンピューティング環境間でプライベート ネットワークのネットワーク到達性が提供されます。すべての環境で、重複のない RFC 1918 IP アドレス空間を使用する必要があります。
開発環境とテスト環境のインスタンスにインターネット アクセスが必要な場合は、次のオプションを検討してください。
- Cloud NAT は、同じ共有 VPC ホスト プロジェクト ネットワークにデプロイできます。同じ共有 VPC ホスト プロジェクト ネットワークにデプロイすると、これらのインスタンスにインターネットから直接アクセスできなくなります。
- アウトバウンド ウェブ トラフィックには、Secure Web Proxy を使用できます。このプロキシにはいくつかのメリットがあります。
Google Cloud とハイブリッド環境やマルチクラウド環境での構築、テスト、デプロイに役立つ Google Cloud のツールと機能の詳細については、Google Cloud 上での DevOps と CI / CD についてのブログをご覧ください。
バリエーション
すべての通信要件を考慮しながら、さまざまな設計要件を満たすために、ミラーリング アーキテクチャ パターンでは次のオプションが提供されます。これらのオプションについては、以下のセクションで説明します。
環境あたりの共有 VPC
環境あたりの共有 VPC の設計オプションを使用すると、環境間でアプリケーションまたはサービスレベルを分離できます。たとえば、特定の組織のセキュリティ要件を満たすために必要な CI / CD や管理ツールを分離できます。これらの要件により、さまざまなサービス間の通信、管理ドメイン、アクセス制御が制限され、これらのサービスは異なるチームによって管理される必要があります。
この設計で分離を実現するには、異なる環境間でネットワーク レベルとプロジェクト レベルの分離を行います。これにより、よりきめ細かい通信と Identity and Access Management（IAM）アクセス制御が可能になります。
管理と運用の観点から、この設計により、環境ごとに、サービス プロジェクトごとに、さまざまなチームによって作成されたアプリケーションとワークロードを柔軟に管理できます。VPC ネットワーキングとそのセキュリティ機能は、次の可能な構造に基づいてネットワーク オペレーション チームによってプロビジョニングおよび管理できます。
- 1 つのチームがすべての環境のすべてのホスト プロジェクトを管理する。
- 各チームがそれぞれの環境でホスト プロジェクトを管理する。
ホスト プロジェクトの管理に関する決定は、各チームのチーム構造、セキュリティ運用、アクセス要件に基づいて行う必要があります。この設計バリエーションを、各環境の共有 VPC ネットワークのランディング ゾーン設計オプションに適用できます。ただし、ハイブリッド ネットワークを介した通信など、異なる環境間で許可される通信を定義するには、ミラーリング パターンの通信要件を考慮する必要があります。
次の図に示すように、メイン環境ごとに共有 VPC ネットワークをプロビジョニングすることもできます。
一元化されたアプリケーション レイヤ ファイアウォール
シナリオによっては、セキュリティ要件により、Cloud Next Generation Firewall の機能を超える高度なファイアウォール メカニズムを使用して、アプリケーション レイヤ（レイヤ 7）と詳細なパケット検査を検討することが義務付けられる場合があります。組織のセキュリティ要件と標準を満たすには、ネットワーク仮想アプライアンス（NVA）にホストされている NGFW アプライアンスを使用できます。Google Cloud の複数のセキュリティ パートナーが、このタスクに適したオプションを提供しています。
次の図に示すように、複数のネットワーク インターフェースを使用して、Virtual Private Cloud とプライベート コンピューティング環境の間のネットワーク パスに NVA を配置できます。
この設計は、次の図に示すように、複数の共有 VPC でも使用できます。
この設計の NVA は、境界セキュリティ レイヤとして機能します。また、インライン トラフィック検査を有効にして、厳格なアクセス制御ポリシーを適用するための基盤としても機能します。
VPC ファイアウォール ルールと侵入防止サービス機能を含む堅牢な多層セキュリティ戦略では、East-West と North-South の両方のトラフィック フローに、より詳細なトラフィック検査とセキュリティ制御を含めます。
ハブアンドスポーク トポロジ
別の設計バリエーションとして、開発とさまざまなテストの段階で別々の VPC（共有 VPC を含む）を使用する方法もあります。このバリエーションでは、次の図に示すように、すべてのステージ環境がハブアンドスポーク アーキテクチャで CI / CD と管理 VPC に接続します。各環境で管理ドメインと関数を分離する必要がある場合は、このオプションを使用します。ハブアンドスポーク通信モデルは、次の要件に役立ちます。
- アプリケーションは、モニタリング、構成管理ツール、CI / CD、認証などの一般的なサービスセットにアクセスする必要があります。
- 共通のセキュリティ ポリシー セットを、ハブを介して一元的にインバウンド トラフィックとアウトバウンド トラフィックに適用する必要があります。
ハブアンドスポーク設計オプションの詳細については、一元管理されたアプライアンスを使用したハブアンドスポーク トポロジと一元管理されたアプライアンスを使用しないハブアンドスポーク トポロジをご覧ください。
上の図に示すように、VPC 間の通信とハイブリッド接続はすべてハブ VPC を通過します。このパターンでは、接続要件に合わせてハブ VPC での通信を制御して制限できます。
ハブアンドスポーク ネットワーク アーキテクチャの一部として、Google Cloud では、スポークとハブ VPC 間の接続オプションとして次のオプションが提供されています。
- VPC ネットワーク ピアリング
- VPN
- ネットワーク仮想アプライアンス（NVA）の使用
- 複数のネットワーク インターフェースの使用
- Network Connectivity Center（NCC）の使用
設計で検討する必要があるオプションの詳細については、ハブアンドスポーク ネットワーク アーキテクチャをご覧ください。スポークとハブ VPC 間の VPC ピアリングで VPN を選択する際の重要な要因は、トラフィックの推移性が必要な場合です。トラフィックの推移性は、スポークからのトラフィックがハブを介して他のスポークに到達できることを意味します。
マイクロサービス ゼロトラスト分散型アーキテクチャ
ハイブリッド アーキテクチャとマルチクラウド アーキテクチャでは、本番環境を開発環境やテスト環境から分離するなど、技術的およびビジネス上の目標を達成するために、複数のクラスタが必要になる場合があります。そのため、ネットワーク境界セキュリティ制御は重要です。特に、特定のセキュリティ要件に準拠する必要がある場合は重要です。
現在のクラウドファースト分散マイクロサービス アーキテクチャのセキュリティ要件を満たすだけでは不十分です。ゼロトラスト分散型アーキテクチャも検討する必要があります。マイクロサービス ゼロトラスト分散型アーキテクチャは、マイクロサービス レベルのセキュリティ ポリシーの適用、認証、Workload Identity を使用してマイクロサービス アーキテクチャをサポートします。信頼は ID ベースであり、各サービスに適用されます。
サービス メッシュなどの分散プロキシ アーキテクチャを使用すると、サービスは呼び出し元を効果的に検証し、リクエストごとにきめ細かいアクセス制御ポリシーを実装できるため、より安全でスケーラブルなマイクロサービス環境を実現できます。Cloud Service Mesh を使用すると、Google Cloud とオンプレミス デプロイにまたがる共通のメッシュをフレキシブルに利用できるようになります。メッシュは、認可ポリシーを使用してサービス間通信を保護します。
このアーキテクチャに、Kubernetes クラスタ内の軽量な Apigee API ゲートウェイ デプロイである Apigee Adapter for Envoy を組み込むこともできます。Apigee Adapter for Envoy は、クラウド ファースト アプリケーション用に設計されたオープンソースのエッジおよびサービス プロキシです。
このトピックの詳細については、以下の記事をご覧ください。
- ゼロトラスト分散型アーキテクチャ
- GKE Enterprise ハイブリッド環境
- Google に接続する
- オンプレミス GKE Enterprise クラスタを Google Cloud ネットワークに接続します。
- マルチクラウドまたはハイブリッド メッシュを設定する
- 環境とクラスタに Cloud Service Mesh をデプロイします。
ミラーリング パターンのベスト プラクティス
- 本番環境のデプロイまたは再構成に必要な CI / CD システムは、高可用性である必要があります。つまり、すべてのアーキテクチャ コンポーネントが、想定されるレベルのシステム可用性を実現するように設計されている必要があります。詳細については、Google Cloud インフラストラクチャの信頼性をご覧ください。
- コードの更新などの繰り返しのプロセスで構成エラーを排除するには、ビルド、テスト、デプロイを標準化するために自動化が不可欠です。自動化する際にさまざまなチェックとガードを使用する方法については、デプロイを自動化するをご覧ください。
- この設計で一元化された NVA を統合するには、セキュリティ アクセス制御のレベルが異なる複数のセグメントを組み込む必要がある場合があります。
- NVA を含むソリューションを設計する際は、すべての通信をブロックする可能性のある単一障害点を回避するために、NVA の高可用性（HA）を考慮することが重要です。NVA ベンダーが提供する HA と冗長性の設計と実装のガイダンスに従ってください。
- VPC ピアリングまたは VPN を介してオンプレミス IP ルートを開発とテストの VPC にエクスポートしないようにすることで、開発環境とテスト環境からオンプレミス環境へのネットワーク到達性を制限できます。詳細については、VPC ネットワーク ピアリングでのカスタムルートの交換をご覧ください。
- Google API のアクセスを必要とする可能性のあるプライベート IP アドレスを持つワークロードの場合、VPC ネットワーク内の Private Service Connect エンドポイントを使用して Google API を公開できます。詳細については、このシリーズの上り（内向き）ゲート型をご覧ください。
- ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンに関する一般的なおすすめの方法を確認します。