별첨

FAQ

DB 접속정보 변경하기

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

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
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!
cd /rpa/properties
vi application.properties

아래 속성을 변경합니다.

ipa.db.server.url= DB_IP
ipa.db.server.port=DB_PORT
wq!
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!

서버 재기동 절차

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

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

기동

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
su ipaadm
cd /rpa/bin
./activemq-run.sh

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

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

또는 

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

ps -ef|grep tomcat

종료

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

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

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

cd /rpa/bin
./stop.sh

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

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

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

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

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 서버 IP/PORT 설정입니다.

Property

Description

ipa.server.ip.{servername}

{servername} 서버가 설치된 주소입니다.

ipa.server.port.{servername}

{servername} 서버가 사용하는 포트입니다.

auth.ssl.verifyiplist

RPA 서버에서 타 서버로 요청이 필요한 경우 ip 주소 명시가 필요합니다. "," 로 ip주소를 구분하며 공백 없이 입력해 줍니다.

ex) 203.254.214.131,112.107.220.134

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

Property

Description

auth.token.timeout

서버 토큰 발행 시 timeout 기본값을 세팅할 수 있습니다.

- 초깃값: 43200, 단위: 초

auth.token.timeout.{detail}

{detail} 의 상세 토큰 timeout을 세팅할 수 있습니다. 단위는 초 이며 설정하지 않을 경우 기본값인 auth.token.timeout으로 세팅됩니다.(bot, designer, standalonebot, user, server, mobile)

useOcr

OCR 기능 사용 여부입니다.

- 초깃값: N, 사용 시: Y

추가적으로 application.propertiesipa.server.ip/port/contextPath.ocr 세팅이 필요합니다.

comm.propertiesocr.server 세팅이 필요합니다.

server.domain

디자이너 SSO 동작을 위한 서버의 domain, 도메인을 사용하지 않는다면 설정 필요 없음

portal.port

디자이너 SSO 동작을 위한 서버의 domain, 8080포트를 사용한다면 설정 필요 없음

support.password.validation

RPA 포털에서 외부 인증 연계를 구성하여 운영중인 경우, Brity RPA의 자체 계정으로 인증을 수행되지 않도록 설정하는 프로퍼티이며, 해당 값을 설정하면 Designer 에서 직접 ID/Password 입력으로 로그인 또는 라이선스 비활성화 기능을 사용할 수 없으며, Mobile은 사용할 수 없습니다.

기본적으로 파일에 존재하지 않으며 필요 시 아래와 같이 프로퍼티를 추가한 후 Gateway, Tenant 서버를 재기동하면 설정이 반영됩니다.

support.password.validation=false

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

Property

Description

spring.datasource.{servername}.url

초기 설정된 DB 주소의 {servername} DB 스키마 주소입니다.

spring.datasource.{servername}.username

초기 설정된 DB 주소의 {servername} DB 유저입니다.

spring.datasource.{servername}.password

초기 설정된 DB 주소의 {servername} DB PW입니다.

- 초깃값: jasyptEncryption (pw는 평문으로 표기하여도 무방)

spring.datasource.max-active

DB 커넥션 풀 제공하는 최대 커넥션 개수입니다.

- 초깃값: 30, 단위: 개

spring.datasource.max-idle

Idle 시 커넥션 풀에 저장되는 최대 커넥션 개수입니다.

- 초깃값: 30, 단위: 개

spring.datasource.min-idle

Idle 시 커넥션 풀에 저장되는 최소 커넥션 개수입니다.

- 초깃값: 30, 단위: 개

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

Property

Description

knox..messenger.server.token

발급받은 Knox messenger 연계용 토큰입니다.

테넌트 포탈로 메뉴화되어 더이상 사용하지 않습니다. (Deprecated)

knox.messenger.module.enabled

Knox messenger 연계 사용 여부입니다.

- 초깃값: false, 사용 시: true

knox.messenger.suffix

Knox 메신저 연계시 도메인 추가 탐색 기능입니다.

아이디 체계가 이메일로 되어있는 경우에만 사용합니다.

값이 없으면 기존 로직대로 동작합니다.

예시) @samsung.com;@partner.samsung.com

