このページの内容は Apigee と Apigee ハイブリッドに該当します。
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 つの環境
最も単純な構造は、1 つの環境のみを有する 1 つの環境グループです。これは、プロダクトを現在評価している組織、テスト インフラストラクチャや分析インフラストラクチャをまだ設定していない組織、または本番環境にプロキシをまだ配置していない組織などに相当します。
1 つの環境グループ内の複数の環境
環境グループには複数の環境を含めることができます。以下の例では、単一の環境グループ prod-group があり、ここに cart-prod、catalog-prod、payment-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.com と payment.example.com が同じ環境グループで定義されている場合、catalog.example.com/proxy1 と payment.example.com/proxy1 は両方とも proxy1 リソースを呼び出します。
ルーティングの例
次に例を示します。
-
prod-group環境グループには、次の環境が含まれています。catalog-prodcart-prodpymnt-prod
-
prod-groupには、次のホスト名が定義されています。catalog.example.compayment.example.com
次のプロキシがこれらの環境にデプロイされます。
catalog-prodのcatalogプロキシ。ベースパスは/catalogです。cart-prodのcartプロキシ。ベースパスは/catalog/cartです。pymnt-prodのpaymentプロキシ。ベースパスは/paymentです。
これにより、次のエンドポイントが作成されます。
catalog.example.com/catalogはcatalog-prod環境のcatalogプロキシにルーティングされます。catalog.example.com/catalog/cartはcart-prod環境のcartプロキシにルーティングされます。payment.example.com/paymentはpymnt-prod環境のpaymentプロキシにルーティングされます。
次の例は、任意のホスト名とベースパスに合致し、グループ内の環境にデプロイされるさまざまなプロキシにリクエストがルーティングされることを示します。
共有環境とルーティング
環境は、複数の環境グループに所属できます。このような環境にプロキシをデプロイする場合は、環境が属している環境グループごとに 1 つずつ、複数のアドレスがプロキシに存在します。これは、あるお客様が複数のパートナーに対してワイルドカード証明書（*.example.com など）を持っている場合に便利です。
次に例を示します。
shared-envは 2 つの環境グループに属します。- ホスト エイリアス
api.partner-1.comのあるpartner-1 - ホスト エイリアス
api.partner-2.comのあるpartner-2
- ホスト エイリアス
- プロキシ
fooは、ベースパス/fooでshared-envにデプロイされます。shared-envは両方の環境グループで共有されるため、fooには次の 2 つのアドレスが割り当てられます。api.partner-1.com/fooapi.partner-2.com/foo
両方のホスト名が同じ環境にルーティングされます。これにより、各環境グループに一意のドメイン名が割り当てられます。Apigee ハイブリッドの場合、このシナリオでは、パートナーごとに異なる証明書に対して mTLS を使用できます。
環境スコープについて
組織は、一部の Apigee 機能にスコープを提供します。たとえば、Key-Value-map（KVM）データは組織レベルで公開できます。つまり、その組織内の環境にデプロイされる API プロキシは同じ KVM データにアクセスできます。
同様に、一部の機能を組織内の環境または環境グループに限定できます。たとえば、Apigee Analytics データは、組織、環境、（最終的には）環境グループの組み合わせによって分割されます。
考慮事項
環境へのデプロイごとに、関連付けられているすべての環境グループのトラフィックのルーティングにその環境が影響を与える可能性があります。新しいベースパスが追加されると、新しいトラフィックを捕捉し始めるか、既存のデプロイですでに処理されている既存のトラフィックのサブセットの捕捉を始めます。
同様に、ベースパスが削除されると、トラフィックが受信されなくなったエンドポイントと通信したり、既存のトラフィックを別のプロキシに再ルーティングすることがあります。トラフィックのルーティングが変更される際には、同じ環境内のプロキシにルーティングされるようになることもあれば、複数の環境で 1 つの環境グループを共有している場合は別の環境にあるプロキシにルーティングされるようになることもあります。
環境または環境グループに追加される API プロキシのベースパスの合計数も考慮する必要があります。最適なパフォーマンスを得るため、1 つの Apigee 環境または環境グループで使用する API プロキシ ベースパスは 3,000 個以下にすることを推奨します。この推奨値を超えると、新規および既存のすべての API プロキシのデプロイでレイテンシが増加する可能性があります。
参考情報
ここでは、環境と環境グループを管理する方法について説明します。
-
Apigee UI を使用する場合:
-
Apigee API を使用する場合: