インストール要件

ハードウェア要件

本番環境内の高可用性インフラストラクチャについては、次の最小ハードウェア要件を満たす必要があります。

次の動画では、インストール環境のサイズ設定に関する概要を説明します。

インストール トポロジで説明されているすべてのインストール シナリオに適用される、インストール コンポーネントの最小ハードウェア要件を次の表に示します。

この表では、オペレーティング システムで必要なハードディスク容量に加えて、ハードディスクの要件も考慮されています。アプリケーションやネットワーク トラフィックによっては、インストールに必要なリソースが次のリソースよりも多い場合や少ない場合があります。

インストール コンポーネント RAM CPU 最小ハードディスク
Cassandra 16 GB 8 コア 250 GB のローカル ストレージ（SSD は 2,000 IOPS に対応）
Message Processor/Router（同じパソコン） 16 GB 8 コア 100 GB
Message Processor（スタンドアロン） 16 GB 8 コア 100 GB
ルーター（スタンドアロン） 16 GB 8 コア 100 GB
アナリティクス - 同じサーバー上の Postgres/Qpid 16GB* 8 コア* 500 GB ～ 1 TB** のネットワーク ストレージ***（SSD バックエンドを推奨、1,000 IOPS 以上をサポート*）
アナリティクス - Postgres マスターまたはスタンバイ（スタンドアロン） 16GB* 8 コア* 500 GB ～ 1 TB** のネットワーク ストレージ***（SSD バックエンドを推奨、1,000 IOPS 以上をサポート*）
アナリティクス - Qpid（スタンドアロン） 16 GB 8 コア 30 GB ～ 50 GB のローカル ストレージ（SSD）

Qpid キューのデフォルトのサイズは 1 GB ですが、2 GB に増やすことができます。さらに容量が必要な場合は、Qpid ノードを追加します。
OpenLDAP/UI/Management Server 8 GB 4 コア 60 GB
UI/Management Server 4 GB 2 コア 60 GB
OpenLDAP（スタンドアロン） 4 GB 2 コア 60 GB

* Postgres のシステム要件をスループットに基づいて調整:

  • 250 TPS 未満: 8 GB、4 コアは、1, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ *** と考えることができます
  • 250 TPS 超: 16 GB、8 コア、1,000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 1, 000 TPS 以上: 16 GB、8 コア、2, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 2, 000 TPS 以上: 32 GB、16 コア、2, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 4, 000 TPS 以上: 64 GB、32 コア、4, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***

** Postgres ハードディスクの値は、Edge によってキャプチャされたすぐに使用できる分析に基づいています。分析データにカスタム値を追加する場合は、それに応じて値を増やす必要があります。必要なストレージを見積もるには、次の式を使用します。

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

次に例を示します。

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

*** Postgresql データベースにはネットワーク ストレージが推奨されます。理由は次のとおりです。

  • 必要に応じて、ストレージ サイズを動的にスケールアップできます。
  • ネットワーク IOPS は、現在の環境、ストレージ、ネットワーク サブシステムのほとんどで、臨機応変に調整できます。
  • バックアップと復元のソリューションの一部として、ストレージ レベルのスナップショットを有効にできます。

また、Monetization Services をインストールする場合のハードウェア要件は次のとおりです（オールインワン インストールではサポートされていません）。

収益化を行うコンポーネント RAM CPU ハードディスク
Management Server（Monetization Services を使用） 8 GB 4 コア 60 GB
アナリティクス - 同じサーバー上の Postgres/Qpid 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドを推奨、1,000 IOPS 以上をサポートするか、上記の表のルールを使用）。
アナリティクス - Postgres マスターまたはスタンバイ スタンドアロン 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドを推奨、1,000 IOPS 以上をサポートするか、上記の表のルールを使用）。
アナリティクス - Qpid（スタンドアロン） 8 GB 4 コア 40 GB ～ 500 GB のローカル ストレージ（SSD または高速 HDD）

