FAQ

DB 접속정보 변경하기

수동으로 DB 접속 정보를 변경하는 방법입니다.

• DB Data Source 정보 변경(DB 데이터로 설정되어 있는 값 update 쿼리 실행)

• 주의 : 변경된 DB_IP 와 DB_PORT 값으로 쿼리문을 재구성하여 update 반영해줍니다.

su ipadb
cd /rpa/pkgs/mariadb/bin
./mysql -u root -p
MariaDB [(none)]> SELECT * FROM catalog.tb_data_source_info;
MariaDB [(none)]> UPDATE catalog.tb_data_source_info SET CONNECT_URL='jdbc:mysql://DB_IP:DB_PORT' WHERE DATA_SOURCE_ID='DS_2bc4eb2ee9b74807941fce8fac7bde87';
엔터
Ctrl-C

• Tomcat comm.Properties 변경(웹 어플 관련, 총 3군데 – tenant/admin/user 포탈)

su ipaadm
cd /rpa/apps/admin/admin/WEB-INF/classes/properties
vi comm.properties

아래 jdbcUrl 속성을 변경합니다.

jdbcUrl=jdbc:mysql:// DB_IP: DB_PORT/rpa?useLegacyDatet~~~생략~~~~
wq!
cd /rpa/apps/admin/user/WEB-INF/classes/properties
vi comm.properties

아래 jdbcUrl 속성을 변경합니다.

jdbcUrl=jdbc:mysql:// DB_IP: DB_PORT/rpa?useLegacyDatet~~~생략~~~~
wq!
cd /rpa/apps/admin/tenant/WEB-INF/classes/properties
vi comm.properties

아래 jdbcUrl 속성을 변경합니다.

jdbcUrl=jdbc:mysql:// DB_IP: DB_PORT/rpa?useLegacyDatet~~~생략~~~~
wq!

• RPA application.properties 변경(단일 파일)

cd /rpa/properties
vi application.properties

아래 속성을 변경합니다.

ipa.db.server.url= DB_IP
ipa.db.server.port=DB_PORT
wq!

• ActiveMQ 설정 변경

cd /rpa/pkgs/apache-activemq-5.15.9/conf
vi activemq.xml

line 39 변경

<bean id="mysql-ds" class="org.apache.commons.dbcp2.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="org.mariadb.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://DB_IP:DB_PORT/activemq?relaxAutoCommit=true&amp;serverTimezone=GMT&amp;"/>
wq!

• Tomcat, RPA Application, Active MQ 를 재기동합니다.

서버 재기동 절차

RPA Service와 Tomcat이 ipaadm으로 설치되고, MariaDB가 ipadb로
설치되었으며 설치 폴더는 /rpa인 경우를 예시로 들어 설명합니다.

서버 기동은 절대 root 권한으로 하는 일이 없어야 하며, 기동 순서는 아래의 순서를 따릅니다

기동

• MariaDB (ipadb 계정으로 실행)

su ipadb
cd /rpa/bin
./mysql-start.sh


또는
cd /rpa/pkgs/mariadb/bin
./mysqld_safe --defaults-file=/rpa/pkgs/mariadb/conf/mysqld.conf &

ps -ef|grep mysql

• ActiveMQ (ipaadm 계정으로 실행)

su ipaadm
cd /rpa/bin
./activemq-run.sh

또는
cd /rpa/pkgs/apache-activemq-5.15.14/bin
./activemq start

ps -ef|grep activemq

• RPA Service (ipaadm 계정으로 실행)

• N/A

  • run.sh : “진짜 기동하겠냐”는 y/n 확인 명령에 한번 더 입력을 하는 절차가 있으며, RPA 서비스 중원하는 특정 서비스 모듈만 기동하고자 하는 경우 argument로 지정해서 단일 기동도 가능합니다.

    • N/A

      (예시 : ./run.sh comm)

  • run-y.sh : 실행 즉시 전체 RPA 서비스 모듈들을 순차적으로 기동시킵니다.

  • ps-rpa.sh : RPA 서비스들이 정상적으로 올라갔는지 전체 프로세스 상태를 출력합니다.

cd /rpa/bin
./run.sh
ps -ef|grep rpa

• Tomcat (ipaadm 계정으로 실행)

cd /rpa/bin
./tomcat-run.sh

또는 

cd /rpa/pkgs/tomcat/bin
./startup.sh

ps -ef|grep tomcat

종료

• Tomcat (ipaadm 계정으로 실행)

cd /rpa/bin
./tomcat-stop.sh

또는
cd /rpa/pkgs/tomcat/bin
./shutdown.sh

ps -ef|grep tomcat 명령어로 프로세스 종료 확인

• RPA Service (ipaadm 계정으로 실행)

cd /rpa/bin
./stop.sh

ps-rpa.sh 스크립트로 프로세스 종료 확인

• ActiveMQ (ipaadm 계정으로 실행)

cd /rpa/bin
./ activemq-stop.sh

또는
cd /rpa/pkgs/apache-activemq-5.15.14/bin
./activemq stop

ps -ef|grep activemq 명령어로 프로세스 종료 확인

• MariaDB (ipadb 계정으로 실행)

su ipadb
cd /rpa/bin
./mysql-stop.sh

또는
cd /rpa/pkgs/mariadb/bin
./mysqladmin
-u root -p shutdown

DB ROOT 패스워드입력 : rpago!23
ps -ef|grep mariadb 명령어로 프로세스 종료 확인

RPA 솔루션 삭제하기

서버 재기동 절차에 따라 서비스를 종료합니다.

ps -ef|grep tomcat 명령어로 프로세스 종료 확인
ps -ef|grep rpa 명령어로 프로세스 종료 확인
ps -ef|grep activemq 명령어로 프로세스 종료 확인
ps -ef|grep mariadb 명령어로 프로세스 종료 확인

권한 오류 발생시 root 계정으로 실행

cd /rpa
rm -rf apps
rm -rf bin
rm -rf certificate
rm -rf logs
rm -rf pkgs
rm -rf properties

DBMS 개별 설치 시 my.cnf 파일 설정 방법

MariaDB 또는 MySQL을 별도로 설치한 경우 다음과 같이 my.cnf 파일을 변경하여야 합니다. 파일 변경은 RPA 솔루션을 설치하기 전에 진행해야 합니다.

DBMS를 종료한 후 아래 내용을 참조하여 my.cnf를 변경하세요. 이후 DBMS를 기동하세요.
기본 설치 시 /etc/mysql/my.cnf 경로에 위치하고 있으며, 수정을 위해서는 root 권한이 필요합니다.

[mysqld]

default_authentication_plugin=mysql_native_password
explicit_defaults_for_timestamp = 1
log_bin_trust_function_creators=1
open_files_limit = 20480
max_connections = 5000
max_allowed_packet = 64M
default-time-zone='+0:00'
innodb-strict-mode=0
collation-server=utf8_general_ci
character-set-server=utf8
sql_mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"

[client]

default-character-set=utf8

DBMS character-set 확인

Brity RPA 솔루션은 MySQL 또는 MariaDB 사용 시 utf8 character-set과 utf-general-ci COLLATION을 사용합니다.

설치 패키지를 통해 MariaDB를 설치한 경우에는 아래 내용을 확인하지 않아도 됩니다.

cd /usr/bin
./mysql -u root -p 또는 ./mysql -port 4406 -u root -p 엔터
패스워드 입력

mysql> show variables like 'char%';
명령을 수행하여 charset 이 utf8 임을 확인.

mysql> show variables like 'coll%';
명령을 수행하여 collation 이 utf8_general_ci 임을 확인.

