はじめに
この記事はUiPathブログ発信チャレンジ2022サマーの28日目の記事です。
昨日は@kou12092さんの記事、明日は@_nooeriさんの記事です。
今回はOn-Prem Orchestratorの運用設計の内、メンテナンスについて説明します。
その他の記事
バックアップ編
監視編
前提
- On-Prem Orchestrator 2021.4
構成は冗長化（Active-Standby）したもの仮定します。
※シングル構成で仮定してもOKです。HA構成（Active-Active）だと構成要素が変わるため（Redisのクラスター構成が追加）、本記事より運用も複雑になります。
1. APサーバのメンテナンス
APサーバでは主に以下のメンテナンスを実施します。
1-1. IISの古いログの削除
IISのログは、Orchestratorがクライアントからリクエストを受ける度に数行ずつ増えていくので、放っておいたらログが肥大化し、ディスク容量を逼迫しかねません。
IISの基本機能にはログを削除する機能がないので、古いログは定期的に削除するようにバッチ処理を実装することを推奨します。
ログの保存場所（デフォルト）
C:¥inetpub¥logs¥LogFiles¥W3SVC2
1-2. 古いパッケージの削除
パブリッシュを何度も実行すると使われなくなった古いバージョンのパッケージが増えてきます。パッケージのファイルの実体は、デフォルトの設定でAPサーバに格納されるので、ディスクの空き容量確保のため、使用しないバージョン（ステータスが「非アクティブ」のものが対象）が溜まっていれば削除することを推奨します。
DB上のメタデータとのデータ整合性を確保するため、APサーバ上のファイルを直接削除すべきではありません。Orchestrator画面から手動（またはAPIを使用）で削除することを推奨します。
1-3. 古いストレージバケットの削除
パッケージと同様、ストレージバケットのファイルもAPサーバに格納されるため、使用していないファイルは削除することを推奨します。プロバイダーが「Orchestrator」のものが対象ですが、それ以外のものは連携先のサービスよります。AWS S3などはストレージの容量の制限がないためメンテナンスは不要ですが、使用料を抑えるために無駄なファイルは消した方が無難かと思います。
DB上のメタデータとのデータ整合性を確保するため、APサーバ上のファイルを直接削除すべきではありません。Orchestrator画面から手動（またはAPIを使用）で削除することを推奨します。
2. DBサーバのメンテナンス
DBサーバでは主に以下のメンテナンスを実施します。
2-1. メンテナンスプラン
DBのパフォーマンス維持のため、SQL Serverのメンテナンスプランを使用し、定期的にメンテナンスを実行します。
メンテナンス実行時はOrchestratorを停止させます。
| メンテナンス | 説明 |
|---|---|
| データベースの整合性の確認 | データベースの破損がないかどうかをチェックし、破損があった場合は修復します。 |
| データベースのバックアップ | データベースをバックアップします。 ※「バックアップ編」を参照 |
| アーカイブデータベースの作成 | データパージする前に別のデータベースをデータを退避します。 ※.csvファイルなどに書き出して退避する場合は不要 |
| 累積データのパージ | ロボット実行ログなど累積しやすいデータを削除します。 ※2-2を参照 |
| トランザクションログファイルのパージ | トランザクションログが肥大化し、ディスクを圧迫しないようにするため、定期的に削除します。 ※「バックアップ編」を参照 |
| 統計情報の更新 | パフォーマンス低下時、統計情報が実態と乖離するので最新化します。 ※インデックスの再構成時、自動的に統計情報は更新されるので、インデックス再構成をするのであれば、本件は実施不要 |
| インデックスのメンテナンス | 断片化したインデックスを解消します。インデックスが断片化するとクエリパフォーマンスが低下します。 |
2-2. 累積レコードのパージ
SQL ServerのようなRDB（リレーショナルデータベース）はレコード数が増大すると、クエリパフォーマンスが低下する恐れがあります。そのため、レコード数が多いテーブルに対し、データを定期的に削除することを推奨します。
監査目的でデータを長期保管する場合は、削除の前に別の場所（アーカイブDBや.csvファイルなど）に退避させてください。
主にメンテナンスの対象になるテーブルは以下です。
| テーブル | 説明 |
|---|---|
| Logs | ロボットの実行ログです。プロセスの実行ごとに開始、終了のレコード、また例外発生時にログが生成されます。ワークフロー中にLogMessageアクティビティを使用することで任意のログを出力することができます。ロボットの実行ログは件数が多く、OC画面上で削除する機能がないためDBから直接データを削除します。 |
| QueueItems | AddQueueアクティビティやOC画面上からのアップロードにてキューアイテムを追加できます。1度追加されたキューアイテムは論理削除しかできないため、DBにデータが一方的にたまり続ける仕様となっています。 |
上記の他に以下のテーブルも必要に応じてメンテナンスします。
RobotLicenseLogs、TenantNotifications、UserNotifications、Jobs、AuditLogs、AuditLogEntities、Actions、Sessions、Ledger、LedgerDeliveries
おわりに
いかがでしょうか。
今回は「バックアップ編」、「監視編」、「メンテナンス編」の3つのテーマを説明しましたが、運用設計には他にも検討すべき項目があります（ID管理、障害時・メンテナンス時の運用フロー、バッチ管理など）。
やはり、オンプレシステムの運用は面倒なので、何も問題がないのであればCloud版を使っておく方が無難ですね。
参考
v2019.10を対象としたドキュメントとなりますが、v2022.4でも十分参考になります。
以下はv2022.4に対応しています。