knox.server.token

메일/일정/유저 연계 시 사용할 연계 토큰입니다.

테넌트 포탈로 메뉴화되어 더이상 사용하지 않습니다. (Deprecated)

knox.server.id

메일/일정/유저 연계 시 사용할 연계 유저입니다.

테넌트 포탈로 메뉴화되어 더이상 사용하지 않습니다. (Deprecated)

knox.server.pw

메일/일정/유저 연계 시 사용할 연계 유저 pw입니다.

jasyptEncoding된 값(pw 평문으로 표기하여도 무방)

더이상 사용하지 않습니다. (Deprecated)

knox.calendar.defaultUserId

일정 연계 시 사용할 유저 세팅입니다.

knox.server.url

Knox 연계 주소입니다. (Production)

knox.server.devurl

Knox 연계 주소입니다. (Stage)

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

Property

Description

logging.level.com.sds.rpa

core, auth, scheduler, gateway 서버의 로그 레벨 설정입니다.

- 초깃값: INFO

- 설정 가능 값 : TRACE, DEBUG, INFO, WARN, ERROR

logging.level.com.sds.ipa.tenant

tenant 서버의 로그 레벨 설정입니다.

- 초깃값: INFO

- 설정 가능 값 : TRACE, DEBUG, INFO, WARN, ERROR

SMTP 메일 연계를 위한 설정입니다.
Tenant Portal > 설정 관리에서 설정할 수 있습니다.(SMTP 설정 참고)
RPA 서버의 인증서 세팅입니다. 각 서버는 설치 시 제공되는 사설인증서가 세팅되어 있습니다.
이중화 구성 시, AP2 서버에는 AP1번 서버와 다른 _02 인증서 세팅이 되어 있어야 합니다.
Brity RPA SaaS 용 세팅입니다. 고객사에서는 별도로 수정할 필요가 없습니다.
변경 가능한 속성값입니다.

Property

Description

scheduler.job.enableSecureParam

Job 실행 이후 파라미터를 확인할 수 없도록 보안 설정을 활성화하여 Job 관련 파일 다운로드 API 호출을 제한합니다.

아래의 comm.properties의 설정값과 일치되는 것을 권장합니다.

활성화하기 위해서는 해당 프로퍼티를 Y로 설정해야 합니다.

- 초깃값 : N

apikey.log.keepdays

API Key를 사용하여 API 요청한 경우 이력을 저장하고 있으며, 해당 이력을 보관하는 기간을 지정합니다. 단위는 일(Days) 입니다.

- 초깃값 : 60

queueMaxMessageSizeMb

RPA 서비스 애플리케이션에서 처리되는 Queue 메시지의 최대 크기를 지정합니다. 메시지 크기의 단위는 MB 입니다.

- 초깃값 : 5

comm.properties 속성 설명

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

Property

Description

defaultLang

포털 기본 언어 세팅입니다.

- 초깃값: KO, KO/EN을 지원

maxUploadSizeMb

메일 첨부, 프로세스, 기념일 등 포털에서 업로드하는 파일의 최대 용량을 설정합니다.

- 초깃값: 10, 단위: MB

defaultTimeZondId

포털 기본 timezone 세팅입니다.

- 초깃값: Asia/Seoul (area/Location 형태의 tz format을 사용함)

예시) America/New_York

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

Property

Description

auth.ssl.verifyiplist

RPA 서버에서 타 서버로 요청이 필요한 경우 ip 주소 명시가 필요합니다. "," 로 ip 주소를 구분하며, 공백 없이 입력 해줍니다.

ex) 203.254.214.131,112.107.220.134

rpa.login.sso

Knox Portal SSO 연동 기능 사용 여부입니다.

- 초깃값: false, 사용 시: true

interface.sendmail

Knox 연동 시 값 변경이 필요합니다

- 초깃값: /interface/api/v1/mail/sendMail

- 연동 시:

/interface/api/v1/knox/mail/sendMail

systemqueue.data.retention.days

DB 저장되는 system queue data 저장 기간입니다.

- 초깃값: 30, 단위: 일

userqueue.data.retention.days

DB 저장되는 user queue data 저장 기간입니다.