DBMS가 utf8과 utf-general-ci로 설정된 상태에서 RPA 솔루션을 설치하여야 COLLATION 충돌이 발생하지 않습니다.
COLLATION 충돌 발생 시 DBMS 설정을 변경하고 RPA 솔루션을 재설치해야 합니다.

DB 이중화 구성 아키텍처 (참고)

DB 이중화는 필요 시 사전 별도 구성이 필요합니다. 

*Brity RPA Server설치 시 DB 이중화 구성 및 기술지원을 하지 않습니다. 


DB 이중화 구성 시 아래 아키텍처 구성도 및 링크를 참고하시기 바랍니다.

[참고] Red Hat Pacemaker https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_administration/ch-startup-haaa

application/comm. properties 각 속성값 설명

application.properties 속성 설명

• 기본 설치 경로: /rpa/properties/application.properties

• SERVER BASIC SETTINGS

현재 서버에 설치된 RPA 서버 IP/PORT 설정입니다.

• SERVER DETAIL SETTINGS

OCR 서버 및 서버 토큰 timeout 등을 설정할 수 있습니다.

• DATABASE SETTINGS

RPA 서버별 DB 설정을 할 수 있습니다.

• KNOX API SETTINGS

Knox api 연계 (메일 및 메신저) 관련 정보 설정입니다. 삼성 관계사 전용 속성입니다. Knox 연계 사용 신청 후 발급받은 토큰/계정정보를 설정합니다.

• LOG LEVEL SETTINGS

/rpa/logs에 저장되는 로그 레벨 설정입니다.

• SMTP API SETTINGS

SMTP 메일 연계를 위한 설정입니다.
Tenant Portal > 설정 관리에서 설정할 수 있습니다.(SMTP 설정 참고)

• CERTIFICATION SETTINGS

RPA 서버의 인증서 세팅입니다. 각 서버는 설치 시 제공되는 사설인증서가 세팅되어 있습니다.
이중화 구성 시, AP2 서버에는 AP1번 서버와 다른 _02 인증서 세팅이 되어 있어야 합니다.

• SAAS SERVICE SETTINGS

Brity RPA SaaS 용 세팅입니다. 고객사에서는 별도로 수정할 필요가 없습니다.

• CUSTOMIZABLE SETTINGS

변경 가능한 속성값입니다.

comm.properties 속성 설명

• 기본 설치 경로: /rpa/apps/admin/{admin/tenant/user}/WEB-INF/classes/properties/comm.properties

• SERVER BASIC SETTINGS

설치된 RPA 포털의 언어/timezone 등 기본 설정입니다.

• SERVER DETAIL SETTINGS

RPA 포털의 인증서 및 Queue, 포털과 연계되는 RPA 서버 설정을 할 수 있습니다.

• DATABASE SETTINGS

RPA 포털의 DB 연결 설정을 할 수 있습니다.

• SAAS SERVICE SETTINGS

Brity RPA SaaS 용 세팅입니다. 고객사에서는 별도 수정할 필요가 없습니다. 
rpa.service.saas 는 항상 false로 유지되어야 합니다.

• CUSTOMIZABLE SETTINGS

자주 변경이 되는 포털 속성 값들입니다.

**최초 설치 시 IP 주소는 현재 서버의 IP 주소로 되어 있습니다.

OCR 서버 구성

OCR 서버 구성 방법

• ABBYY SDK 설치한 후 라이선스 활성화

• /rpa/apps/textrecognitionServer/application.properties에 다음 property 추가 혹은 수정

abbyy.classification=true //프로퍼티 추가
abbyy.enginePath=/opt/ABBYY/FREngine12/Bin //ABBYY SDK 경로에 맞게 수정
abbyy.serialNumber=jYRy6SdjWv4RE8pCZTNN //발급받은 프로젝트 아이디

• 재기동

/rpa/apps/textrecognitionServer/run.sh

포탈 연계를 위한 프로퍼티 변경 사항

• 아래 파일들에 useOcr=Y 프로퍼티 추가

• N/A

  • /rpa/apps/gateway/application.properties

  • /rpa/apps/admin/admin/WEB-INF/classes/properties/comm.properties

  • /rpa/apps/admin/user/WEB-INF/classes/properties/comm.properties

  • /rpa/apps/admin/tenant/WEB-INF/classes/properties/comm.properties

• /rpa/properties/application.properties에 다음 프로퍼티 추가

useOcr=Y
ipa.server.ip.ocr={설치되는 서버 아이피}
ipa.server.port.ocr={설치되는 서버 포트}

• 게이트웨이 서버 재구동

/rpa/apps/gateway/stop.sh
/rpa/apps/gateway/run.sh

• 포털 재구동

/rpa/bin/tomcat-run.sh
/rpa/bin/tomcat-stop.sh

• 테넌트별 OCR 기능 활성화

• N/A

  • /tenant 포털 접속 후 설정 관리 → useOcr 테넌트별로 사용 여부 체크

서버 데이터 에이징 설정

서버 데이터 에이징 관련 작업

• RPA 서버는 아래와 같은 데이터 보존기간을 설정할 수 있으며, 이를 위해 스케쥴링된 데이터 에이징 작업이 서버 내부적으로 매일 수행합니다.

• 또한, 포털의 기능을 이용하면 예전 데이터들을 명시적으로 수동 삭제하는 것도 가능합니다.

이 작업들을 통하여 보존기간이 지난 불필요한 DB의 데이터들은 delete 수행되지만, delete 이후에도 DB에서는 해당 테이블스페이스의 물리적인 파일의 용량은 크게 줄어들지 않습니다.

사용량이 많아서 저장공간이 점진적으로 늘어나는 것에 대해서는 서버관리자가 그에 맞도록 스토리지를 늘여주는 것을 고려해주시고,

에이징을 통해서 delete된 데이터에 대한 추가적인 스토리지 공간 확보는 DB 저장공간이 여유가 있는 상황에서 주기적으로 아래의 MariaDB 효율화 작업을 수행해주시면 저장공간을 좀더 확보할 수 있습니다. (정기 메인터넌스 작업 등에서 수행 권고)

공식적으로 MariaDB에서는 아래와 같이 OPTIMIZE TABLE 기능을 제공하고 있으며,

https://mariadb.com/kb/en/optimize-table/

MariaDB의 작업에 대해서는 고객사마다 버젼, 운영의 주체, 구성 아키텍쳐 등이 다른데다 RPA의 기술지원 범위에 속하지 않기 때문에 Optimize 작업을 위한 백업/수행/절차 등은 DBA 또는 계약된 유지보수 업체 등을 통해서 검토해주시길 바랍니다.

• 정리하면, RPA 서버관리자/운영자가 해줄 수 있는 DB 스토리지를 줄일 수 있는 방법들은 아래의 내용으로 검토할 수 있겠습니다.

1) 기본설정으로 제공되는 30일간의 데이터까지 유지할 필요가 없다면 retention값을 줄여봅니다.
   서버의 application.properties 파일에 "scheduler.log.keepdays=30" 으로 속성 추가하고 
   원하는 보관기간 숫자(일)를 설정한 후, scheduler 서비스를 재기동합니다.

2) 각 테넌트의 어드민들은 누적된 각 프로젝트의 옛날 버젼들 중, 더이상 사용하지 않는 버젼들은 확인 후 삭제합니다.

3) PM이나 서비스 오프가 가능한 시간을 이용해서 물리적인 DB 용량을 확보하기 위한 DB Table Optimize 작업을 수행합니다.

