アマゾン ウェブ サービス (AWS)、Microsoft Azure、Google Cloud Platform (GCP) など、複数のエンタープライズ クラウド デプロイ オプションを使用して Orchestrator をホストすることができます。選択したデプロイ オプションと構築するロボット グループのサイズに応じた、さまざまなハードウェア要件を確認する必要があります。

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

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

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

開発環境

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

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

SQL Server

運用環境

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

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

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

• Orchestrator の High Availability Add-on (HAA) (真の高可用性を実現するには 3 つ以上の HAA ノード、地理的冗長性を確保するには 6 つ以上の HAA ノードが必要です。)

📘

注:

Multi-node Orchestrator deployments use the RESP (REdis Serialization Protocol) for communication, and thus can be configured using any solution relying on this protocol.
UiPath がサポートしているソリューションは HAA のみです。

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

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

---

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

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

📘

注:

ロボットが 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

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

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

Elasticsearch サーバー

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

• 保持期間 (ユーザーは、独自の保持ポリシーの実施が必要となります)。
• ログ メッセージの頻度 - ロボット開発者は、メッセージがログ記録に値すると考えられる場合、任意で [メッセージをログ] アクティビティを使用します。
• ロボットに設定されたログ レベルの値。たとえば、ロボットのログ レベルが 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 アプリケーション サーバー

SQL Server

📘

注:

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 サーバー

---

大規模なデプロイ

IaaS での Attended デプロイ

次のセクションでは、Azure Infrastructure as a Service (IaaS) サービスを使用した大規模で拡張可能なデプロイの要件について説明します。次のサービスが必要です。

• VM Availability Set for Orchestrator
• Elasticsearch の VM 可用性セット
• Windows Server SQL VM
• Azure Load Balancer
• High Availability add-on (HAA)
• 分散 DNS サービス (CloudFlare など)

アーキテクチャ

📘

注:

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

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

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

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

---

ハードウェア要件

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

Orchestrator ノード

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

SQL Server

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

Elasticsearch 可用性セット

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

---

ソフトウェア要件

The versions listed above are those used for the deployments and performance tested loads described.

負荷分散

マルチノード デプロイの場合、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 スケールセットに必要なノードの数は、デプロイされているロボットの数によって異なります。

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

パフォーマンス テスト

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

静的データ

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

動的データ

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

PaaS での Attended デプロイ

次のセクションでは、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:
  • VM Availability Set

パフォーマンス テスト

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

静的データ

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

動的データ

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

TCP ポート

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