- 초깃값: 30, 단위: 일

queue.cron.start.expression

Queue의 데이터 삭제 주기를 설정합니다.

- 초깃값: 매일 새벽 3시(0 0 3 * * ?)

초, 분, 시, 일, 월, 요일, 연 cron expressions 값

useKnox

삼성 관계사에서 사용이 가능한 Knox 연계 설정을 화면에서 조회할 수 있도록 설정합니다. comm.properties 파일 내 속성이 정의되어 있지 않으므로 속성값 변경이 필요한 경우 파일 내 속성을 명시(useKnox=true) 해야 합니다.

- 초깃값: false (Knox 연계 설정이 표시되지 않습니다.)

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

Property

Description

spring.datasource.max-active

DB 커넥션 풀 제공하는 최대 커넥션 개수입니다.

- 초깃값: 30, 단위: 개

spring.datasource.max-idle

Idle 시 커넥션 풀에 저장되는 최대 커넥션 개수입니다.

- 초깃값: 30, 단위: 개

spring.datasource.min-idle

Idle 시 커넥션 풀에 저장되는 최소 커넥션 개수

- 초깃값: 30, 단위: 개

jdbcUserName

초기 설치 시 admin 계정을 사용합니다.

jdbckey

초기 설치된 admin 계정의 pw입니다.

평문 입력도 가능합니다.

Brity RPA SaaS 용 세팅입니다. 고객사에서는 별도 수정할 필요가 없습니다. 
rpa.service.saas 는 항상 false로 유지되어야 합니다.
자주 변경이 되는 포털 속성 값들입니다.

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

Property

Description

agreemetUse

개인정보 처리 방침 기능 사용 여부입니다.

- 초깃값: false, 사용 시: true

사용 시 회원가입 시 사용자의 개인정보 처리 방침 동의가 필수값이 되며, 이는 catalog.fr_user_info_history 테이블에 저장됩니다.


각 고객사별 개인정보 처리 방침은 /rpa/apps/admin/{admin/user/tenant}/WEB-INF/classes 하위에 agreeContent.html(국문), agreeContent_en.html(영문) 형태로 저장하면 됩니다.

passwordChangeCycle

설정된 주기에 따라 유저 로그인 시 pw 변경 팝업을 노출합니다

- 초깃값: 6, 단위: 월(month)

fcm.databse.url

*모바일 접속 시

firebase로부터 제공 받은 계정 정보입니다.

fcm.credentials.path

*모바일 접속 시

firebase로부터 제공 받은 credential 파일입니다.

/rpa/apps/admin/{admin/user/tenant}/WEB-INF/classes 경로에 저장 후

ex) fcm.credentials.path=classpath:{파일명}

apns.cert.path

iOS 모바일용 인증서 경로입니다.

/rpa/apps/admin/{admin/user/tenant}/WEB-INF/classes 경로에 저장 후

ex) apns.cert.path=classpath:{파일명}

apns.cert.path

발급받은 iOS 모바일 인증서 PW입니다.

portalSSO

admin/tenant/user 포털 간 SSO 사용 여부입니다.

(초깃값: true) (미사용 시: false)

미사용 시 admin/tenant/user 포털 간 별도의 세션을 사용해 사용자를 관리합니다.

portal.sso.***Url

portalSSO 적용 시 사용되는 URL입니다.

도메인 적용 시: https://{DOMAIN:PORT}/***

이중화 적용 시: https://{L4_IPAddr:PORT}/***

단일 서버 적용: https://{Svr_IPAddr:PORT}/***

useOcr

OCR 기능 사용 시 Y로 변경해야 합니다.

-초깃값 : N

external.auth.login

false / true (초기값 : false)

고객사에서 자체 인증 시스템 연동할 경우 true 로 설정합니다.

scheduler.job.enableSecureParam

Job 실행 이후 파라미터를 확인할 수 없도록 보안 설정을 활성화합니다.

활성화하기 위해서는 해당 프로퍼티를 Y로 설정해야 합니다.

위 application.properties의 설정값과 일치되는 것을 권장합니다.

- 초깃값 : N

disableUserInfoCopy

