리포지토리 파티셔닝 이해

리포지토리는 자동화 워크스페이스(자동화 및 파일)를 관리할 수 있는 핵심 구성 요소 중 하나입니다. 파티셔닝을 사용하면 리포지토리를 확장하고 체크인 및 체크아웃과 같은 리포지토리 관련 작업의 성능을 최적화할 수 있습니다.

주: 리포지토리 파티셔닝 기능을 사용하려면 엔터프라이즈 플랫폼 라이선스가 필요합니다. 이 기능에 대해 지원되는 버전에 대한 자세한 정보는 엔터프라이즈 플랫폼 항목을 참조하십시오.

개요

Automation 360 리포지토리는 모든 Bot, 양식, 프로세스 및 종속성 파일이 저장되는 단일 Git 리포지토리입니다. 리포지토리는 Git을 기반으로 하므로 체크인, 체크아웃, 버전 기록, 롤백 및 버전 비교와 같은 몇 가지 기본적인 버전 관리 기능을 제공합니다. 따라서 Automation 360에서 외부 원격 Git과의 통합은 필수 사항이 아닙니다.

Automation 360의 모든 파일은 버전 관리를 위해 Git 리포지토리에 저장됩니다. 일정 기간이 지나면 파일 수, 파일 크기, Git 커밋 등으로 인해 Git 리포지토리가 커질 수 있습니다. 이로 인해 리포지토리 작업을 실행할 때 지연이 발생할 수 있습니다.

리포지토리 파티셔닝을 사용하면 Automation 360 리포지토리 폴더를 별도의 Git 리포지토리로 분할할 수 있습니다. 루트 수준 폴더의 대용량 공개 리포지토리를 선택한 폴더 수준의 여러 Git 리포지토리로 분할하여 리포지토리 파티션의 성능 문제를 제한할 수 있습니다.

주: Control Room 관리자 또는 리포지토리 파티셔닝 권한이 있는 사용자는 리포지토리 파티셔닝 기능을 사용할 수 있습니다.

이점

리포지토리 파티셔닝의 몇 가지 이점은 다음과 같습니다.

빠른 체크인 및 체크아웃으로 더욱 빠른 업무 처리
폴더가 분할되어 있으므로 분할된 각 폴더에는 상대적으로 적은 수의 체크인 활동(커밋)이 있습니다. 이러한 소규모 커밋 덕분에 체크인 및 체크아웃 작업(동시 체크인 및 체크아웃 포함)이 더 빨라집니다.
Git 공간에서 폴더의 논리적 분리
Git에서 여러 리포지토리를 만들면 단일 장애 지점의 위험을 완화할 수 있습니다. 한 리포지토리의 문제가 다른 리포지토리나 그 안에 포함된 자동화에 부정적인 영향을 미치지 않습니다.

권장 사항

일반적인 프로덕션 시나리오에서는 다양한 부서에 해당하는 폴더가 Bots 폴더 내에 생성됩니다. 특정 비즈니스 프로세스나 프로젝트(여러 비즈니스 프로세스)를 기준으로 부서 폴더 내에 하위 폴더가 생성됩니다. 고객이 다양한 수준에서 생성할 수 있는 공유 라이브러리를 보유하는 것도 일반적이며, 이는 다른 프로세스에 걸쳐 추가적으로 공유됩니다.

모든 파일이 다양한 자동화 또는 시민 개발자에 의해 동시에 동일한 파티션(git 리포지토리)에 체크인되는 시나리오를 고려하십시오. 데이터 처리 속도에 영향을 미치고 상당한 지연을 초래할 수 있습니다. 장기적으로 성능에 영향이 없도록 하기 위해서는 아래의 권장 접근 방식을 검토하십시오.

운영 접근 방식
팀당 하나의 파티션을 만드는 것이 좋습니다. 하나의 팀은 유사한 일련의 비즈니스 프로세스를 다루는 사람들의 그룹으로 구성됩니다. 각 팀의 최적의 성과를 위해 각 세트의 개발자 수를 50명 이하로 제한하십시오. 개발자가 더 많은 경우 확장성을 위해 파티션으로 나눌 수 있습니다.
수행하는 모든 파티션에 대해 해당 폴더에 자동화 또는 파일을 체크인하거나 가져오려는 사용자는 파티션이 진행 중이라는 알림을 받습니다.