• N/A

  • 서비스 중에 온라인 수행을 하게되면 트랜잭션에 따른 영향으로 문제가 발생할 소지가 있습니다.

  • 실제로는 테이블에 lock 을 걸고, 새로운 테이블로 내용을 복사한 후, 기존 테이블을 삭제하고, 새 테이블 이름을 원래 테이블명으로 변경하는 로직이라 특정 테이블에 대해 Optimize 작업할 때 그 테이블 크기만큼의 디스크 여유 공간이 반드시 확보되어 있어야 합니다.

  • 사전에 테스트할 수 있는 개발/스테이지 환경이 있다면 먼저 수행해서 소요시간이나 영향도를 체크합니다.

  • 테이블의 데이터 크기가 작은 테이블부터 진행을 추천합니다.

  • 수행시간은 예전 경험상, 대략 200기가의 테이블에 대해 Optimize 했을 때, 3시간 정도 걸린 리포팅이 있습니다.

MariaDB의 OPTIMIZE TABLE 작업

MariaDB의 OPTIMIZE TABLE 작업은 아래와 같은 시나리오로 진행을 검토할 수 있습니다.

아래의 시나리오에는 데이터 백업/복구 등은 포함되어 있지 않으며, 단지 시나리오 예시를 참조하셔서 고객사에 맞는 절차와 수행계획을 DBA와 진행하시길 바랍니다. (RPA 기술지원에서는 MariaDB 메인터넌스에 대해서는 지원이 불가합니다)

• OPTIMIZE TABLE 작업 시나리오 예시

1) 작업전 DB 서버 디스크 용량 확인(스키마별) : After와 비교를 위해 기록해둡니다.

cd /data/mariadb/data
du -h --max-depth=1

2) MariaDB로 접속합니다.

cd /rpa/pkgs/mariadb/bin
./mysql -u root -p
비번입력

3) 작업전에 전체 DB 용량을 확인합니다. (쿼리 수행)

SELECT SUM(data_length+index_length)/1024/1024 used_MB, SUM(data_free)/1024/1024 free_MB FROM information_schema.tables;

전체 얼마나 사용하고 있고, DATA_FREE는 얼마인지 간단히 현황 확인이 가능합니다.
(Before & After를 확인하기 위해서 작업 전/후의 데이터 기록)
☞ DATA_FREE : 할당되었지만 사용되지 않은 바이트
    이 data_free 컬럼에는 사실상 사용 중이 아닌 테이블에 할당된 여유 공간의 양이 표시됩니다. 
    OPTIMIZE TABLE을 사용하면 이 공간을 확보할 수 있을 것입니다.
    (테이블의 단편화 현상을 해결하여 차지하는 용량을 줄이게 됩니다)

4) OPTIMIZE 작업으로 줄일 대상 테이블 선별 (쿼리로 확인)

-- 데이터를 가장 많이 사용하는 20 개 테이블 조회
select concat(round(data_length/(1024*1024),2),'M') data, t.* from information_schema.TABLES t order by DATA_LENGTH desc limit 20;
 
-- DATA_FREE 양이 높은 상위 20개 테이블 조회
select concat(round(DATA_FREE/(1024*1024),2),'M') data, t.* from information_schema.TABLES t order by DATA_FREE desc limit 20;

DATA_FREE 가 높은 테이블 중, 특히 tb_asset_file 또는 tb_job_related_file 등을 체크하고 선별하여 리스트업합니다.

5) OPTIMIZE 수행

RPA 서비스를 내려놓는 메인터넌스 시간을 충분히 확보한 상태에서, 선별된 각 테이블들에 대해 순차적으로 각각 명령어를 수행합니다.

-- 명령어
OPTIMIZE TABLE 테이블이름

예시) rpa.tb_job_related_file 테이블을 옵티마이즈하는 경우

MariaDB [(none)]> optimize table rpa.tb_job_related_file;
+-------------------------+----------+----------+-------------------------------------------------------------------+
| Table                   | Op       | Msg_type | Msg_text                                                          |
+-------------------------+----------+----------+-------------------------------------------------------------------+
| rpa.tb_job_related_file | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| rpa.tb_job_related_file | optimize | status   | OK                                                                |
+-------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.074 sec)
수행결과 "Table does not support optimize, doing recreate + analyze instead" 메시지가 표시되지만 실제로 optimize 는 적용됩니다.

6) 작업이 완료되면 용량 확인 쿼리를 다시 한번 수행하여 데이터가 얼마나 줄었는지 확인해봅니다.

7) 작업 소요시간과 효과등을 정리하여, 어느정도 주기로 효율화 작업을 진행해줄 것인가의 정책에 재반영하고 운영업무에 포함시켜줍니다.

이중화 구성시 - 세션 타임아웃 문제 "Connection Reset by Peer"

• 이중화 구성시 세션 타임아웃에 의해 통신에러가 발생되며, 이경우 서버와 봇간의 상태 정보 불일치등 기능상 오류가 발생됨

• 서버 로그상에 "Connection Reset by Peer" 에러가 발생합니다.

• 이중화 구성시 L4 등의 장비에 설정된 idle Timeout 값에 따라 해당 현상이 발생될 수 있습니다.

문제 해결 방법

1) L4 session timeout 후 TCP 'RST' flag 전송 옵션 ON 가능 여부 확인 (인프라 담당자 확인 요청)

2) 서버 Property내 재연결 시도 옵션 추가, 단 L4의 세션 타임아웃 값을 확인하여 보다 작게 설정

• 공통 application.properties에 추가된 속성(3.1.0.0908 핫픽스 이상 적용)

• N/A

  • rpa.httpclient.maxIdleTime=300s

  • rpa.httpclient.maxLifeTime=300s

Job 트리거 및 Processflow waitmail Polling주기 설정

Job 트리거(이벤트 서버) waitmail Polling주기 설정

1) /apps/core/run.sh파일에 아래 내용을 추가한다. (ms 단위)
 - "-Devent.polling.queue.interval=600000" 추가 (ms 600초=10분)
 - 해당 값 미 설정시 Default값으로 동작 (10초 주기)

2) 설정 값을 적용하기 위한 core재시작
    cd /rpa/apps/core
    ./stop.sh
    ./run.sh

Processflow waitmail Polling주기 설정

1) /apps/workflow/run.sh파일에 아래 내용을 추가한다. (초 단위)
 - "-Dworkflow.event.mail.interval=600" 추가  (sec 600초=10분)
 - 해당 값 미 설정시 Default값으로 동작 (1분 주기)

2) 설정 값을 적용하기 위한 workflow재시작
    cd /rpa/apps/workflow
    ./stop.sh
    ./run.sh

waitmail polling주기 관련 문의사항 정리

1) 잡트리거 & 프로세스 플로우 서버 Default값은 얼마인가요?
 - 서버 Default값 관련 잡트리거는 10초 주기이며, 프로세스 플로우가 1분 주기입니다.

2) 이메일 잡트리거는 10초 주기로 반복하고, 잡트리거의 갯수(10개) 만큼 수행되는게 맞나요? 
 - 주기당 등록된 이메일 잡트리거만큼 메일 서버에 접근합니다.

3)  잡트리거에서 내부적으로 몇번의 녹스 api 접근이 이루어 지나요?
 - 정확하게는 API가 아닌 pop3로 접속합니다. 주기당 계정당 1번 접속합니다.
   예시) 주기가 10초이고 이메일 잡트리거가 5개 등록되어 있다면, 1분에 접속하는 횟수는 [6 * 5 = 30회] 입니다.
     주기가 10초이므로 1분에 6회 반복, 이메일 잡트리거가 5개 있으므로, 주기당 5번 접속 ==> 6 * 5 = 30회

