Automation Anywhere Enterprise Knowledge On-Premises FAQs

On-Premises의 정의와 아키텍처부터 인프라 요구 사항, 배포 프로세스, 보안 고려 사항 등 Automation Anywhere Enterprise Knowledge 플랫폼의 On-Premises 배포와 관련된 일반적인 질문과 자세한 답변은 이 FAQ를 참조하십시오.

배포

Enterprise Knowledge On-Premises 설치는 AWS, GCP, Azure 또는 베어메탈 및 VMWare와 같은 가상 머신에서의 설치를 지원하나요?

예, 해당 플랫폼 전반에 걸쳐 생산 및 개발 환경에 모두 필요한 사양을 보유하고 있습니다.

Automation Anywhere Enterprise Knowledge On-Premises를 사용하고 싶어도 Automation 360 Cloud를 꼭 사용해야 하나요? 아니면, 완전히 폐쇄된 환경에서 나의 고유한 Automation 360 Cloud와 동등한 환경을 구축할 수 있나요?

Kubernetes, Pod 서비스 및 API 서비스가 포함된 Automation 360 클라우드에 대한 On-Premises 배포는 지원되지 않습니다. Enterprise Knowledge는 On-Premises 또는 클라우드에서 SaaS로 배포할 수 있습니다. 제품 자체는 동일하며 Automation 360 클라우드 환경과 Automation 360 On-Premises 환경 모두에서 함께 사용할 수 있습니다.

On-Premises 환경은 누가 배포하나요?

초기에 설치할 때는 Enterprise Knowledge SME와 귀사가 함께 협력해야 합니다. 지정된 배포 머신에 대한 SSH 및 네트워크 액세스를 제공해야 합니다. 직접적인 액세스 권한을 부여할 수 없는 경우, 필요한 액세스 권한을 가진 기술 인력을 지정해야 합니다. Enterprise Knowledge SME는 화면 공유를 통해 해당 인력에게 원격으로 안내를 제공할 수 있습니다. 귀사는 필요한 기계를 제공할 책임이 있습니다. 초기 설치 및 후속 업데이트는 소프트웨어를 다운로드, 배포 및 구성하는 일련의 세션을 통해 완료됩니다. 설치 스크립트는 자산을 검색하고, 설치를 수행하며, 시스템을 구성하고, 구성 요소를 배포하고, 향후 업데이트를 활성화하기 위해 CI/CD 연결을 통합합니다. 설치 및 업데이트는 직접 관리할 수 있는 사항이 아님을 유의하시기 바랍니다.

작동 시스템을 배포하는 데 걸리는 예상 소요 시간은 어떻게 되나요?

배포는 특정한 환경 및 요구 사항에 따라 대략 4시간에서 2주까지 다양할 수 있습니다. SSL 인증서 같은 문제나 네트워크에 대한 전체 액세스 권한이 없어 변경을 할 수 없는 경우 등 방해 요인이 발생하기도 합니다. 하지만, 이상적인 시나리오대로 진행된다면 완료하고 테스트하는 데 약 4시간이 소요됩니다.

들어오는 연결에 대해 SSL 인증서를 수락하는 노드는 무엇입니까?

대부분 배포 시 SSL이 필요하지만, 초기 배포를 진행할 때는 구현되지 않을 수 있습니다. 서버는 SSL 없이 배포될 수 있으며 나중에 구성할 수 있습니다. 아키텍처 다이어그램에 설명된 특정 배포 포트는 SSL 인증서를 적용해야 하는 위치를 나타냅니다.

설치하는 데 스크립트가 사용되나요?

예, Terraform 스크립트는 현재 모든 구성 요소를 설치하는 데 사용됩니다. 이 스크립트는 설치 프로세스를 간소화하며, 일관적이고 반복 가능한 결과를 보장합니다.

공유 저장소에 대한 요구 사항이 있나요?

아니요, 공유 파일 저장소는 필요하지 않습니다. Docker 컨테이너 및 기타 서비스는 모든 저장소 요구 사항에 대해 로컬 스크래치 디스크와 PostgreSQL 데이터베이스를 사용합니다.

SSD 디스크가 필요한가요?

예, SSD(Solid State Drive)는 필수입니다. 데이터베이스, 특히 벡터 데이터베이스는 크기 때문에 디스크 지연 시간에 매우 민감합니다. 디스크 액세스의 지연은 성능에 부정적인 영향을 미칩니다.

