下り(外向き)ゲート型と上り(内向き)ゲート型

Last reviewed 2023-12-14 UTC

下り(外向き)ゲート型と上り(内向き)ゲート型パターンは、ワークロード間で選択した API を双方向に使用することが求められるシナリオで、下り(外向き)ゲート型と上り(内向き)ゲート型を組み合わせて使用します。ワークロードは、 Google Cloud、プライベート オンプレミス環境、または他のクラウド環境で実行できます。このパターンでは、API ゲートウェイ、Private Service Connect エンドポイント、またはロードバランサを使用して特定の API を公開し、必要に応じて認証、認可、API 呼び出し監査を提供できます。

このパターンとメッシュ パターンの主な違いは、特定の IP アドレスの送信元と宛先との双方向 API の使用または通信のみを必要とするシナリオに適用されることです。たとえば、Private Service Connect エンドポイントを介して公開されるアプリケーションなどです。通信は公開 API または特定の IP アドレスに制限されるため、環境間のネットワークを設計で調整する必要はありません。一般的な適用シナリオには、次のものがあります(ただしこれらに限定されません)。

  • 合併、買収。
  • パートナーとのアプリケーション統合。
  • 組織のアプリケーションとサービスと、独自のアプリケーションを管理し、異なる環境でホストする異なる組織部門との統合。

通信は次のように機能します。

  • Google Cloud にデプロイするワークロードは、内部 IP アドレスを使用して API ゲートウェイ(または特定の宛先 IP アドレス)と通信できます。プライベート コンピューティング環境内にデプロイされた他のシステムにはアクセスできません。
  • 逆に、他のコンピューティング環境にデプロイするワークロードは、内部 IP アドレスを使用して、 Google Cloud側の API ゲートウェイ(または特定の公開エンドポイント IP アドレス)と通信できます。 Google Cloud にデプロイされた他のシステムにはアクセスできません。

アーキテクチャ

次の図は、下り(外向き)ゲート型と上り(内向き)ゲート型のパターンのリファレンス アーキテクチャを示しています。

 Google Cloud とオンプレミスまたは他のクラウド ネットワーク間のデータの下り(外向き)と上り(内向き)。

上の図の設計アプローチには、次の要素があります。

  • Google Cloud 側では、ワークロードを VPC(または共有 VPC)にデプロイし、インターネットに直接公開しません。
  • Google Cloud 環境ネットワークは、他のコンピューティング環境に拡張されます。この環境は、オンプレミスでも別のクラウドでも構いません。環境を拡張するには、適切なハイブリッド接続とマルチクラウド接続の通信パターンを使用して、環境間の通信を容易にし、内部 IP アドレスを使用できるようにします。
  • 必要に応じて、特定のターゲット IP アドレスへのアクセスを有効にして、トランジット VPC を使用してアプリケーション VPC の外部に境界セキュリティ レイヤを追加できます。
    • トランジット VPC で次世代ファイアウォール(NGFW)を備えた Cloud Next Generation Firewall またはネットワーク仮想アプライアンス(NVA)を使用すると、トラフィックを検査し、アプリケーション VPC に到達する前に特定のソースからの特定の API へのアクセスを許可または禁止できます。
  • API ゲートウェイまたはロードバランサを介して API にアクセスし、プロキシレイヤとサービス API の抽象化またはファサードを提供する必要があります。
  • API として使用されるアプリケーションの場合は、Private Service Connect を使用して公開アプリケーションの内部 IP アドレスを指定することもできます。
  • すべての環境で、重複のない RFC 1918 IP アドレス空間を使用します。

このパターンの一般的なアプリケーションでは、アプリケーション バックエンド(またはアプリケーション バックエンドのサブセット)を Google Cloud にデプロイし、他のバックエンド コンポーネントとフロントエンド コンポーネントをオンプレミス環境または他のクラウドにホストします(階層型ハイブリッド パターンまたはパーティショニングされたマルチクラウド パターン)。アプリケーションが進化し、クラウドに移行するにつれて、特定のクラウド サービスに対する依存関係と優先順位がしばしば生じます。

これらの依存関係と設定により、アプリケーションとバックエンドが複数のクラウド プロバイダに分散されることがあります。また、一部のアプリケーションは、オンプレミス環境と複数のクラウド環境に分散されたリソースとサービスの組み合わせで構築される場合があります。

