環境について

環境は、API プロキシを実行するための分離コンテキストまたは「サンドボックス」を提供します。1 つの組織で、複数の環境を作成できます。

多くのユーザーは、基本インストール中にテスト用の環境を 1 つだけセットアップします。しかし、複数の環境を作成して、それぞれに限られた数のプロキシをデプロイすることをおすすめします。

仮想ホストと環境について

Apigee Hybrid は、Istio Ingress ゲートウェイを使用して、受信 API トラフィックを処理します。MART サービスとランタイムサービスはどちらも Istio Ingress ゲートウェイを使用して、クラスタ外部に公開された接続を管理するように構成されます。これは、たとえば、API プロキシへのすべての HTTP リクエストと HTTPS リクエストが最初に Istio Ingress ゲートウェイで処理されることを意味します。

ハイブリッドでは、1 つ以上の環境を作成して、各環境にホストエイリアスを 1 つずつ割り当てます。ホストエイリアスは DNS 名です。その DNS 名への受信トラフィックは、Ingress でその環境にルーティングされます。内部的に、各環境は 1 つの Message Processor だけに割り当てられます。このプロセッサは、プロキシリクエストの処理、ポリシーの適用、ターゲットサービスとの間でやり取りされるトラフィックのルーティングを担当します。したがって、ホストエイリアスが、特定の受信リクエストをどの Message Processor が受信するかを決定します。

次のコードは、複数の環境が定義されている構成例を示しています（このような構成は、オーバーライドファイルにあります）。環境の dev1 と prod1 のホストエイリアスは異なることに注意してください。

    envs:
      - name: dev1
        hostAlias: "apitest.mydomain.net"
        ...

      - name: prod1
        hostAlias: "apiprod.mydomain.net"
        ...

ベースパス /foo1 を持つプロキシが環境 dev1 にデプロイされているとします。次のようにプロキシを呼び出すことができます。

curl -k https://apitest.mydomain.net/foo1

この呼び出しが Ingress に到達したとき、Ingress はその呼び出しの送信先が dev1 環境に関連付けられた Message Processor であることを知っており、そこでリクエストが処理されます。

同様に、foo1 も prod1 環境にデプロイされている場合は、このようなプロキシリクエストをホストエイリアス apiprod.mydomain.net に発行できます。

curl -k https://apiprod.mydomain.net/foo1

この呼び出しは Ingress によってそのホストに関連付けられた MP にルーティングされます。

つまり、作成する環境ごとにホストエイリアスを割り当てる必要があります。各環境が 1 つの Message Processor だけにマッピングされ、ホストエイリアスがリクエストを受け取る Message Processor を特定します。

複数の環境で同じホストエイリアスを共有できます

Apigee Hybrid を使用すれば、好きな方法で管理できる複数の環境を作成できます。たとえば、dev1、dev2、dev3 などの複数の開発環境を作成し、それぞれに 1 つのホストエイリアスをマッピングすることができます。さらに、各環境に複数のプロキシをデプロイできます。

アンチパターン: すべてのプロキシを 1 つのハイブリッド環境にデプロイする。

おすすめの方法: 複数の環境を作成し、それぞれに限られた数のプロキシをデプロイする。ハイブリッドがプロキシ呼び出しをホストエイリアスを共有する適切な環境にルーティングする方法を管理するための手法をベースパスルーティングと言います。

たとえば、次の構成では、環境の dev1 と dev2 が同じホストエイリアスを共有しています。

envs:
      - name: dev1
        hostAlias: "apitest.mydomain.net"
        ...
      - name: dev2
        hostAlias: "apitest.mydomain.net"
        ...

複数の環境が同じホストエイリアスを共有している場合は、ベースパスルーティングという構成手法を使用して、特定のプロキシベースパスを特定の環境にマッピングする必要があります。詳細については、ベースパスルーティングをご覧ください。

プロキシデプロイメントの数を制限する

ハイブリッドの場合に、複数の環境で同じ仮想ホストを共有できるということは、特定の環境へのプロキシデプロイメントの管理方法を慎重に検討する必要があることを意味します。ハイブリッドでは、複数の環境を作成して、それぞれに限られた数のプロキシをデプロイすることをおすすめします。

環境にデプロイするプロキシの数はいくつにすべきですか？この質問に対する答えはありませんが、次の表で、各環境にデプロイするプロキシの数を制限することが推奨される理由と、プロキシデプロイメントの管理で考慮すべきことに関する一般的なガイダンスを提供します。

考慮すべき課題	説明
Message Processor の起動時間	Message Processor（MP）が起動するまでの時間とその MP にデプロイされるプロキシの数には直接的な相関関係があります。自動スケーリング Kubernetes 環境では、起動時間の増加が問題になることがあります。MP にデプロイされるプロキシが多いほど、その MP のスケーリングや再作成が必要な場合の MP の起動時間が長くなります。
スケーリングのパフォーマンス	1 つの環境に複数のプロキシがデプロイされ、プロキシの 1 つが大量のトラフィックを受信するために頻繁に自動スケーリングされる場合は、その環境内のすべてのプロキシがそれと一緒にスケーリングされます。1 つの高トラフィックプロキシを含む複数のプロキシのスケーリングでは、パフォーマンスが低下することがあります。
ノイジーネイバー	同じ環境に複数のプロキシがデプロイされた状態で、1 つのプロキシがクラッシュすると、MP の再起動中にその環境内のすべてのプロキシが停止します。環境にデプロイするプロキシの数を制限することにより、1 つのプロキシのクラッシュによる影響を最小限に抑えられます。

環境設定リファレンス

環境設定要素の完全なリストについては、構成プロパティのリファレンスで envs をご覧ください。

環境の操作

構成の詳細については、以下のトピックをご覧ください。