NAS 사용이 가능한가요?
아니요, NAS(네트워크 연결 스토리지)는 적합하지 않습니다. NAS는 네트워크를 통해 액세스되는 공유 디스크를 포함합니다. iSCSI를 통해 파티셔닝하고 프로비저닝하더라도, 기존 하드 드라이브의 고유한 네트워크 지연 및 회전 지연(일반적으로 SSD보다 액세스가 2.5~5배 더 느림) 때문에 성능 요구 사항에 적합하지 않습니다.
On-Premises의 기능에 대한 제한 사항이 있나요?
On-Premises 배포에는 고유한 기능 제한 사항이 없습니다. 크롤링 및 SSO(Single Sign-On)와 같은 기능이 전적으로 지원됩니다. 내부 리소스에 액세스하려면 네트워크 내에서 특정 IP 주소나 도메인을 화이트리스트에 추가해야 할 수 있습니다. 문서 편집기 및 지원 로깅을 활성화하는 것은 선택 사항 구성입니다. \'작업\' 기능은 선택적으로 활성화하거나 비활성화할 수 있습니다. 인터넷에 접근할 수 없는 고도로 제한된 에어갭 환경에서는 로컬 네트워크 기능 외에 다른 기능을 활용하는 데 제한이 있을 수 있다는 점을 유의해야 합니다.
여러 선택 사항 옵션이 있습니다. 이러한 선택 사항을 사용하지 않으면 필요한 기계 수가 줄어드나요?
아니요, 선택 사항 기능을 포함하거나 제외해도 필요한 기계 수에는 영향을 미치지 않습니다.
센트리 시그널링 머신은 선택 사항으로 표시되어 있습니다. 이 기계는 어떤 작업을 수행하나요?
센트리 시그널링 머신이 활성화된 경우, 지원 목적에 유용한 자세한 디버깅 정보를 로깅을 통해 제공합니다. 이 머신이 사용될 경우 일반적으로 다른 구성 요소와 함께 배치됩니다.
문서 편집기는 선택 사항입니다. 이는 어떤 작업을 수행하나요? 그리고 공동으로 배치되나요?
예, 문서 편집기는 선택 사항 기능이며 콘솔 내에 통합된 기능입니다. 문서 편집기는 실시간 문서 편집을 위해 웹 소켓 기능을 제공합니다. 웹 소켓 서버는 이 기능을 지원하며, 향후 웹 소켓 기반 작업에 활용할 수 있습니다. 편집기는 자주 사용되지 않을 수 있지만, 권한이 있는 사용자가 시스템 내에서 문서를 직접 입력하고 편집하여 지식 베이스(KB)에 추가할 수 있는 활동을 허용합니다. 지식의 주요 출처가 업로드된 데이터이거나 크롤링된 데이터인 경우 문서 편집기가 크게 필요하지 않습니다. 편집기를 호스팅하는 Docker 컨테이너는 다른 구성 요소와 함께 배치될 수 있습니다. 그러나, 지식을 추가할 때는 문서 파일을 표준 공유 콘텐츠 위치에 게시한 다음, 해당 위치에서 웹 크롤링 또는 자동화된 프로세스를 통해 KB에 업로드하는 것이 권장됩니다.
LLM이 제공되나요?
아니요, LLM(대형 언어 모델)은 On-Premises 배포에 직접 제공되지 않습니다. 그러나, 기본적으로 제공되는 연결이 있어 클라우드 제공과 유사하게 크레딧을 활용할 수 있습니다. 대부분의 On-Premises 배포에서는 자체 BYOK(Bring Your Own Key) 구성을 활용하여 맞춤형 LLM 연결을 사용할 것으로 예상됩니다.
On-Premises 배포는 크레딧 사용이나 BYOK GenAI 사용에 어떤 영향을 미치나요?
LLM에 액세스하기 위해 기본으로 제공된 크레딧을 사용할 수 있는 옵션이 있습니다. 그러나 LLM을 비용 효율적으로 확장성을 고려하여 사용하고 하이퍼스케일러나 다른 GenAI LLM 공급업체와의 기존 관계를 활용하려면 대부분의 경우 LLM을 호스팅하는 데 BYOK(Bring Your Own Key) 모델을 사용할 가능성이 높습니다. 이 경우 네트워크 내에서 해당 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에 배포되어야 합니다.

