ハードウェア要件

Orchestrator をホストするために利用できるエンタープライズ クラウド デプロイには複数の選択肢があります。たとえば、アマゾン ウェブ サービス (AWS)、Microsoft Azure、Google Cloud Platform (GCP) などです。選択したデプロイ オプションや構築予定の環境のサイズに応じて、異なるハードウェア要件を確認する必要があります。

この章では、これらのいくつかのシナリオに固有のハードウェア要件に関する洞察を提供します。

小規模から中規模のデプロイ

ハードウェア要件は、開発環境と運用環境によって異なります。運用環境と同じハードウェア要件をテストおよび開発の目的で使用することもできますが、特に大規模なデプロイの場合は、不必要な高いコストが生じてしまいます。

開発環境

これらの要件は、最大 100 台の Unattended ロボットが同時に実行されることを想定しています。次のように構成された 2 台のマシンを使用できます。1台は Orchestrator および Elasticsearch (任意) 用、もう 1 台は SQL Server 用です。

Web アプリケーション サーバー

CPU コア数 (> 2GHz)	RAM (GB)	HDD (GB)
4	4	150

SQL Server

CPU コア数 (> 2GHz)	RAM (GB)	HDD (GB)
4	8	300

運用環境

運用環境では、次の各役割に対してそれぞれ専用のサーバーを用意することを強くお勧めします。

• Orchestrator Web アプリケーション
• SQL Server データベース エンジン
• Elasticsearch と Kibana

マルチノードでのインストールでは、上記に加えて次のものが必須です。

• Orchestrator の場合 (高可用性自体を実現するには 3 つ以上の HAA ノード、地理的冗長性を確保するには 6 つ以上の HAA ノードが必要です)。
  注:

  Orchestrator のマルチノード デプロイは、通信に REdis Serialization Protocol (RESP) を使用するため、このプロトコルを使用するあらゆるソリューションによる設定が可能です。

  UiPath がサポートしているソリューションは HAA のみです。

以下に詳述するように、必要な各サーバーのハードウェア構成は、デプロイのサイズによって異なります。ここでのハードウェア要件は、次の定義に基づいてデプロイされたロボットで行ったテストから導きだされたものです。

• ロボットから Orchestrator へのメッセージ送信頻度は、1 秒当たり 1 メッセージとする。
• ロボットは、60 秒間に次のメッセージを送信する。
  • 15 件のメッセージ ログ
  • 2 件のハートビート
  • 6 件のアセット取得要求
  • 6 件のキュー アイテム追加要求
  • 6 件のキュー アイテム取得要求

最大 250 台の Unattended ロボットに対応

Web アプリケーション サーバー

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<20	4	4	100
<50	4	4	100
<100	4	4	150
<200	4	4	200
<250	4	4	200

注:

ロボットが 200 台以上ある場合は、UiPath.Orchestrator.dll.config ファイルで、SQL 接続文字列のプールで許可される接続の数を 500 に増やします。そのためには、Max Pool Size=500 パラメーターを接続文字列に追加し、以下の例のようにする必要があります。

<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max Pool Size=500;" />

SQL Server

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<20	4	8	100
<50	4	8	200
<100	4	8	300
<200	8	8	SSD 400
<250	8	16	SSD 400

必要ディスク容量は、次の項目に大きく依存します。