分散アプリケーションの場合、外部 Cloud Load Balancing のハイブリッド接続とマルチクラウド接続機能を使用して、ユーザー リクエストを終了し、他の環境のフロントエンドまたはバックエンドに転送できます。このルーティングは、次の図に示すように、ハイブリッド ネットワーク接続を介して行われます。この統合により、さまざまな環境にアプリケーション コンポーネントを段階的に分散できます。 Google Cloud でホストされているフロントエンド サービスからバックエンド サービスへのリクエストは、内部ロードバランサ(図の ILB)によって確立されたハイブリッド ネットワーク接続を介して安全に通信します。

オンプレミス環境または他のクラウド環境のアプリケーション フロントエンドと、 Google Cloud 環境のアプリケーション バックエンドとの間でデータが送受信されます。データは、 Google Cloudの内部ロードバランサ(ILB)を経由します。

上の図の Google Cloud 設計を使用すると、次のことが可能になります。

  • このパターンの通信モデルに沿って、両側で事前定義された API を使用して、 Google Cloud、オンプレミス、その他のクラウド環境間の双方向通信を容易にします。
  • 分散アプリケーション コンポーネント(フロントエンドまたはバックエンド)を使用してインターネットに接続するアプリケーションのグローバル フロントエンドを提供し、次の目標を達成するには、ポイント オブ プレゼンス(PoP)に分散された Google Cloud の高度なロード バランシングとセキュリティ機能を使用します。
  • サーバーレス マネージド サービスを使用して、資本費用を削減し、運用を簡素化します。
  • 速度とレイテンシを最適化するために、アプリケーション バックエンドへの接続をグローバルに最適化します。
    • Google Cloudの Cross-Cloud Network を使用すると、最適なプライベート接続を介してアプリケーション コンポーネント間のマルチクラウド通信を実現できます。
  • 需要の高い静的コンテンツをキャッシュに保存し、Cloud CDN へのアクセスを提供することで、グローバル Cloud Load Balancing を使用するアプリケーションのアプリケーション パフォーマンスを向上させます。
  • グローバルに分散されたウェブ アプリケーション ファイアウォール(WAF)と DDoS 軽減サービスを提供する Google Cloud Armor 機能を使用して、インターネットに接続するアプリケーションのグローバル フロントエンドを保護します。
  • 必要に応じて、Private Service Connect を設計に組み込むことができます。これにより、パブリック インターネットを経由せずに、 Google Cloud サービス API または他の環境から公開されたサービスへの非公開のきめ細かいアクセスが可能になります。

バリエーション

下り(外向き)ゲート型と上り(内向き)ゲート型アーキテクチャ パターンを他のアプローチと組み合わせると、このパターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。

分散 API ゲートウェイ

パーティション分割されたマルチクラウド パターンに基づくシナリオなどでは、アプリケーション(またはアプリケーション コンポーネント)をさまざまなクラウド環境(プライベート オンプレミス環境を含む)に構築できます。一般的な要件は、クライアント リクエストをアプリケーション フロントエンドから、アプリケーション(またはフロントエンド コンポーネント)がホストされている環境に直接転送することです。この種の通信には、ローカル ロードバランサまたは API ゲートウェイが必要です。これらのアプリケーションとそのコンポーネントには、統合に特定の API プラットフォーム機能が必要になる場合があります。

次の図は、Apigee と Apigee ハイブリッドが、各環境にローカライズされた API ゲートウェイを使用してこのような要件に対処するように設計されていることを示しています。API プラットフォームの管理は、 Google Cloudに集中しています。この設計により、事前承認済みの IP アドレス(ターゲット API と宛先 API、または Private Service Connect エンドポイント IP アドレス)のみが、 Google Cloud と他の環境の間で通信できる厳格なアクセス制御対策を適用できます。

オンプレミス環境または他のクラウド環境と Google Cloud 環境との間でデータが送受信されます。アプリケーション フロントエンドへのクライアント リクエストは、アプリケーション(またはフロントエンド コンポーネント)がホストされている環境に直接送信されます。

