ゲート付き下り(外向き)ネットワーキング パターンのアーキテクチャは、オンプレミス環境または別のクラウド環境から、 Google Cloudにデプロイされたワークロードに特定の API を公開することをベースにしています。オンプレミス環境や他のクラウド環境から公共のインターネットに直接公開することなく、これを行うことができます。この制限された公開は、既存のワークロードのファサードとして機能する API ゲートウェイまたはプロキシ、またはロードバランサを介して容易に実現できます。API ゲートウェイ機能を、境界ネットワークなどの分離された境界ネットワーク セグメントにデプロイできます。
ゲート付き下り(外向き)ネットワーク パターンは、主に階層型アプリケーション アーキテクチャ パターンとパーティション分割されたアプリケーション アーキテクチャ パターンに適用されます(ただし、これらに限定されません)。内部ネットワーク内にバックエンド ワークロードをデプロイする場合、ゲート付き下り(外向き)ネットワーキングは、オンプレミス コンピューティング環境内で高いレベルのセキュリティを維持するのに役立ちます。このパターンでは、次の通信要件を満たすようにコンピューティング環境を接続する必要があります。
- Google Cloud にデプロイするワークロードは、内部 IP アドレスを使用して、アプリケーションを公開する API ゲートウェイまたはロードバランサ(または Private Service Connect エンドポイント)と通信できます。
- プライベート コンピューティング環境内の他のシステムに、 Google Cloud内から直接アクセスすることはできません。
- プライベート コンピューティング環境から Google Cloud にデプロイされたワークロードへの通信は許可されません。
- 他の環境のプライベート API へのトラフィックは、 Google Cloud 環境内からのみ開始されます。
このガイドでは、プライベート ハイブリッド ネットワークを介して接続されたハイブリッド環境とマルチクラウド環境について説明します。組織のセキュリティ要件で許可されている場合は、パブリック IP アドレスを持つリモート ターゲット API への API 呼び出しをインターネット経由で直接行うことができます。ただし、次のセキュリティ メカニズムを考慮する必要があります。
- Transport Layer Security(TLS)を備えた API OAuth 2.0。
- レート制限。
- 脅威保護ポリシー。
- API レイヤのバックエンドに構成された相互 TLS。
- 事前定義された API の送信元と宛先との通信のみを両側から許可するように構成された IP アドレス許可リスト フィルタリング。
API プロキシを保護するには、その他のセキュリティに関する考慮事項を検討してください。詳細については、Apigee を使用したアプリケーションと API の保護のベスト プラクティスをご覧ください。
アーキテクチャ
次の図は、前のセクションで説明した通信要件をサポートするリファレンス アーキテクチャを示しています。
上の図のデータフローは次のとおりです。
- Google Cloud 側では、ワークロードを Virtual Private Cloud(VPC)にデプロイできます。VPC は単一または複数(共有または非共有)にできます。デプロイは、組織のプロジェクトとリソース階層の設計に沿っている必要があります。
- Google Cloud 環境の VPC ネットワークは、他のコンピューティング環境に拡張されます。環境はオンプレミスでも、別のクラウドでも構いません。内部 IP アドレスを使用して環境間の通信を容易にするには、適切なハイブリッド マルチクラウド ネットワーキング接続を使用します。
特定の VPC IP アドレスから発信され、リモート ゲートウェイまたはロードバランサに宛てられたトラフィックを制限するには、IP アドレス許可リスト フィルタリングを使用します。ステートフル ファイアウォール ルールを使用すると、これらの接続からの戻りトラフィックが許可されます。次の機能の組み合わせを使用して、通信を保護し、許可された送信元 IP アドレスと宛先 IP アドレスに限定できます。
次世代ファイアウォール(NGFW)検査機能を備え、ネットワーク パスに配置されたネットワーク仮想アプライアンス(NVA)。
侵入防止サービス(IPS)を備えた Cloud Next Generation Firewall Enterprise。脅威防止のための詳細なパケット検査を実装します。
すべての環境は、重複のない RFC 1918 IP アドレス空間を共有します。
バリエーション
下り(外向き)ゲート型アーキテクチャ パターンを他のアプローチと組み合わせると、このパターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。
Google Cloud API Gateway とグローバル フロントエンドを使用する
この設計アプローチでは、API の公開と管理はGoogle Cloud内に存在します。上の図に示すように、Apigee を API プラットフォームとして実装することで、この要件を満たすことができます。リモート環境に API ゲートウェイまたはロードバランサをデプロイするかどうかは、特定のニーズと現在の構成によって異なります。Apigee には、接続をプロビジョニングする 2 つのオプションがあります。
- VPC ピアリングを使用
- VPC ピアリングを使用しない
Google Cloud のグローバル フロントエンド機能(Cloud Load Balancing、Cloud CDN(Cloud Interconnect 経由でアクセスする場合)、Cross-Cloud Interconnect など)により、オンプレミス環境や他のクラウド環境でホストされているバックエンドを持つアプリケーションにユーザーがアクセスする速度が向上します。
コンテンツ配信速度を最適化するには、 Google Cloud の PoP からアプリケーションを配信します。 Google Cloud の PoP は、世界中の 180 を超えるインターネット エクスチェンジと 160 を超える相互接続施設にあります。
Apigee と Cloud CDN を使用して次の処理を行う際に、POP が高パフォーマンスの API のデリバリーにどのように役立つかについては、YouTube で Apigee と Cloud CDN を使用した高パフォーマンス API のデリバリーをご覧ください。
- レイテンシを短縮します。
- API をグローバルにホストする。
- トラフィックのピーク時に可用性を高める。
上の図に示す設計例は、VPC ピアリングのない Private Service Connect に基づいています。
この設計のノースバウンド ネットワークは、次を介して確立されます。
- クライアント リクエストが終了するロードバランサ(図の LB)は、トラフィックを処理してから Private Service Connect バックエンドに転送します。
- Private Service Connect バックエンドを使用すると、 Google Cloud ロードバランサは、Private Service Connect ネットワーク エンドポイント グループ(NEG)を使用して、プロデューサー サービス アタッチメントに関連付けられた Private Service Connect 接続を介して、公開サービス(Apigee ランタイム インスタンス)にクライアント リクエストを送信できます。
サウスバウンド ネットワーキングは、次の方法で確立されます。
- お客様の VPC 内の内部ロードバランサ(図の ILB)に関連付けられたサービス アタッチメントを参照する Private Service Connect エンドポイント。
ILB は、ハイブリッド接続ネットワーク エンドポイント グループ(ハイブリッド接続 NEG)とともにデプロイされます。
ハイブリッド サービスには、VPN や Cloud Interconnect などのハイブリッド ネットワーク接続を介したハイブリッド接続 NEG を介してアクセスします。
詳細については、ハイブリッド接続でリージョン内部プロキシ ネットワーク ロードバランサを設定すると Private Service Connect のデプロイ パターンをご覧ください。
Private Service Connect を使用してリモート サービスを公開する
Private Service Connect オプションを使用すると、次のシナリオでリモート サービスを公開できます。
- API プラットフォームを使用していない、または次の理由で VPC ネットワーク全体を外部環境に直接接続したくない場合。
- セキュリティ上の制限やコンプライアンス要件がある。
- 合併や買収のシナリオなど、IP アドレス範囲が重複している。
- 期限が短い場合でも、環境全体のクライアント、アプリケーション、サービス間の安全な単方向通信を可能にします。
- 他の環境で公開されているサービスにアクセスするために、サービス プロデューサー VPC(トランジット VPC)を介して複数のコンシューマ VPC への接続を提供して、スケーラビリティの高いマルチテナントまたはシングルテナントのサービスモデルを提供することが必要になる場合があります。
API として使用されるアプリケーションに Private Service Connect を使用すると、公開されたアプリケーションに内部 IP アドレスが提供され、リージョン間で、またはハイブリッド接続を介してプライベート ネットワーク内で安全にアクセスできるようになります。この抽象化により、ハイブリッド接続モデルとマルチクラウド接続モデルを介して、さまざまなクラウドとオンプレミス環境のリソースを統合できます。Private Service Connect を使用してサービスを公開し、きめ細かいアクセス権を付与することで、アプリケーションの統合を加速し、オンプレミス環境または他のクラウド環境にあるアプリケーションを安全に公開できます。この場合は、次のオプションを使用できます。
- リージョン内部プロキシ ネットワーク ロードバランサまたは内部アプリケーション ロードバランサを参照するサービス アタッチメント。
- ロードバランサは、この設計でトランジット VPC として機能するプロデューサー VPC 内のハイブリッド ネットワーク エンドポイント グループ(ハイブリッド接続 NEG)を使用します。
上の図では、次の図に示すように、アプリケーションの VPC ネットワーク内のワークロードは、Private Service Connect エンドポイントを介して、オンプレミス環境または他のクラウド環境で実行されているハイブリッド サービスに到達できます。単方向通信用のこの設計オプションは、トランジット VPC へのピアリングの代替オプションです。
上の図の設計では、複数のフロントエンド、バックエンド、またはエンドポイントが同じサービス アタッチメントに接続できるため、複数の VPC ネットワークまたは複数のコンシューマーが同じサービスにアクセスできます。次の図に示すように、アプリケーションを複数の VPC からアクセスできるようにできます。このアクセス可能性は、IP アドレス範囲が重複していても、複数のコンシューマ VPC によってサービスが使用されるマルチテナント サービスのシナリオで役立ちます。
IP アドレスの重複は、異なる環境にあるアプリケーションを統合する際に発生する一般的な問題の 1 つです。次の図の Private Service Connect 接続は、IP アドレスの重複の問題を回避するのに役立ちます。IP アドレス変換を実行するために、Cloud NAT や NVA などの追加のネットワーキング コンポーネントをプロビジョニングまたは管理する必要はありません。構成例については、Private Service Connect を使用してハイブリッド サービスを公開するをご覧ください。
この設計には次のような利点があります。
- 共有スケーリング依存関係や大規模な複雑な管理を回避できます。
- きめ細かい接続制御によりセキュリティを強化します。
- サービスのプロデューサーとコンシューマ、リモート外部環境間の IP アドレスの調整が軽減されます。
上の図の設計アプローチは、後段階で拡張して、Private Service Connect オプションなど、前述のネットワーキング設計オプションを使用して、Apigee を API プラットフォームとして統合できます。
Private Service Connect のグローバル アクセスを使用して、他のリージョンから Private Service Connect エンドポイントにアクセスできるようにします。
Private Service Connect エンドポイントに接続するクライアントは、エンドポイントと同じリージョンまたは別のリージョンに配置できます。このアプローチは、複数のリージョンにホストされているサービスに高可用性を提供したり、単一リージョンで利用可能なサービスに他のリージョンからアクセスしたりするために使用できます。他のリージョンでホストされているリソースから Private Service Connect エンドポイントにアクセスする場合、グローバル アクセスが有効なエンドポイントに宛てられたトラフィックにリージョン間アウトバウンド料金が適用されます。
ベスト プラクティス
- API プラットフォーム ソリューションとして Apigee と Apigee ハイブリッドを検討すると、いくつかのメリットがあります。Apigee は、バックエンド サービス API のプロキシレイヤと抽象化またはファサードを提供し、セキュリティ機能、レート制限、割り当て、分析を組み合わせて提供します。
- 要件とアーキテクチャに該当する場合は、Kubernetes を使用した Apigee Hybrid のデプロイ アーキテクチャで Apigee Adapter for Envoy を使用します。
- Google Cloud の VPC とプロジェクトの設計は、リソース階層と安全な通信モデルの要件に基づく必要があります。
- API Gateway を使用する API の場合は、IP アドレスの許可リストも使用する必要があります。許可リストを使用すると、異なる環境でホストされている可能性のある API コンシューマと API ゲートウェイの特定の IP アドレスの送信元と宛先への通信を制限できます。
- VPC ファイアウォール ルールまたはファイアウォール ポリシーを使用して、Private Service Connect エンドポイントを介して Private Service Connect リソースへのアクセスを制御します。
- アプリケーションがアプリケーション ロードバランサを介して外部に公開されている場合は、DDoS 攻撃とアプリケーション レイヤのセキュリティ脅威から保護するために、追加のセキュリティ レイヤとして Google Cloud Armor の使用を検討してください。
インスタンスにインターネット アクセスが必要な場合は、アプリケーション(コンシューマ)VPC で Cloud NAT を使用して、ワークロードがインターネットにアクセスできるようにします。これにより、API ゲートウェイまたはロードバランサの背後にデプロイされているシステムで、外部パブリック IP アドレスを持つ VM インスタンスを割り当てることを回避できます。
- アウトバウンド ウェブ トラフィックには、 Google Cloudの Secure Web Proxy を使用できます。このプロキシにはいくつかのメリットがあります。
ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認してください。