環境と環境グループについて

このページの内容は ApigeeApigee ハイブリッドに該当します。

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

このセクションでは、環境と環境グループについて説明します。

概要

Apigee 環境は、組織内でのソフトウェア環境で、API プロキシの作成デプロイが目的です。環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。ある特定の API プロキシを、単一の環境または複数の環境にデプロイできます。

各環境にデプロイできる API プロキシ、共有フロー、その他のリソースの数には上限があります。これらの上限は、環境を使用する Apigee 組織のタイプ(サブスクリプション、従量課金制、ハイブリッド)によって異なります。詳細については、制限事項のドキュメントをご覧ください。

環境グループ(Apigee API の envgroup ともいいます)は、リクエストを個々の環境にルーティングする方法を定義する基本機能です。個々の環境ではなく、環境グループにホスト名を定義します。Apigee はこれらのホスト名定義を使用して、グループ内の環境にリクエストを転送します。

環境内でデプロイされたプロキシにアクセスするには、環境が少なくとも 1 つの環境グループのメンバーであることが必要です。つまり、環境を使用するには、グループに環境を割り当てる必要があります。

環境グループごとに環境を論理的なグループに分けると、次の利点があります。

  • ホスト名管理に一元化: 環境グループは、ホスト名を管理するための一元的な場所を提供します。
  • 分析情報の集約: グループを使用すれば、個々の環境ではなく、環境グループ全体のレポートを一度に確認することで誤りを分析できます。
  • 競合の回避: 環境をグループ化することで、同じホスト名の下にデプロイされたプロキシのベースパスが存在するようにできます。

サポートされているデプロイタイプ

Apigee では、環境で次のデプロイタイプがサポートされています。

タイプ 説明
プロキシ Apigee 開発環境で API プロキシを開発してテストし、Apigee Integration のテスト環境と本番環境にデプロイします。API プロキシのデプロイをご覧ください。
アーカイブ VS Code での Apigee を使用したプログラム可能な API プロキシを開発およびテストします。

アーカイブ デプロイメントで禁止されている操作の概要

Apigee 環境でアーカイブ デプロイメントを有効にすると、環境内で特定のアクションを行うことができなくなり、競合を防ぐことができます。

  • Apigee UI では、API プロキシのデプロイで説明されているように、デプロイのステータスの表示や確認を行うことや、アーカイブ デプロイを管理することはできません。また、Debug の使用で説明されているように Debug の UI を使用することもできません。回避策として、gcloud または API を使用して環境内のすべてのアーカイブ デプロイを一覧表示し、Debug API を使用できます。
  • Apigee UI、API、または gcloud を使用して、リソース ファイルまたはターゲット サーバーの作成、更新、または削除を行うことはできません
  • 現時点で、サービス アカウントを使用した Google 認証はサポートされていません。

禁止されている上の操作のいずれかを実施しようとすると、操作が失敗し、次のエラー メッセージが表示されます。

FAILED_PRECONDITION

プロキシ デプロイ ユニット

プロキシ デプロイ ユニットは、環境にデプロイされたプロキシと共有フローをリージョンごとにカウントします。

デプロイ ユニットのタイプは次のとおりです。

  • 標準プロキシのデプロイ ユニットは、現在デプロイされているプロキシの数を標準プロキシとしてカウントします。
  • 拡張プロキシのデプロイ ユニットは、現在デプロイされているプロキシの数をカウントしますが、このプロキシは拡張プロキシとみなされます。
  • 共有フローのデプロイ ユニットは、デプロイされた共有フローの数をカウントします。

使用量はデプロイの割り当ての対象となる場合があります。これは、一度に使用できるデプロイ ユニット数の上限です。詳しくは、利用資格(従量課金制またはサブスクリプション 2024)をご覧ください。

組織のプロキシ デプロイ単位の使用状況とデプロイ割り当ての詳細を表示する方法については、プロキシのデプロイの使用状況を表示するをご覧ください。

環境タイプ

従量課金制ユーザーの場合は、環境を作成するときに環境タイプ(基本中間、または包括的)を指定します。環境に関連する機能と費用は、環境タイプによって異なります。詳しくは、従量課金制の環境タイプ従量課金制の利用資格をご覧ください。

サブスクリプション プランの場合、環境タイプは常に包括的であるため、環境タイプについて把握する必要はありません。

転送プロキシ

Apigee では、指定された URI へのトラフィックの転送がサポートされています。この機能は環境レベルで適用され、プロキシでの初期処理後にトラフィックをインターネットに転送するために使用できます。