사용자 데이터 목록 복사 및 엑셀 다운로드를 할 수 없도록 설정을 변경합니다.

활성화하기 위해서는 해당 프로퍼티를 Y로 설정해야 합니다.

- 초깃값 : N

auth.apikey.addlimitdays

API Key 추가 시점으로부터 설정 가능한 최대 만료 일자의 일수를 설정합니다.

단위는 일(Days) 입니다.

- 초깃값 : 365

OCR 서버 구성

OCR 서버 구성 방법

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

※ 정상 구동되면 로그에서 Abbyy SDK 정보를 확인할수 있습니다.

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

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

서버 데이터 에이징 설정

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

작업 주체

에이징 작업 내용

내부 동작 로직

설정 위치 및 변경

Optimize 고려

서버

(자동)

tb_job_related_file 테이블 데이터 삭제

매일 00시에 각 테넌트별로 존재하는 tb_job_related_file 테이블에서 설정값(days)이후의 의 데이터들을 삭제

(해당 row를 delete 해줌)

application.properties 파일에 아래의 속성값을 명시적으로 선언 (선언되지 않는 경우 30일로 처리됨)



scheduler.log.keepdays=30

각DB의 tb_job_related_file 테이블

운영자

(수동)

각 테넌트에 등록된 프로젝트들의 구 버젼 삭제

프로젝트의 버젼이 쌓이다보면 더이상 사용하지 않는 구버젼들이 누적됨. 사용하지 않는 구버젼들을 Admin Portal 기능으로 삭제하면 tb_asset_file 테이블의 데이터가 delete됨.


각DB의 tb_asset_file 테이블

서버

(자동)

Queue에 사용된 파일 삭제

메세지가 수신된 후 30일이 지나면 로그에서 삭제됨

comm.properties에 아래와 같이 기본정의된 내용으로 변경 가능

#Queue historical data retention

systemqueue.data.retention.days=30

userqueue.data.retention.days=30

queue.cron.start.expression=0 0 3 * * ?


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

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

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

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

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

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

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

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

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

MariaDB의 OPTIMIZE TABLE 작업

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

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

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"

문제 해결 방법

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

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

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 비활성화)

그림1

만약, 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

2

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

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

3

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 아래에 솔루션을 설치했을 경우 각 서비스의 로그를 아래와 같이 확인할 수 있습니다.

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

more mariadb.err, vi mariadb 명령어로 로그 전체를 볼 수 있습니다.

tail -f maraidb.err 명령어로 로그를 계속 출력합니다.

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

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

RPA 서비스 접속 확인

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

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

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

(예시)

curl https://182.193.17.236:8777/version --insecure
curl http://182.193.17.236:9091/auth/version

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 가 발생했는지 확인 할수 있는 방법은 다음과 같습니다.

간단한 shell 스크립트로 java heap 메모리의 상태 확인 및 효율적인 설정 가이드를 제공하는 것으로 ps -ef , jstat 정도의 명령만 수행 함으로 시스템 영향도는 없습니다.

에러 로그 전체에 대해서 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
#!/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 파라메터 항목별 권장 설정값

구분

항목

기본값

(OS 및 버젼별 상이함)

권장값

설명

TCP/IP

net.ipv4.tcp_max_syn_backlog

128

8191

Connection 연결 요청시 대기할 수 있는 전역/포트당 최대 연결개수를 설정

net.core.somaxconn

128

4096

net.ipv4.tcp_fin_timeout

60

60

FIN_WAIT_2 상태의 소켓을 해제하는 시간 설정

net.ipv4.tcp_keepalive_intvl

75

75

net.ipv4.tcp_keepalive_probes

9

9

net.ipv4.tcp_keepalive_time

7200

1800

net.ipv4.tcp_syn_retries

6

4

연결 요청에 대한 응답이 없을 때 재시도 할 횟수를 설정

net.ipv4.tcp_retries2

15

7

살아있는 TCP 연결을 종료하기 전까지 재시도 할 횟수를 설정

net.core.rmem_default

212992

262144

송신/수신 데이터를 위한 소켓 기본/최대 버퍼 크기를 설정

net.core.rmem_max

212992

10485760

