プラネット、リージョン、Pod、組織、環境、仮想ホストについて

Edge for Private Cloud バージョン 4.16.05

Edge Private Cloud のオンプレミス環境、すなわち Edge インスタンスは、一連のサーバーノードにインストールされた Edge コンポーネントから構成されます。次の図は、Edge インスタンスを構成するプラネット、リージョン、ポッド、組織、環境、仮想ホストの関係を示しています。

次の表に、これらの関係を示します。

以下を含む

関連付け

デフォルト

プラネット

1 つ以上のリージョン

なし

リージョン

1 つ以上のポッド

「dc-1」

ポッド

1 つ以上の Edge コンポーネント

"central"
"gateway"
"analytics"

組織

1 つ以上の環境

Message Processor を含む 1 つ以上のポッド、組織管理者の役割を持つユーザー

none

環境

1 つ以上の仮想ホスト

親組織に関連付けられたポッドに含まれる 1 つ以上の Message Processor

none

仮想ホスト

1 つ以上のホスト エイリアス

none

プラネットについて

プラネットは Edge のハードウェアおよびソフトウェア環境全体を表し、1 つ以上のリージョンを含むことができます。Edge では、プラネットはリージョンの論理グループです。Edge のインストール時にプラネットを明示的に作成または構成することはありません。

リージョンについて

「リージョン」は、1 つ以上のポッドのグループです。デフォルトでは、Edge をインストールすると、インストーラが "dc-1" という名前のリージョンを 1 つ作成します。このリージョンには次の 3 つのポッドが含まれています。

リージョン

リージョン内のポッド

「dc-1」

"gateway"、"central"、"analytics"

次の図は、デフォルトのリージョンを示しています。

この図では、ロードバランサがトラフィックを "gateway" ポッドに転送しています。"gateway" ポッドには、API リクエストを処理する Edge Router と Message Processor が含まれています。複数のデータセンターを定義していない限り、追加のリージョンを作成する必要はありません。

複雑な環境では、2 つ以上のリージョンを作成できます。複数のリージョンを作成してマシンを地理的に編成することで、ネットワークの移動時間を最小限にできます。このシナリオでは、API の利用者に対して地理的に「近く」になるように API エンドポイントをホストします。

Edge では、各リージョンはデータセンターと呼ばれます。米国東部のデータセンターではボストン、マサチューセッツからのリクエストを処理し、シンガポールのデータセンターではアジアのデバイスやパソコンからのリクエストを処理できます。

たとえば次の図は、2 つのデータセンターに対応する 2 つのリージョンを示しています。

Pod について

ポッドは、1 つ以上の Edge コンポーネントと Cassandra データストアのグループです。Edge コンポーネントは同じノードにインストールすることもできますが、別々のノードにインストールするのが一般的です。Cassandra データストアは、そのポッド内の Edge コンポーネントが使用するデータ リポジトリです。

デフォルトでは、Edge をインストールすると 3 つのポッドが作成され、各ポッドに次の Edge コンポーネントと Cassandra データストアが関連付けられます。

ポッド

Edge コンポーネント

Cassandra データストア

"gateway"

Router、Message Processor

cache-datastore
counter-datastore
dc-datastore

keyvaluemap-datastore
kms-datastore

"central"

Management Server、Zookeeper、LDAP、UI、Qpid

application-datastore
apimodel-datastore
audit-datastore

auth-datastore
management-server
user-settings-datastore

"analytics"

Postgres

analytics-datastore

reportcrud-datastore

"gateway" ポッドの Edge コンポーネントと Cassandra データストアは API の処理に必要です。API リクエストを処理するには、これらのコンポーネントとデータストアが起動し、実行されている必要があります。"central" ポッドと "analytics" ポッドのコンポーネントとデータストアは API の処理に必要ではありませんが、Edge に追加機能を提供しています。

次の図は、各ポッドのコンポーネントを示しています。

デフォルトで作成される 3 つのポッド以外に、Message Processor と Router のポッドを作成することもできます。また、既存のポッドに Edge コンポーネントを追加することもできます。たとえば、増加したトラフィックの負荷を処理するために、"gateway" ポッドに Router と Message Processor を追加できます。

"gateway" ポッドには Edge Router と Message Processor が含まれています。Router は、同じポッドの Message Processor にのみメッセージを送信します。他のポッドの Message Processor にメッセージを送信することはありません。

各ポッドのインストールの最後に次の API 呼び出しを使用して、サーバーの登録情報を確認できます。これは便利なモニタリング ツールです。

curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName

ここで、ms_IP は Management Server の IP アドレスまたは DNS 名で、podName は次のいずれかです。

  • gateway
  • 中央
  • アナリティクス

たとえば、「gateway」ポッドの場合は次のとおりです。

> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway

次の形式で出力が表示されます。

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
}, 
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

type 属性にはコンポーネント タイプが列挙されます。ここには、Pod に登録されている Cassandra データストアが含まれます。Cassandra ノードが "gateway" ポッドにインストールされている場合、すべてのポッドで登録されている Cassandra データストアが表示されます。

組織について

「組織」とは、API、API プロダクト、アプリ、デベロッパーなど、Apigee アカウント内のすべてのオブジェクトのコンテナです。組織は 1 つ以上のポッドに関連付けられ、各ポッドには 1 つ以上の Message Processor が含まれます。

デフォルトでは、Edge Private Cloud のオンプレミス環境に組織は存在しません。組織を作成するときは、次の 2 つの情報を指定します。

  1. 組織管理者として機能するユーザー。このユーザーが別のユーザーを組織に追加し、各ユーザーのロールを設定できます。
  2. "gateway" ポッド（Message Processor を含むポッド）。