어떤 액세스 포트가 사용되나요?

Enterprise Knowledge 서버에 액세스하는 사용자 및 자동화를 위해 80(HTTP), 443(HTTPS), 8000(HTTP/HTTPS 웹 소켓), 8443(HTTP/HTTPS 웹 소켓), 1234(웹 소켓) 등의 포트를 화이트리스트 목록에 추가해야 합니다. 사용자 또는 봇이 네트워크 내에서 액세스하는 것을 차단하는 애플리케이션 수준(계층 7) 방화벽이 없도록 하는 것이 중요합니다. 단일 머신 배포에서 Supabase VM과 Docker 컨테이너가 완전히 통신할 수 있어야 한다는 점을 유의하시기 바랍니다. 마찬가지로 더 크고 분산된 배포에서는 모든 기계가 제한 없는 내부 통신이 가능해야 합니다.

SSL이 지원되나요?

예, SSL(Secure Sockets Layer)이 지원됩니다. 이 작업에는 호스트 또는 도메인 이름과 연결된 SSL 인증서가 필요합니다. 다음은 귀사의 환경 내에서 SSL을 구성하는 일반적인 단계입니다.

  • DNS에 FQDN(정규화된 도메인 이름) 호스트 이름을 지정된 IP 주소로 해석하는 기록을 추가합니다.
  • 초기 테스트를 위해 certbot 같은 도구를 사용하여 임시로 자체 서명된 SSL 인증서를 생성할 수 있습니다. 그러나, 생산 환경에서는 FQDN 호스트 이름에 대해 반드시 유효한 SSL 인증서와 개인 키를 제공하는 것이 좋습니다.
  • SSL 인증서와 키 파일을 해당 머신의 /nginx-proxy/ssl/ 폴더 내에 배치합니다.
  • 이 단계를 완료하고 나면 Enterprise Knowledge SME 팀에 알립니다. 그러면 해당 팀은 올바른 SSL 파일을 가리키도록 Nginx 프록시에서 필요한 구성을 완료할 수 있습니다.
  • 프런트엔드 Docker 컨테이너가 Supabase VM과 별도로 배포되는 경우 프런트엔드를 위한 별도의 인증서 및 키 파일 세트를 생성해야 합니다.
솔루션 구성 요소 내에서 어떤 포트가 사용되나요?
표 1.
목적 경로 매개변수 내부* 외부 HTTP HTTPS WSS/WS
프런트엔드 /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
백엔드 /api BACKEND_SUFFIX 8001 X x
Automator /automator [AUTOMATOR_SUFFIX] 8002 x X
Redis 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(Automator) 5433 x x
Redis(Automator) 6380 x x
Ollama 11434 x x ****

* 모든 내부 시스템은 서로 자유롭게 통신할 수 있어야 합니다.

** 관리자 전용

*** SSL(https) 연결을 사용하는 것을 권장하지만, PoC를 위해 http 연결도 지원할 수 있습니다.

**** Ollama를 로컬에 배포하는 경우에만 적용됩니다.

클라이언트(사람, 봇, API)는 어떤 포트를 사용하나요?

클라이언트는 80/443만 사용합니다. 다른 포트는 내부 통신과 관리 및 배포에 사용됩니다. Nginx는 모든 액세스 및 송신을 프록시합니다.

내 네트워크 내에서 어떤 허용된 메서드를 활성화해야 하나요?
일부 네트워크는 방화벽, 앱 가속기 및 일부 스위치를 통해 계층 7 앱 레이어로 앱 필터링을 켭니다. 네트워크 내에 있는 솔루션에 다음 메서드를 허용하는 것이 중요합니다.
  • GET
  • POST
  • PUT
  • 삭제
  • 옵션