250 TPS を超えるインストールでは、1, 000 IOPS をサポートするローカル ストレージを備えた HDD をおすすめします。

オペレーティング システムとサードパーティ ソフトウェアの要件

これらのインストール手順と提供されているインストール ファイルは、サポート対象ソフトウェアとサポート対象バージョンに示すオペレーティング システムとサードパーティ ソフトウェアを使用してテストされています。

Java

インストール前に、サポート対象の Java 1.8 が各マシンにインストールされている必要があります。サポートされている JDK は、サポートされているソフトウェアとそのバージョンに記載されています。

インストールを行うユーザーの JAVA_HOME 環境変数に JDK のルート ディレクトリが設定されていることを確認します。

SELinux

SELinux の設定によっては、Edge コンポーネントのインストールと起動で問題が発生することがあります。必要に応じて、インストール時に SELinux を無効にするか制限なしモードに設定し、インストール後に再度有効にできます。詳細については、Edge apigee-setup ユーティリティのインストールをご覧ください。

「apigee」ユーザーの作成

インストール手順により、「apigee」という名前の Unix システム ユーザーが作成されます。Edge のディレクトリとファイルの所有者は Edge プロセスと同様です。つまり、Edge コンポーネントは「apigee」ユーザーとして実行されます。必要に応じて、別のユーザーとしてコンポーネントを実行することもできます。

インストール ディレクトリ

デフォルトでは、インストーラはすべてのファイルを /opt/apigee ディレクトリに書き込みます。このディレクトリの場所は変更できません。このディレクトリは変更できませんが、/opt/apigee のシンボリック リンクの作成で説明されているように、/opt/apigee を別のロケーションにマッピングするシンボリック リンクを作成できます。

このガイドの説明では、インストール ディレクトリは /opt/apigee と記載されています。

シンボリック リンクを作成する前に、まず「apigee」という名前のユーザーとグループを作成する必要があります。このグループとユーザーは、Edge インストーラが作成するものと同じです。

シンボリック リンクを作成するには、bootstrap_4.19.06.sh ファイルをダウンロードする前に次の手順を実施します。これらの手順はすべて root ユーザーで行う必要があります。

  1. 「apigee」ユーザーとグループを作成します。 
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. /opt/apigee から目的のインストール ルートへのシンボリック リンクを作成します。 
    ln -Ts /srv/myInstallDir /opt/apigee

    ここで、/srv/myInstallDir は Edge ファイルの適切な場所です。

  3. インストール ルートとシンボリック リンクの所有権を「apigee」ユーザーに変更します。 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

掲載ネットワークの設定

インストール前にネットワーク設定を確認することをおすすめします。インストーラは、すべてのマシンが固定 IP アドレスを持つことを想定しています。次のコマンドを使用して設定を検証します。

  • hostname は、マシンの名前を返します。
  • hostname -i は、他のマシンからアドレスできるホスト名の IP アドレスを返します。

オペレーティング システムの種類とバージョンによっては、ホスト名が正しく設定されていない場合に /etc/hosts と /etc/sysconfig/network の編集が必要になることがあります。詳しくは、お使いのオペレーティング システムのドキュメントをご覧ください。

サーバーに複数のインターフェース カードが搭載されている場合、hostname -i コマンドはスペースで区切られた IP アドレスのリストを返します。デフォルトでは、Edge インストーラは返された最初の IP アドレスを使用しますが、これが正しい IP アドレスでない場合があります。この代替手段として、インストール構成ファイルで次のプロパティを設定できます。

ENABLE_DYNAMIC_HOSTIP=y

このプロパティを「y」に設定すると、インストール プロセスの一環として、使用する IP アドレスを選択するよう求められます。デフォルト値は n です。詳細については、Edge 構成ファイル リファレンスをご覧ください。

TCP ラッパー