net.core.wmem_default

212992

262144

net.core.wmem_max

212992

10485760

net.ipv4.tcp_tw_reuse

0

1

Local Port가 부족할 경우, TIME_WAIT 상태의 소켓을 재사용하도록 설정

(RHEL 7.6 버젼부터는 미권고)

net.ipv4.ip_local_port_range

32768 60999

16384 65000

Local Port 할당 범위를 설정하여 서버 내에서 사용 가능한 동시 연결수를 제어

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

구분

항목

기본값

(OS 및 버젼별 상이함)

권장값

설명

ulimit

soft nofile

1024

8192 이상

해당 User가 Open 할 수 있는 최대 FD(File Descriptor) 개수를 설정

hard nofile

4096

8192 이상

WAS 권장 설정값 적용 가이드

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

공통 적용 가이드

항목

적용효과

적용방법

설치 패키지 적용 여부

Heap Dump 적용

장애 발생시 원인 분석 및 디버깅에 활용

기동 스크립트의 JVM 실행 옵션에 추가

기본적용

GC log 설정 적용

어플리케이션의 메모리 사용과 GC 수행 모니터링 등 성능 튜닝 및 메모리 누수 분석시 활용 가능

기동 스크립트의 JVM 실행 옵션에 추가


1) Tomatat의 경우 setenv.sh에서 Export 하는 CATALINA_OPS에 지정

위치 : CATALINA_BASE/bin/setenv.sh


2) API 서버들은 run.sh에 옵션적용


3) 설정 가능 항목

-XX:+PrintGCDateStamps GC 이벤트 발생 시간을 출력한다.

-XX:+PrintGCDetails GC 이벤트 세부 정보를 로깅한다.

-XX:+UseGCLogFileRotation 로그 순환 기능을 켠다.

-XX:+NumberOfGCLogFiles=<n> 보관 가능한 최대 로그파일 갯수를 설정한다.

-XX:+GCLogFileSize=<size> 순환 직전 각 파일의 최대 크기를 설정한다.

선택사항

Serve 모드 운영 적용

서버 환경에서 실행될 때 더 많은 최적화를 수행하도록 JVM을 구성하게 됨.

기동 스크립트에 JVM 옵션 추가 (-server)


1) Tomcat의 경우, setenv.sh에 Export하는 CATALINA_OPTS에 지정

위치 CATALINA_BASE/bin/setenv.sh

export CATALINA_OPTS="$CATALINA_OPTS -Xmx2g –Xms2g -server"


2) API 서버들은 run.sh에 옵션으로 추가

기본적용

Tomcat 적용 가이드

항목

적용효과

적용방법

설치 패키지 적용 여부

Access Log Time Taken 필드 기본적용

응답시간 데이터를 토대로 성능 모니터링, 최적화, 사용자경험 평가 등의 작업을 수행할 수 있음

Tomcat의 server.xml에 %D or %T 추가


<Valve className="org.apache.catalina.valves.AccessLogValve"

directory="/rpa/logs/admin"

prefix="admin_access_log" suffix=".txt"

pattern="%h %l %u %t %D &quot;%r&quot; %s %b" />

기본적용

(%D 옵션)

Heap 메모리 옵션 설정

인스턴스 메모리가 무한정 상승하는 것을 방지

setenv.sh에 Export하는 CATALINA_OPTS에 지정

위치 CATALINA_BASE/bin/setenv.sh

export CATALINA_OPTS="$CATALINA_OPTS -Xmx2g –Xms2g -server

기본적용

(기본 2g)

Log Level INFO설정

서버 로그를 통한 문제 발생시 원인 분석시 활용 가능

위치 : Tomcat의 logging.properties 에서 설정


사용가능한 레벨은

ALL, FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE

기본적용

(INFO)

connectionTimeout 설정

서비스 요청이 많을 경우 Connection 연결 대기 시 불필요한 자원을 점유하여 가용 Thread 부족에 의한 장애가 발생 할 수 있음.

tomcat server.xml 파일에 Connector 속성에서 설정


<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="10000" redirectPort="8443" />

기본적용

(10000 이하)

validationInterval 설정