시스템이 SSO, Automator 또는 크롤링을 사용하는 경우 어느 노드에서 호출을 시작하나요?
SSO는 클라이언트 액세스와 마찬가지로 프런트엔드 서비스입니다. SSO를 사용하면 이 프로세스는 인증 서비스로 계속 진행되며, 인증 요청이 성공하면 웹훅을 통해 연결되어 인증이 완료되고 추가 사용을 위한 토큰이 생성됩니다.
크롤링은 백엔드 서비스이며, 모든 인바운드/아웃바운드 트래픽은 백엔드 엔드 서버에 의해 처리됩니다.
Automator는 백엔드 서비스이며, 모든 인바운드/아웃바운드 트래픽은 프런트엔드 서버에 의해 처리됩니다.
Enterprise Knowledge는 포워드 프록시를 사용할 수 있나요?

네. Nginx는 모든 인바운드 및 아웃바운드 트래픽을 프록시합니다. 해당 네트워크는 귀사의 네트워크이므로, 이와 같이 작동하려면 엔드투엔드 트래픽을 허용하도록 구성해야 합니다.

SSH 관리는 어떻게 진행되나요?
기술 인력이 설치, 업데이트 및 필요한 문제 해결을 수행하려면 배포 박스(주요 데이터베이스 머신)에 대한 SSH 액세스가 필요합니다.
이러한 액세스를 지원하는 방법:
  • 기본 머신에서 특정 리소스에 필요한 SSH 키와 네트워크 액세스를 구성해야 합니다.
  • 귀사 팀이 직접적인 액세스를 제공할 수 없는 경우, 당사는 귀사 팀의 지정된 기술 인력을 요구합니다. 해당 인력은 필요한 액세스 권한을 보유하고 있어야 합니다. 설치, 업데이트 및 문제 해결을 해야 할 때 해당 인력이 가용될 수 있어야 합니다.
  • 당사의 Enterprise Knowledge SME 인력과 귀사의 기술 인력이 긴밀히 협력할 것입니다. 이들은 필요한 단계를 조정할 것입니다. 공유 화면 회의 등 IT를 이용한 협업 방식을 통해 의견을 조정할 수 있습니다.
  • 기술 세션을 조율하는 데 시간이 걸릴 수 있습니다. 더 긴 배포 스크립트를 다운로드하고 실행하려면 시간이 걸립니다. Enterprise Knowledge SME에서 제공하는 지원은 여러 세션으로 진행될 가능성이 큽니다. 따라서 담당 인력은 필요에 따라 시작, 일시 중지, 계속 및 중단할 수 있도록 대비해야 합니다.
데이터는 저장 중에, 그리고 전송 중에 암호화되나요?
예, 전송 중인 데이터에는 SSL 및 TLS 1.2가 사용됩니다.
예, 저장 중인 데이터에는 AES 256이 사용됩니다. 또한 초기 설정 스크립트에서 OnPrem 설치에 대한 암호화 키를 생성하고 설정할 수 있습니다.
SSO는 어떻게 적용될 수 있나요?
SSO는 Okta, Azure AD, SAML 2.0과 같은 프로토콜을 통해 지원됩니다.
HA(고가용성)는 어떻게 보장되나요?
OnPrem 배포에서 핵심적인 고려 사항은 귀사 IT 팀이 네트워크 중단을 관리하고 HA(고가용성)를 보장할 책임이 있다는 것입니다. Enterprise Knowledge 설치, 특히 단일 서버를 초과하는 설정의 경우 기본적인 장애 허용 기능이 포함되어 있지 않습니다. 따라서, 확장 가능하고 HA 요구 사항을 충족하는 적절한 아키텍처를 설계하기 위해서는 크기를 조정하는 작업이 필수적입니다.
무엇을 백업해야 하나요?
구성 및 매개변수, 즉 모든 것이 데이터베이스에 저장됩니다. 데이터베이스의 예약된 백업은 백업 및 복원 작업을 모두 처리합니다.
Docker 이미지가 현재 사용되고 있나요?
Docker 이미지는 현재 직접 사용되고 있지 않습니다. 그러나 docker-compose 파일이 제공되므로 Docker 이미지를 조립할 수 있습니다.
어떤 요소가 Docker 자동 확장을 지원하나요?
Docker 컨테이너는 배포에 사용되며, Docker v27.1.1 이상 버전이 필요합니다. SME 팀과 함께 크기 조정 작업을 진행하면서 API 및 작업자에 대한 자동 확장으로 크기 조정을 해야 하는지 여부와 완전한 분산 배포를 위한 서버의 분산에 대해 결정합니다.
고객에게 Docker 레지스트리가 필요한가요?
아니요.