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

Edge for Private Cloud v4.18.05

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

次の表で、これらの関係を説明します。

コンポーネント 次を含む 関連付け デフォルト
プラネット 1 つ以上のリージョン なし
リージョン 1 つ以上の Pod "dc-1"
ポッド 1 つ以上の Edge コンポーネント "central"
"gateway"
"analytics"
組織 1 つ以上の環境 Message Processor を含む 1 つ以上のポッド、組織管理者の役割を持つユーザー なし
環境 1 つ以上の仮想ホスト 親組織に関連付けられたポッドに含まれる 1 つ以上の Message Processor なし
仮想ホスト 1 つ以上のホスト エイリアス なし

プラネットについて

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

リージョンについて

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

リージョン リージョン内の Pod
"dc-1" "gateway"、"central"、"analytics"

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

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

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

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

次の図は、2 つのリージョン（データセンター）が存在する環境を表しています。

Pod について

「ポッド」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		 identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
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
  • central
  • analytics

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

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

Apigee は次のような出力を返します。

[ {
  "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 属性にはコンポーネント タイプが列挙されます。ここには、ポッドに登録された Cassandra データストアが含まれます。Cassandra ノードが "gateway" ポッドにインストールされている場合、すべてのポッドで登録されている Cassandra データストアが表示されます。

組織について

「組織」とは、ある Apigee アカウントに属する API、API プロダクト、アプリ、デベロッパーなどのすべてのオブジェクトのコンテナです。組織は 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 ノードで開いている必要があります。これにより、次の URL にリクエストを送信して、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 アドレスと仮想ホストのポートを設定します。

詳細については、仮想ホストについてをご覧ください。

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

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

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

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

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

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

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

http://routerIP:9001/proxy-base-path/resource-name

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

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