TCP ラッパーは一部のポートの通信をブロックし、OpenLDAP、Postgres、Cassandra のインストールに影響を与える可能性があります。これらのノードで /etc/hosts.allow と /etc/hosts.deny をチェックし、必要な OpenLDAP、Postgres、Cassandra ポートにポート制限がないことを確認します。

iptables

必要な Edge ポート上のノード間の接続を妨げる iptables ポリシーがないことを確認します。必要に応じて、次のコマンドを使用して、インストール中に iptables を停止できます。

sudo/etc/init.d/iptables stop

CentOS 7.x の場合:

systemctl stop firewalld

ディレクトリへのアクセス

次の表に、Edge プロセスの特別な要件がある Edge ノードのディレクトリを示します。

サービス ディレクトリ 説明
ルーター /etc/rc.d/init.d/functions

Edge Router は Nginx ルーターを使用しており、/etc/rc.d/init.d/functions への読み取りアクセス権が必要です。

セキュリティ プロセスで /etc/rc.d/init.d/functions に権限を設定する必要がある場合は、700 に設定しないでください。700 に設定すると Router の起動が失敗します。

/etc/rc.d/init.d/functions への読み取りアクセスを許可するには、権限を 744 に設定します。
Zookeeper /dev/random Zookeeper クライアント ライブラリには、乱数ジェネレータ /dev/random への読み取りアクセス権が必要です。/dev/random の読み取りがブロックされている場合、Zookeeper サービスの起動に失敗することがあります。

Cassandra

すべての Cassandra ノードは、1 つのリングに接続される必要があります。Cassandra は信頼性とフォールト トレラントを確保するために、データレプリカを複数のノードに保存します。各 Edge キースペースのレプリケーション戦略によって、レプリカが配置される Cassandra ノードが決まります。詳細については、Cassandra のレプリケーション係数と整合性レベルについてをご覧ください。

Cassandra は、使用可能なメモリに基づいて Java のヒープサイズを自動的に調整します。パフォーマンスの低下やメモリの消費量が多い場合は、Java リソースを調整するをご覧ください。

Edge for Private Cloud をインストールした後、/opt/apigee/apigee-cassandra/conf/cassandra.yaml ファイルを調べて Cassandra が正しく構成されていることを確認できます。たとえば、Edge for Private Cloud のインストール スクリプトで次のプロパティが設定されていることを確認します。

  • cluster_name
  • initial_token
  • partitioner
  • seeds
  • listen_address
  • rpc_address
  • snitch

PostgreSQL データベース

Edge をインストールした後、システムで使用可能な RAM の量に基づき、次の PostgreSQL データベースの設定を調整できます。

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

以下の値を設定します。

  1. postgresql.properties ファイルを編集します。 
    vi /opt/apigee/customer/application/postgresql.properties

    ファイルが存在しない場合は作成します。

  2. 上記のプロパティを設定します。
  3. 編集内容を保存します。
  4. PostgreSQL データベースを再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

システム制限

Cassandra ノードと Message Processor ノードで次のシステム制限が設定されていることを確認します。

  • Cassandra ノードでは、/etc/security/limits.d/90-apigee-edge-limits.conf でインストール ユーザー（デフォルトは「apigee」）に対して soft および memlock、nofile、アドレス空間（as）の上限を設定します。次に例を示します。 
    apigee soft memlock unlimited
apigee hard memlock unlimited
apigee soft nofile 32768
apigee hard nofile 65536
apigee soft as unlimited
apigee hard as unlimited
  • Message Processor ノードでは、/etc/security/limits.d/90-apigee-edge-limits.conf でオープン ファイル記述子の最大数を 64, 000 に設定します。 
    apigee soft nofile 32768
apigee hard nofile 65536

    必要に応じて、この上限を引き上げることができます。たとえば、一度に大量の一時ファイルを開く場合はこの値を増やします。

ネットワーク セキュリティ サービス（NSS）

