デプロイ アーキテクチャ

用語

Automation Suite のデプロイで使用される主要な概念について詳しくは、「 用語集」をご覧ください。

デプロイ モードとユース ケース

Automation Suite では、次のデプロイ モードをサポートしています。

デプロイ モード	説明
シングルノード - 既定のモード	既定で、評価シナリオとデモ シナリオでサポートされています。 シングルノード デプロイは運用環境でも使用できますが、特定の要件が満たされている場合に限ります。詳しくは、以下をご覧ください。
マルチノード - 運用環境、HA 対応	運用用途でサポートされます。 次の 2 種類のマルチノード モードから選択できます。 ライトモード 既定では、インフラストラクチャと共有コンポーネントは HA モードに設定され、すべてのサービスは非 HA に設定されます (少なくとも 1 つのレプリカでポッドの水平自動スケーリングが有効化されます)。 特定のサービスを HA に設定できます。 また、デプロイ後に追加の構成を実行して、完全な HA 機能を実現することもできます。 HAモード HA が完全に有効化され、クラスター内の高可用性または外部の高可用性のいずれかが使用されます。

注:

シングルノード デプロイは、マルチノード デプロイに必要なハードウェアを追加することで、高可用性 (HA) 設定に変換できます。詳しくは、「 シングルノード (評価) デプロイをマルチノード (HA) デプロイにスケーリング する」をご覧ください。

Automation Suite は、Kubernetes に基づくクラウド ネイティブ アーキテクチャを使用しており、Kubernetes が持つ規模、自動リソース管理、信頼性に関するすべてのメリットを提供します。

これらのメリットを提供するために、Kubernetes の設計は以下の基本的な側面に基づいています。

• 複数の奇数個のマシン上で実行されます (3、5、7 など)。
• 定足数の原則を使用して、独立ノードの障害とデータの破損に対処します。N 台のマシンのクラスターにおいて、定足数を満たす N/2 + 1 台のマシンが残っている限り、そのクラスターは機能して適切に回復することができ、障害は観測されません。

デプロイ アーキテクチャ

このページでは、Automation Suite のアーキテクチャに関する洞察を提供し、インストーラーにバンドルされているコンポーネントについて説明します。

ノードの種類

次の図は、Automation Suite のデプロイで利用可能なノードの種類を示しています。

サーバー ノードは、重要なクラスター操作 (ワークロード オーケストレーション、クラスター ステート管理など) を実行し、受信要求を負荷分散するクラスター管理サービス (制御プレーン) をホストします。Kubernetes は、いくつかの UiPath® 製品や共有コンポーネントを、基になるリソースの可用性に基づいて実行することもできます。

エージェント ノードは、UiPath® 製品と共有コンポーネントのみを実行します。

特殊なエージェント ノードは、Task Mining の分析や、GPU 機能を必要とする Document Understanding パイプライン、Automation Suite ロボットなどの特別なワークロードを実行します。ただし、Task Mining、Document Understanding 、Automation Suite ロボットのコア サービスは、引き続きサーバー ノードまたはエージェント ノードで実行されます。特殊なエージェント ノードは、UiPath® 製品や共有コンポーネントをホストしません。

重要:

Automation Suite では、各ノードでどの UiPath® 製品が実行されるかを保証できません。これは Kubernetes によってのみ管理されます。

シングルノードの評価デプロイ

ここでのシングルノードの評価デプロイとは、シングルサーバー ノードを意味します。これは、Automation Suite 全体を 1 つのマシンにデプロイするという意味ではありません。製品スイート全体が 1 つのサーバー ノードに収まらない場合、または Task Mining の分析や、GPU 機能を必要とする Document Understanding パイプラインなどの特殊なタスクを実行する場合は、エージェントまたは特殊なエージェント ノードを追加しなければならないことがあります。

次の図は、シングルノードの評価のデプロイを示しています。

ライト モードのデプロイ

ライト モードは、インフラストラクチャ リソースに対する要求が少ない軽量のデプロイです。高可用性を必要とするサービスに対して高い構成可能性と柔軟性を提供します。既定では、インフラストラクチャと共有コンポーネントは HA モードでデプロイされ、すべてのサービスはライト モードになります。特定のサービスを HA モードに切り替えることができます。

重要:

ライト モードは運用環境で使用できますが、高可用性が有効化されていないサービスを持つことの影響とリスクに注意する必要があります。

マルチノードの高可用性対応の運用デプロイ

マルチノードの高可用性対応の運用環境のデプロイでは、ロード バランサーの背後に 3 つ以上のサーバー ノードが含まれます。これにより、障害が発生していずれかのサーバー ノードがダウンした場合でも、引き続き Automation Suite を利用して重要なビジネス ワークフローを確実に実行できます。エージェント ノードの数は任意であり、実際の使用状況に基づきます。

次の図は、マルチノードの高可用性対応の運用環境のデプロイを示しています。

High Availability Add-on

マルチノード設定では、高可用性 (HA) が既定で有効化されます。ただし、クラスター サービスが使用する Redis ベースのインメモリ キャッシュは単一のポッドで実行され、単一障害点となります。キャッシュ ノードの障害や再起動の影響を軽減するには、冗長性を備えたマルチポッドのキャッシュのデプロイを可能にする High Availability Add-on (HAA) を購入してください。

マルチノード設定で HAA を有効化する方法について詳しくは、「 High Availability Add-on を有効化する」をご覧ください。

