![Rule Assembly process flow](https://demo5-academy.pega.com/sites/default/files/styles/1024/public/media/images/2020-11/RuleAssemblyProcess.png?itok=ZTgXMN5C)
ルールアッセンブリーおよび実行パフォーマンス
ルールアッセンブリープロセスでは、アプリケーションの実行に使用するルールのキャッシュを作成します。 Pega Platform™が効率的に作動するには、ルールのキャッシングが不可欠です。 しかし、状況によっては、ルールのアッセンブリーに時間がかかり、パフォーマンスが低下することがあります。 Pega Platformは、ルールアッセンブリーの問題を検出するツールを提供しており、パフォーマンス上の問題を修正または軽減するための適切なアクションを取ることができます。
ルールアッセンブリーおよび実行によるパフォーマンスへの影響
ユーザーは、レポートの作成や画面の計算値の更新などの特定のタスクを実行しているときだけでなく、アプリケーションでの作業中にも、全体的なレスポンスの遅さを感じることがあります。 事例証拠に加えて、パフォーマンス問題を特定するためのパフォーマンス分析ツールやシステムアラートが利用できます。 ルールアッセンブリーまたはルールキャッシング問題が、一般的なパフォーマンス問題の原因となることがあります。
ルールアッセンブリー
ある環境に新しいアプリケーションが導入されると、システムを利用するユーザーは、最初のうちはアプリケーションのパフォーマンスの低下に気付く場合があります。 アプリケーションが起動すると、コアとなるPega Platformがルールとアプリケーションコードを統合し、ルールを取得してキャッシュします。 このアクションをルールアッセンブリーといいます。 ルールアッセンブリーとは、アプリケーションルールに対応したJavaコードを生成し、コンパイルするシステムプロセスです。 Pega Platformは、新しいJVMノードが起動したとき、新しいコードが配備されたとき、または更新されたルールがアプリケーション内で初めて実行されたときに、ルールのアッセンブリーを行います。 このアクションは、しばしばFirst Use Assembly(FUA)と呼ばれています。 ユーザーがルールの大部分を実行した後は、コードがキャッシュに保持されるため、システムパフォーマンスが最適化されます。
新しいルールや更新されたルール多数があると、パフォーマンスに大きな影響を与えます。 既存のルールが更新されると、キャッシュされていたバージョンに削除するよう印付けされ、ルールが再キャッシュされます。 例えば、新しいアプリケーションをQAシステムに移行した後、ルールアッセンブリー時間がパフォーマンスの統計値を膨張させることがあります。 これらの結果は、実際のアプリケーションのパフォーマンスを誤って解釈する原因となる可能性があります。
ルールキャッシング
アプリケーションが拡張されると、大量のルールセットやアクセスグループを追加することができます。 多数のアクセスグループやルールセットアッセンブリーによる過剰なルールキャッシングは、パフォーマンスを低下させる場合があります。
ルールキャッシュとは、最近使用されたルールをメモリ内に集めたものです。 Pega Platformはルールキャッシュを維持することで、不要なルールレゾリューションやデータベースインタラクションを避け、アプリケーションのパフォーマンスを向上させます。 アプリケーションがルールをリクエストすると、Pega Platformは当該ルールがキャッシュ内にある場合は実行します。 ルールがキャッシュに存在しない場合、Pega Platformはルールをキャッシュに追加します。
ルールセットリストと呼ばれるユニークなルールセットの組み合わせには、それぞれのキャッシュがあります。 アプリケーションに多数のルールセットがある場合、Pega Platformはシステムリソースを使用してルールセットリストをキャッシュします。 Pega Platformの実装では、様々なユーザー向けのルールを含む一つのルールベースを持ち、複数のアプリケーションのルールを含むことができます。 例えば、顧客担当者がクレームのインバウンドコールを処理するためにシステムにログインしたり、顧客がアプリケーションのセルフサービスのウェブサイトにログインしたりします。 各ユーザーに対して、固有のアクセスグループとルールセットリストがあります。 Pega Platformは、各アクセスグループをシステムメモリとCPUを使用する個別のキャッシュインスタンスとして管理します。
次の問題に答えて、理解度をチェックしましょう。
ルールアッセンブリーやキャッシングに関する問題の診断と対処
過剰なルールキャッシュや不要なルールセットがあると、システムのパフォーマンスが低下します。 ルールアッセンブリーやキャッシング問題の多くは、設計時の注意深い計画により防ぐことができます。 ルールセットリストのバリエーションを最小限に抑え、ルールをチェックアウトできるユーザーを限定することで、パフォーマンス上の問題を軽減することができます。
オペレーターがAllow rule check out を有効にすると、チェックアウトされたルールがある場所にパーソナルルールセットが作成されます。 この機能は、個別のキャッシュを生成する独自のルールセットリストを作成します。 非開発環境では、システム管理者のオペレーターのみがこのオプションを有効にすることが奨励されます。
補足: Allow rule check outオプションは、オペレーターIDレコードのSecurity タブで利用できます。
ルールアッセンブリーとキャッシュ問題を診断するには、ルールアッセンブリー(RA)の統計をご覧ください。 個人のRA統計を表示するには、My Performance Detailsツールを実行し、User ID is EqualフィールドにユーザーIDを入力します。 アプリケーションのRA統計を表示するには、Performance Analyzer (PAL) ツールを実行します。
補足: My Performance Detailsツールは、Dev StudioのConfigure > System > Performance > My Performance Detailsに移動して利用できます。 PALツールは、Dev Studioのに移動して利用できます。ツールとツールで表示されPAL Configure > System > Performance > PAL My Performance Detailsる統計は同じです。 違いは、My Performance Detailsツールでは個々のユーザーの統計を見ることができることです。
RA統計値が高い場合は、ルールアッセンブリーやキャッシングに問題があると考えられます。
Rule I/O ElapsedとRA Elapsed数値を検討してください。 Rule I/O Elapsedは、解決されたルールをデータベースから取得するのにかかった時間を示し、RA Elapsedは、ルールアッセンブリーとキャッシングにかかった時間を示します。 ルールI/Oやルールアッセンブリーの数値が高い場合は、システムが不必要にルールをアッセンブリーしていることを示しています。
補足: PALツールの詳細に関しては、Pega Communityの記事「Overview of the Performance Tools (PAL)」および「Interpreting the Performance Tool (PAL) Detail display」を参照してください。
次の問題に答えて、理解度をチェックしましょう。
過剰なルールアッセンブリーの原因
過剰なルールアッセンブリーの一般的な原因は、ユーザーが異なるルールセットリストを持っていることです。 アクセスグループがそれぞれ特有のルールセットリストを持ち、個人がルールをチェックアウトできる場合に、ルールセットリストの相違が発生します。 各ユーザーが、わずかに異なるルールセットリストを含む異なるアクセスグループを持っている場合、それぞれが独自にルールのアッセンブリーを行うため、パフォーマンスが低下します。 設計時には、オペレーターが共通のアクセスグループを使用するように注意してください。 アクセスグループは、可能な限り同じアプリケーションルールを使用しなければなりません。 アプリケーションで同じ機能を実行するユーザーは、全員がオペレーターIDレコードで同じアクセスグループを指定する必要があります。
注: プロダクションルールセットをアクセスグループに追加する際には注意が必要です。 プロダクションルールセットは、ルールセットリストに相反する順序で追加される可能性があり、その場合一意のルールセットリストの数が増えるため、ルールキャッシュも増えてしまいます。
また、ルールアッセンブリーは、ルールセットやアプリケーションが新しいシステムに移行またはインポートされた時にも発生します。 移行後のアッセンブリーの影響を軽減するために、Pega PlatformはStatic Assemblerを提供します。 このツールを使うと、ユーザーがリクエストする前に、アプリケーション内のすべてのルールをアッセンブルすることができます。
補足: Static Assemblerの実行に関する詳細については、Pega Communityの記事「Preassembling rules in the application」と「How to reduce rules assembly processing in the production system」を参照してください。
ルールアッセンブリーに関する問題が発生した場合、アラートが生成されます。 ルールアッセンブリーが正常に行われない場合、次のようなアラートが表示されます。 アラートログを確認することで、アッセンブリーに関する問題を特定することができます。
PEGA0032
-ルールの変更(更新、削除、作成)により、ルールアアッセンブリーキャッシュに多数の無効エントリーが生成される場合。PEGA0037
- ルールアッセンブリーにかかる時間のしきい値超過。PEGA0038
- ルールアッセンブリーキャッシュアクセスの待ち時間のしきい値超過。
過剰なルールアッセンブリーの管理
使用するルールセットリストの数を最小限に抑えることで、過剰なルールアッセンブリーを管理することができます。 始めに、Active Rule Set Listレポートを開いて、ルールセットリスト数の急激な増加をモニタリングします。 例えば、生産システムにあってはならないブランチルールセットを探します。
補足: Dev StudioでConfigure > System > Performance > Active Rule Set ListをクリックするとActive Rule Set Listレポートが表示されます。
以下の操作を行うことで、使用中のルールセットリストの数を最小限に抑えることができます。
- アプリケーションの移行前にルールセットブランチをマージする。 ブランチを使用して、開発中のルールを本番環境から分離する。 本番環境でブランチを使用しないようにすることで、ブランチルールセットのルールアッセンブリーへの影響を防ぎます。
- アクセスグループの数を最小限にし、アクセスグループをルールセットへのアクセスではなくパーミッションの管理に使用する。 複数のアクセスグループが、同じルールセットを異なる順番で参照することがあります。 ルールセットリストの不要な変更を避けるために、アプリケーションで同じタスクを実行するユーザーを同じアクセスグループにまとめてください。
- ルールを更新しないユーザーに対して、ルールのチェックアウトを無効にする。 ルールのチェックアウトを有効にすると、ユーザーのパーソナルルールセットが作成されます。 この設定により、当該ユーザーに固有のルールセットリストが提供されます。 ユーザーがルールを更新しない場合、不要なルールセットの変更を避けるために、ユーザーのオペレーターIDレコードのルールチェックアウトオプションを無効にしてください。
- 1つのルールセットを複数のアプリケーションレコードに追加することを避ける。 ルールセットのブロックが一貫した順序でスタックに追加されるように、可能な限りルールセットをアプリケーションにまとめます。 この操作には、アプリケーションをリファクタリングして組み込みアプリケーションを作成することも含まれます。
次の問題に答えて、理解度をチェックしましょう。
このトピックは、下記のモジュールにも含まれています。
If you are having problems with your training, please review the Pega Academy Support FAQs.