次のリストに、Apigee API ゲートウェイを使用する上記の図の 2 つの異なる通信パスを示します。

  • クライアント リクエストは、アプリケーション(またはフロントエンド コンポーネント)をホストする環境でアプリケーション フロントエンドに直接到達します。
  • 各環境内の API ゲートウェイとプロキシは、複数の環境間で異なる方向のクライアントとアプリケーションの API リクエストを処理します。
    • Google Cloud(Apigee)の API ゲートウェイ機能は、 Google Cloudでホストされているアプリケーション(フロントエンドまたはバックエンド)コンポーネントを公開します。
    • 別の環境(ハイブリッド)の API ゲートウェイ機能は、その環境でホストされているアプリケーション フロントエンド(またはバックエンド)コンポーネントを公開します。

必要に応じて、トランジット VPC の使用を検討してください。トランジット VPC を使用すると、懸念事項を分離し、別の VPC ネットワークでセキュリティ検査とハイブリッド接続を実行できます。IP アドレスの到達性の観点から、トランジット VPC(ハイブリッド接続が接続されている VPC)は、エンドツーエンドの到達性を維持するための次の要件を容易にします。

  • ターゲット API の IP アドレスは、クライアント/リクエスト元がホストされている他の環境にアドバタイズする必要があります。
  • ターゲット API と通信する必要があるホストの IP アドレスは、ターゲット API が存在する環境にアドバタイズする必要があります(API リクエスト元(クライアント)の IP アドレスなど)。例外は、ロードバランサ、プロキシ、Private Service Connect エンドポイント、NAT インスタンス経由で通信が行われる場合です。

リモート環境への接続を拡張するために、この設計ではカスタマー ルート交換機能を使用してダイレクト VPC ピアリングを使用します。この設計により、 Google Cloud アプリケーション VPC 内でホストされているワークロードから発信された特定の API リクエストを、トランジット VPC 経由で転送できます。または、トランジット VPC 内のハイブリッド ネットワーク エンドポイント グループ バックエンドを持つロードバランサに関連付けられている、アプリケーション VPC 内の Private Service Connect エンドポイントを使用することもできます。この設定については、次のセクションの Private Service Connect を使用した双方向 API 通信で説明します。

Private Service Connect を使用した双方向 API 通信

企業が API ゲートウェイ(Apigee など)をすぐに使用する必要がない、または後で追加することを希望する場合もあります。ただし、異なる環境の特定のアプリケーション間の通信と統合を有効にするというビジネス要件がある場合があります。たとえば、会社が別の会社を買収した場合、その会社に特定のアプリケーションを公開する必要がある場合があります。アプリケーションを会社に公開する必要がある場合があります。両社は、それぞれ異なる環境(Google Cloud、オンプレミス、または他のクラウド)に独自のワークロードをホストしている可能性があり、IP アドレスの重複を回避する必要があります。このような場合は、Private Service Connect を使用して効果的な通信を促進できます。

API として使用されるアプリケーションの場合は、Private Service Connect を使用して公開アプリケーションにプライベート アドレスを提供することもできます。これにより、リージョン間で、またはハイブリッド接続を介して、プライベート ネットワーク内で安全にアクセスできます。この抽象化により、ハイブリッド接続モデルとマルチクラウド接続モデルを介して、さまざまなクラウドとオンプレミス環境のリソースを統合できます。また、マルチクラウド環境とオンプレミス環境全体でアプリケーションをアセンブルすることもできます。これにより、API ゲートウェイが使用されていない、または使用が予定されていない安全なアプリケーションを統合するなど、さまざまな通信要件を満たすことができます。

次の図に示すように、Cloud Load Balancing で Private Service Connect を使用すると、2 つの異なる通信パスを実現できます。各パスは、個別の接続目的で異なる方向から開始されます(理想的には API 呼び出しを介して開始します)。

  • このガイドで説明する Private Service Connect の設計上の考慮事項と推奨事項はすべて、この設計に適用されます。
  • 追加のレイヤ 7 検査が必要な場合は、この設計(トランジット VPC で)に NVA を統合できます。
  • この設計は、API ゲートウェイの有無にかかわらず使用できます。

オンプレミス環境または他のクラウド環境と Google Cloud 環境は、さまざまなパス、さまざまなロードバランサ、VPC エンドポイント、サブネットを介してデータを通信します。

上の図に示す 2 つの接続パスは独立した接続を表しており、単一の接続またはフローの双方向通信を表していません。

Private Service Connect エンドポイントとインターフェースを使用した双方向通信