유효성 검사 시간이 짧을 경우 빈번한 Connection 점검 주기에 의해 부하 유발 할 수 있음.

유효성 검사 시간이 길 경우 정상적으로 유효성 체크를 하지 못해 손상된 Connection을 사용하여 장애 발생 할 수 있음

JDBC 커넥션 풀 라이브러리내 validationInterval 설정

기본적용

(30000)

StuckThreadDetectionValve 설정

비정상적으로 오래 수행되는 Request에 대한 인지가 늦어져서 Thread 과점유 현상이 발생할 있으며, Thread 부족 현상으로 인한 전체 서비스 지연 및 장애가 발생할 수 있음

(StuckThreadDetectionValve는 수행시간이 긴 쓰레드 감지하여 로깅 및 인터럽트)

server.xml 파일에서 적용할 Valve를 대상 컨테이너 하위에 설정



<Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="600" />

기본적용

(600초)

스프링부트 적용 가이드

항목

적용효과

적용방법

설치 패키지 적용 여부

Access log 설정

요청 기록, 문제 진단, 모니터링, 성능 튜닝 등에 반드시 필요한 자료이므로 Access Log를 남기는 것을 권고함

(Access/AP/GC Log 등 주기적인 삭제는 3.4 주기적 로그파일 삭제 가이드 문서에 명시)

3.3 Accesslog 설정 활성화 가이드 참고

선택사항

Circuit Breaker 적용

MSA 구조에서 Circuit Breaker를 사용하는 경우 하나의 서비스에서 발생한 장애가 다른 서비스로 전파될 가능을 차단함.

장애 발생 중에 반복해서 해당 요청이 들어올 경우 리소스가 낭비되어 서비스 처리 능력이 저하될 수 있음

별도 가이드 작성중

기본적용

(Communication

Scheduler)


선택사항

(나머지 서비스)

WebClient ConnectionTimeout 설정

서비스 요청이 많을 경우 Connection 연결 대기 시 불필요한 자원을 점유하여 가용 Thread 부족에 의한 장애가 발생 할 수 있음

CONNECT_TIMEOUT_MILLIS 10000 이하 설정

기본적용

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 오케스트레이터의 서버 자원 증설의 기준 가이드를 제공합니다.

자원 증설 방안 비교

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

2) 단점 
성능 향상 및 부하 분산에 한계가 발생됩니다. 
서버 한대가 부담하는 양이 많아서 장애 발생시 백업 방안이 없습니다. 
기존의 서버를 교체하여 성능을 올리는 경우 서비스 다운 타임이 발생합니다.
1) 장점
여러개의 노드가 부하를 분산하여 원할한 서비스를 제공할 수 있습니다.
장애 대응시 백업 플랜을 세울 수 있으며, 유연한 자원운영이 가능합니다.

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

항목

스케일 업

스케일 아웃

구성

확장성

CPU 변경, 메모리 추가 등으로 하드웨어 장비의 성능을 높임

하나의 장비에서 처리하던 일을 여러 장비에 나눠서 처리함

구성

단일화 구성, 성능 확장에 한계

이중화 구성, 수평 확장이 가능

장애 대응

한 대의 서버에 부하가 집중되어 장애 영향도가 큼

여러대의 서버에 분산 처리,

장애시 전면 장애의 가능성이 적음

필요 자원

CPU, 메모리, 디스크

추가 서버 노드

스케일 업 증설 기준

1) 서버의 CPU 사용량은 처리량이나 작업 부하에 따라 다를 수 있으며, 일반적으로 CPU 사용량이 평균 70% 이상이면 증설 여부를 검토 합니다.
2) 메모리 사용량은 프로젝트의 동시 수행 량에 따라 달라지나 사실상 메모리 사용량이 평균 80% 이상이면 증설을 고려하여야 합니다. 상세한 메모리 사용량은 메모리 산정기준을 참고합니다.
3) 정확한 기준은 서버의 용도, 업무 특성 등에 따라 다를 수 있습니다.  따라서 서버 증설 여부를 결정하는 고객사의 합의된 절차나 기준에 따라 판단하여야 합니다.
4) 기타 디스크 증설 기준은 다음의 설치 매뉴얼내의 Disk 용량 산정기준을 참고합니다.