構成された環境内のプロキシにリクエストが着信すると、含まれているすべてのポリシーで処理され(転送プロキシ機能のサポートを参照)、HTTP を使用して新しい URI に転送されます。

環境の転送プロキシ設定に加えた変更が直ちに反映されるのは、新しいリクエストのみです。すでに処理されているリクエストは、リクエスト受信時の設定のままで完了します。

転送プロキシを構成する手順については、環境で転送プロキシを構成するをご覧ください。

転送プロキシ機能のサポート

一般提供されているすべてのプロキシ機能が、転送プロキシと同じ可用性や適用範囲を持つわけではありません。

Apigee は現在、Apigee ハイブリッドを除き、転送プロキシを使用する基本認証をサポートしていません。

次の表に、追加機能のサポート状況を示します。

機能またはポリシー 転送プロキシのサポート / 適用範囲
ターゲット エンドポイント
HTTP ヘルスチェック
サービス呼び出し
JavaScript による HTTP 呼び出し
統合ターゲット
ローカル ループバックを介したプロキシ チェーン接続 ×
メッセージのパブリッシュ ×
クラウド ロギング ×
Synchronizer との通信 ×
Syslog を介したメッセージ ロギング ×

転送プロキシの制限事項

現在、転送プロキシでは、外部オーディエンスを介した GoogleToken はサポートされていません。

要点

次の表に、環境、組織、環境グループについて留意すべき重要事項を示します。

要素 ルール
組織
  • 複数の環境グループを含めることができます
  • 環境グループを 1 つ以上指定する必要があります
環境
  • 少なくとも 1 つの環境グループに属する必要があります
  • 複数のグループに所属可能です
  • 同じグループ内の他のすべての環境とホスト名を共有します
  • 指定された URI にトラフィックを転送する場合に使用可能
環境タイプ
  • 環境で使用可能な機能が異なります
  • 環境の料金が異なります

環境タイプをご覧ください)

環境グループ
  • 複数のホスト名を持つことができます
  • 1 つ以上の環境を含みます
  • グループに割り当てられるホスト名は、そのグループに固有のものである必要があります(他のグループでは使用できません)

以降のセクションで、環境グループ内で環境がどのように構成されているかを示します。

1 つの環境グループと 1 つの環境

最も単純な構造は、1 つの環境のみを有する 1 つの環境グループです。これは、プロダクトを現在評価している組織、テスト インフラストラクチャや分析インフラストラクチャをまだ設定していない組織、または本番環境にプロキシをまだ配置していない組織などに相当します。

1 つの環境グループ内の複数の環境

環境グループには複数の環境を含めることができます。以下の例では、単一の環境グループ prod-group があり、ここに cart-prodcatalog-prodpayment-prod の 3 つの環境が含まれています。

環境グループレベルで定義されたホスト名。

環境グループには単一のホスト名の example.com があります。このホスト名を使用して、任意の環境にデプロイされたプロキシにリクエストをルーティングできます。ホスト名は環境グループレベルで定義され、特定の環境にルーティングされない点に注意してください。

この環境グループを作成する方法については、環境グループの操作をご覧ください。

1 つの環境へのルーティングの制限

前の例では、単一のホスト名によって 3 つのすべての環境内のプロキシにリクエストをルーティングできます。単一環境(たとえば、catalog-prod)内のプロキシへのアクセスを制限する場合は、catalog-prod 環境のみを含む別の環境グループを作成します。その後、その環境グループに定義されたホスト名は、catalog-prod にのみアクセスできます。

以下の例では、環境グループ catalog-prod-group のホスト名 catalog.example.com は、環境 catalog-prod 内のプロキシにのみリクエストをルーティングできます。

単一環境の環境グループ。

 

グループを作成する準備はできたら

コンソールを開きます

 

 

環境についての詳細を確認するには:

詳細を読む

 

 

環境グループについての詳細を確認するには:

詳細を読む

 

ルーティングとベースパス

簡単な構成では、デプロイされた API プロキシへのリクエストは、ホスト名、ベースパス、API リソースの名前で構成されます。以下に例を示します。

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

複数の環境でホスト名を共有できるように、環境グループでホスト名を定義します。ベースパスと API リソースは API プロキシで定義されます。

ベースパスと API リソースの詳細については、まずルートについてをご覧ください。また、フロー構成のリファレンスフロー変数のリファレンスを参照して、これらの要素がどのように連携するかについて確認してください。

ホスト名

環境グループを作成したら、1 つ以上のホスト名をそのグループに関連付けます。たとえば、次の環境グループを作成し、それぞれに独自のホスト名を持たせることができます。

環境グループ名
(環境)
prod-group