ネットワーク セキュリティ サービス（NSS）は、セキュリティ対応のクライアント アプリケーションとサーバー アプリケーションの開発をサポートする一連のライブラリです。NSS v3.19 以降がインストールされていることを確認する必要があります。

現在のバージョンを確認するには:

yum info nss

NSS を更新するには:

yum update nss

詳細については、RedHat のこちらの記事をご覧ください。

NSCD（ネームサービス キャッシュ デーモン）を使用する場合の IPv6 の DNS ルックアップを無効にする

NSCD（ネームサービス キャッシュ デーモン）をインストールして有効にした場合、Message Processor は 2 つの DNS ルックアップ（IPv4 用と IPv6 用）を実行します。NSCD を使用する場合は、IPv6 で DNS ルックアップを無効にする必要があります。

IPv6 で DNS ルックアップを無効にするには:

  1. すべての Message Processor ノードで /etc/nscd.conf を編集します。
  2. 次のプロパティを設定します。 
    enable-cache hosts no

Google Cloud Platform 上の RedHat/CentOS 7 で IPv6 を無効にする

Google Cloud Platform 上の RedHat 7 または CentOS 7 に Edge をインストールする場合は、すべての Qpid ノードで IPv6 を無効にする必要があります。

IPv6 を無効にする手順については、該当する OS バージョンの RedHat または CentOS ドキュメントをご覧ください。たとえば、次のようなことができます。

  1. エディタで /etc/hosts を開きます。
  2. コメントアウトするには、次のいずれかの列に「#」文字を挿入します。 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. ファイルを保存します。

AWS AMI

Red Hat Enterprise Linux 7.x 用の AWS Amazon Machine Image（AMI）に Edge をインストールする場合は、まず次のコマンドを実行する必要があります。

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

ツール

インストーラでは、EL5 または EL6 で提供される標準バージョンの次の UNIX ツールが使用されます。

awk

式の

libxslt

RPM

unzip

ベース名

grep

LUA ソケット

rpm2cpio

useradd

bash

 hostname

ls

sed

週

BC

id

net-tools

sudo

wget

curl

Libaio

perl（procps から）

tar

xerces-c
Cyrus-Sasl libdb4 pgrep（procps から） tr おいしい

date

 libdb-cxx

ps

uuid

chkconfig
ディレクトリ名 リバーブ pwd 名前  
エコー librdmacm python    

ntpdate

サーバーの時刻は同期することをおすすめします。まだ構成されていない場合、ntpdate ユーティリティはこの目的のために、サーバーが時刻を同期しているかどうかを確認できます。このユーティリティは、yum install ntp を使用してインストールできます。これは、OpenLDAP 設定を複製する場合に特に便利です。サーバーのタイムゾーンは UTC で設定していることに注意してください。

OpenLDAP 2.4

オンプレミスのインストールには OpenLDAP 2.4 が必要です。サーバーがインターネットに接続している場合は、Edge のインストール スクリプトが OpenLDAP をダウンロードしてインストールします。サーバーがインターネットに接続していない場合は、Edge のインストール スクリプトを実行する前に OpenLDAP がインストールされていることを確認する必要があります。RHEL/CentOS では、yum install openldap-clients openldap-servers を実行して OpenLDAP をインストールできます。

13 ホストのインストールと 2 つのデータセンターを持つ 12 ホストのインストールの場合、OpenLDAP をホストするノードが複数あるため、OpenLDAP レプリケーションが必要です。

ファイアウォールと仮想ホスト

virtual という用語は、一般的に IT 分野では負荷がかかりすぎるため、Apigee Edge for Private Cloud のデプロイおよび仮想ホストに当てはまります。用語 virtual の主な用途は 2 つあります。

  • 仮想マシン（VM）: 必須ではありませんが、デプロイによっては VM テクノロジーを使用して Apigee コンポーネント用に分離されたサーバーが作成されます。物理ホストと同様に、VM ホストにはネットワーク インターフェースとファイアウォールを設定できます。
  • 仮想ホスト: Apache 仮想ホストに類似したウェブ エンドポイント。