파티션 분할이 진행되는 동안 사용자는 분할된 폴더나 하위 폴더에서 체크인, 가져오기, 대량 체크인 및 삭제 작업을 수행할 수 없습니다. 해당 시간 동안 사용자가 자동화에 체크인을 시도하더라도 대기하라는 알림이 표시됩니다. 그러면 사용자는 아무 문제 없이 개인 워크스페이스에서 작업을 계속할 수 있으며 작업이 차단되지도 않습니다. 또한, Git 복원, Git 설정 및 대량 패키지 업데이트는 보편적으로 제한됩니다.

20GB 크기의 리포지토리에서 테스트한 결과, 이 작업에 최대 1.5시간이 걸리는 것으로 나타났습니다. 그러나 이 시간은 NAS(네트워크 연결 스토리지)의 성능에 따라 달라질 수 있습니다. 운영 비용이 매우 낮으며 시간이 지남에 따라 이를 수행할 수 있습니다.

예를 들어, 사용자나 시민 개발자가 적은 영업일 종료 시점에 4~6개의 파티션을 수행할 수 있습니다. 이는 다른 비즈니스 유저에게 영향을 주지 않고 파티셔닝 프로세스를 실행할 수 있게 합니다.

파티션 분할할 폴더를 결정합니다.
폴더 분할에 대한 다음 권장 사항을 검토합니다.
  • RepositoryFolderSizeReport.exe 도구를 다음 위치 (Control Room 노드 중 하나에 있는 스크립트 디렉토리에서 실행합니다. 명령어 사용: 
    RepositoryFolderSizeReport.exe --root "Z:\Server Files\repository\16933f12-fdee-4a7f-8e76-a9bf127918c6\0\Automation Anywhere\Bots"
  • 환경에서 위 스크립트를 올바른 테넌트 ID로 바꿔야 합니다.

    예: 16933f12-fdee-4a7f-8e76-a9bf127918c6.

  • Z:\Server Files\repository를 사용하여 NAS 드라이브를 검토합니다.
  • 폴더 경로 및 해당 크기(MB)가 포함된 folder_sizes.csv 보고서를 생성합니다.
    이를 통해 폴더 파티셔닝을 계획할 수 있습니다.
    주: Git은 최적의 성능을 위해서 리포지토리 크기를 2GB보다 작게 제한할 것을 권장합니다.
  • 이 유틸리티는 폴더 파티션을 계획하는 데 도움이 되는 각 폴더의 크기를 제공합니다.
시간 초과 설정
리포지토리 파티셔닝은 폴더를 파티션하기 위해 외부 프로그램을 시작합니다. 이 외부 프로그램이 12시간(기본값) 이내에 출력을 제공하지 않으면 종료되며, 사용자는 파티셔닝 프로세스를 다시 시작할 수 있습니다. 12시간 제한 시간이 너무 길면 다음 위치의 속성 파일을 수정하여 2시간으로 변경할 수 있습니다. <CR_Folder>\\config\\repository.properties.

다음을 보장합니다. (값을 초 단위로 설정하여 repository.partition.read.line.timeout 속성을 업데이트함) 예를 들어, 2시간의 시간 초과의 경우 값을 7200으로 설정합니다.

모든 변경 사항이 적용된 후 커널을 다시 시작합니다.

리포지토리 파티셔닝 모니터링
  • 스크립트 PartitionMonitor를 사용하여 로그 파일에서 파티셔닝 진행 상황을 모니터링합니다.
  • 각 CR 노드에서 PartitionMonitor.ps1 스크립트를 실행합니다.

    파티셔닝 요청은 설계상 노드 중 하나에서 처리됩니다. 따라서 진행 결과는 해당 특정 노드에서만 볼 수 있습니다.

  • Windows PowerShell을 열고 스크립트 디렉터리 (C:\scripts)로 이동합니다. 다음을 실행합니다. 다음 명령어 사용: 
    .\PartitionMonitor.ps1 -sourceDirectory "C:\ProgramData\AutomationAnywhere\Logs" -outputFile out.log