ゲートされた上り(内向き)パターンで説明したように、クライアント サービス通信を有効にするオプションの 1 つは、Private Service Connect エンドポイントを使用して、プロデューサー VPC 内のサービスをコンシューマ VPC に公開することです。この接続は、ハイブリッド接続を介してオンプレミス環境や別のクラウド プロバイダ環境に拡張できます。ただし、シナリオによっては、ホストされたサービスで非公開の通信が必要になることもあります。

コンシューマ VPC 内または外部でホストできるデータソースからデータを取得するなど、特定のサービスにアクセスする場合、このプライベート通信は、アプリケーション(プロデューサー)VPC とリモート環境(オンプレミス環境など)の間で行うことができます。

このようなシナリオでは、Private Service Connect インターフェースにより、サービス プロデューサーの VM インスタンスがコンシューマのネットワークにアクセスできます。これは、プロデューサーとコンシューマーのロールが分離されている状態を維持しながら、ネットワーク インターフェースを共有することで行われます。コンシューマー VPC のこのネットワーク インターフェースを使用すると、アプリケーション VM は、コンシューマー リソースがプロデューサー VPC 内にローカルに存在しているかのように、コンシューマー リソースにアクセスできます。

Private Service Connect インターフェースは、コンシューマ(トランジット)VPC に接続されたネットワーク インターフェースです。Private Service Connect インターフェースが接続されているコンシューマ(トランジット)VPC から到達可能な外部宛先に到達できます。したがって、この接続は、次の図に示すように、オンプレミス環境などのハイブリッド接続を介して外部環境に拡張できます。

 Google Cloud のアプリケーションと、オンプレミスまたは他のクラウド ネットワーク内のワークロード間のデータの下り(外向き)と上り(内向き)。

コンシューマ VPC が外部組織またはエンティティ(サードパーティ組織など)である場合、通常、コンシューマ VPC 内の Private Service Connect インターフェースへの通信を保護することはできません。このようなシナリオでは、Private Service Connect インターフェース VM のゲスト OS でセキュリティ ポリシーを定義できます。詳細については、Private Service Connect インターフェースのセキュリティを構成するをご覧ください。または、組織のセキュリティ コンプライアンスや標準に準拠していない場合は、別の方法を検討してください。

ベスト プラクティス

  • インターネットからのクライアント リクエストを、プライベート オンプレミスまたは他のクラウド環境でホストされているフロントエンドによってローカルで受信する必要がある場合は、API ゲートウェイ ソリューションとして Hybrid の使用を検討してください。

    • このアプローチでは、API プラットフォーム(Apigee)の一貫性を維持しながら、ソリューションを完全に Google Cloudでホストされる環境に移行することもできます。
  • 他の環境が長期的または恒久的なハイブリッドまたはマルチクラウド セットアップにある場合、他の環境への大量のアウトバウンド データ転送のレイテンシを最小限に抑え、費用を最適化するには、次の点を考慮してください。

    • Cloud Interconnect または Cross-Cloud Interconnect を使用します。
    • 適切な環境のターゲット フロントエンドでユーザー接続を終端するには、ハイブリッドを使用します。
  • 要件とアーキテクチャに該当する場合は、Kubernetes を使用したハイブリッド デプロイで Apigee Adapter for Envoy を使用します。

  • 接続パスとルーティング パスを設計する前に、移行元環境と移行先環境とともに、ローカルまたはリモートの API ゲートウェイに転送する必要があるトラフィックまたは API リクエストを特定する必要があります。

  • VPC Service Controls を使用して、プロジェクト内の Google Cloud サービスを保護し、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定して、データ漏洩のリスクを軽減します。

  • Virtual Private Cloud(VPC)ファイアウォール ルールまたはファイアウォール ポリシーを使用して、Private Service Connect エンドポイントを介して Private Service Connect リソースへのネットワーク レベルのアクセスを制御します。たとえば、アプリケーション(コンシューマー)VPC のアウトバウンド ファイアウォール ルールでは、VM インスタンスからエンドポイントの IP アドレスまたはサブネットへのアクセスを制限できます。

  • Private Service Connect インターフェースを使用する場合は、Private Service Connect インターフェースのセキュリティを構成して、インターフェースへの通信を保護する必要があります。

  • プライベート サブネット内のワークロードにインターネット アクセスが必要な場合は、Cloud NAT を使用して、ワークロードに外部 IP アドレスを割り当ててパブリック インターネットに公開しないようにします。

  • ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認してください。