アプリケーションのパフォーマンスの問題

アプリケーションの設計が不十分だと、再利用性が低く、整備が困難で、診断や解決が難しいという、パフォーマンスのネックとなる要素を含むアプリケーションになってしまいます。 アプリケーション設計のベストプラクティスであるガードレールを適用すると、このような問題が発生するリスクを軽減することができます。

Pega Platformは、アプリケーションで作成したルールが、所定のガードレールに準拠しているかどうかをモニターします。 ルールがガードレールに違反した場合、Pega Platformは当該ルールに警告を適用します。 この警告は、生じる可能性のあるエラーの重大度と種類を示し、多くの場合、違反の対処方法が記載されています。 各警告はルールの設定に関する特定の問題を示し、各ルールが複数の警告を表示することもあります。 Pega Platformは、ルールを保存する際に、ガードレールの検査を行います。

例えば、レポート用に最適化されていないプロパティがケースデータBLOBに埋め込まれていると、レポート実行時のパフォーマンスが低下します。 このベストプラクティスに違反したレポートディフィニッションを保存しようとすると、パフォーマンスに影響を与える可能性があることを警告するガードレール警告メッセージが表示されます。

ガードレールの警告を確認し、ガードレールに違反しているアプリケーションの設計要素を特定し、ガードレールの違反に対してどのように対処するのが最善か、十分な情報を得た上で決定します。 アプリケーションのガードレール警告の全体的な質と重大度を迅速に評価できるように、Pega Platformではコンプライアンススコアを提供しています。 ガードレールスコアおよび警告はアプリケーションごとに適用され、Pega Platformのコアルールは含まれません。 コンプライアンススコアは、重度または中程度のガードレール警告があるルールの数を測定し、警告なしまたは注意レベルのガードレール警告があるルールの数と比較します。 Dev StudioのApplication Guardrailsランディングページは、アプリケーションのコンプライアンススコアを生成して表示します。

Pega Platformの最新リリースでは、新しいガードレールの検証や警告が追加されるため、アプリケーションのアップデート後はガードレールの再評価やルールの再検証を行ってください。 顧客のアプリケーションが最新リリースにアップデートされた場合、新しいガードレールのベストプラクティスは、すでにアプリケーション内に存在するルールには自動的に適用されません。 新しいガードレール警告を適用するには、それ以前のリリースのルールを再評価する必要があります。 Pega Platformにはルールセットごとにルールを再検証する機能があるため、新しい警告が古いルールに適用されます。 再検証プロセスの実行に関する詳細は、Pega Communityの記事「About the bulk Revalidate and Save tool」を参照してください。

次の問題に答えて、理解度をチェックしましょう。

システムパフォーマンスには様々な側面があります。 例えば、通常エンドユーザーは、システムのパフォーマンスはレスポンスタイム（リクエストからレスポンスまでの経過秒数）と同義であると考えています。 ビジネスレベルでは、システムのパフォーマンスを測る重要な指標として、1分、1時間、1日あたりに処理可能な完成作業ユニット数を示すスループットがあります。 パフォーマンスには様々な側面があるため、目標と成功の尺度について合意することは、パフォーマンステスト分析の重要な最初のステップです。

Pega Platformは、ランタイムに「prconfig.xml」ファイルまたはDynamic System Settingsで設定したさまざまなパフォーマンスのしきい値に基づいてシステムアラートを生成します。 アラートは、特定のインタラクションやルールの実行がパフォーマンスのしきい値を超えたことを示すテキスト入力やメッセージです。 また、このメッセージは、リクエスターのタイプ（ブラウザーやバッチリクエスターなど）や、アラートの発生原因となったアクティビティやストリームを特定します。

次のテキストは、しきい値違反のアラートを示しています。

Pega Platformは、アプリケーション処理時にアラートをパフォーマンスアラートログに書き込みます。 Dev Studioでは、Configure > System > Operation > Logs をクリックしてAlertを選択することで、アラートログを表示することができます。 また、Pega Platformは、アラートをキャプチャー、分析、管理するためのモニタリングアプリケーション「Predictive Diagnostic Cloud（PDC）」を提供しています。 オンプレミス版のPDCはPega Autonomic Event Services（AES）とも呼ばれています。 これらのアプリケーションは、ヘルスチェックダッシュボード、強化された分析機能、データベーステーブル指標の推奨など、モニタリング機能を大幅に向上します。

次の問題に答えて、理解度をチェックしましょう。

アプリケーションのパフォーマンス問題における原因の特定は困難な場合があります。 アプリケーションでは、過剰な応答時間、長いリクエストの結果セット、無効なデータの返送、データベースデッドロック、オープン接続が多すぎるなど、さまざまなパフォーマンス問題が発生します。

例えば、エンドユーザーから報告された過剰な応答時間などのパフォーマンス問題は、アプリケーションのSQLクエリーの記述の不足、ネットワークの遅延、またはデータベースサーバーのパフォーマンスの問題が原因である可能性があります。