4) 프로세스플로우 내부적으로도 waitmail 카드가 knox 로그인 포함하여 몇번의 녹스 api 이루어 지나요?
  - 프로세스플로우도 주기당 waitmail 카드만큼 메일 서버로 pop3 접근을 시도합니다.

문제 해결

Runtime Library 추가 설치 (libtinfo.so.5)

최초 설치 후, MariaDB가 정상적으로 기동되지 않거나 접속에 오류가 나는 경우와 관련하여 Linux OS에 따라 libtinfo.so.5 라는 추가 런타임 라이브러리를 요구하는 경우가 있습니다. 이 경우에는 에러 메시지를 확인하고 필요한 라이브러리를 직접 설치해야 합니다. CentOS나 RHEL에서 다음과 같은 에러가 발생할 경우 아래 라이브러리를 추가로 설치해야 합니다.

libtinfo.so.5: cannot open shared object file: No such file or directory

인터넷 연결이 불가능할 경우에는 함께 배포되는 패키지를 이용하여 다음과 같이 직접 설치하세요. (CentOS)

cd /rpa/install/lib/ncurses
sudo rpm -i --nosignature ncurses-compat-libs-6.1-7.20180224.el8.x86_64.rpm

인터넷 연결이 가능한 환경에서는 다음과 같이 설치가 가능합니다..

sudo yum install libncurses*

# Ubuntu의 경우에는 아래의 명령어를 대신 사용
sudo apt install libncurses5

간혹 Ubuntu 환경에서 MariaDB 설치 시 table들을 생성하는 과정 중에 아래와 같은 오류 메시지가 발생하는 경우가 있습니다.

/rpa/pkgs/mariadb/bin/mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

인터넷 연결이 가능한 환경에서는 아래와 같은 명령어로 관련 라이브러리를 설치할 수 있습니다.

sudo apt-get install libaio1 libaio-dev

또는 
sudo yum install libaio

IPv6 사용 여부 확인 (IPv6 비활성화)

IPv6와 IPv4를 동시에 사용할 경우 정상적으로 동작하지 않을 수 있기 때문에 IPv6를 사용하지 않도록 변경해야 하는 경우가 있습니다.

CentOS 8를 사용하는 서버의 IPv6 활성화 여부는 아래 명령어를 통해서 확인할 수 있습니다.

ip a | grep inet6(IPv6 비활성화)

만약, IPv6 설정이 활성화되어 있는 경우 위와 같이 inet6 키워드를 확인할 수 있고, 설정되지 않은 경우에는 아무것도 출력되지 않습니다.

IPv6 주소를 비활성화하는 방법으로 sysctl 명령어를 사용할 수 있습니다.

sysctl 명령어를 사용하여 IPv6 주소를 비활성화하려면 다음의 절차를 따르세요.

1. 아래 명령어를 이용하여 새로운 sysctl 설정 파일 /etc/sysctl.d/70-ipv6.conf을 생성하세요.

# sudo vi /etc/sysctl.d/70-ipv6.conf

2. 파일 생성이 완료되면 아래의 명령어를 입력한 후 저장하세요.

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

3. 활성화된 IPv6를 비활성화하기 위해서 아래의 명령어를 입력하세요.

# sudo sysctl --load /etc/sysctl.d/70-ipv6.conf

4. 아래의 명령어를 입력하여 IPv6가 정상적으로 비활성화되었는지 확인하세요.

# ip a | grep inet6

위의 명령어를 입력한 후 결과 메시지가 아무것도 나오지 않으면, IPv6 설정이 모든 네트워크 카드에 대하여 비활성화된 것을 확인할 수 있습니다. (이 설정은 reboot한 이후에도 유지됩니다)

만약 CentOS 8에서 위의 sysctl 명령어를 이용해서 IPv6을 비활성화 처리한 이후에도 여전히 IPv6 키워드가 확인되는 경우라면, 이는 CentOS 8에서 기본적으로 Network Manager를 사용하고 있는 상태이기 때문에 nmcli 명령어를 사용해서 아래와 같이 처리한 후 reboot을 해줘야 합니다.

nmcli 명령어를 사용하여 IPv6 활성화 상태를 비활성화하려면 아래의 명령어를 입력하세요.

# sudo nmcli connection modify interface ipv6.method ignore

마지막으로 아래 명령어를 입력하여 CentOS 8를 재부팅하세요.

# sudo reboot

Ubuntu를 사용하는 서버의 IPv6 활성화 여부는 아래 명령어를 통해서 확인할 수 있습니다.

# ip a | grep inet6

만약, IPv6 설정이 활성화되어 있는 경우 위와 같이 inet6 키워드를 확인할 수 있고, 설정되지 않은 경우에는 아무것도 출력되지 않습니다.

Ubuntu도 IPv6 주소를 비활성화하는 방법으로 sysctl 명령어를 사용할 수 있습니다.

Ubuntu에서 sysctl 명령어를 사용하여 영원히 IPv6 주소를 비활성화하려면 다음의 절차를 따르세요.

(CentOS 8과 비교하면 수정하는 파일과 내용에 조금 차이가 있습니다)

1. 아래 명령어를 이용하여 sysctl 설정 파일인 /etc/sysctl. conf을 vi 에디터로 열어줍니다.

# sudo vi /etc/sysctl. conf

2. 파일의 끝부분에 아래의 명령어들을 append 하여 붙인 후 저장하세요.

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1

3. 설정을 적용하기 위해서 아래의 명령어를 입력하세요.

# sudo sysctl -p

4. 아래의 명령어를 입력하여 IPv6가 정상적으로 비활성화되었는지 확인하세요.

# ip a | grep inet6

위의 명령어를 입력한 후 결과 메시지가 아무것도 나오지 않으면, IPv6 설정이 모든 네트워크 카드에 대하여 비활성화된 것을 확인할 수 있습니다. (이 설정은 reboot한 이후에도 유지됩니다)

만약 Ubuntu에서 위의 sysctl 명령어를 이용해서 IPv6을 비활성화 처리한 이후에도 여전히 IPv6 키워드가 확인되는 경우라면, OS가 sysctl 설정파일을 커널 파라미터로 강제 read하도록 만들기 위해서 아래와 같이 처리 해줘야 합니다.

/etc/rc.local 파일을 만들어 줍니다..

# sudo vi /etc/rc.local

/etc/rc.local 파일의 내용을 아래와 같이 채워주고 저장합니다.

#!/bin/bash
# /etc/rc.local

/etc/sysctl.d
/etc/init.d/procps restart

exit 0

이 파일에 실행권한을 아래와 같이 재설정합니다.

# sudo chmod 755 /etc/rc.local

상기 방법이외에도 GRUB을 설정하여 IPv6를 비활성화시켜주는 방법도 있지만 본 문서에서는 다루지 않습니다.

에러 로그 확인

/rpa 아래에 솔루션을 설치했을 경우 각 서비스의 로그를 아래와 같이 확인할 수 있습니다.

• MariaDB 로그 확인

cd /rpa/logs/mariadb
tail -f mariadb.err

• Tomcat 로그 확인

cd /rpa/logs/admin
tail -f catalina.out

• RPA AP 로그 확인

cd /rpa/logs

asset, auth, comm, event, gateway, interface, scheduler, tenant, extrecognitionServer, workflow 폴더 하위의 에러 로그를 확인합니다.

RPA 서비스 접속 확인

Linux 내부/외부 접속 문제가 있는지 명령어로 확인할 수 있습니다. 