(catalog-prod
cart-prod
pymnt-prod)
dev-group

(dev-env)
test-group

(test-env)
ホスト名 catalog.example.com
payment.example.com
dev.example.com test.example.com

ベースパスは、プロキシの作成時に定義します。

グループ内の環境にプロキシをデプロイする場合、ホスト名とベースパスとリソース名を組み合わせて、該当プロキシへの API リクエストのエンドポイントを定義します。

1 つの環境グループに複数のホスト名を定義できます。これらを使用して、グループ内の任意の環境にデプロイされた任意のプロキシを呼び出すことができます。たとえば、ホスト名 catalog.example.compayment.example.com が同じ環境グループで定義されている場合、catalog.example.com/proxy1payment.example.com/proxy1 は両方とも proxy1 リソースを呼び出します。

ルーティングの例

次に例を示します。

  • prod-group 環境グループには、次の環境が含まれています。

    • catalog-prod
    • cart-prod
    • pymnt-prod
  • prod-group には、次のホスト名が定義されています。

    • catalog.example.com
    • payment.example.com
  • 次のプロキシがこれらの環境にデプロイされます。

    • catalog-prodcatalog プロキシ。ベースパスは /catalog です。
    • cart-prodcart プロキシ。ベースパスは /catalog/cart です。
    • pymnt-prodpayment プロキシ。ベースパスは /payment です。

これにより、次のエンドポイントが作成されます。

  • catalog.example.com/catalogcatalog-prod 環境の catalog プロキシにルーティングされます。
  • catalog.example.com/catalog/cartcart-prod 環境の cart プロキシにルーティングされます。
  • payment.example.com/paymentpymnt-prod 環境の payment プロキシにルーティングされます。

次の例は、任意のホスト名とベースパスに合致し、グループ内の環境にデプロイされるさまざまなプロキシにリクエストがルーティングされることを示します。

API リクエストは、ホスト名とベースパスに基づいて、グループ内の複数の環境にルーティングされます。

共有環境とルーティング

環境は、複数の環境グループに所属できます。このような環境にプロキシをデプロイする場合は、環境が属している環境グループごとに 1 つずつ、複数のアドレスがプロキシに存在します。これは、あるお客様が複数のパートナーに対してワイルドカード証明書(*.example.com など)を持っている場合に便利です。

次に例を示します。

  • shared-env は 2 つの環境グループに属します。
    • ホスト エイリアス api.partner-1.com のある partner-1
    • ホスト エイリアス api.partner-2.com のある partner-2
  • プロキシ foo は、ベースパス /fooshared-env にデプロイされます。shared-env は両方の環境グループで共有されるため、foo には次の 2 つのアドレスが割り当てられます。
    • api.partner-1.com/foo
    • api.partner-2.com/foo

両方のホスト名が同じ環境にルーティングされます。これにより、各環境グループに一意のドメイン名が割り当てられます。Apigee ハイブリッドの場合、このシナリオでは、パートナーごとに異なる証明書に対して mTLS を使用できます。

環境スコープについて

組織は、一部の Apigee 機能にスコープを提供します。たとえば、Key-Value-map(KVM)データは組織レベルで公開できます。つまり、その組織内の環境にデプロイされる API プロキシは同じ KVM データにアクセスできます。

同様に、一部の機能を組織内の環境または環境グループに限定できます。たとえば、Apigee Analytics データは、組織、環境、(最終的には)環境グループの組み合わせによって分割されます。

考慮事項

環境へのデプロイごとに、関連付けられているすべての環境グループのトラフィックのルーティングにその環境が影響を与える可能性があります。新しいベースパスが追加されると、新しいトラフィックを捕捉し始めるか、既存のデプロイですでに処理されている既存のトラフィックのサブセットの捕捉を始めます。

同様に、ベースパスが削除されると、トラフィックが受信されなくなったエンドポイントと通信したり、既存のトラフィックを別のプロキシに再ルーティングすることがあります。トラフィックのルーティングが変更される際には、同じ環境内のプロキシにルーティングされるようになることもあれば、複数の環境で 1 つの環境グループを共有している場合は別の環境にあるプロキシにルーティングされるようになることもあります。

環境または環境グループに追加される API プロキシのベースパスの合計数も考慮する必要があります。最適なパフォーマンスを得るため、1 つの Apigee 環境または環境グループで使用する API プロキシ ベースパスは 3,000 個以下にすることを推奨します。この推奨値を超えると、新規および既存のすべての API プロキシのデプロイでレイテンシが増加する可能性があります。

参考情報

ここでは、環境と環境グループを管理する方法について説明します。