パフォーマンスアラートは、パフォーマンス問題の根本原因を特定するのにも役立ちます。 特定のアラートが頻繁に表示されるパターンや原因を特定するために、アラートの組み合わせを利用することができます。 例えば、過剰な応答時間の問題をトラブルシューティングするには、以下のアラートが原因を特定するのに役立ちます。

Pega Platformは現在、100種類以上のアラートを扱っています。 アラートの一覧とアラートを受ける理由については、Pega Communityの記事「List of performance and security alerts in Pega Platform」を参照してください。

一般的なアラートには次のようなものがあります。 

Pega Platformには100種類以上のパフォーマンスアラートが組み込まれており、専用のログファイルも用意されているため、パフォーマンスのしきい値を超えた各原子操作を特定することができます。 高度なパフォーマンス分析には、通常大量のデータを読み取り処理するための高い技術力が必要ですが、Pega Platformでは、アプリケーション向けに作成したルールがパフォーマンスに与える影響を理解するのに役立つ、使いやすいアラートと関連するログを提供しています。

開発環境では、一部のパフォーマンスアラートは通常一過性のもので、本番環境ではランタイムに発生しないタスクが原因となっています。 しかし、開発環境で作動するパフォーマンスアラートの多くは、最近実行されたルール、またはルールの組み合わせが、確立されたパフォーマンスのしきい値を超えたことを早期に警告します。 これらのパフォーマンスアラートは、無視したり設定変更によって実質的に無効化したりすることもできますが、パフォーマンス全体に影響を与えるルールに関する貴重な初期の手がかりとなります。

アプリケーションのパフォーマンスには様々な側面があるため、目標と成功の尺度について合意することは、パフォーマンス改善の取り組みにおける重要な最初のステップとなります。 負荷テストでは、本番環境で問題が発生する前に、パフォーマンス問題を特定することができます。 パフォーマンスのしきい値を変更することで、明確なメリットが得られる場合もあります。 例えば、PegaRULESデータベースから取得する行数を減らすことで、ネットワーク上で送信されるバイト数も減り、サーバーにデータを保存するために必要なメモリ量も減る可能性が高くなります。

その他の変更は、トレードオフを伴う場合があります。 例えば、ある種類のリソースの需要を減らす（または供給を増やす）と、別の種類のリソースの需要が増えます。 このような変化は、特定の指標ではパフォーマンスを向上させても、別の方法で評価するとパフォーマンスに悪影響を及ぼす可能性があります。 パフォーマンスの低下と有利条件を特定するには、調査が必要な場合もあります。 使用頻度の低いタスクを200％高速化することは素晴らしいことですが、重要で使用頻度の高いタスクを2％改善することに比べれば、そのタスクの全体的な影響は小さいかもしれません。

パフォーマンスアラートのしきい値にはデフォルト値があり、アプリケーションで明示的に設定されていない場合があります。 パフォーマンスのしきい値を調整するには、Dynamic System Settings（DSS）を使用するのが望ましいですが、praconfig.xmlファイルでシステム設定を変更することもできます。 アラートのしきい値はprconfig.xmlで維持することができますが、Pega Platformの現在のバージョンは強化されており、prconfig.xmlで以下のパラメーター名と値がに設定されている場合には、DSSインスタンスを使用してアラートのしきい値を維持することができます。

パフォーマンスのしきい値のDSSレコードを追加するには、次のように定義します。

• 短い説明–パフォーマンスのしきい値の目的や意図を説明する、短い説明的な文を使用します。 例えば、デフォルトのHTTPインタラクションのしきい値を定義するDSSレコードの短い説明は、HTTPインタラクション時間しきい値となります。
• 所有ルールセット–prconfig.xmlで初期化されたパフォーマンスのしきい値の設定に使用されるDSSレコードの所有ルールセットはPega-Engineのルールセットです。 Pega Platformでは、Pega-Engine以外の所有ルールセットでパフォーマンスのしきい値のDSSレコードを作成することはできません。
• 設定目的–DSSレコードでは、パフォーマンス関連のしきい値設定項目は、proconfig/[performance-related threshold setting name]/defaultの形式で記述されます。 例えば、HTTPブラウザーのインタラクション時間しきい値を調整するDSSレコードを作成するには、設定目的として「prconfig/alerts/broswer/interactionTimeThreshold/warnMS」と入力します。
• ノード分類–どのノードに設定を適用するかを指定します。 すべてのノードに設定を適用するには、/defaultを指定します。 アラートのしきい値設定は、通常すべてのノードに適用されます。 ノードの分類に関する詳細は、「Learning about default dynamic system settings」を参照してください。
• 値–しきい値を指定します。 各アラートのしきい値の単位は、Pega Communityの記事「List of performance and security alerts in Pega Platform」に記載されています。 下図では、値はミリ秒で表示されています。