環境は、API プロキシを実行する分離されたコンテキスト、すなわち「サンドボックス」を提供します。単一の組織で複数の環境を作成できます。詳細については、環境と環境グループについてをご覧ください。
基本的なインストール中に、テスト用の環境を追加しました。ただし、ベスト プラクティスとしては、複数の環境を作成し、各環境に限られた数のプロキシをデプロイすることをおすすめします。
仮想ホストと環境について
Apigee ハイブリッドは、Istio Ingress ゲートウェイを使用して受信 API のトラフィックを処理します。MART サービスとランタイム サービスはどちらも、Istio Ingress ゲートウェイを使用して、クラスタ外部に公開された接続を管理するよう構成されます。このため、たとえば API プロキシへのすべての HTTP リクエストと HTTPS リクエストは、最初に Istio Ingress ゲートウェイで処理されます。
ハイブリッドでは、1 つ以上の環境を作成し、各環境にホスト エイリアスを割り当てます。ホスト エイリアスは DNS 名です。その DNS 名宛ての受信トラフィックは、Ingress によって対応する環境にルーティングされます。内部では、各環境は単一の Message Processor に割り当てられており、その 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 にルーティングされます。
つまり、作成する各環境にはホスト エイリアスが割り当てられている必要があります。各環境は単一の Message Processor にのみマッピングされ、どの Message Processor が特定のリクエストを受信するかはホスト エイリアスによって決まります。
複数の環境で同じホスト エイリアスを共有する
Apigee ハイブリッドでは、自由に管理できる複数の環境を作成できます。たとえば、dev1、dev2、dev3 など複数の開発環境を作成し、それぞれに単一のホスト エイリアスをマッピングできます。さらに、各環境に複数のプロキシをデプロイできます。
アンチパターン: すべてのプロキシを 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 をご覧ください。
環境の操作
構成の詳細については、以下のトピックをご覧ください。