VM 内のルーターは、ホスト エイリアスまたはインターフェース ポートが異なっている限り、複数の仮想ホストを公開できます。

1 つの物理サーバー（A）で「VM1」と「VM2」という名前の 2 つの VM を実行している場合があります。「VM1」が、VM 内の「eth0」という名前を持ち、仮想化マシンまたはネットワーク DHCP サーバーによって IP アドレス 111.111.111.111 が割り当てられている仮想イーサネット インターフェースを公開するとします。すると、VM2 は「eth0」という名前の仮想イーサネット インターフェースを公開し、IP アドレス 111.111.111.222 が割り当てられます。

2 つの VM のそれぞれで Apigee ルーターを実行している場合があります。Router は、次のような架空の例のように、仮想ホストエンドポイントを公開します。

VM1 の Apigee ルーターは、eth0 インターフェース（特定の IP アドレス）を持つ 3 つの仮想ホスト api.mycompany.com:80、api.mycompany.com:443、test.mycompany.com:80 を公開します。

VM2 のルーターは api.mycompany.com:80 を公開します（VM1 と同じ名前とポート）。

物理ホストのオペレーティング システムにネットワーク ファイアウォールが存在する可能性があります。そのファイアウォールは、仮想インターフェース（111.111.111.111:{80, 443} と 111.111.111.222:80）で公開されているポートにバインドされる TCP トラフィックを渡すように構成する必要があります。また、各 VM のオペレーティング システムでは、eth0 インターフェースに独自のファイアウォールを設定し、ポート 80 と 443 での接続を許可します。

ベースパスは、デプロイしたさまざまな API プロキシに API 呼び出しをルーティングするための 3 番目のコンポーネントです。API プロキシ バンドルは、異なるベースパスを使用している場合にエンドポイントを共有できます。たとえば、あるベースパスを http://api.mycompany.com:80/ として定義し、別のベースパスを http://api.mycompany.com:80/salesdemo として定義できます。

この場合、http://api.mycompany.com:80/ トラフィックを 2 つの IP アドレス（VM1 の 111.111.111.111 と VM2 の 111.111.111.222）に分割するロードバランサまたはトラフィック ディレクターが必要です。この関数は特定のインストールに固有のもので、ローカル ネットワーキング グループによって構成されます。

ベースパスは API をデプロイするときに設定されます。上記の例では、組織 mycompany-org に、ホストエイリアスが api.mycompany.com でポートが 80 に設定された 2 つの API（mycompany と testmycompany）をデプロイできます。デプロイでベースパスを宣言しないと、ルーターは受信リクエストを送信する API を認識しません。

たとえば、API が testmycompany をベース URL /salesdemo を指定してデプロイした場合、ユーザーはその API に http://api.mycompany.com:80/salesdemo を使用してアクセスします。/ のベース URL を使用して API mycompany をデプロイすると、ユーザーは http://api.mycompany.com:80/ URL で API にアクセスできます。

ライセンス

Edge のインストールごとに、Apigee から取得した一意のライセンス ファイルが必要となります。Management Server のインストール時に、ライセンス ファイルのパス（例: /tmp/license.txt）を指定する必要があります。

ライセンス ファイルはインストーラによって /opt/apigee/customer/conf/license.txt にコピーされます。

ライセンス ファイルが有効な場合、Management Server は、有効期限と許可された Message Processor（MP）の数を検証します。いずれかのライセンス設定が期限切れの場合は、/opt/apigee/var/log/edge-management-server/logs にあるログでそれを調べることができます。その場合は、Apigee Edge サポートに移行の詳細をお問い合わせください。

まだライセンスをお持ちでない場合は、Apigee Sales にお問い合わせください。