このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示します。
このトピックでは、Apigee システム アーキテクチャの概要について説明します。これは、プロビジョニング中に作成されるコンポーネントと、システム全体における目的を理解するのに役立ちます。
Apigee には VPC ピアリングありと VPC ピアリングなしの 2 つのプロビジョニング オプションがあります。以降のセクションでは、両方のオプションについて説明します。
- VPC ピアリングが有効になっているアーキテクチャ
- VPC ピアリングが無効になっているアーキテクチャ
- クライアント アプリが Apigee API プロキシを呼び出します。
- リクエストはグローバル L7 外部 HTTPS ロードバランサ（XLB）に配置されます。XLB には、外部 / 公開 IP と TLS 証明書が構成されています。
- XLB は仮想マシン（VM）にリクエストを送信します。VM は、VPC と Google の VPC（Apigee によって管理される）の間のブリッジとして機能します。
- VM が Apigee にリクエストを送信すると、API プロキシ リクエストが処理されます。
- Apigee によってリクエストがバックエンド サービスに送信され、レスポンスがクライアントに返されます。
VPC ピアリングが有効になっているアーキテクチャ
このセクションでは、Apigee を VPC ピアリング オプションを使用してプロビジョニングする場合の Apigee システム アーキテクチャについて説明します。
プロビジョニングの概要
プロビジョニング中に、お客様が管理する Virtual Private Cloud ネットワーク（VPC）と Apigee が管理する VPC ネットワークとの双方向通信を許可するように、コンポーネントが構成され、作成されます。最初のいくつかのプロビジョニング手順を完了すると、2 つの VPC が作成されますが、まだ通信はできません。双方向の通信を許可するには、さらに構成が必要です。図 1 を参照してください。
VPC 間の通信を有効にするには、VPC ネットワーク ピアリングを使用します。ネットワーク ピアリングでは、2 つの Virtual Private Cloud（VPC）ネットワークが同じプロジェクトまたは同じ Google Cloud 組織に属しているかどうかにかかわらず、内部 IP アドレス接続を使用できます。ネットワーク ピアリングの手順を完了すると、2 つの VPC 間で通信が可能になります。図 2 を参照してください。
インターネット上のクライアント アプリから Apigee にトラフィックをルーティングするには、グローバル外部 HTTPS ロードバランサ（XLB）を使用します。XLB では、プロジェクト間のサービス参照を使用して、Google Cloud プロジェクト間（お客様の Google Cloud プロジェクトと Apigee Google Cloud プロジェクト間など）の通信を行うことができます。
また、ネットワークブリッジとして機能する仮想マシン（VM）のマネージドインスタンスグループ（MIG）をプロビジョニングすることも可能です。MIG VM には、ピア ネットワーク間で双方向通信を行う機能があります。プロビジョニングが完了すると、インターネット上のアプリが XLB と、XB がブリッジ VM と、ブリッジ VM が Apigee ネットワークと通信します。図 3 と図 4 を参照してください。
この構成では、トラフィックは Apigee（MessageLogging ポリシーなど）から内部 VPC で実行されているワークロードにルーティングされます。この場合、内部 VPC との通信は下り（外向き）の NAT IP を経由しません。代わりに、Apigee インスタンスの IP の 1 つを使用してトラフィックをルーティングできます。
API プロキシ呼び出しのライフサイクル
次の図（図 5）は、プロビジョニングされた Apigee システム コンポーネントを移動する API プロキシ呼び出しのライフサイクルを示しています。
VPC ピアリングが無効になっているアーキテクチャ
このセクションでは、Apigee が VPC ピアリング オプションを使用してプロビジョニングされていない場合の Apigee システム アーキテクチャについて説明します。
プロビジョニング中に、お客様が管理する Virtual Private Cloud ネットワーク（VPC）と Apigee が管理する VPC ネットワークとの双方向通信を許可するように、コンポーネントが構成され、作成されます。最初のいくつかのプロビジョニング手順を完了すると、2 つの VPC が作成されますが、まだ通信はできません。双方向の通信を許可するには、さらに構成が必要です。図 6 を参照してください。
VPC 間の通信を有効にするには、ノースバウンド トラフィックを Apigee にルーティングし、サウスバウンド トラフィックを Google Cloud プロジェクトで実行されているターゲット サービスにルーティングするために Private Service Connect（PSC）を使用します。
PSC を使用すると、サービス プロデューサー（Apigee）とサービス コンシューマー（自身が制御する 1 つ以上の他のクラウド プロジェクト）間のプライベート接続が有効になります。この方式（図 7）では、リクエストはグローバル外部ロードバランサまたはリージョン外部ロードバランサを経由して、サービス アタッチメントと呼ばれる単一のアタッチメント ポイントに到達します。
Apigee をバックエンド ターゲットにプライベート接続するには、ターゲットがデプロイされる VPC ネットワークにサービス アタッチメントを、Apigee VPC にエンドポイント アタッチメントを作成する必要があります。これらの 2 つのエンティティで、Apigee をターゲット サービスに接続できます。サウスバウンド ネットワーキング パターンをご覧ください。
PSC を使用して Apigee をプロビジョニングする手順（VPC ピアリングなし）については、VPC ピアリングを使用しないコマンドライン プロビジョニングで説明されています。
