Automation Anywhere Enterprise Knowledge On-Premisesに関するよくある質問

Automation Anywhere Enterprise Knowledge プラットフォームの On-Premises デプロイメントに関する一般的な質問と詳細な回答については、この FAQ を参照してください。On-Premises の定義とアーキテクチャから、インフラ要件、デプロイプロセス、セキュリティ考慮事項などにわたります。

デプロイ

エンタープライズ知識 On-Premises のインストールは、AWS、GCP、Azure、または VMWare などのベアメタルおよび仮想マシンへのインストールをサポートしますか？

はい、これらのプラットフォームにおける生産環境と開発環境の両方に必要な仕様があります。

Automation Anywhere Enterprise Knowledge On-Premises を使うことを好むのに、Automation 360 Cloud をまだ使う必要がありますか？それとも、完全に閉じた施設内でネイティブAutomation 360 Cloud の同等環境を構築できますか？

Automation 360クラウドのOn-Premisesデプロイメントは Kubernetes、Pod サービス、および API サービスではありません。 エンタープライズ知識は、On-Premises またはクラウド上で SaaS として展開できます。 製品自体は同じであり、Automation 360 クラウド環境と Automation 360 On-Premises 環境の両方で併用できます。

On-Premises 環境は誰がデプロイしますか？

初期インストールは、エンタープライズ知識の SME とあなたとの共同作業です。 指定されたデプロイメントマシンに SSH およびネットワークアクセスを提供する必要があります。 直接アクセスを許可できない場合は、必要なアクセス権を持つ技術リソースを割り当てる必要があります。 エンタープライズ知識の SME は、これらのリソースを画面共有を通じてリモートでガイドできます。 あなたには必要な機械を用意する責任があります。 初期インストールとその後のアップデートは、ソフトウェアのダウンロード、デプロイ、および設定を含む一連のセッションを通じて完了します。 インストールスクリプトは、アセットを取得し、インストールを実行し、システムを構成し、コンポーネントをデプロイし、将来の更新を可能にするための CI/CD 接続を組み込みます。 インストールとアップデートは、あなたが直接管理するものではないことに注意してください。

システムを稼働させるのにどれくらいの時間がかかるか、見積もりはありますか？

デプロイメントは、特定の環境と要件に応じて、約4時間から2週間まで変動する可能性があります。 時には、SSL 証明書や、変更を加えるためにネットワークへの完全なアクセスを持っていない人がいるなどの障害に直面することがあります。 しかし、理想的なシナリオでは、最終化とテストに約4時間かかります。

どのノードが受信接続のための SSL 証明書を受け入れますか？

ほとんどのデプロイメントには SSL が必要ですが、初期デプロイメント時には実装されていない可能性があります。 サーバーは SSL なしでデプロイでき、後で設定できます。 アーキテクチャ図に示された特定のデプロイメントポートは、SSL 証明書を適用する必要がある場所を示しています。

スクリプトはインストールに使用されますか？

はい、Terraform スクリプトは現在すべてのコンポーネントをインストールするために使用されています。 これらのスクリプトはインストールプロセスを効率化し、一貫した再現可能な結果を保証します。

共有ストレージの要件はありますか？

いいえ、共有ファイルストレージは必要ありません。 Docker コンテナとその他のサービスは、すべてのストレージニーズに対してローカルのスクラッチ ディスクと PostgreSQL データベースを使用します。

SSD ディスクは必要ですか？

はい、SSD（ソリッドステートドライブ）は必須です。 データベース、特にそのサイズのためにベクター データベースは、ディスクのレイテンシーに非常に敏感です。 ディスク アクセスの遅延はパフォーマンスに悪影響を与えます。

