コントロールルームの反応が遅くなった原因
Blue Prism公式ブログをご覧いただき、誠にありがとうございます。プロフェッショナルサービスのAkiです。
Blue Prismのコントロールルームやスタジオの反応が遅くなってきた、と何年間もBlue Prismをご利用いただいているお客様から聞きました。
実は、そうだとは言え、本当の問題はコントロールルームやスタジオではなく、接続又はデータベースにあることが多いです。
本稿では、コントロールルームやスタジオの反応が遅くなった主な３つの原因をご紹介します。
１. 接続モードはWCF（Windows Communication Foundation）を利用すること
Blue Prismのスタジオ、コントロールルームの画面を立ち上げる際に、ログイン画面で、接続先を選択しますが、その接続の構成設定はどうなっているでしょうか。下記のデータベース接続の構成の中で、選ばれている「接続モード」を確認してみて下さい。
WCF (Windows Communication Foundation) はセキュリティが優れていますが、パフォーマンスが優れているのが.Net Remotingです。 .Net Remotingはより多くの負荷を処理できるため、エラーや速度低下を気づいた場合、.Net Remotingに乗り換えることが考えられます。
Blue Prismは、バージョン6.0の初期のドキュメントにも書いてあったように、特定の接続方法を推奨しなくなりました。 組織のセキュリティ ポリシーを理解し、パフォーマンスを犠牲し、WCFを利用する必要があるかどうかを判断する必要があります。
.Net Remotingは著しく良いパフォーマンスを提供し、ロードバランサ―エラーのリスクも低減します。信頼できる環境の中で、優れるセキュリティーの接続方法が必要なければ、.Net Remotingをご利用いただけます。
（参考：Should I use .Net Remoting or WCF? : (blueprism.com)）
ただし、マイクロソフトの公式ページによると.Net Remotingはレガシーテクノロジーと特定されており、将来サポートされなくなる可能性もあるため、必要な時、速やかにWCFに移行できるように準備することを推奨します。
2. プロセスやオブジェクトに無限ループが存在していること
Blue Prism Enterpriseを立ち上げた直後、コントロールルームにアクセスすると、アプリケーションが凍結し、ロードできるまで何分もかかる現象が現れる場合、処理中のセッションに無限ループが存在していることも考えられます。そのセッションを見つけて、無限ループを解決する必要があります。
また、無限ループを防ぐため、構築ベストプラクティスを徹底的に遵守し、構築レビューをきちんと行うことを推奨します。
3. データベースメンテナンスが良くできていないこと
データベースの空きが大きくても、下記のテーブルが大きい時、パフォーマンス低下が発生します。
・ BPASessionLog_Unicode及びBPASessionLog_NonUnicode:
この2つのテーブルが一番速くデータが溜まっていくため、定期的にアーカイブを行う必要があります。アーカイブ頻度はプロセスの実行状況及びデータベースの容量によります。どんなアーカイブ頻度で良いのかはBlue Prism プロフェッショナルサービスチームにご相談いただけます。
定期的にアーカイブを行ってもこの２つのテーブルが大きい場合、各プロセス、オブジェクトのログレベルをレビューする必要があります。
プロセス及びオブジェクトの各ステージのログレベルは下記の通りに設定できます：
・ BPAAuditEvents:
このテーブルの中で一番大きい容量を占めるのはプロセス・オブジェクトのバージョンコントロールデータです。それ以外のデータはあまり容量を占めることはなく、増量も速くないため、このテーブルのメンテナンスは主にはプロセス・オブジェクトのバージョンコントロールデータをアーカイブすることです。
全てのプロセス・オブジェクトのバージョンコントロールデータをアーカイブすると、バージョン比較ができなくなるため、普段は直近の2-3バージョンを残し、より古いバージョンをアーカイブすることを推奨します。
プロセス履歴クリーンアップの詳細手順については、Blue Prism プロフェッショナルサービスにご相談いただけます。
・ BPAProcess:
このテーブルの中には、実はプロセスだけでなく、オブジェクトも含まれています。インフラストラクチャーの構成やスペックにもよりますが、アクティブなプロセス及びオブジェクトの総数が1000を超えると、パフォーマンス低下を経験するお客様が多いです。
そのため、プロセス及びオブジェクトをレビューし、必要ないプロセス及びオブジェクトは必ず削除することを推奨します。
また、この問題を根本的に解決するため、運用ではなく、開発規則からプロセス及びオブジェクトの作成単位を定義し、再利用できるコンポネントを徹底的に作り、管理することを推奨します。
既存の開発規則のレビューやBlue Prism設計・開発ベストプラクティスについてご相談がございましたら、Blue Prismプロフェッショナルサービスにお問い合わせください。
・ BPATag:
このテーブルに登録されるのはワークキューアイテムに一度でも付けられたタグです。このテーブルのサイズも小さく、具体的には、件数を2000アイテム以下にキープすることを推奨します。そのため、ユニークタグになるようなタグの付け方は推奨しません。
ユニークタグとはワークキューの個別のアイテムごとに発生するタグのものです。例えば、チケット番号、処理日時等、各ワークキューのケースアイテムにユニークな値になるタグが挙げられます。手動、又はWork Queue VBOでワークキューアイテムが削除されても、そのアイテムに付けられたタグは自動的にこのテーブルから削除されません。そのため、手動、又はWork Queue VBOでワークキューアイテムを削除する可能性がある場合、定期的に、もう使用されないタグ（どんなワークキューアイテムにも紐づかないタグ）がないかを確認し、削除することを推奨します。
そもそも、タグとは、ワークキューのケースアイテムを分類分けする為に使うもので、大量に発生するものではありません。
このテーブルが逼迫するようなことがあるのであれば、開発者はタグの使い方をきちんと理解し、再定義するなど、見直しをする必要があるかもしれません。
・ BPAResource:
環境内のランタイム リソース(RR) やインタラクティブクライアント（IC）が多いほど、データベースで実行されるポーリング（サーバからRRやICへ死活監視を行う問い合わせ）量と、RR から他の RR への TCP 接続が多くなります。その結果、コントロールルームの反応が重たくなったり、スケジュール実行ができないエラーが発生したりします。
Blue Prism バージョン6の場合、アプリケーションサーバー（APサーバー）が1台に対して、データベースで登録されるランタイムリソース数は100台以下とすることが推奨されています。（但し、使い方によっては、もっと数を少なくする必要があります。
例えば、コントロールルームやスタジオを使うインタラクティブクライアントなどは特に負荷が高くなりますので、100より少なくても、パフォーマンスが劣化する可能性は高いです。）そのため、もう使用されないランタイムリソースは必ずリタイヤする必要があります。
ランタイムリソースのリタイヤする方法は下記の通りになります：
以上はコントロールルーム及びスタジオの反応が遅いと感じる際に最初にご確認いただきたい原因です。
コントロールルーム及びスタジオのパフォーマンス低下を防ぐために、定期的にデータベースのメンテナンスを行うだけでなく、常に構築ベストプラクティスを遵守し、徹底的に設計・構築レビューを行うことにより、無限ループや不適切なプロセス・オブジェクトの作成を避け、再利用性の高いコンポネントを作成する必要があります。
構築・運用ベストプラクティスにご興味がございましたら、是非Blue Prismの担当営業までプロフェッショナルサービスについてお問い合わせくださいませ。
皆様と直接セッションができる機会を心よりお待ちしております。