Q&A: デプロイ　テンプレート

• Q: マルチノードの高可用性対応運用環境プロファイルでは、完全な製品選択のプロセッサ要件は 96 (v-)CPU/コアですが、この要件にはサーバー ノードとエージェント ノードも含まれますか? それともサーバー ノードまたはエージェント ノードのどちらかを指していますか?
• A: UiPath のドキュメントには、マルチノードの高可用性対応運用環境プロファイルでは、ノードあたりの最小 CPU/RAM を搭載したサーバー ノードが少なくとも 3 つ必要であると記載されています。この条件が満たされている限り、残りの CPU/RAM 要件は、同じく最小 CPU/RAM の要件を満たす追加のサーバー ノードまたはエージェント ノードのいずれかに分散できます。

• Q: UiPath® Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) のノードのフォールト トレランスとは何を指していますか? エージェント ノード、サーバー ノードのみ、またはその両方が対象ですか?
• A: UiPath® Automation Suite Install Sizing Calculator (インストール サイジング計算ツール) の推奨事項はフォールト トレランスに基づいており、最悪のシナリオにおいても常に 3 つ以上のサーバー ノードが利用可能になっています。サーバーの数を増やすことで、サーバーがダウンしてもデプロイが失敗しないようにすることができます。

• Q: Amazon Route 53 でプライベート ドメインを使用できますか?
• A: はい、プライベート ホスト ゾーンがサポートされています。

• Q: クラウド ソリューション (AWS など) でも DNS レコードを指定する必要がありますか? オンプレミスの DNS ソリューションを Automation Suite の AWS デプロイで使用できますか? たとえば、エンドユーザーがアクセスする URL の場合、クラウドまたはオンプレミスのどちらの DNS でレコードを解決できる必要がありますか?
• A: Amazon Route 53 以外の DNS インフラストラクチャを使用できます。ただし、デプロイを実行する VPC で DNS が解決可能である必要があります。

• Q: Kubernetes の一部として使用されているのは、どの CNI プラグインですか? たとえば、ベンダー提供である場合、Kubernetes ソリューションは VPC/VNET との連携をサポートします。AWS Kubernetes を使用する場合、ベンダーがワークロードを作成してデプロイすると常に、ポッドは IP アドレスを VPC 自体から取得します。つまり、AWS または Azure のサービスがワークロードにアクセスできます。
• A: Cilium CNI を使用しています。Kubernetes ディストリビューションには、サポート対象の CNI が 3 つ付属していますが、AWS 固有の CNI ではありません。

• Q: サービス IP とポッド IP の範囲はカスタマイズされていますか?
• A: 現在、サービス IP とポッド IP の範囲はカスタマイズされていません。既定の CIDR は 10.42.0.0/16 です。

• Q: Automation Suite を AWS の既存の VPC にデプロイする場合、CloudFormation の代わりに TerraForm を使用できますか?
• A: いいえ、できません。UiPath では、クラウド プロバイダーのネイティブの Infrastructure as Code ツールを使用しています (AWS の場合は CloudFormation、Azure の場合は ARM)。

• Q: 前の質問に関して、IaC の標準が Terraform である場合、Terraform のコードを開発する必要があるのですか?
• A: Automation Suite を手動でデプロイする (既存の AWS テンプレートや Azure テンプレートを使用しない) 場合は、ご質問のとおり、Terraform のコードを開発する必要があります。または、既存の CloudFormation テンプレートをデプロイに使用するか、Terraform コードの作成を支援するベースとして使用できます。

• Q: Graviton ベースのプロセスをデプロイに使用できますか?
• A: いいえ、Kubernetes ディストリビューションは ARM をサポートしていません。

• Q: Automation Suite は AMD でホストできますか? それとも Intel プロセッサでのみホストできますか?
• A: アーキテクチャ要件を満たしている限り、どちらでも問題ありません。

• Q: Automation Suite のテンプレートを Ubuntu や CentOS にデプロイできますか?
• A: いいえ、Ubuntu と CentOS はサポートされていません。

• Q: AWS のデプロイで EFS が自動的にデプロイされる場合、どの程度の領域が予約されますか?
• A: EFS には、事前プロビジョニングされたサイズはありません。従量課金制です。EFS は、クラスター全体にわたる全ディスクの全バックアップを保持します。つまり、6 TB のデータを使用します。これは、すべてのノードのストレージ データ ディスク領域の合計です。

• Q: Azure のデプロイでは、AWS と同じように NFS ソリューションがデプロイされますか? その場合、どの程度の領域が予約されますか?
• A: NFS は、複数の実装方法が可能なプロトコルです。AWS Elastic File System はそのような実装の 1 つです。NFS サーバーは別の実装です。Azure には、Azure Files という別の実装があります。バックアップを作成する場合は、これらのインフラストラクチャ要素のいずれかが必要です。

• Q: 自動スケーリングを有効化する場合、ノードではカスタマイズされたイメージが必要ですか?
• A: 自動スケーリングではお使いの RedHat イメージが使用され、その上に UiPath® ソフトウェアがインストールされます。今のところはっきりしたデータはありませんが、コールド スタートは 5 分から 10 分の範囲内です。

• Q: Microsoft SQL Server の Standard Edition を使用できますか?
• A: We support Microsoft SQL Server 2019 Standard and Enterprise editions and higher. For more on SQL requirements, see our documentation.

• Q: 合計 vCPU 数の要件である 96 コアは最初から必要ですか? それともこの要件は自動スケーリングの一部になっていて、ノードはリソースの必要性に応じて追加または削除されますか?
• A: システムの電源をオンにするには 96 コアが必要です。その後は、さまざまなスケーリング方法を使用できます。ただし、この数を下回らないようにする必要があります。

• Q: RHEL イメージは自分で選択するのですか? それとも AWS または Azure のテンプレートで指定されているのですか? 自分でテンプレートを選択する必要がある場合は、テンプレートを介してデプロイする際にどの RHEL バージョンを使用すればよいですか?
• A: デプロイでは、基本的な RHEL イメージ (実行時に決定) を使用して Auto Scaling グループ テンプレートを作成し、これを仮想マシンのプロビジョニング時に適用します。つまり、すべてのソフトウェアは新しい EC2 インスタンスの作成時にインストールされます。テンプレートでは、現在 RHEL 8.2 が使用されています。

• Q: Kubernetes クラスター用以外の仮想マシンは必要ですか?
• A: Automation Suite を実行するために、クラスター外に追加の仮想マシンは不要です。ただし、UiPath Robot を実行するための既存のマシンがない場合は、UiPath® Studio (IDE) 用の開発者用仮想マシンまたはデスクトップのほかに、そのためのマシンが必要になる可能性があります。

• Q: CloudWatch または Azure Monitor と連携して Kubernetes ログを記録できるようにする予定はありますか?
• A: 現在のところ、CloudWatch にログをプッシュするための連携はありません。

• Q: Automation Suite で MySQL や PostgreSQL などのオープンソース データベース ソリューションを使用できますか?
• A: Microsoft SQL Server の要件は、Automation Suite がデプロイされるクラウドとは無関係です。