ThingWorx クラスタのサイジングに関する考慮事項
ThingWorx Foundation ノードのサイジング
クラスタ構成の運用では、ThingWorx Foundation の個々のノードのサイズはほとんど変わりません。クラスタノードごとに、Thing モデル全体をロードするための十分なメモリが必要です。したがって、各クラスタノードのサイズは、単一サーバーノードのサイズと一致していなければなりません。たとえば、中規模の単一サーバーのサイズは 16 基の vCPU と 32 GiB RAM です。同様に、2 ノードクラスタの場合、各クラスタノードは 16 基の vCPU と 32 GiB RAM になります。
Apache Ignite が別個にデプロイされている場合、プロパティの状態の情報は Ignite ノードに転送されるので、Foundation サーバーのメモリ消費量がわずかに減る可能性があります。
CPU 利用率はバックグラウンドでクラスタ同期化タスクを実行するために上昇します。クラスタ構成では、共有キャッシュの遅延が増えることにより、個々のオペレーションが若干遅くなることもあります。これは複数のノードにまたがって多数のオペレーションを並列で実行する機能 (ビジネスロジック/ユーザーのリクエスト) によって相殺されます。
高可用性を実現するには、個々のノードの適切なサイズを決定した後で、アプリケーションのピーク負荷の処理に必要な数より 1 つ以上多い数の ThingWorx Foundation ノードをデプロイすることをお勧めします。これにより、1 つのノードで障害が発生した場合でも、クラスタは引き続き必要なパフォーマンスを発揮できるようになります。
接続サーバーノードのサイジング
クラスタ構成の運用では、デバイスの負荷をクラスタ全体に分散したり、ノードで障害が発生した場合に分散し直したりするために、接続サーバーが必要です。
Foundation ノードと同様に、想定される数のデバイスを処理するために必要な数より 1 つ以上多い数の接続サーバーをデプロイすることをお勧めします。これにより、接続サーバーの 1 つのノードで障害が発生した場合でも、接続サーバーはすべてのデバイスとの接続を維持できます。
接続サーバーの個々のオプションのシステム要件については、ThingWorx Connection Services ヘルプセンターを参照してください。
Apache ZooKeeper ノードのサイジング
Apache ZooKeeper は分散アプリケーションを同期化するためのオープンソースソリューションです。ThingWorx ノードの監視およびリーダー選出機能が備わっています。
それぞれ 2 vCPU と 2 GiB RAM を備えた 3 ノードセットが推奨されます。クォーラムを維持するにはインスタンス数が奇数である必要があります。
詳細については Apache ZooKeeper のシステム要件 https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq を参照してください。
データベースノードのサイジング
高可用性の限界を超えると、クラスタ化された ThingWorx 構成ではデータベースの負荷が上昇します。これを説明するために、Microsoft Azure 仮想マシンを使用して、同一負荷でのテストを 5 つの異なる中規模デプロイメントで実行しました。
|
単一ノードとクラスタでのパフォーマンスの比較 (PostgreSQL のみ)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
なし
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
なし
|
なし
|
なし
|
なし
|
なし
|
|
ノード当りの結果 (平均)
|
26,000 WPS
19 HTTP Ops
|
12,000 WPS
10 HTTP Ops
|
10,000 WPS
6 HTTP Ops
|
7,000 WPS
6 HTTP Ops
|
6,000 WPS
2 HTTP Ops
|
|
結果の合計
|
24,000 WPS
19 HTTP Ops
|
30,000 WPS
24 HTTP Ops
|
28,000 WPS
22 HTTP Ops
|
30,000 WPS
12 HTTP Ops
|
|
|
備考: Sizing Guide の推奨サイズは、ThingWorx の実装をサイジングするときの初期ベースラインとして使用するためのものです。個々の結果は Edge のコンフィギュレーションやアプリケーションの負荷などによって異なります。
|
|||||
上記のテストではデータ取得のわずかな改善が見られましたが、データベースリソースが不十分なため HTTP リクエストのパフォーマンスは向上していません。
これに対処するため、さらに大きな RDBMS インスタンスを使用したり、以下に示すように InfluxDB を使用したりすることによって、スケーラビリティを向上させることができます。
|
単一ノードとクラスタのパフォーマンスの比較 (PostgreSQL + InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
なし
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
ノード当りの結果 (平均)
|
90,000 WPS
120 HTTP Ops
|
53,000 WPS
187 HTTP Ops
|
39,000 WPS
148 HTTP Ops
|
31,500 WPS
127 HTTP Ops
|
27,000 WPS
108 HTTP Ops
|
|
結果の合計
|
106,000 WPS
375 HTTP Ops
|
118,000 WPS
445 HTTP Ops
|
126,000 WPS
508 HTTP Ops
|
135,000 WPS
540 HTTP Ops
|
|
|
備考: Sizing Guide の推奨サイズは、ThingWorx の実装をサイジングするときの初期ベースラインとして使用するためのものです。個々の結果は Edge のコンフィギュレーションやアプリケーションの負荷などによって異なります。
|
|||||
 |
これらのテストではオープンソースの InfluxDB が使用されており、これでは高可用性は実現されません。本番環境での ThingWorx クラスタの実装には InfluxDB Enterprise が推奨されます。InfluxDB Enterprise のサイシングでは、示されている 2 つの InfluxDB "データ" ノードに加え、3 つの "メタ" ノードを計画し、通常はそれぞれに 1-2 vCPU と 0.5-1GiB RAM を割り当てます。InfluxDB のサイジングの詳細については、https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/ を参照してください。
|
Apache Ignite ノードのサイジング
ThingWorx クラスタで、Apache Ignite はプロパティ値とファイル転送ジョブなどの追加データのための共有キャッシュを提供します。
Ignite は ThingWorx Foundation プロセスに埋め込むことができ、その場合には別個にインストールする必要がありません。あるいは、負荷をさらに分散するため、Ignite を別個のクラスタとしてデプロイすることもできます。
Ignite は以下の 2 つのモードのいずれかで実行することもできます。
• PARTITIONED モード - データは複数のパーティションに均等に分割され、参加ノード間で均等に分割されます。キャッシュ書き込みのパフォーマンスが最大になります。
• REPLICATED モード - 各 Ignite インスタンスがすべてのデータポイントのコピーを持ちます。キャッシュ読み取りのパフォーマンスが最大になります。
詳細については、キャッシュモードに関する Apache Ignite のドキュメンテーション https://apacheignite.readme.io/docs/cache-modes を参照してください。
Ignite に起因する主な負荷は各 ThingWorx Foundation と Ignite インスタンスの間のネットワークスループットです。CPU、ディスク、メモリの要件に基づけばクラウドプロバイダから提供されている VM のなかでより小規模のものが選ばれる傾向がありますが、ネットワークスループットが低下していないか監視することが重要です。
スループットの問題が発生した場合、ネットワーク容量が大きい、より大規模なシステムに移行するか、Ignite ノードを追加して (パーティションモードを使用) 負荷を分散することによって対処できます。
おおよその出発点としては、ThingWorx Foundation ノードと同じメモリサイズとするのが安全で堅実な見積りになります。
共有キャッシュのメモリフットプリントをさらに正確に計算するには、以下の手順に従います。
1. ThingWorx プロパティキャッシュ用の VTQ (値、タイムスタンプ、品質) メモリフットプリントを計算します。
a. 各タイプの Thing について、メモリ内のデータ型のサイズを求めます。たとえば、プロパティが 50 文字の文字列であり、各文字に 2 バイト必要な場合、その文字列には 100 バイトのメモリが必要です。
b. 8 バイトを加算します (その値の日付/時刻に 4、値の品質に 4)。
c. 2 を掛けます。ThingWorx は各プロパティの現在の値と前の値をキャッシュします。
d. そのタイプの Thing の数を掛けます。
e. 各タイプの Thing の結果を合算します。
2. Ignite での値のメモリ内インデックス用に 30 % を加算します。
3. Ignite クラスタ全体で使用するデータコピーの数を掛け合わせます。たとえば、1 つの Ignite ノードで障害が発生した場合にデータが失われないようにデータのバックアップが 1 つ必要な場合、2 を掛けます。
4. デプロイする Ignite クラスタノードの数で割ります。
5. 各 Ignite ノードには、それ自体のオペレーション用に最大で 300 MB が追加で必要です。
詳細については、Apache Ignite のドキュメンテーション https://apacheignite.readme.io/docs/capacity-planning を参照してください。