스케일 아웃 증설 기준

1) 스케일 아웃을 고려 하기 위해서는 기본적으로 이중화 구성이 적용된 상태이어야 합니다.
2) 한개의 노드는 설치 권장 사양의 서버 자원을 기준으로 증설을 고려합니다.
   상세한 권장 사양은 설치 메뉴얼내 HW요구사항을 참고 합니다.
3) 일반적으로 80%가동중인 봇 100대이상 증가시 부하 분산을 위한 노드 증설 기준으로 제시 합니다.
4) 각 노드별 임계치 설정은 다음과 같이 자원 모니터링 기능에서 설정할 수 있습니다.

서버 구성

서버 구성도

기본 설치 경로 : /rpa

No.

모듈명

포트

프로

토콜

기능

설치 경로

1

Web Portal

8080

https

관리자/사용자/테넌트 관리UI를 제공하는 웹 포탈

/rpa/apps/admin

2

Gateway

8777

https

모든 API 요청에 대한 URL라우팅 및 이벤트 로깅

/rpa/apps/gateway

3

Auth

9091

http

라이선스 인증, API인가를 위한 기능을 제공

/rpa/apps/auth

4

Communication

9001

https





(wss)

봇과의 통신담당 및 봇의 상태를 모니터링 함

(WebSocket)

/rpa/apps/comm

5

Scheduler

9093

http

작업 할당 및 실행, Job결과 관리

/rpa/apps/scheduler

6

Workflow

9094

http

프로세스 플로우 실행 및 결과 관리

/rpa/apps/workflow

7

Core

9096

http

- 예전의 Asset, Interface, Event 서비스를 Core 서비스 하나로 통폐합(v2.0부터)

- 프로젝트, 공용 리소스 관리

- 외부 연계 API를 제공(Konx메일, 메신져, 푸쉬등)

- 비동기 이벤트에 대한 publish 및 subscriber관리

/rpa/apps/core

8

Batch

9098

http

통계, 데이터 정리 등 배치 작업 수행

/rpa/apps/batch

9

Tenant

9099

http

전체 테넌트 정보관리 및 테넌트 변경 이벤트 관리

/rpa/apps/tenant

10

TextRecognition

9095

http

OCR 기능 및 API제공

(# Abby 라이선스가 필요한 선택서비스)

/rpa/apps/textrecognitionServer

이중화 서버 구성도

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

No.

모듈명

포트

이중화

1

Web Portal

8080

Active-Active

2

Gateway

8777

Active-Active

3

Auth

9091

Active-Active

4

Communication

9001

Active-Active

5

Scheduler

9093

Active-Active

6

Workflow

9094

Active-Active

7

Core

9096

Active-Active

8

Batch

9098

Active-Active

9

Tenant

9099

Active-Active

10

TextRecognition

9095

Active-Active

서비스 상태 점검

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 서비스 하나로 통폐합했기 때문에 모듈명이 다를 수 있는 점 유의바랍니다
프로세스 모듈

No.

서비스 모듈

포트

모듈명

1

Core

9096

asset

2

Auth

9091

auth

3

Communication

9001

communication

4

API Gateway

8777

gateway

5

Scheduler

9093

scheduler

6

Tenant

9099

tenant

7

OCR

9095

textrecognition

8

Workflow

9094

workflow

9

Batch

9098

batch

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

로그 위치 및 파일 관리

1. 모듈별 로그 위치
   /{설치위치}/logs/{모듈명}/server.log  #전체로그 
   /{설치위치}/logs/{모듈명}/error.log    #에러로그
   Ex) /rpa/logs/auth/serverlog
2. 오류 추적하기
   기능간 모듈 관계도를 참고하여 우선적으로 관련된 로그를 확인합니다.
3. 오류 파일 관리하기
   기본적인 로그 저장은 1일 이며. 파일 최대 사이즈는 10MB 입니다. 최대 사이즈 초과 시 자동으로 
   새로운 로그 파일이 생성됩니다. 주기적으로 필요 없는 로그 파일은 삭제 해서 서버 용량을 확보해야 
   합니다.