Performance Monitoring Toolset デプロイメントガイド

このドキュメントでは、Performance Monitoring Toolset（パフォーマンス監視ツールセット）のデータ推定について説明し、ユーザー自身によるデプロイメントのハードウェア要件のサイズ設定を可能にします。このドキュメントは次の推定に役立ちます。

• ColdFusion の 1 つのインスタンスにマッピングする必要がある Elasticsearch インスタンスの数。
• Performance Monitoring Toolset または ColdFusion によって生成され、ColdFusion で受信されたトラフィックに基づいて Elasticsearch に保存されるデータの量。

このドキュメントの背景

ユーザーの主な問い合わせは以下に集中しています。

• 特定デプロイメントの Elasticsearch 要件の決定
• 指定された量の ColdFusion サーバーに対する Elasticsearch 要件の評価

ベンチマークがなければ、お客様は、経験に基づくサイズ設定に頼らざるを得ず、ツールが要件を完全には表現できていないリスクがありました。

このドキュメントの範囲

このドキュメントでは、Performance Monitoring Toolset で生成されるデータを推定するための基本的な構成要素を示します。 

また、1 つの ColdFusion ノードで生成されるデータを構成要素として検討し、様々なデプロイメントに拡大適用します。

Performance Monitoring Toolset の基本構成

本番環境にデプロイするには、Performance Monitoring Toolset を ColdFusion サーバーとは別にデプロイすることをお勧めします。

Performance Monitoring Toolset には、次の 2 つのコンポーネントがあります。

1. 監視サーバー
2. データストア

サーバー構成の仕様は次のとおりです。

Performance Monitoring Toolset の最小要件：

1. RAM：Performance Monitoring Toolset ランタイムとデータストアサービスで使用可能な 8 GB 以上の RAM（16 GB を推奨）。
2. CPU： 4 CPU コア（8 CPU コアを推奨）。
3. ハードディスク：Performance Monitoring Toolset データストア用の 50 GB 以上の空きディスク容量（100 GB を推奨）。

Performance Monitoring Toolset サーバーの最小要件：

1. RAM：Performance Monitoring Toolset サーバーとデータストアサーバーが同じマシンにインストールされている場合は 8 GB。Performance Monitoring Toolset サーバーが別個にインストールされている場合は、4 GB の RAM が必要です。
2. ハードディスク：Performance Monitoring Toolset サーバーとデータストアサーバーが同じマシンにインストールされている場合は 40 GB の空きディスク容量。Performance Monitoring Toolset サーバーのスタンドアロンインストールでは、10 GB の空きディスク容量を推奨します。

データストアサーバー（Elasticsearch 5.6.3）の最小要件：

1. RAM：Performance Monitoring Toolset サーバーとデータストアサーバーが同じマシンにインストールされている場合は 8 GB。
2. ハードディスク：40 GB の空きディスク容量。Elasticsearch I/O のパフォーマンスを最適化するには、SSD をお勧めします。
3. Elasticsearch プロセスに最低限必要な RAM は 4 GB です。

Performance Monitoring Toolset と共に複数の ColdFusion インスタンスを設定してあり、サーバが多数のリクエストを受信している場合は、データストアのクラスターをインストールすることをお勧めします。

データストアの正常性監視について詳しくは、データストアの正常性監視を参照してください。

ユースケース

Elasticsearch クラスターを使用した Performance Monitoring Toolset：

複数の ColdFusion（CF）ノードを持つトポロジを使用した大規模なデプロイメントでは、Elasticsearch クラスターを使用することをお勧めします。また、このクラスターを適切なハードウェアでバックアップする必要があります。

1 つの Elasticsearch ノードを使用した Performance Monitoring Toolset：

生成された指標データに基づく 1 つの Elasticsearch（ES）ノードの設定を次の表に示します。また、この表はアーカイブ戦略も示しています。

Performance Monitoring Toolset には、8 GB のヒープを推奨します。

リクエスト以外のデータサイズが 5 KB の場合：

Performance Monitoring Toolset でのデータのアーカイブ

時間と共にデータが増加すると、データを適切にアーカイブする必要性も高まります。

アーカイブは、データの定期バックアップの維持管理や組織のデータ保持ポリシーへの準拠に役立ちます。アーカイブを使用すれば、明確に定義されたプロセスを使用して古くなったデータを削除することができます。Performance Monitoring Toolset では、リポジトリでレコードをアーカイブしたり、アーカイブの頻度はデータ保持期間を設定したりできます。

