Orchestrator
2022.4
バナーの背景画像
Orchestrator インストール ガイド
最終更新日 2024年2月15日

ハードウェア要件

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 の High Availability Add-on (HAA) (高可用性自体を実現するには 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 に格納し、ログ レベルが InfoWarn および Trace のメッセージを Elasticsearch に格納する)。
  • ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
  • 古いログ記録メッセージの保持期間 (ユーザーは自身の保持ポリシーを施行する必要があります)。
  • ロボットに設定されたログ記録レベルの値。たとえば、ロボットのログ記録レベルが Info に設定されている場合、InfoWarnErrorCritical のレベルが設定されたメッセージのみが Orchestrator に送信されます。レベルが DebugTrace および 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 に設定されている場合、レベルが InfoWarn、「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 にはログ レベルが ErrorCritical のメッセージのみを格納し、すべてのメッセージ (ErrorCritical を含む) は 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) サービスを使用した、大規模で拡張可能なデプロイの例です。次の構成が使用されました。

アーキテクチャ

注:

下記のアーキテクチャの例には、任意のコンポーネントや異なるコンポーネント (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 の High Availability Add-on (HAA) (高可用性自体を実現するには 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 オートメーションを使用する場合は必要です。

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

Was this page helpful?

サポートを受ける
RPA について学ぶ - オートメーション コース
UiPath コミュニティ フォーラム
UiPath ロゴ (白)
信頼とセキュリティ
© 2005-2024 UiPath. All rights reserved.