NAS は可能ですか?
いいえ、ネットワーク接続ストレージ（NAS）は適していません。 NAS はネットワーク越しにアクセスされる共有ディスクを含みます。 iSCSI を介してパーティション分割およびプロビジョニングされていても、従来のハードドライブの固有のネットワーク遅延と回転遅延（通常、SSDよりも2.5倍から5倍遅いアクセス）は、パフォーマンス要件には不適切です。
On-Premisesの機能に制限はありますか?
On-Premises のデプロイには、固有の機能制限はありません。 クロールやシングルサインオン（SSO）などの機能が完全にサポートされています。 内部リソースへのアクセスには、ネットワーク内の特定の IP アドレスまたはドメインをホワイトリストに追加する必要がある場合があります。 Document Editor の有効化および Support ログの記録は任意の構成です。 アクション機能は、選択的に有効または無効にすることもできます。 インターネット アクセスのない高度に制限されたエアギャップ環境は、ローカルネットワーク機能を超えたユーティリティの制限を経験する可能性があることに注意しましょう。
任意のアイテムもあります。 それらを使用しないことで必要になるマシンが減りますか？
いいえ、任意の機能の追加または除外は必要なマシンの数に影響しません。
監視信号機セントリー シグナリング マシンは任意（オプション）と記載されていますが、これは何をするものですか？
監視信号機が有効になっている場合、詳細なデバッグ情報をログを通じて提供し、サポート目的に役立ちます。 使用されるときは、通常他のコンポーネントと共に配置されます。
ドキュメント エディターは任意ですが、その機能と配置について教えてください。
はい、ドキュメント エディターは任意の機能であり、コンソール内に統合された機能です。 リアルタイムのドキュメント編集のためのウェブ ソケット機能を提供します。 ウェブ ソケット サーバーはこの機能をサポートしており、今後のウェブ ソケット ベースのアクションに活用できます。 エディターは頻繁には使用しないかもしれませんが、権限を持つユーザーがシステム内で直接文書を入力および編集できるようにし、ナレッジベース (KB) に追加する活動を可能にします。 知識の主要なソースがアップロードされたデータまたはクロールされたデータである場合、ドキュメント エディターはほとんど不要です。 エディターをホストする Docker コンテナは、他のコンポーネントと同じ場所に配置できます。 ただし、知識を追加するためのベストプラクティスは、ドキュメント ファイルを標準の共有コンテンツ場所に投稿し、その既知のポイントからウェブ クロールまたは自動化プロセスを通じて KB にアップロードすることです。
LLM は提供されますか?
いいえ、大規模言語モデル（LLM）は、On-Premises のデプロイメントに直接提供されていません。 しかし、組み込みの接続が含まれており、クレジットの使用が可能です（クラウド提供に似ています）。 ほとんどの On-Premises デプロイメントでは、独自のキーを持ち込む (BYOK) アレンジメントを活用して、カスタム LLM 接続を使用することが予想されます。
On-Premises のデプロイメントは、クレジットまたは BYOK GenAI の消費にどのように影響しますか？
LLM にアクセスするために、組み込みのクレジットを使用するオプションがあります。 しかし、コスト効率が高くスケーラブルな LLM の利用のため、またハイパースケーラーや他の GenAI LLM ベンダーとの既存の関係を活用するために、ほとんどの場合、LLM のホスティングには Bring Your Own Key（BYOK）モデルが採用される可能性が高いです。 このような場合、ネットワーク内でそれぞれの LLM サービスプロバイダーへのアウトバウンド接続をホワイトリストに追加する必要があります。
大規模な完全分散デプロイメントを超えたスケーリングはどのように処理されますか？
完全に分散されスケールされたデプロイは、現在クラウド オファリングのみに適用され、On-Premisesには適用されません。 より大規模なクラウド デプロイメントはポッドサーバーのスケールアウトと Docker コンテナの反復を伴いますが、次の考慮事項はOn-Premisesに適用されます:
  • 大多数の場合、あなたにとっての On-Premises デプロイメントは単一のマシンです。
  • 詳細なアーキテクチャのコンポーネントは、全体の構造を理解するためのものであり、ほとんどは初期デプロイ後に直接操作されることはありません。
  • 大規模な完全分散レベルを超えるスケーリングは、現在 On-Premises デプロイメントにはサポートされていません。
  • 高可用性 (HA) および災害復旧 (DR) は On-Premises で標準サポートされていません。

アーキテクチャ

On-Premisesにはどのようなアーキテクチャがありますか。
On-Premisesアーキテクチャは Docker とデータベースに基づいています。 事前に構築された静的な Docker イメージを使用せず、代わりに Docker と docker-compose を使用してオーケストレーションを行います。
どのデータベースが使用されていますか？

使用されるデータベースは PostgreSQL で、ベクター インデックス ストアとして機能するように変更された Supabase として知られています。 このカスタマイズされたデータベースは、提供されたインストール スクリプトを使用して、指定された要件に従って構築されます。

データベースは独立したサーバーですか、それとも RDS、Azure、またはその他のクラウド プロビジョニングが可能ですか？

