マルチノードのアーキテクチャと設計に関する考慮事項

次のアーキテクチャ図は Linux 上の Automation Suite のデプロイを示しています。Kubernetes が 6 台のマシンにインストールされ、ロード バランサーとデータ ストレージが配されています。 マシン タイプは複数あり、サーバー ノード 3 つ、エージェント ノード 2 つ、専用エージェント ノード 1 つという構成です。

サーバー ノード

サーバー ノードは Kubernetes コントロール プレーンをホストし、このコントロール プレーンは Kubernetes クラスター全体を制御します。 一般的なマルチノード デプロイでは、サーバー ノード数は奇数にする必要があり、最小サーバー数は 3 です。 この制限は、Kubernetes コントロール プレーンの一部である etcd コンポーネントによるものです。 詳細については、etcd のドキュメントをご覧ください。同じ理由で、クラスターを正常な状態に保つには、サーバー ノードの大部分が常に利用可能である必要があります。

これらのノードは、Prometheus、クラスタ内 ObjectStore Ceph、UiPath Insights、クラスタ内 Docker レジストリなど、ノード上にデータ ストレージを必要とするコンポーネントもホストします。

エージェント ノード

エージェント ノードは、ワーカー ノードと呼ばれることもあります。これらのノードの目的は、UiPath® サービスとその他の共有されるスイート機能をホストすることです。これらのノードにはデータ ディスクが接続されていないため、ディスク ストレージを必要とするコンポーネントをホストすることはできません。

エージェント ノードは、任意の時点で使用可能なノードの数に制限を課しません。 結果として得られるクラスターに、失われたノードのすべてのポッドをホストする十分な容量がある限り、クラスターは中断することなく期待どおりに動作します。

専用エージェント ノード

これらのノードは特殊なタスク専用の特殊なエージェント ノードです。たとえば、ロボット実行用の Automation Suite ロボット ノードや Document Understanding モデル用の GPU ノードなどです。これらのノード上で他の UiPath® サービスをホストすることはできません。

ロード バランサー

Automation Suite の外部にインストールされるロード バランサーは、Automation Suite クラスターでホストされているアプリケーションにアクセスするためのエントリ ポイントとして機能します。 ロード バランサーは、ノードのフォールト トレランスに対応している必要があります。 すべてのサーバー ノードをロード バランサー上に構成する必要がありますが、エージェント ノードも任意で構成することができます。 ただし、専用エージェント ノードは不要です。

ロボットが Orchestrator にアクセスしようとすると、呼び出しはロード バランサーに送信され、利用可能な任意のノードに渡されます。 各ノードは、Istio と呼ばれるネットワーク コンポーネントもホストします。Istio はロード バランサーのような役目を果たすサービス メッシュです。 ノードで実行されている Istio が呼び出しを受信すると、クラスター全体で Orchestrator インスタンスを見つけようとします。 見つかると、呼び出しがそのインスタンスにリダイレクトされます。

デプロイの設計方法

多数の小容量マシンか、少数の大容量マシンか

多数の小容量マシンか、少数の大容量マシンか、どちらを選ぶかは完全にユーザー次第であり、どちらの選択肢にもそれぞれ長所と短所があります。 多数の小容量マシンのほうが少数の大容量マシンよりもノードのフォールト トレランスに対する回復性が高くなります。 同時に、管理オーバーヘッドも増えます。

たとえば、Automation Suite クラスターに 96 vCPU が必要な場合は、次のいずれかのオプションを選択できます。

• オプション 1: 1 台あたり 16 vCPU のマシンを 6 台。

  • 影響: 1 台のマシンを失った場合、クラスターの容量は 16 vCPU 減少するだけなので、結果として生成されるクラスターにすべてのポッドをホストする容量がない場合にのみ、サービスに影響します。 ただし、6 台のマシンを管理するには手間が増えます。

• オプション 2: 1 台あたり 32vCPU のマシンを 3 台。

  • 影響: 1 台のマシンを失った場合、クラスターの容量が 32 vCPU 減少し、Automation Suite に大きな影響を与えます。 ただし、3 台のマシンを管理するほうが手間は少なくなります。

結論として、デプロイの設計は目標によって決まるということです。 フォールト トレランスの向上が目標である場合は、多数の小容量マシンのほうが適しています。 一方、管理オーバーヘッドの削減が目標の場合は、少数の大容量マシンを選択する必要があります。

エージェント ノードではなく、すべてサーバー ノードにするべきか

エージェント ノードではなく、すべてサーバー ノードにするべきかどうかは、RTO または RPO によって異なります。

たとえば、Automation Suite に 80 vCPU が必要だとします。 これを実現するには、次のいずれかの方法を選択できます。

• オプション 1: 1 台あたり 16 vCPU のサーバー マシンを 5 台。 ここでは、最大 2 台のサーバー ノードを失っても運用を継続できます。

  • このオプションは、データ損失に対する回復性が目標である場合に推奨されます。 2 台のサーバー ノードが失われた場合でも、データは無事であり、残りのレプリカから再構築できます。

• オプション 2: 3 台のサーバー ノードと、1 台あたり 16 vCPU のエージェント ノード 2 台。 ここでは、1 台のサーバー ノードと両方のエージェント ノード、合計で 3 台のマシンが失われても運用を継続できます。

  • このオプションは、ノードの可用性に対する回復性が目標である場合に推奨されます。 3 台のマシンが失われても、クラスターは限られた機能で引き続き使用でき、ノードが復元されると、クラスター全体が回復します。 ただし、ストレージはサーバー ノードに接続されているため、このセットアップではデータ損失が発生しやすくなります。 2 台のサーバー ノードが完全に失われた場合、バックアップからデータを復元しない限り、データを再構築することが困難になる可能性があります。