まず、次のフィールドを指定してリポジトリを作成する必要があります。

アーカイブは、手動でも自動でも実行できます。

1. 手動 - 「アーカイブ」セクションに移動し、リポジトリを選択してアーカイブを手動でトリガーします。
2. 自動アーカイブ - 定期的に実行するようにアーカイブのスケジュールを設定することもできます。それには、詳細を指定する必要があります。

        a. 有効化：選択したリポジトリでアーカイブを有効化するには、このチェックボックスをオンにします。

        b. リポジトリ名：作成したすべてのリポジトリをリストします。

        c. 次より古いデータをアーカイブ：アーカイブの開始時点からデータを保持する必要がある日数を入力します。30 日を指定した場合、過去 30 日のデータのみが取得されます。残りはアーカイブされます。

        d. 頻度：間隔（日数）を入力して、アーカイブの定期的なスケジュールを設定します。

詳しくは、次のトピックを参照してください。

• Performance Monitoring Toolset の設定
• Elasticsearch ドキュメントの「Heap: Sizing and Swapping」（ヒープのサイズ設定とスワップ）
• Elasticsearch ドキュメントの「Production Deployment」（本番環境へのデプロイ）

Elasticsearch システム構成

Performance Monitoring Toolset では、Elasticsearch をデータストアとして使用します。  Elasticsearch はファイルを大量に処理する I/O 操作を実行するので、SSD ドライブの使用をお勧めします。

Web サーバーコネクタを ColdFusion に設定する際に、「Performance Monitoring Toolset のプロパティ」セクションの「ハートビート間隔」オプションを設定できます。コネクタ指標が Elasticsearch にポストされる頻度が、この設定で決まります。

マシン上のメモリやその他のプロセスの可用性に基づいて、最適なヒープサイズを Elasticsearch に割り当てる必要があります。

Elasticsearch の JVM ヒープサイズは、<pmt_root>/datastore/config ディレクトリの jvm.config ファイルを編集して設定できます。

ヒープサイズの下限と上限を 8 GB に設定するには、次の設定を更新します。

• - Xms8g
• - Xmx8g

ヒープサイズは、物理 RAM の 50％以下にする必要があります。これは、カーネルファイルシステムのキャッシュ用に十分な物理 RAM を確保するためです。

実行時に JVM ヒープサイズが変更されないようにするには、最大ヒープサイズに等しい初期ヒープサイズで JVM を起動します。

Elasticsearch で使用されるデフォルトのガベージコレクションは CMS です。マルチコア CPU での Serial GC の使用はお勧めしません。

JVM ヒープサイズの設定について詳しくは、Elasticsearch ドキュメントの Heap: Sizing and Swapping（ヒープのサイズ設定とスワップ）を参照してください。

オペレーティングシステムの設定

ファイルスワッピング／ページング

ホストシステムでメインメモリとセカンダリストレージの間のスワッピングを無効にするには、Linux で次のシステムコマンドを使用します。

sudo swapoff –a

スワッピングを完全に無効にするには、/etc/fstab ファイルを編集し、「swap」という単語を含む行をすべてコメントアウトします。

Windows では、次の UI 操作でページングファイルを無効にします。

システムのプロパティ／詳細設定／パフォーマンス／設定／詳細設定／仮想メモリ／変更

Linux では、sysctl で vm.swappiness の値 が 1 に設定されていることを確認します。これにより、カーネルがスワップする傾向が低くなります。通常の状況下ではスワップしませんが、緊急状態ではシステム全体がスワップできるようになります。

もう 1 つの選択肢は、mlockall（Linux／Unix システムの場合）または VirtualLock（Windows の場合）を使用してプロセスのアドレス空間を RAM に固定し、Elasticsearch メモリがスワップアウトされないようにすることです。それには、config/elasticsearch.yml ファイルに次の行を追加します。

bootstrap.memory_lock: true

また、<pmt_root>/datastore/config ディレクトリにある elasticsearch.yml ファイルで次の設定を使用して、mockall を有効にすることもできます。

bootstrap.mlockall: true

これで、JVM のメモリがロックされて、OS によってスワップされないようになります。

開いているファイル記述子の制限

（これは nix システムにのみ適用されます）