예를 들어, gateway 통신이 리눅스 내부에서는 성공했으나 봇 PC에서 실패했다면 해당 port의 방화벽이 오픈되어 있지 않다고 예상할 수 있습니다. (Curl 명령이 아닌 Web Browser를 통해서도 확인이 가능합니다. )

접속이 정상적인 경우 설치된 서비스의 버전이 표시됩니다.

(예시)

• gateway 통신 상태 확인 (https 임에 주의)

curl https://182.193.17.236:8777/version --insecure

• auth 통신 상태 확인 (http 임에 주의)

curl http://182.193.17.236:9091/auth/version

• communication 통신 상태 확인

curl https://182.193.17.236:9001/communication/version -- insecure

확인용 명령어 참조

비정상적인 상황에 대한 체크를 위해 아래의 명령어들을 활용할 수 있습니다.

mysql 명령이 안될 때

alias mysql=/rpa/pkgs/mariadb/bin/mysql
export PATH=$PATH:/rpa/pkgs/mariadb/bin/

날짜 확인

date

서비스 포트 LISTEN 현황 보기

ipaadm 계정 로그인 상태에서

lsof -i -nP | grep LISTEN

운영체제 비트 확인

getconf LONG_BIT

telnet 없이 포트 오픈 여부 확인

curl의 파라미터 중, url에 telnet 스키마도 허용됩니다.

curl -v telnet://ip:port

예시) curl -v telnet://70.70.189.84:22

통신이 가능한 상태라면 결과에 "Connected to ... "라는 내용이 마지막에 보여집니다.

RPA 서비스의 java 실행 heap memory 사이즈 조정

특정 RPA 서비스 모듈의 로그 상에서 "java.lang.OutOfMemoryError: Java heap space" 의 OOM(Out Of Memory)에러 메시지가 기록되면서 오류가 발생하는 경우, 해당 RPA 서비스 모듈의 java 실행관련 heap memory 설정을 늘여줍니다.

예를 들어, 공용 리소스 가져오기를 실패하는 asset 관련 문제가 발생한 경우, 해당 서비스모듈은 core 이고 (2.0버전부터 기존의 interface, asset, event 이상의 3가지 서비스가 core로 통합), 수정할 실행스크립트(run.sh)는 아래의 경로에 위치합니다. vi 에디터로 run.sh을 열어줍니다.

cd /rpa/apps/core
vi run.sh

Java의 실행 옵션들 중, "-Xms"와 "Xmx" 항목을 찾아서 현재 설정되어있는 값보다 메모리 사이즈를 더 높여서 수정해주세요. 참고로 위의 옵션들은 아래와 같이 정의됩니다.

-Xms : 초기 Heap size 설정
-Xmx : 최대 Heap size 설정

초기에 1G로 잡혀있는 것을 2G로 늘여주는 예를 든다면,

변경전 : -Xms1G -Xmx1G
변경후 : -Xms2G -Xmx2G

수정 사항을 저장하고, 해당 서비스 모듈을 restart 해주시면 바로 적용됩니다.

메모리 옵션값 증가에 따라 해당 서비스 모듈의 메모리 사용률은 증가할 것이기 때문에 사전에 서버에서 아래와 같은 top 또는 free 명령어등을 이용해서 메모리 사용량을 확인하신 후, 물리적인 메모리가 여유가 있는 상황에서 진행해주시고, 만약 메모리가 부족한 상황이라면 물리적인 메모리 증설을 먼저 하고나서 적용하실 것을 권장합니다.

top 명령어로 memory 상태 확인 (리눅스 서버)

리눅스 서버의 각종 usage 상황을 보여줍니다. (옵션 없이 실행하면 3초마다 화면 갱신)

아래와 delay 옵션을 이용해서 화면을 1초마다 갱신시키고, 화면에서 Shift + m 을 함께 눌러주면 memory 사용률이 높은 프로세스부터 정렬해서 보여줍니다.

top -d 1

/rpa/bin/ps-rpa.sh 명령을 수행하여 시작(-Xms) 최대(-Xmx) 메모리 설정을 확인합니다.

top 명령의 PID를 비교하여 물리메모리(RES) 값이 Heap 메모리를 넘지 않는지 확인하고 Heap 메모리가 부족한 경우 최대 메모리 Xmx 값을 늘려 줍니다.

ipaadm 338 1 1 12:34 tty1 00:01:01 java -jar -DDEV_HOME=/rpa/logs -Dspring.config.location=/rpa/properties/application.properties,classpath:/application.properties -Xms2G -Xmx2G rpa_auth.jar
ipaadm 379 1 1 12:34 tty1 00:00:52 java -jar -DDEV_HOME=/rpa/logs -Xms1G -Xmx1G -Dspring.config.location=/rpa/properties/application.properties,classpath:/application.properties rpago_api_gateway.jar

Java Heap 메모리를 설정은 각 서비스의 run.sh 을 수정한 후 재기동 해주면 됩니다.

vi /rpa/apps/auth/run.sh
vi /rpa/apps/gateway/run.sh
vi /rpa/apps/tenant/run.sh
vi /rpa/apps/core/run.sh
vi /rpa/apps/comm/run.sh
vi /rpa/apps/scheduler/run.sh
vi /rpa/apps/workflow/run.sh
vi /rpa/apps/textrecognitionServer/run.sh

리눅스는 가용한 메모리가 있을 경우 이를 최대한 활용하는 차원에서 캐시 등의 용도로 사용하게 되고 메모리 요청이 있을 경우에는 이를 반환합니다.

실제 사용 메모리는 (used - buff/cache) 이며, avail Mem값은 가용한 메모리로 보면 됩니다.

단순히 Mem의 free가 적다고 메모리가 부족한 상황은 아니며, 사용중인 Swap used가 많으면 성능저하가 발생합니다.

일반적으로 (free + buff/cache) 양이 전체 메모리(Mem total)의 20% 이상이어야 정상적인 상황으로 볼 수 있는데, 이값이 20%를 넘지 않으면서 Swap used가 많이 일어나고 있다면 물리적 메모리 증설이 필요하다고 볼 수 있습니다.

에러 로그 내 OutOfMemory 체크 스크립트 사용법

서버 로그파일에서 OutOfMemory 가 발생했는지 확인 할수 있는 방법은 다음과 같습니다.

에러 로그 전체에 대해서 OutOfMemory 로그 추출 방법

1) 스크립트 파일 준비
oom-check.sh 파일을 /rpa/bin/oom-check.sh 에 위치시킵니다.

2) 스크립트 실행
cd /rpa/bin
./oom-check.sh

3) 스크립트 반복 실행
./oom-check.sh -t

메모리 상태 확인 및 조치 실시

1) 결과 확인
/rpa/logs/*/error.log 파일에  OutOfMemory 가 검색된 경우 파일내용을 화면에 표시합니다.
결과 없는 경우는 아무것도 표시되지 않습니다.

RPA 서비스들의 Heap Memory 상태를 표시합니다.
Minor GC, Full GC 수행 횟수 및 수행 시간 등을 확인 할 수 있습니다.

2) RPA Service Memory Check 옵션
ETIME : Process Elapsed Time
YOUNG : Young Area Heap Size (GB)
YGC   : Minor GC Count
YGCAT : Minor GC Average Time (sec)
OLD   : Old Area Heap Size (GB)
FGC   : Full GC Count
FGCAT : Full GC Average Time(sec)

3) 메모리 안정화 조건
YGCAT : 0.05 sec 내외 
FGCAT : 1 sec 내외

• oom-check.sh 내려받기

oom-check.sh

• oom-check.sh 소스 내용

#!/bin/bash
grep -r 'OutOfMemory' ../logs/*/error.log

