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

Edge for Private Cloud v4.19.01

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

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

コンポーネント	構成要素	関連付け	デフォルト
プラネット	1 つ以上のリージョン		なし
リージョン	1 つ以上のポッド		"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 つのポッドが含まれています。

リージョン	リージョン内のポッド
"dc-1"	"gateway"、"central"、"analytics"

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

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

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

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

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

ポッドについて

ポッドは、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 データストアが表示されます。

組織について

組織は、API、API プロダクト、アプリ、開発者など、Apigee アカウントのすべてのオブジェクトを含むコンテナです。組織は 1 つ以上のポッドに関連付けられ、各ポッドには 1 つ以上の Message Processor が含まれます。

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

組織管理者の役割を担うユーザー。このユーザーが別のユーザーを組織に追加し、各ユーザーの役割を設定します。
"gateway" ポッド。Message Processor を含むポッドです。

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

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

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

環境について

組織は、組織内の API プロキシ用のランタイム実行コンテキストです。環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。1 つの API プロキシを 1 つの環境にデプロイすることも、複数の環境にデプロイすることもできます。

組織には、複数の環境を含められます。たとえば、1 つの組織に "dev"、"test"、"prod" などの環境を定義できます。

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

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

環境を含む組織
環境に対する API プロキシリクエストを処理する Message Processor。これらの Message Processor は、環境の親組織に関連付けられたポッドに存在する必要があります。
デフォルトでは、環境を作成すると、Edge は環境の "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 プロキシの作成時に定義されます。

通常、IP アドレスとポート番号を使用して顧客に 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 エントリがない場合、ホストエリアスに Router の IP アドレスと仮想ホストのポートを routerIP:port という形式で設定します。

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

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

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

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

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

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

組織の管理者としての役割を果たすために選択したユーザー
example という名前の組織
組織に prod という名前の環境を作成し、"gateway" ポッドのすべての Message Processor を関連付けます。
環境内に default という名前の仮想ホストを作成し、ポート 9001 での HTTP アクセスを許可します。
仮想ホストのホストエイリアス

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

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

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

詳しくは、組織のオンボーディングを行うをご覧ください。