オンライン デプロイ

オンライン デプロイとは、Automation Suite のインストール時と実行時の両方でインターネットへのアクセスが必要であることを意味します。すべての UiPath® 製品とサポート ライブラリは、UiPath® レジストリ、または UiPath® が信頼するサードパーティ ストアでホストされます。

制限付きのファイアウォールまたはプロキシ サーバーのいずれかを使用して、インターネットへのアクセスを制限できます。この場合、Automation Suite で必要なトラフィック以外の、インターネット上のトラフィックをすべてブロックします。この種類のセットアップは、 半オンライン デプロイとも呼ばれます。詳しくは、「 ファイアウォールを構成する 」および「 プロキシ サーバーを構成する」をご覧ください。

これらの種類のデプロイは、オフライン デプロイと比較して容易で高速であり、インストールおよび管理するハードウェア リソースが少なくて済みます。

次の図は、オンライン デプロイ モデルを示しています。

オフライン デプロイ

オフライン デプロイ (エアギャップ) とは、インターネットへのアクセスがない、完全に分離された設定です。この種類の設定では、UiPath® 製品のすべてのコンテナー イメージとバイナリ (tarball の形式で提供) を保存するレジストリを追加でインストールする必要があります。

次の図は、オフラインのエアギャップ デプロイ モデルを示しています。

注:

レジストリにバイナリをアップロード (ハイドレート) すると、ハードウェア要件が増え、インストールが複雑になり、オンライン デプロイと比較してインストールの実行に必要な時間が長くなります。

オフライン インストールでは、インストール時の複雑さが増すだけでなく、マシンのメンテナンス、障害復旧、新しいバージョンへのアップグレード、セキュリティ パッチの適用などのクラスター管理操作も複雑になります。

インストール後にデプロイ方法を変更することはできません。つまり、インストールをオンラインで行った場合、オフラインに変更することはできません。また、その逆の変更もできません。慎重に検討した上でデプロイ戦略を選択することをお勧めします。

Automation Suite のアーキテクチャ

次の図に、Automation Suite のアーキテクチャを示します。Docker レジストリと S3 互換 ObjectStore は外部でホストすることもできます。

以下の表に、Automation Suite に含まれるサードパーティ コンポーネントのリストを示します。

コンポーネント	任意/必須	説明
RKE2	Required	Rancher が提供する Kubernetes ディストリビューション。これは、アーキテクチャ コンポーネントとサービスのすべてを実行するコンテナー オーケストレーション プラットフォームです。
CEPH ObjectStore	任意 (外部 ObjectStore がある場合)	Amazon S3 準拠のオブジェクト/BLOB ストレージを公開するオープンソースのストレージ プロバイダーです。 これにより、サービスは BLOB ストレージのような機能を操作に使用できます。
ArgoCD	Required	オープンソースの Kubernetes 用宣言的 CD ツールです。目的とするアプリケーションのステートを定義するための信頼できる情報源として Git リポジトリを使用する GitOps パターンに従います。Kubernetes クラスター内で実行される Automation Suite コンポーネントと UiPath® サービスに対して、アプリケーション ライフサイクル管理 (ALM) 機能を提供します。
Docker レジストリ	任意 (外部レジストリがある場合)	オンプレミスでインストール時および実行時のコンテナー イメージをプッシュおよびプルするために使用するオープンソースの Docker レジストリです。
Istio	Required	Kubernetes クラスター内で実行されるマイクロサービスに対して、Ingress、要求のルーティング、トラフィック監視などの機能を提供するオープンソースのサービス メッシュです。
Prometheus	Required	Kubernetes 向けのオープンソースのシステム監視ツールキットです。Kubernetes コンポーネントからのメトリック、およびクラスター内で実行されるワークロードをスクレイピングまたは受け入れ、それらを時系列データベースに保存します。
Grafana	Required	Prometheus に保存されているデータのクエリと可視化に使用するオープンソースの可視化ツールです。クラスターおよびサービスの監視に使用するさまざまなダッシュボードを作成、提供できます。
Alertmanager	Required	Prometheus サーバーなどのクライアント アプリケーションが送信するアラートの処理を支援するオープンソースのツールです。アラートの重複削除、グループ化、および適切な受信連携 (電子メール、PagerDuty、OpsGenie など) へのルーティングを行います。
Redis	Required	一部の UiPath® サービスがキャッシュ機能を一元化するために使用する、高可用性 (HA) 非対応 (単一シャード) の Redis Enterprise です。
FluentD と Fluentbit	Required	信頼性の高いオープンソースのログ スクレイピング ソリューションです。ログ オペレーターは、すべてのノードに対してバックグラウンド プロセスをデプロイおよび構成し、ノード ファイル システムからコンテナーとアプリケーションのログを収集します。
Gatekeeper	Required	Kubernetes の管理者が、クラスターのコンプライアンスとベスト プラクティスを保証するためのポリシーを実装できるようにするオープンソースのツールです。
Velero	必須1	スナップショットのバックアップと復元を可能にするオープン ソース ツールです。
Thanos	Required	永続性を確保するために Prometheus マトリックスを ObjectStore にプッシュするためのオープンソースのツールです。

¹ バックアップおよび復元時にのみインストールされます。

外部コンポーネント

また、外部ロード バランサーや SQL Server など、いくつかの外部コンポーネントも用意する必要があります。 このスイートには、いくつかの拡張ポイントが用意されています。