Apigee アーキテクチャの概要

このページは Apigee と Apigee ハイブリッドに適用されます。

Apigee Edge ドキュメントを表示する

このトピックでは、Apigee システム アーキテクチャの概要について説明します。これは、プロビジョニング中に作成されるコンポーネントと、システム全体における目的を理解するのに役立ちます。

Apigee には VPC ピアリングありと VPC ピアリングなしの 2 つのプロビジョニング オプションがあります。以降のセクションでは、両方のオプションについて説明します。

  • VPC ピアリングが有効になっているアーキテクチャ
  • VPC ピアリングが無効になっているアーキテクチャ

    • VPC ピアリングが有効になっているアーキテクチャ

    このセクションでは、Apigee を VPC ピアリング オプションを使用してプロビジョニングする場合の Apigee システム アーキテクチャについて説明します。

    プロビジョニングの概要

    プロビジョニング中に、お客様が管理する Virtual Private Cloud ネットワーク（VPC）と Apigee が管理する VPC ネットワークとの双方向通信を許可するように、コンポーネントが構成され、作成されます。最初のいくつかのプロビジョニング手順を完了すると、2 つの VPC が作成されますが、まだ通信はできません。双方向の通信を許可するには、さらに構成が必要です。図 1 を参照してください。

    図 1: お客様の VPC と Apigee の VPC は、追加の構成を行わなければ相互に通信できません。

    VPC 間の通信を有効にするには、VPC ネットワーク ピアリングを使用します。ネットワーク ピアリングでは、2 つの Virtual Private Cloud（VPC）ネットワークが同じプロジェクトまたは同じ Google Cloud 組織に属しているかどうかにかかわらず、内部 IP アドレス接続を使用できます。ネットワーク ピアリングの手順を完了すると、2 つの VPC 間で通信が可能になります。図 2 を参照してください。

    図 2: VPC ネットワーク ピアリングにより VPC 間の通信が可能になります。

    インターネット上のクライアント アプリから Apigee にトラフィックをルーティングするには、グローバル外部 HTTPS ロードバランサ（XLB）を使用します。XLB では、プロジェクト間のサービス参照を使用して、Google Cloud プロジェクト間（お客様の Google Cloud プロジェクトと Apigee Google Cloud プロジェクト間など）の通信を行うことができます。

    また、ネットワーク ブリッジとして機能する仮想マシン（VM）のマネージド インスタンス グループ（MIG）をプロビジョニングすることも可能です。MIG VM には、ピア ネットワーク間で双方向通信を行う機能があります。プロビジョニングが完了すると、インターネット上のアプリが XLB と、XLB がブリッジ VM と、ブリッジ VM が Apigee ネットワークと通信します。図 3 と図 4 を参照してください。

    図 3: マネージド VM によって、ピア ネットワーク間でリクエストとレスポンスをやり取りできます。

    この構成では、トラフィックは Apigee（MessageLogging ポリシーなど）から内部 VPC で実行されているワークロードにルーティングされます。この場合、内部 VPC との通信は下り（外向き）の NAT IP を経由しません。代わりに、Apigee インスタンスの IP の 1 つを使用してトラフィックをルーティングできます。

    図 4: 内部 VPC のワークロードに非公開でルーティングされたトラフィック。

    API プロキシ呼び出しのライフサイクル

    次の図（図 5）は、プロビジョニングされた Apigee システム コンポーネントを移動する API プロキシ呼び出しのライフサイクルを示しています。

    図 5: 内部 VPC のワークロードに非公開でルーティングされたトラフィック。
    1. クライアント アプリが Apigee API プロキシを呼び出します。
    2. リクエストはグローバル L7 外部 HTTPS ロードバランサ（XLB）に配置されます。XLB には、外部 / パブリック IP と TLS 証明書が構成されています。
    3. XLB は仮想マシン（VM）にリクエストを送信します。VM は、VPC と Google の VPC（Apigee によって管理される）の間のブリッジとして機能します。
    4. VM が Apigee にリクエストを送信すると、API プロキシ リクエストが処理されます。
    5. Apigee によってリクエストがバックエンド サービスに送信され、レスポンスがクライアントに返されます。

    VPC ピアリングが無効になっているアーキテクチャ

    このセクションでは、Apigee が VPC ピアリング オプションを使用してプロビジョニングされていない場合の Apigee システム アーキテクチャについて説明します。

    プロビジョニング中に、お客様が管理する Virtual Private Cloud ネットワーク（VPC）と Apigee が管理する VPC ネットワークとの双方向通信を許可するように、コンポーネントが構成され、作成されます。最初のいくつかのプロビジョニング手順を完了すると、2 つの VPC が作成されますが、まだ通信はできません。双方向の通信を許可するには、さらに構成が必要です。図 6 を参照してください。

    図 6: お客様の VPC と Apigee の VPC は、追加の構成を行わなければ相互に通信できません。

    VPC 間の通信を有効にするには、ノースバウンド トラフィックを Apigee にルーティングし、サウスバウンド トラフィックを Google Cloud プロジェクトで実行されているターゲット サービスにルーティングするために Private Service Connect（PSC）を使用します。

    PSC を使用すると、サービス プロデューサー（Apigee）とサービス コンシューマ（自身が制御する 1 つ以上の他のクラウド プロジェクト）間のプライベート接続が有効になります。この方式（図 7）では、リクエストはグローバル外部ロードバランサまたはリージョン外部ロードバランサを経由して、サービス アタッチメントと呼ばれる単一のアタッチメント ポイントに到達します。

    Apigee をバックエンド ターゲットにプライベート接続するには、ターゲットがデプロイされる VPC ネットワークにサービス アタッチメントを、Apigee VPC にエンドポイント アタッチメントを作成する必要があります。これらの 2 つのエンティティで、Apigee をターゲット サービスに接続できます。サウスバウンド ネットワーキング パターンをご覧ください。

    PSC を使用して Apigee をプロビジョニングする手順（VPC ピアリングなし）については、VPC ピアリングを使用しないコマンドライン プロビジョニングで説明されています。

    図 7. VPC ピアリングを使用しない Apigee アーキテクチャ。このアーキテクチャの詳細については、Apigee アーキテクチャの概要をご覧ください。