- 基本情報
- 要件
- ベスト プラクティス
- インストール
- 更新
- Identity Server
- 起動エラーのトラブルシューティング
ハードウェア要件
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
マルチノードでのインストールでは、上記に加えて次のものが必須です。
- for Orchestrator (3+ HAA nodes are required for true high availability and 6+ HAA nodes for geo-redundancy.
注:
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 |
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 |
ロボットが 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 |
次のセクションでは、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 のスループット) |
ソフトウェア要件
|
ソフトウェア |
バージョン |
|---|---|
|
オペレーティング システム |
Windows Server 2016 |
|
データベース |
SQL Server 2019 |
|
ログ |
Elasticsearch 7.2.0 |
上記のバージョンは、下記の負荷でデプロイおよびパフォーマンスのテストを行った際に使用したバージョンです。
負荷分散
マルチノード デプロイの場合、2 つの Azure Standard ロード バランサーを使用することをお勧めします。
- Orchestrator サーバー用に 1 つ。
- Elasticsearch サーバー用に 1 つ。
High Availability Add-on
-
for Orchestrator (3+ HAA nodes are required for true high availability and 6+ HAA nodes for geo-redundancy.
重要: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 デプロイのパフォーマンスに関する情報を示します。
アーキテクチャ
次の前提条件が満たされている必要があります。
-
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 |
|
ポート |
説明 |
|---|---|
|
443 | ユーザーと、Robot が接続された Orchestrator とが通信するための既定のポート。 |
|
1433 | Orchestrator と SQL Server マシン間の通信用の既定のポート。 |
|
9200 | Orchestrator と Elasticsearch 間の通信。 |
|
9300 | Elasticsearch ノード間の通信 (該当する場合)。 |
|
5601 | Kibana プラグインが使用する既定のポート (該当する場合)。 |
|
3389 | 高密度ロボットに必要な RDP オートメーションを使用する場合は必要です。 |
