リポジトリのパーティショニングの理解

リポジトリは、Automation Workspace を管理できるようにするコア コンポーネントの 1 つです (オートメーションとファイル)。 パーティショニングにより、リポジトリを調整し、チェックインやチェックアウトなどのリポジトリ関連操作のパフォーマンスを最適化できます。

注: リポジトリのパーティショニング機能には Enterprise Platform ライセンスが必要です。 この機能のサポートされているバージョンの詳細については、「Enterprise Platform」を参照してください。

概要

Automation 360 リポジトリは単一の Git リポジトリで、すべての Bots、フォーム、プロセス、依存関係のファイルが格納されています。 リポジトリは Git をベースにしているため、チェックイン、チェックアウト、バージョン履歴、ロールバック、バージョン比較など、すぐに使えるバージョン管理機能が利用できます。 したがって、Automation 360 では、外部リモート Git との統合は、要件ではありません。

Automation 360 の Git リポジトリにあるすべてのファイルは、バージョン管理のために保存されます。 Git リポジトリは、ファイル数、ファイル サイズ、Git コミット数などによって、長期間に渡って大きくなる可能性があります。 これにより、リポジトリ アクションの実行に遅延が発生する場合があります。

リポジトリ パーティショニングを使えば、Automation 360 リポジトリ フォルダーを別々の Git リポジトリに分割することができます。 ルート レベルのフォルダーにある大サイズの公開リポジトリは、選択したフォルダー レベルで複数の Git リポジトリに分割し、リポジトリ パーティションでのパフォーマンスの問題を抑えることができます。

注: A Control Room[リポジトリをパーティショニングする] 権限を持つ 管理者またはユーザーは、リポジトリのパーティショニング機能を使用できます。

メリット

リポジトリをパーティショニングするメリットには、次のものがあります。

迅速なチェックインとチェックアウトによる高速操作の実現
フォルダーはパーティショニングされるため、パーティショニングされた各フォルダーでは、チェックイン アクティビティ (コミット) が比較的少なくなります。 このようにコミット数が減る結果、チェックインとチェックアウトの操作 (同時チェックインとチェックアウトを含む) はより速くなります。
フォルダーは Git スペースで論理的に分離されます。
Git で複数のリポジトリを作成すると、単一障害点のリスクを軽減できます。 あるリポジトリで発生した問題が、他のリポジトリやその中に含まれるオートメーションに悪影響を及ぼすことはありません。

推奨事項

通常の生産シナリオでは、さまざまな部門に対応するフォルダーがBotsフォルダー内に作成されます。 特定のビジネス プロセスやプロジェクトに基づいて（複数のビジネス プロセス）、部門フォルダー内にサブフォルダーが作成されます。 顧客が異なるレベルで作成できる共有ライブラリを持つことも一般的であり、それらは他のプロセス間でさらに共有されます。

さまざまな自動化や市民開発者によって、すべてのファイルが同時に同じパーティション（gitリポジトリ）にチェックインされるシナリオを考えてみてください。 これはデータ処理速度に影響を与え、かなりの遅延を引き起こす可能性があります。 長期的にパフォーマンスに影響が出ないようにするために、以下の推奨アプローチを確認してください。

運用アプローチ
各チームごとに 1 つのパーティションを作成することをお勧めします。 チームは、同様のビジネス プロセスのセットに取り組む人々のグループで構成されています。 各セットの開発者数を 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 ファイル\rリポジトリ を使用して NAS ドライブを確認してください。
  • folder_sizes.csv レポートを生成し、フォルダーのパスとそれぞれのサイズ（MB 単位）を含めます。
    これにより、フォルダーのパーティショニングを計画できます。
    注: Git は、最適なパフォーマンスのためにリポジトリのサイズを2GB未満に制限することを推奨します。
  • このユーティリティは、フォルダーのパーティションを計画するのに役立つ各フォルダーのサイズを提供します。
タイムアウト設定
リポジトリのパーティショニングは、フォルダーをパーティション分割するために外部プログラムを起動します。 この外部プログラムが12時間（デフォルト）以内に出力を提供しない場合、プログラムは終了し、ユーザーはパーティショニング プロセスを再起動できます。 12 時間のタイムアウトが長すぎる場合は、<CR_Folder>\\config\\repository.propertiesにあるプロパティ ファイルを変更することで 2 時間に変更できます。

repository.partition.read.line.timeout プロパティを秒単位で値を設定して更新することを確認してください。 例えば、2時間のタイムアウトの場合、値を7200に設定します。

すべての変更後にカーネルを再起動します。

リポジトリのパーティショニングの監視
  • ログファイルでPartitionMonitorスクリプトを使用してパーティショニングの進行状況を監視します。
  • 各 CR ノードで PartitionMonitor.ps1 スクリプトを実行します。

    パーティショニング リクエストは、設計上、ノードの1つで処理されます。 したがって、進捗結果はその特定のノードでのみ表示されます。

  • Windows PowerShellを開き、スクリプトディレクトリ (C:\scripts) に移動します。 次のコマンドを実行します:
    .\PartitionMonitor.ps1 -sourceDirectory "C:\ProgramData\AutomationAnywhere\Logs" -outputFile out.log