#이하생략

Tomcat 로그 시간 KST 기준으로 통일시키기

Tomcat의 로그는 아래와 같이 KST와 UTC 가 혼용되어서 로깅되고 있음.  (설치 기본상태)
변경대상 파일
각 Web Application에서 사용중인 logback.xml 설정파일 3개
☞ 위치
/rpa/apps/admin/admin/WEB-INF/classes/logback.xml
/rpa/apps/admin/user/WEB-INF/classes/logback.xml
/rpa/apps/admin/tenant/WEB-INF/classes/logback.xml

<configuration>
    <!-- Console Log -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                [%-5p] [Thread Id=%t] [%date{"yyyy-MM-dd HH:mm:ss.SSSZ"}{KST}] %13F:%04L %m%n
            </Pattern>
        </layout>
    </appender>

서버 운영 가이드

OS 파라메터 적용 가이드

이번 절에서는 리눅스 시스템을 관리하고 제어 하는 OS 커널 파라메터에 대한 권장값을 제시 합니다. 
기본적으로 OS에 따라 설정 방법 등에 차이가 있으며, 솔루션에서 직접적으로 제어하지는 않습니다.
따라서 서버 운영자는 해당 가이드를 활용하여 커널 파라메터에 대한 권장값을 적용하기 바랍니다.

솔루션에 영향을 미치는 인자는 다음과 같습니다.

NetWork 성능 조율
파일시스템 성능 조율

설정 하는 이유

OS 커널 파라메터는 리눅스 시스템을 관리하고 제어 하는 값으로 커널 파라메터 값을 설정하여 시스템을 최적화 할 수 있습니다. 

기본적인 설정 방법은 다음과 같습니다.
- vi /etc/systl.conf 명령어로 파일안에 값을 설정하면됩니다. (영구적으로 적용 가능)
- sysctl 명령으로 커널 변수의 값을 제어 할 수도 있습니다.

세부 설정 방법

세부 설정 방법은 다음과 같습니다.

1) 설정 값 조회 방법
 - sysctl [커널파라미터]
 ex) # sysctl net.ipv4.tcp_max_syn_backlog

2) 즉시 적용 방법
 - sysctl -w [커널파라미터]=[설정하고 싶은 값]
 ex) # sysctl -w net.ipv4.tcp_max_syn_backlog=1024
 
3) 영구 설정시
# vi /etc/sysctl.conf
net.ipv4.tcp_max_syn_backlog=1024 
net.core.somaxconn=1024           
net.ipv4.tcp_fin_timeout=60      
net.ipv4.tcp_keepalive_intvl=75    
net.ipv4.tcp_keepalive_probes=9   
net.ipv4.tcp_keepalive_time=7200   
net.ipv4.tcp_syn_retries=6
net.ipv4.tcp_retries2=15

4) 설정 후 적용법
# /sbin/sysctl -p 명령어로 적용 합니다.

OS 파라메터 항목별 권장 설정값

리소스 파라메터 권장 설정값

WAS 권장 설정값 적용 가이드

이번 절에서는 솔루션 구동에 필요한 tomcat 및 스프링부트 설정에 대한 권장 가이드를 제공합니다. 기본적으로 설치시에 대부분 권장값이 적용되어 설치가 됩니다. 운영자는 해당 설정값에 대해 파악하고 필요시 조정 및 관리 할 수 있어야 합니다. 또한 운영 이슈 발생 시 분석을 위한 필수 로그 및 설정 방법들을 확인할 수 있어야 합니다.

공통 적용 가이드

Tomcat 적용 가이드

스프링부트 적용 가이드

Accesslog 설정 활성화 가이드

이번 절에서는 Accesslog 설정 활성화 가이드에 대해 설명합니다. Accesslog는 클라이언트 요청 기록, 문제 진단, 모니터링, 성능 튜닝 등에 반드시 필요한 자료이므로 장애 발생시 원인 파악등을 위해 활용이 가능하므로 설정할 것을 권장합니다.

게이트웨이 (gateway) 서비스에 Access Log 추가하는 방법

1) 게이트웨이 서비스 폴더(예 /rpa/apps/gateway) run.sh 에 파리미터 추가
-Dlogging.config=./logback.xml -Dreactor.netty.http.server.accessLogEnabled=true 추가

2) 첨부된 logback.xml  파일을 게이트웨이 서비스 폴더(예 /rpa/apps/gateway)에 업로드  
   첨부파일 : logback.xml

3) 게이트웨어 서비스 재시작하여 /rpa/logs/gateway/access_log.log 파일 확인

auth, batch, comm, core, scheduler, tenant, textrecognitionServer, workflow 서비스에 Access Log 추가하는 방법

1) Access Log 추가하고 싶은 서비스 폴더(예 /rpa/apps/auth)에 application.properties 생성, 이미 있다면 내용 추가
디렉토리(server.tomcat.accesslog.directory)는 각 서비스에 맞도록 변경

2) run.sh 실행 쉘에 apllication.properties 추가

3) 서비스 재시작하여 /rpa/logs/서비스명/access-log 생성되는지 확인

로그파일 주기적 삭제 가이드

이번 절에서는 주기적으로 쌓이게 되는 로그에 대한 삭제 가이드 입니다. 지속적으로 쌓이게 되는 로그파일로 인해 디스크 공간 부족이 발생될 수 있으므로 반드시 로그 디렉토리를 확인해서 삭제 방안을 적용하여야 합니다. 삭제 주기, 백업 설정 등 세부 운영 방안은 각 사의 정책과 환경에 따라 적용하기를 권장합니다.

로그 자동 삭제 쉘 스크립트 만들기

예시)

1) 수정된지 11일지난 파일은 삭제된다.  파일을 열고 아래처럼 작성한다.
> cd /rpa/tools
> vi log_del.sh