• ワーク キューが使用されているかどうか。ワーク キューが使用されている場合、毎日/毎週追加されるトランザクションの平均数と、各トランザクションのサイズ (フィールドの数や各フィールドのサイズ) に依存します。
• 正常に処理されたキュー アイテムの保持期間 (ユーザーは独自の保持ポリシーを施行する必要があります)。
• ロボットによって記録されたメッセージがデータベースに格納されるかどうか。格納される場合、フィルター処理によって特定のレベルのメッセージのみを DB に格納できます (たとえば、ログ レベル Error および Critical のメッセージを DB に格納し、ログ レベルが Info、Warn および Trace のメッセージを Elasticsearch に格納する）。
• ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
• 古いログ記録メッセージの保持期間 (ユーザーは自身の保持ポリシーを施行する必要があります)。
• ロボットに設定されたログ記録レベルの値。たとえば、ロボットのログ記録レベルが Info に設定されている場合、Info、Warn、Error、Critical のレベルが設定されたメッセージのみが Orchestrator に送信されます。レベルが Debug、Trace および Verbose のメッセージは無視され、Orchestrator には送信されません。

Elasticsearch サーバー

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<20	4	4	100
<50	4	4	100
<100	4	8	150
<200	4	12	200
<250	4	12	300

必要ディスク容量は、次の項目に依存します。

• 保持期間 (ユーザーは、独自の保持ポリシーの実施が必要となります)。
• ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
• ロボットに設定されたログ レベルの値。たとえば、ロボットのログ レベルが Info に設定されている場合、レベルが Info、Warn、「Error」、「Critical」のメッセージのみが Orchestrator に送信されます。レベルが「Debug」、「Trace」および「Verbose」のメッセージは無視され、Orchestrator には送信されません。
  注: ロボットが 50 台以上ある場合は、-Xms と -Xmx 引数の両方をメモリの合計の半分に設定することで、Elasticsearch が使用する Java 仮想マシンに利用可能な RAM の 50% を使用するよう指示します。これは ES_JAVA_OPTS 環境変数を使用するか、jvm.options ファイルを編集することで実行できます。

250 台から 500 台の Unattended ロボットに対応

Web アプリケーション サーバー

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<300	8	8	200
<400	8	8	220
<500	16	16	250

SQL Server

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<300	16	32	SSD 400
<400	16	32	SSD 500
<500	16	32	SSD 600

注: SQL Server Standard Edition では、使用する最大 CPU コア数は 16 です。仮想マシンの場合は、このコア数をそれぞれ 4 コアを持つ 4 つの仮想ソケットとして取得していることを確認してください (8 コアを持つ 2 ソケットや 2 コアを持つ 8ソケットではない)。Enterprise Edition では、16 コアを取得するための組み合わせは重要ではありません。

ロボットが 300 台以上ある場合は、SQL Server データベースにログ記録のメッセージをすべて保存しないことを検討してください。DB にはログ レベルが Error と Critical のメッセージのみを格納し、すべてのメッセージ (Error と Critical を含む) は Elasticsearch に格納してください。

Elasticsearch サーバー

ロボット数	CPU コア数 (2GHz 以上)	RAM (GB)	HDD (GB)
<300	4	12	300
<400	4	16	500
<500	4	16	600

大規模なデプロイ

IaaS での有人デプロイ

次のセクションは、Azure Infrastructure as a Service (IaaS) サービスを使用した、大規模で拡張可能なデプロイの例です。次の構成が使用されました。

• Orchestrator 用の仮想マシン可用性セット
• Elasticsearch の仮想マシン可用性セット
• Windows Server SQL VM
• Azure Load Balancer
• 分散 DNS サービス (CloudFlare など)

アーキテクチャ

注:

下記のアーキテクチャの例には、任意のコンポーネントや異なるコンポーネント (CyberArk、UiPath High Availability Add-on など) が含まれています。

ここに示した Jumpbox は必須ではありませんが、分離性と安全性を提供するため、運用環境に推奨されるベスト プラクティスです。

シングル ノード アーキテクチャ

マルチノード アーキテクチャ

ハードウェア要件

このセクションでは、以下の「デプロイのスケーリング」に記載されているパフォーマンス テストに使用されるハードウェア構成について説明します。

Orchestrator ノード

各 Orchestrator ノードは次のように構成する必要があります。

VCPUs	RAM (GB)	SSD (GB)
16	32	128

SQL Server

SQL Server 仮想マシンの仕様は、Orchestrator ノードの数に合わせて拡張する必要があります。

Orchestrator ノード	VCPUs	RAM (GB)	ディスク
1 - 2	8	16	1TB - データベース、tempDB、およびトランザクション ログ用の Ultra SSD ディスク
5	16	32	1TB - データベース用の Ultra SSD ディスク 1TB - tempDB 用の Ultra SSD ディスク 1TB - トランザクション ログ用の Ultra SSD ディスク
10	32	64	1TB - データベース用の Ultra SSD ディスク 1TB - tempDB 用の Ultra SSD ディスク 1TB - トランザクション ログ用の Ultra SSD ディスク
15	40	96	1TB - データベース用の Ultra SSD ディスク 1TB - tempDB 用の Ultra SSD ディスク 1TB - トランザクション ログ用の Ultra SSD ディスク

Elasticsearch 可用性セット

Elasticsearch 可用性セットは、3 つのマスターノードと 6 つのデータノード、合計 9 つのノードで構成され、それぞれ次の仕様を備えています。

VCPUs	RAM (GB)	OS SSD (GB)	Data SSD (TB)
8	16	128 (5000 IOPS 100 MB/s のスループット)	1 (5000 IOPS 200 MB/s のスループット)

ソフトウェア要件

• オペレーティング システム

• データベース

• ログ

上記のバージョンは、下記の負荷でデプロイおよびパフォーマンスのテストを行った際に使用したバージョンです。

負荷分散

マルチノード デプロイの場合、2 つの Azure Standard ロード バランサーを使用することをお勧めします。

• Orchestrator サーバー用に 1 つ。
• Elasticsearch サーバー用に 1 つ。

High Availability Add-on

• Orchestrator の場合 (高可用性自体を実現するには 3 つ以上の HAA ノード、地理的冗長性を確保するには 6 つ以上の HAA ノードが必要です)。

  重要:

  Orchestrator のマルチノード デプロイは、通信に REdis Serialization Protocol (RESP) を使用するため、このプロトコルを実装するあらゆるソリューションによる設定が可能です。

  UiPath では、Orchestrator の高可用性デプロイは、UiPath High Availability Add-on が使用されている場合にのみサポートされます。

デプロイのスケーリング

Orchestrator スケールセットに必要なノードの数は、デプロイされているロボットの数によって異なります。

Orchestrator スケール セット ノード数	ロボット数
1	最大 6,000 台
2	14,000 台まで
5	80,000 台まで
10	200,000 台まで
15	最大 300,000 台

これらのデプロイは、上記のハードウェアとソフトウェアの構成を使用してテストされ、以下の指定された負荷の下でパフォーマンスの低下を示しませんでした。

パフォーマンス テスト

以下の 2 つの表に示すデータは、有人デプロイのデータです。

静的データ

静的データは、Orchestrator の初期負荷を示します。

エンティティ	1 ノード	2 ノード	5 ノード	10 ノード	15 ノード
テナント	1	1	1	1	1
フォルダー	1	2	4	4	6
ロボット	6,000	14,000	80,000	200,000	300,000
パッケージ	8,000	16,000	48,000	48,000	48,000
プロセス	4,000	8,000	24,000	24,000	24,000
キュー	600	1,200	1,800	2,400	3,000
キュー アイテム	1,120,000	1,500,000	3,000,000	5,000,000	7,000,000
アセット	500	1,000	1,500	3,000	4,500

動的データ

動的データは、プロセスの実行時に Orchestrator に追加または変更されるデータを指します。

エンティティ	1 ノード	2 ノード	5 ノード	10 ノード	15 ノード
キュー アイテム (1 日当たり)	300,000	600,000	4,000,000	9,000,000	10,500,000
ジョブ (1 分当たり)	700	1,500	3,000	6,000	7,500
ログ (1 分当たり)	20,000	50,000	300,000	600,000	800,000
NuGet のダウンロード (1 分当たりの最大値)	1,000	3,000	10,000	14,000	18,000
接続されたロボット (最大値)	6,000	14,000	80,000	200,000	300,000
ハートビート (1 分当たり)	12,000	28,000	160,000	400,000	600,000
実行中のロボット	3,000	7,000	40,000	100,000	150,000
使用できるロボット	3,000	7,000	40,000	100,000	150,000

PaaS での有人デプロイ

次のセクションでは、PaaS デプロイのパフォーマンスに関する情報を示します。

アーキテクチャ

次の前提条件が満たされている必要があります。

• Orchestrator:

  • Orchestrator App Service プラン: 20 インスタンスの P3V2
  • Azure SQL Server: Premium P15: 4000 DTU
  • Azure Redis Cache P2 Premium 13GB

• Identity Server:

  • Identity Server App Service プラン: 2 インスタンスの P3V2
  • Azure SQL Server: Standard S7: 800 DTU

• Elasticsearch:

  • 仮想マシン可用性セット

パフォーマンス テスト

以下の表に示すデータは、有人デプロイのデータです。

静的データ

静的データは、Orchestrator の初期負荷を示します。

エンティティ	1 ノード
テナント	1
フォルダー	8,000
ロボット	80,000
パッケージ	8,000
プロセス	8,000
キュー	8,000
キュー アイテム	2,000,000
アセット	8,000

動的データ

動的データは、プロセスの実行時に Orchestrator に追加または変更されるデータを指します。

エンティティ	1 ノード
キュー アイテム (1 日当たり)	5,000,000
ジョブ (1 分当たり)	2,600
ログ (1 分当たり)	240,000
NuGet のダウンロード (1 分当たりの最大値)	2,000
接続されたロボット (最大値)	80,000
ハートビート (1 分当たり)	160,000
実行中のロボット	40,000
使用できるロボット	40,000

TCP ポート

ポート	説明
443	ユーザーと、Robot が接続された Orchestrator とが通信するための既定のポート。
1433	Orchestrator と SQL Server マシン間の通信用の既定のポート。
9200	Orchestrator と Elasticsearch 間の通信。
9300	Elasticsearch ノード間の通信 (該当する場合)。
5601	Kibana プラグインが使用する既定のポート (該当する場合)。
3389	高密度ロボットに必要な RDP オートメーションを使用する場合は必要です。

こちらから Studio と Robot のハードウェア要件もあわせてご確認ください。