システムユーザーが開くことができるファイル記述子の数を設定するには、/etc/security/limits.conf ファイルを編集します。

この数を 65536 以上に設定します。

os_user soft nofile <no_of_files>

os_user hard nofile <no_of_files>

次に例を示します。

* soft nofile 65536

* hard nofile 65536

ユーザーあたりのプロセスの制限

ユーザーが使用できるプロセスの最大数を 2048 以上に設定します。

/etc/security/limits.conf file

* soft nproc <no_of_proc>

* hard nproc <no_of_ proc >

または、次のように ulimit コマンドを使用します。

ulimit –u 2048

仮想メモリ

Elasticsearch では、64 ビットシステムのインデックスを格納するのに、デフォルトで mmapfs ディレクトリを使用します。オペレーティングシステムにおける mmap カウントのデフォルトの上限は低すぎる可能性があり、その結果、メモリ不足例外が発生する場合があります。

Linux では、次のコマンドを root として実行して、この上限を増やすことができます。

sysctl -w vm.max_map_count=262144

この値を永続的に設定するには、/etc/sysctl.conf の vm.max_map_count 設定を更新します。

設定された値を確認するには、再起動後に sysctl vm.max_map_count を実行します。

ポート範囲と接続タイムアウト

/etc/sysctl.conf ファイルで次のディレクティブを使用して、ポート範囲を広げ、TCP 接続タイムアウトを短くします。

net.ipv4.ip_local_port_range = 1024 65535

net.ipv4.tcp_fin_timeout = 30

Elasticsearch クラスターの設定

Performance Monitoring Toolset では、複数のホストに配置できる Elasticsearch ノードクラスターをデータストアにすることができます。これにより、データストアを必要に応じて水平方向または垂直方向にスケーリングできます。

<pmt_root>/datastore/config にある elasticsearch.yml ファイルを編集します。

次のように、Elasticsearch ノードの IP アドレスとポートのペアを discovery.zen.ping.unicast.hosts プロパティに追加します。

discovery.zen.ping.unicast.hosts: ["xx.xx.xx.xx:9300", "zz.zz.zz.zz:9301"]

このポート値を、ノード間通信に使用される transport.tcp.port に設定する必要があります。ポート値は、それぞれのノードの elasticsearch.yml ファイルに記載されています。

次のプロパティを true に設定して、Elasticsearch ノードの 1 つをマスターとして設定してください。

node.master: true

その他のすべての Elasticsearch ノードでは、このプロパティを false に設定してください。

node.master: false

次のプロパティを (マスター適格ノードの総数 / 2 + 1) に設定します。

discovery.zen.minimum_master_nodes  

これにより、マスターの選択時に通信する必要があるノードの数を決定することで、「スプリットブレイン」問題を回避できます。

設定の変更を有効にするには、ノードを再起動します。

Elasticsearch のヒープサイズの設定

デフォルトでは、Performance Monitoring Toolset データストアサービスは、最小サイズと最大サイズが 2 GB のヒープを使用するように設定されています。監視用に多数の ColdFusion サーバーを設定しない場合は、これで十分です。ただし、求めるパフォーマンス上のメリットを得るには、ヒープサイズを最適な値に設定することが重要です。

では、Elasticsearch のヒープサイズを変更するにはどうすればよいでしょうか。ヒープサイズを設定するには、2 とおりの方法があります。

Windows 以外のプラットフォームと Windows プラットフォーム（Elasticsearch をコマンドプロンプトで実行する場合）

ヒープサイズを設定するための手順は次のとおりです。

Windows プラットフォーム（Elasticsearch をサービスを介して実行する場合）

Elasticsearch を Windows サービスを介して実行する場合、ヒープサイズの設定方法は異なります。

ヒープサイズを設定するには、次の手順に従います。

Elasticsearch のヒープサイズを設定する際の推奨事項は次のとおりです。

1. 最小ヒープサイズ（Xms）と最大ヒープサイズ（Xmx）を同じ値に設定します。
2. Elasticsearch で使用できるヒープが大きいほど、キャッシュに使用できるメモリが増えます。ただし、ヒープが大きすぎると、ガベージコレクションによる一時停止の時間が長くなるおそれがあります。
3. Xmx を物理 RAM の 50％以下に設定して、カーネルファイルシステムのキャッシュ用に十分な物理 RAM を確保します。32 GB を超えないようにしてください。