組織内に複数の環境を作成できます。Edge のデフォルトのインストール手順では、"test" と "prod" という 2 つの環境を作成するように求められます。必要であれば、さらに多くの環境（"staging"、"experiments" など）を作成できます。

組織は、一部の Apigee 機能のスコープになります。たとえば、Key-Value マップ（KVM）データは組織レベルで使用できますが、これはすべての環境から利用できることを意味します。キャッシュ保存などの他の機能のスコープは特定の環境に限定されます。Apigee の分析データは組織と環境の組み合わせごとに分割されています。

次の図は、組織の主なオブジェクトを表しています。これらのオブジェクトには、組織全体で定義されるものと、特定の環境に固有のものがあります。

環境について

「環境」は、組織内の API プロキシのランタイム実行コンテキストです。環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。ある特定の API プロキシを、単一の環境または複数の環境にデプロイできます。

1 つの組織に複数の環境を含めることが可能です。たとえば、1 つの組織に "dev"、"test"、"prod" 環境を定義するとします。

環境を作成するときに、1 つ以上の Message Processor を環境に関連付けます。環境は、API プロキシが実行される一連の Message Processor のグループと考えることもできます。どの環境も、同じまたは異なる Message Processor に関連付けることができます。

環境を作成するには、次の 2 つの情報を指定します。

  1. 環境を含む組織。
  2. 環境に対する API プロキシ リクエストを処理する Message Processor。これらの Message Processor は、環境の親組織に関連付けられたポッドに存在する必要があります。
    デフォルトでは、環境を作成すると、"gateway" ポッドで使用可能なすべての Message Processor がその環境に関連付けられます。また、使用可能な Message Processor のサブセットを指定して、環境ごとに異なる Message Processor でリクエストを処理することもできます。

Message Processor は複数の環境に関連付けることができます。たとえば、Edge のインストール環境に 2 つの Message Processor（A と B）が存在し、組織に 3 つの環境（"dev"、"test"、"prod"）を作成するとします。

  • "dev" 環境では、大量のトラフィックが発生することはないため、Message Processor A を関連付けます。
  • "test" 環境では、大量のトラフィックの発生する可能性が低いため、Message Processor B に関連付けます。
  • "prod" 環境では、Message Processor A と B の両方を関連付け、本番環境レベルのトラフィック量を処理できるようにします。

ある環境に割り当てる Message Processor は、すべて同じポッドに属していても、あるいはリージョンやデータセンターが異なる複数のポッドに属していても、どちらでもかまいません。たとえば、組織内で環境をグローバルに定義し、3 つの異なるリージョン（米国、日本、ドイツ）の Message Processor が含まれるとします。

API プロキシをグローバル環境にデプロイすると、API プロキシは 3 つのデータセンターのすべての Message Processor で実行されます。Router は同じポッドの Message Processor にのみトラフィックを転送するため、データセンターの Router で受信した API トラフィックはそのデータセンターの Message Processor にのみ転送されます。

仮想ホストについて

「仮想ホスト」では、API プロキシが公開される Edge Router のポートが定義されます。さらに、拡張機能により、アプリが API プロキシへのアクセスに使用する URL も定義されます。環境ごとに 1 つ以上の仮想ホストを定義する必要があります。

仮想ホストで指定したポート番号が Router ノードで開いていることを確認します。これにより、次のリクエストを送信することで API プロキシにアクセスできます。

http://<routerIP>:<port>/{proxy-base-path}/{resource-name}
https://<routerIP>:<port>/{proxy-base-path}/{resource-name}

ここで

  • http または https: 仮想ホストが TLS/SSL をサポートするように構成されている場合は HTTPS を使用します。仮想ホストが TLS/SSL をサポートしない場合は HTTP を使用します。
  • <routerIP>:<port> は、仮想ホストの IP アドレスとポート番号です。
  • {proxy-base-path} と {resource-name} は、API プロキシの作成時に定義されます。

通常、API をユーザーに公開するときに IP アドレスとポート番号は使用しません。代わりに、Router とポートの DNS エントリを定義します。例:

http://myAPI.myCo.com/{proxy-base-path}/{resource-name}
https://myAPI.myCo.com/{proxy-base-path}/{resource-name}

仮想ホストには、DNS エントリのドメイン名に一致するホスト エイリアスを作成する必要があります。上記の例では、myAPI.myCo.com のホスト エイリアスを指定します。DNS エントリがない場合は、<routerIP>:port の形式で、ホスト エイリアスに Router の IP アドレスと仮想ホストのポートを設定します。

詳細については、http://apigee.com/docs/api-services/content/virtual-hosts をご覧ください。

最初の組織、環境、仮想ホストの作成

通常、Edge のインストール プロセスが完了した後に最初に行うのは、「オンボーディング」プロセスで組織、環境、仮想ホストを作成することです。オンボーディングを行うには、Edge Management Server ノードで次のコマンドを実行します。

/<inst_root>/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

このコマンドは、ユーザー、組織、環境、仮想ホストを定義した構成ファイルを入力として使用します。

たとえば、以下を作成します。

  • 組織管理者の役割を担うユーザー
  • example という名前の組織
  • "gateway" ポッドのすべての Message Processor に関連付けられている、prod という名前の（組織内の）環境
  • ポート 9001 で HTTP アクセスを許可する、default という名前の環境内の仮想ホスト
  • 仮想ホストのホスト エイリアス

このスクリプトの実行後、次の形式の URL を使用して API にアクセスできます。

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

後で必要な数の組織、環境、仮想ホストを追加できます。

オンボーディングの詳細については、組織のオンボーディングをご覧ください。