データベースは独立したサーバーでなければならず、仮想マシン (VM) として起動する必要があります。 AWS RDS Aurora、Azure Database for PostgreSQL、または同様のクラウド提供サービスなどの管理されたクラウド データベース サービスに置き換えることはできません。 データベース サーバーは、全体のデプロイメントのコア コンポーネントであり、完全に機能する Supabase ノードにするためには、手作業での設定が必要です。

Postgres はどのようにSupabase にしますか？Supabase については聞いていません

はい、データベースはアーキテクチャ内の専用サーバーに存在する必要があります。 Supabase は、機能が強化された PostgreSQL と解釈できます。 したがって、既存の管理された PostgreSQL インスタンスやその他のタイプのデータベースを直接 Supabase に変換することはできません。 しかし、データを一方から他方に移行することは可能です。 Supabase インスタンスは完全なハンズオン管理を必要とします。

ハイパースケーラーが提供する PostgreSQL データベースは良い出発点ですか？

いいえ。このデータベースは、直接のアクセスと制御を必要とする特定の変更を要求します。 AWS RDS のようなマネージドサービスは、PostgreSQL のデプロイメントをより抽象化された、スライスされた使用法を提供し、Supabase に変換するために必要なカスタマイズのレベルを提供しません。 Supabase は、ハイパースケーラー プラットフォーム上またはローカル インフラストラクチャ上でホストされるかにかかわらず、VM デプロイする必要があります。

どのアクセスポートが使用されていますか？

エンタープライズ ナレッジサーバーにアクセスするユーザーおよび自動化のために、次のポートをホワイトリストに追加する必要があります: 80 (HTTP)、443 (HTTPS)、8000 (HTTP/HTTPS ウェブソケット)、8443 (HTTP/HTTPS ウェブソケット)、および 1234 (ウェブソケット)。 アプリケーションレベル（レイヤー7）のファイアウォールが、ネットワーク内のユーザーや Bot のアクセスをブロックしていないことを確実にすることが重要です。 単一マシンのデプロイメントでは、Supabase VM と Docker コンテナが完全に通信できる必要があることに注意してください。 同様に、大規模で分散した展開では、すべてのマシンが制限のない内部通信を持つ必要があります。

SSL はサポートされていますか？

はい、SSL（セキュアソケットレイヤー）がサポートされています。 これはホストまたはドメイン名に関連付けられた SSL 証明書を必要とします。 お使いの環境での SSL 構成の一般的な手順は次のとおりです:

  • DNS にレコードを追加して、完全修飾ドメイン名（FQDN）ホスト名を指定された IP アドレスに解決します。
  • 初期テストのために、certbot のようなツールを使用して一時的な自己署名 SSL 証明書を生成できます。 しかし、運用環境では、FQDN ホスト名に対して有効な SSL 証明書と秘密キーを提供することを強くお勧めします。
  • /nginx-proxy/ssl/ フォルダー内に SSL 証明書とキー ファイル をそのマシンに配置してください。
  • これらの手順が完了したら、Enterprise Knowledge SME チームに通知して、正しい SSL ファイル を指すように Nginx プロキシ上で必要な設定を最終化できるようにしてください。
  • Supabase VM とは別にフロントエンドの Docker コンテナがデプロイされている場合、フロントエンド用に別の証明書とキーのファイルを作成する必要があります。
ソリューションコンポーネント内で使用されるポートは何ですか？
表 1.
目的 パス パラメーター 内部* 外部 HTTP HTTPS WSS/WS
フロントエンド /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
バックエンド /api BACKEND_SUFFIX 8001 X x
オートメーター /オートメーター AUTOMATOR_SUFFIX 8002 x X
リディス 6379 x X
RabbitMQ 5672, 15672 x x
ドキュメント エディター /ws WEBSOCKET_SUFFIX 1234 1234 x x x
Supabase Kong API Gateway /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x
Supabase Postgres 6543 x x
PostgreSQL（オートメーター） 5433 x x
Redis (オートメーター) 6380 x x
オラマ 11434 x x ****

* すべての内部マシンは互いに自由に通信できる必要があります

** 管理者のみ

*** SSL（https）接続の使用を推奨しますが、PoC のために http 接続もサポートできます

**** ローカルに Ollama をデプロイする場合のみ適用されます

クライアント（人間、Bot、API）はどのポートを使用しますか？