#!/bin/sh
find /rpa/logs/*/* -mtime +10 -delete
find /rpa/logs/*/archived/*.* -mtime +10 -delete
find /rpa/logs/admin/*.* -mtime +10 -delete
cp /rpa/logs/admin/catalina.out /rpa/logs/admin/catalina_$(date +%F_%H-%M-%S).log
cat /dev/null > /rpa/logs/admin/catalina.out

2) 저장하고 나가기 (:wq)

3) 실행권한주기
> chmod 755 log_del.sh

스케쥴 등록하기(crontab), root 권한

예시)
1)crontab에 등록, 매일 00:30분에 삭제 쉘를 실행함.
>crontab -e
30 00 * * * /home/rpco/tools/log_del.sh

2) 저장후 나가기(:wq)

Portal 인스턴스 분리 가이드 (user, admin, tenant 분리)

이번 절에서는 Brity RPA 오케스트레이터 포탈 인스턴스를 분리 하는 방법에 대한 설명입니다.
Brity RPA에는 사용자 권한 별로 user, admin, tenant 포탈이 각각 존재 합니다.
기본적으로 3개의 포탈은 하나의 서비스로 기동되도록 설치가 됩니다.
이번절에서는 3개의 포탈을 분리 하는 방법과 장단점에 대해서 설명합니다.

장단점

3개의 포탈을 각 인스턴스로 분리하여 운영하는 경우에는 다음과 같은 장단점이 있으며 고객사의 정책에 따라 결정하여 설정이 가능합니다. 

장점 : 포털 인스턴스 분리를 통해 장애시 영향도 최소화
단점 : 개별로 인스턴스를 기동함으로 인한 CPU/Memory등 서버 자원 사용량 및 관리 대상의 증가

커맨드 수행 가이드

기본 설치 패키지에는 별도로 제공되지 않으며, 다음과 같이 수동으로 분리 설정이 가능합니다.

* 포털 인스턴스 분리 커맨드 

아래 명령어를 통해 인스턴스 분리가 수행됩니다. 

1) 기존 폴더는 백업이 진행됩니다.
tomcat 폴더백업 /home/rpa/pkgs/tomcat_bak
admin 폴더백업 /home/rpa/apps/admin_bak
톰캣 실행쉘 /home/rpa/bin/tomcat-run.sh.bak
톰캣 종료쉘 /home/rpa/bin/tomcat-stop.sh.bak

2) 커맨드 수행
아래 커멘드는 RPA 경로 /home/rpa 기준으로 만들어졌으며 각자의 설치경로를 바꾸어 사용하기 바랍니다.

cd /home/rpa/apps
cp -R admin admin_bak
cd /home/rpa/pkgs
cp -R tomcat tomcat_bak
mkdir tomcat/tomcat_admin
mkdir tomcat/tomcat_user
mkdir tomcat/tomcat_tenant
cp -R tomcat_bak/* tomcat/tomcat_admin
cp -R tomcat_bak/* tomcat/tomcat_user
cp -R tomcat_bak/* tomcat/tomcat_tenant
cd /home/rpa/apps
mkdir portal_admin
mkdir portal_user
mkdir portal_tenant
ln -s /home/rpa/apps/admin/user /home/rpa/apps/portal_user/user
ln -s /home/rpa/apps/admin/admin /home/rpa/apps/portal_admin/admin
ln -s /home/rpa/apps/admin/tenant /home/rpa/apps/portal_tenant/tenant
f=server.xml
cd /home/rpa/pkgs/tomcat/tomcat_user/conf
sed -i 's/8080/8080/g' $f
sed -i 's/8009/8009/g' $f
sed -i 's/8443/8443/g' $f
sed -i 's/8005/8005/g' $f
sed -i 's/\/apps\/admin/\/apps\/portal_user/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/user/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/user/g' logging.properties
cd /home/rpa/pkgs/tomcat/tomcat_admin/conf
sed -i 's/8080/8090/g' $f
sed -i 's/8009/8010/g' $f
sed -i 's/8443/8444/g' $f
sed -i 's/8005/8006/g' $f
sed -i 's/\/apps\/admin/\/apps\/portal_admin/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/admin/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/admin/g' logging.properties
cd /home/rpa/pkgs/tomcat/tomcat_tenant/conf
sed -i 's/8080/8070/g' $f
sed -i 's/8009/8011/g' $f
sed -i 's/8443/8445/g' $f
sed -i 's/8005/8007/g' $f
sed -i 's/\/apps\/admin/\/apps\/portal_tenant/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/tenant/g' $f
sed -i 's/\/logs\/admin/\/logs\/admin\/tenant/g' logging.properties
f=comm.properties
cd /home/rpa/apps/admin/user/WEB-INF/classes/properties
sed -i 's/\/user\/auth/\/tenant\/auth/g' $f
sed -i 's/\/admin\/admin/\/portal_user\/user/g' $f
sed -i 's/8080\/user/8080\/user/g' $f
sed -i 's/8080\/admin/8090\/admin/g' $f
sed -i 's/8080\/tenant/8070\/tenant/g' $f
sed -i 's/portalSSO=true/portalSSO=false/g' $f
cd /home/rpa/apps/admin/admin/WEB-INF/classes/properties
sed -i 's/\/user\/auth/\/admin\/auth/g' $f
sed -i 's/\/admin\/admin/\/portal_admin\/admin/g' $f
sed -i 's/8080\/user/8080\/user/g' $f
sed -i 's/8080\/admin/8090\/admin/g' $f
sed -i 's/8080\/tenant/8070\/tenant/g' $f
sed -i 's/portalSSO=true/portalSSO=false/g' $f
cd /home/rpa/apps/admin/tenant/WEB-INF/classes/properties
sed -i 's/\/user\/auth/\/tenant\/auth/g' $f
sed -i 's/\/admin\/admin/\/portal_tenant\/tenant/g' $f
sed -i 's/8080\/user/8080\/user/g' $f
sed -i 's/8080\/admin/8090\/admin/g' $f
sed -i 's/8080\/tenant/8070\/tenant/g' $f
sed -i 's/portalSSO=true/portalSSO=false/g' $f
cd /home/rpa/bin
cp tomcat-run.sh tomcat-run.sh.bak
sed -i 's/.\/startup.sh/#.\/startup.sh/g' tomcat-run.sh
sed -i 's/cd /#cd /g' tomcat-run.sh
sed -i 's/sudo -u/sudo /g' tomcat-run.sh
f=tomcat-run.sh
sed -i '19 i cd /home/rpa/pkgs/tomcat/tomcat_user/bin' $f
sed -i '20 i ./startup.sh' $f
sed -i '21 i cd /home/rpa/pkgs/tomcat/tomcat_admin/bin' $f
sed -i '22 i ./startup.sh' $f
sed -i '23 i cd /home/rpa/pkgs/tomcat/tomcat_tenant/bin' $f
sed -i '24 i ./startup.sh' $f
sed -i '12 i cd /home/rpa/pkgs/tomcat/tomcat_user/bin' $f
sed -i '13 i ./startup.sh' $f
sed -i '14 i cd /home/rpa/pkgs/tomcat/tomcat_admin/bin' $f
sed -i '15 i ./startup.sh' $f
sed -i '16 i cd /home/rpa/pkgs/tomcat/tomcat_tenant/bin' $f
sed -i '17 i ./startup.sh' $f
cp tomcat-stop.sh tomcat-stop.sh.bak
sed -i 's/.\/shutdown.sh/#.\/shutdown.sh/g' tomcat-stop.sh
sed -i 's/cd /#cd /g' tomcat-stop.sh
f=tomcat-stop.sh
sed -i '20 i cd /home/rpa/pkgs/tomcat/tomcat_user/bin' $f
sed -i '21 i ./shutdown.sh' $f
sed -i '22 i cd /home/rpa/pkgs/tomcat/tomcat_admin/bin' $f
sed -i '23 i ./shutdown.sh' $f
sed -i '24 i cd /home/rpa/pkgs/tomcat/tomcat_tenant/bin' $f
sed -i '25 i ./shutdown.sh' $f

변경 사항 및 기동 절차

1. 인스턴스 분리에 따른 포트 변경 
- user 포털 https://ip:8080/user => https://ip:8080/user
- admin 포털 https://ip:8080/admin => https://ip:8090/admin
- tenant 포털 https://ip:8080/tenant => https://ip:8070/tenant
* 추가된 웹포트 8090, 8070 에 대해서 방화벽 추가 오픈 필요

2. web 어플리케이션 소스폴더 심볼릭 링크
- user 포털 /home/rpa/apps/admin/user => /home/rpa/apps/portal_user/user
- admin 포털 /home/rpa/apps/admin/admin => /home/rpa/apps/portal_admin/admin
- tenant 포털 /home/rpa/apps/admin/tenant => /home/rpa/apps/portal_tenant/tenant

3. tomcat 인스턴스 분리
- 기존 한개의 인스턴스로 구동 /home/rpa/pkgs/tomcat/bin/startup.sh
- 변경 3개의 인스턴스로 개별 구동 가능
=> user 포털 기동 /home/rpa/pkgs/tomcat/user/bin/startup.sh
=> user 포털 종료 /home/rpa/pkgs/tomcat/user/bin/shutdown.sh
=> admin 포털 기동 /home/rpa/pkgs/tomcat/admin/bin/startup.sh
=> admin 포털 종료 /home/rpa/pkgs/tomcat/admin/bin/shutdown.sh
=> tenant 포털 기동 /home/rpa/pkgs/tomcat/tenant/bin/startup.sh
=> tenant 포털 종료 /home/rpa/pkgs/tomcat/tenant/bin/shutdown.sh

4. tomcat 기동방법
- 톰캣 기동은 기존과 동일하게 /home/rpa/bin/tomcat-run.sh 통해 3개 인스턴트 동시 기동하도록 구성됨

5, tomcat 종료방법
- 톰캣 종료는 기존과 동일하게 /home/rpa/bin/tomcat-stop.sh 통해 3개 인스턴트 동시 종료되도록 구성됨

설정 원복 방법

설정후 원복 방법은 다음과 같습니다. 삭제시 유의 바랍니다.

cd /home/rpa/apps
rm -rf portal_admin
rm -rf portal_tenant
rm -rf portal_user
cp /home/rpa/apps/admin_bak/user/WEB-INF/classes/properties/comm.properties /home/rpa/apps/admin/user/WEB-INF/classes/properties/comm.properties
cp /home/rpa/apps/admin_bak/user/WEB-INF/classes/properties/comm.properties /home/rpa/apps/admin/user/WEB-INF/classes/properties/comm.properties
cp /home/rpa/apps/admin_bak/user/WEB-INF/classes/properties/comm.properties /home/rpa/apps/admin/user/WEB-INF/classes/properties/comm.properties
cd /home/rpa/pkgs/tomcat
rm -rf tomcat_admin
rm -rf tomcat_user
rm -rf tomcat_tenant
cd /home/rpa/bin
rm tomcat-run.sh tomcat-stop.sh
mv tomcat-run.sh.bak tomcat-run.sh
mv tomcat-stop.sh.bak tomcat-stop.sh

서버 자원 증설 가이드

오케스트레이터 설치시 솔루션에서 기본적인 권장 사양을 제시합니다. 그러나 사용기간이 늘어나면서 서버의 사용자 수, 봇의 수, 잡의 수행 횟수, 예약 작업 수 등 전체 사용량이 증가하면서 초기 서버 자원으로 서비스를 할 수 있는 한계가 발생됩니다. 이 경우 운영자는 서버 자원의 증설을 고려 하여야 합니다. 운영자는 초기 설치 부터 사용자 및 봇의 증가 등을 고려 하여 인프라 구성을 고려 하여야 합니다. 
이번 절에서는 Brity RPA 오케스트레이터의 서버 자원 증설의 기준 가이드를 제공합니다.

자원 증설 방안 비교

• 스케일 업(Scale-up)

1) 장점 
추가적인 네트워크 연결 없이 용량을 증가 시킬수 있습니다. 
스케일 아웃 방법 보다 관리 비용이나 운영 이슈가 적고, 서버 자원의 사양을 올리는 작업으로 비교적 쉽게 적용이 가능합니다.

2) 단점 
성능 향상 및 부하 분산에 한계가 발생됩니다. 
서버 한대가 부담하는 양이 많아서 장애 발생시 백업 방안이 없습니다. 
기존의 서버를 교체하여 성능을 올리는 경우 서비스 다운 타임이 발생합니다.

• 스케일 아웃(Scale-out)

1) 장점
여러개의 노드가 부하를 분산하여 원할한 서비스를 제공할 수 있습니다.
장애 대응시 백업 플랜을 세울 수 있으며, 유연한 자원운영이 가능합니다.

2) 단점
서버의 수가 늘어날 수록 서버 관리가 힘들어 지는 부분이 있으며, 초기 아키텍쳐 도입시 네트워크 장비등 기반 인프라 확보등 초기 비용이 수반됩니다.
노드가 확장될 수록 문제 발생시 L4등 다양한 장애가 발생되는 경우 원인 규명이 어려워 질 수 있습니다.
사용자가 적어 지거나 확장의 필요성이 없어지는 경우 확보된 자원 사용에 손해가 발생될 수 있습니다.

• 스케일 업(Scale-up)과 스케일 아웃(Scale-out)의 장단점 비교

스케일 업 증설 기준

1) 서버의 CPU 사용량은 처리량이나 작업 부하에 따라 다를 수 있으며, 일반적으로 CPU 사용량이 평균 70% 이상이면 증설 여부를 검토 합니다.

2) 메모리 사용량은 프로젝트의 동시 수행 량에 따라 달라지나 사실상 메모리 사용량이 평균 80% 이상이면 증설을 고려하여야 합니다. 상세한 메모리 사용량은 메모리 산정기준을 참고합니다.

3) 정확한 기준은 서버의 용도, 업무 특성 등에 따라 다를 수 있습니다.  따라서 서버 증설 여부를 결정하는 고객사의 합의된 절차나 기준에 따라 판단하여야 합니다.

4) 기타 디스크 증설 기준은 다음의 설치 매뉴얼내의 Disk 용량 산정기준을 참고합니다.

스케일 아웃 증설 기준

1) 스케일 아웃을 고려 하기 위해서는 기본적으로 이중화 구성이 적용된 상태이어야 합니다.

2) 한개의 노드는 설치 권장 사양의 서버 자원을 기준으로 증설을 고려합니다.
   상세한 권장 사양은 설치 메뉴얼내 HW요구사항을 참고 합니다.

3) 일반적으로 80%가동중인 봇 100대이상 증가시 부하 분산을 위한 노드 증설 기준으로 제시 합니다.

4) 각 노드별 임계치 설정은 다음과 같이 자원 모니터링 기능에서 설정할 수 있습니다.

서버 구성

서버 구성도

기본 설치 경로 : /RPA

이중화 서버 구성도

스위치 구성에 따라 RPA 서버를 이중화 하여 구성할 수 있습니다
※ 하드웨어(L4/L7) 혹은 소프트웨어 reverse proxy (nginx) 스위치 별도 구성 필요함, Application 과 무관하게 이중화 구성이 가능한 RDBMS는 별도로 설명하지 않음.

서비스 상태 점검

1. Health Check API 호출

아래의 API 호출 형식과 모듈명을 참고하여 API를 로컬 호출합니다. (Method : GET)

예: http://127.0.0.1:9091/auth/version

예외)
 •gateway, comm 서비스는 https를 사용해야 합니다.
 •gateway는 모듈명 없이 사용함(https://서버주소:8777/version)
 •RPA v2.0부터는 이전 버전에서의 Asset, Interface, Event 서비스들을 Core 서비스 하나로 통폐합했기 때문에 모듈명이 다를 수 있는 점 유의바랍니다

2. 호출 결과

서비스가 정상 상태라면 API호출 시 버전 정보가 표시됩니다.
OCR 서비스의 경우, 버전 정보뿐만 아니라 성능정보가 JSON 형태로 함께 표시됩니다.

로그 위치 및 파일 관리

1. 모듈별 로그 위치
   /{설치위치}/logs/{모듈명}/server.log  #전체로그 
   /{설치위치}/logs/{모듈명}/error.log    #에러로그
   Ex) /rpa/logs/auth/serverlog

2. 오류 추적하기
   기능간 모듈 관계도를 참고하여 우선적으로 관련된 로그를 확인합니다.

3. 오류 파일 관리하기
   기본적인 로그 저장은 1일 이며. 파일 최대 사이즈는 10MB 입니다. 최대 사이즈 초과 시 자동으로 
   새로운 로그 파일이 생성됩니다. 주기적으로 필요 없는 로그 파일은 삭제 해서 서버 용량을 확보해야 
   합니다.