クライアントは80/443のみを使用します。 他のポートは内部通信および管理および展開のためのものです。 Nginx はすべてのアクセスと出口をプロキシします。

私のネットワーク内で有効にする必要がある許可されたメソッドは何ですか？
一部のネットワークは、ファイアウォール、アプリ アクセラレーター、および一部のスイッチを介して、レイヤー 7 アプリ レイヤーで APP フィルタリングを有効にします。 ネットワーク内での解決策のために、以下の方法を許可することが重要です:
  • GET
  • POST
  • PUT
  • DELETE
  • オプション
システムが SSO、オートメーター、またはクローリングを使用している場合、どのノードから呼び出しが開始されますか？
SSO は、クライアント アクセスのように、フロントエンド サービスです。 SSO を使用すると、このプロセスは認証サービスと続き、認証リクエストが成功した場合、Webhook を介して接続し、認証を完了し、さらなる使用のためにトークンを生成します。
クロールはバックエンド サービスであり、すべてのインバウンド/アウトバウンド トラフィックはバックエンドエンド サーバーによって処理されます。
オートメーターはバックエンド サービスであり、すべてのインバウンド/アウトバウンド トラフィックはフロントエンド サーバーによって処理されます。
エンタープライズ知識はフォワード プロキシを使用できますか？

はい。 Nginx はすべての受信および送信トラフィックをプロキシします。 あなたのネットワークですので、これが機能するようにトラフィックをエンドツーエンドで許可するように設定してください。

SSH 管理はどうですか？
デプロイメント ボックス（メイン データベース マシン）への SSH アクセスは、技術リソースがインストール、更新、および必要なトラブルシューティングを行うために必要です。
このアクセスを促進するために:
  • 基本マシン上の特定のリソースに必要な SSH キーとネットワークアクセスを構成する必要があります。
  • お客様のチームが直接アクセスを提供できない場合は、お客様のチームから指定された技術リソースが必要です。 これらのリソースには必要なアクセス権が必要です。 インストール、更新、トラブルシューティングの際に必要なときに利用できる必要があります。
  • 私たちの企業知識の SME リソースとあなたの技術リソースが密接に協力します。 必要な手順を調整します。 IT の共有アクセス、例えば共有画面会議を通じてこの調整を実現できます。
  • 調整された技術セッションには時間がかかる場合があります。 長いデプロイメント スクリプトのダウンロードと実行には時間がかかります。 私たちのエンタープライズ知識の SME からのサポートは、複数のセッションを含む可能性があります。 したがって、指定されたリソースは、必要に応じて開始、一時停止、続行、停止できるように準備されるべきです。
データは静止時および転送中に暗号化されていますか？
はい、データの転送には SSL と TLS 1.2 が使用されています。
はい、AES 256 は静止データに使用されます。 さらに、初期セットアップスクリプトの一部として、OnPrem インストール用の暗号化キーを生成して設定することが可能です。
SSO をどのように適用できますか?
SSO は、Okta、Azure AD、SAML 2.0などのプロトコルを介してサポートされています。
高可用性 (HA) を提供するものは何ですか?
OnPrem デプロイメントにおいて重要な考慮事項は、IT チームがネットワークの障害を管理し、高可用性 (HA) を確保する責任があることです。 エンタープライズ知識のインストールは、特に単一サーバーを超えるセットアップの場合、組み込みのフォールトトレランスを含んでいません。 したがって、適切なアーキテクチャを設計し、スケールし、HA 要件を満たすためには、サイズ決定の演習が不可欠です。
バックアップが必要なものは何ですか？
すべて―構成とパラメータはデータベースに保存されています。 データベースの定期バックアップは、バックアップと復元の両方の操作を処理します。
現在 Docker イメージは使用されていますか？
Docker イメージは現在直接使用されていません。 しかし、Docker イメージは docker-compose ファイルが利用可能であるため、組み立てることができます。
どのようにして Docker の自動スケーリングが可能になりますか？
Docker コンテナはデプロイメントに使用され、Docker v27.1.1 以上が必要です。 SME チームとのサイズ決定演習は、API およびワーカーの自動スケーリングによるサイズ決定がソリューションに必要かどうか、さらに完全に分散されたデプロイメントに向けたサーバーの分配が必要かどうかを判断します。
顧客は Docker レジストリが必要ですか？
いいえ。