2024年06月12日

JENNIFERを用いた
性能テストの標準化

各サーバのリアルタイムな使用状況の確認
エラーの内訳は？
遅かったアプリケーションのTOP10の状況は？
遅かったSQLのTOP10の状況は？
遅いトランザクションは？
遅いSQLは？
遅い業務（ビジネスグループ）は？
日付別エラーの内訳は？
昨日の１３時～１４時までの状況は（再現）？
コミュニケーションツール（開発側と運用側、アプリ側と基盤側）
障害検知
ロードバランスが正しく行われているかの確認
全トランザクションの分布状況の表示（応答時間分布グラフ）

はじめに

昨今、開発スケジュールの短縮が進み、システムの性能問題の発生リスクが高まっています。そのため、テストや品質管理に携わる技術者には、この問題に対処するための解決策が求められています。本資料を用いてJENNIFERをテスト工程で使用することは、パフォーマンス問題を早期に解決させ効率の良いテスト実施に有効な解決策になります。

Webアプリケーションの開発工程で、性能要件を確認するための負荷テストがあります。これはスケジュールの厳しいプロジェクトなどでは後回しにされることがありますが、負荷テストで起こることは当然本番環境でも起こり得るため、後で後悔しないためにも必須の工程です。
負荷テストによって、構築するシステムがどの程度の負荷に耐えられるかを測定して、システムの信頼性と耐用範囲を明確にします。Webアプリケーションの場合、同時にアクセスするユーザをどれだけ処理できるか、閾値を越えた場合のシステムの振る舞いを検証する試験です。システムに負荷を発生させるツールを使用し、高負荷をかけ、システムの振る舞いについて検証します。
特にシステムの本番直前、または運用時に発生するパフォーマンスや問題解決のため、負荷テストツールを利用して顧客のリクエストに近い負荷を発生させることにより、システムのボトルネックとアプリケーションの問題ポイントをJENNIFERで確認できます。

負荷テストの目的は、単に負荷をかけることではなく、アプリケーションのボトルネックを検出し、改善と対策を行なって性能を最適化することにあります。
この目的を達成するためには、負荷テストの実行中に、CPUの使用状況、メモリの稼働率、スレッド、スループットなどに関して、テスト対象のサーバの動作状況をモニタリングする必要があります。ここで重要なのは、サーバの主要な性能データのモニタリングだけでは十分ではないということです。もし、主要な性能データがモニタリングできたとしても、アプリケーションが想定どおりに機能していることは保証できません。しかし、Web アプリケーションは、多数の異なるコンポーネントで構成されており、これらの全てのシステム性能データをモニタリングすることは現実的ではありません。
負荷テストにおける最良の性能モニタリングとは、想定した応答時間内で実際のトランザクションが処理内容に誤りがなく実行されているという、ユーザ視点の性能劣化を検知するためのモニタリングです。さらに加えて、検知された性能問題の根本的な原因を追究するためのシステム側の性能分析機能も必要です。

JENNIFERと負荷テストツールを併用することで、チューニング作業を効率的に行なうことが可能です。　特にJENNIFER統合ダッシュボードはシステムの担当者別の観点で性能データをAPサーバ中心に関連を確認するため、共通のビュー(view)によってチューニングできます。

1. 各サーバのリアルタイムな使用状況の確認

JENNIFERを利用することにより、チューニング作業を効率的に行なうことが可能です。
特にJENNIFERダッシュボードは、各システム担当者別に各々の観点で、性能データをAPサーバ中心に連関関係を確認できます。そのため、共通のビュー(view)を通じてリアルタイムシステム状況を確認、チューニングを行なうことが可能となります。
各サーバのトランザクション状況、システムのリソース状況（アクティブサービスリスト、アクティブDB、平均応答時間、SQL、ユーザ、スループット、CPU、メモリ、システムメモリ、ヒープメモリなど）を確認することが可能です。

システムアドミンダッシュボード

システムアドミンダッシュボードは、リアルタイムモニタリング用のチャートとユーザが統計的観点から図を比較できるチャートで構成されます。これらのチャートを使用して、サービスのスループットおよび障害状態をモニタリングし、システムを安定的に運用できます。

メモリ

メモリ（リアルタイム）はシステムのメモリ関連の項目をリアルタイムにモニタリングします。
JAVA：JMXで収集できるデータの中からメモリ関連の項目をリアルタイムモニタリングする画面です。
.NET：プロセスメモリは.NETのBCLライブラリが提供する機能を利用して収集した値を、システムメモリはWin32 APIを利用して収集した値を表示します。
PHP：Linuxの/procディレクトリを照会してプロセスメモリ、システムメモリデータを収集します。

ユーザ

JENNIFERが収集したユーザ関連の様々なメトリクスを一目でモニタリングできる画面です。

X-View

イベント

システムリソース

CPUおよびメモリのリソース関連情報がリアルタイムに推移が一目でわかる、モニタリングする画面です。

DB（SQL）

RDBMSを使用するサービスのSQLに関連したメトリクスをリアルタイムでモニタリングする画面です。

DB（コネクション）

DBコネクション関連の性能データをモニタリングする画面です。

ビジネス関連

ビジネス観点の性能データをモニタリングする画面です。

2. エラーの内訳は？

例外（エラー）を効率的に確認することが可能です。サーバ毎の例外内容、例外の内訳、例外の詳細内容を、各システム担当者が共通のビュー(view)を通じて一つの画面で確認、チューニングを行なうことが可能です。

2-1　アプリケーション状況

2-2　イベント(分析)

2-3　イベント(リアルタイム)

3. 遅かったアプリケーションのTOP10の状況は？

アプリケーション状況を確認でき、チューニング作業を効率的に行なうことが可能です。アプリケーションの稼働状況、遅いトランザクションの確認、詳細内容（平均、最大応答時間など）の確認が可能です。また、各アプリケーションの詳細SQL内容（応答時間、平均応答時間、SQLなど）を確認することが可能です。

① 分析 → ② アプリケーション状況 → ③ 日付選択 → ④ アプリケーション

4. 遅かったSQLのTOP10の状況は？

SQL状況を確認でき、チューニング作業を効率的に行なうことが可能です。一つの画面で、SQLの稼働状況、遅いSQLの確認、詳細内容（平均、最大応答時間など）の確認が可能です。また、各アプリケーションの詳細SQL内容（応答時間、平均応答時間、SQLなど）を確認することが可能です。

① 分析 → ② アプリケーション状況 → ③ 日付選択 → ④ SQL → ⑤ SQLの内訳

5. 遅いトランザクションは？

リアルタイムトランザクション状況を確認でき、チューニング作業を効率的に行なうことが可能です。一つの画面で、リアルタイムトランザクションの稼働状況、遅いトランザクション、SQLの確認、詳細内容（平均、最大応答時間など）の確認が可能です。また、各アプリケーションの詳細SQL内容（応答時間、平均応答時間、SQLなど）を確認することが可能です。

6. 遅いSQLは？

リアルタイムトランザクション状況を確認でき、チューニング作業を効率的に行なうことが可能です。一つの画面で、リアルタイムトランザクションの稼働状況、遅いトランザクション、SQLの確認、詳細内容（平均、最大応答時間など）の確認ができます。また、各アプリケーションの詳細SQL内容（応答時間、平均応答時間、SQLなど）を確認することが可能です。

①X-View → ②ドラッグ→ ③SQL時間でソート→ ④トランザクションの内訳

7. 遅い業務（ビジネスグループ）は？

ビジネス観点の性能データをモニタリングする画面です。ビジネスグループの選択およびビジネス別イベント、アクティブサービスをモニタリングします。

8. 日付別エラーの内訳は？

任意の時間帯で実行されたアプリケーション、SQLおよび外部トランザクションをヒット数および訪問ユーザ数に基づき照会します。様々な種類の通知(Notification)を提供し、ユーザが簡単にイベントを認識できるようにしています。さらに、様々なユーザリクエストおよびシステム環境に応じて、適切なイベントルールの定義ができる方法を提供します。

9. 昨日の１３時～１４時までの状況は（再現）？

X-Viewにより、各トランザクション情報をレスポンス時間別に点グラフで表しながら、詳細な実行の内訳情報を提供します。過去のトランザクションデータを特定の期間のトランザクションデータを照会・分析することが可能です。

処理された全トランザクションの応答時間分布を確認することが可能です。

10. コミュニケーションツール（開発側と運用側、アプリ側と基盤側）

掲示板を利用すると、情報交換や会話・議論などを行うことができます。

11.障害検知

アプリケーション実行中、発生した障害要素を検出できる機能があります。これにより、運用中のシステムの問題要因を分析、問題発生の原因を提供し、運用者/開発者が簡単に障害要因を認識しながら修正できるようにします。特定の日付または該当日付の時間を選択すると、発生したエラーの種類と件数を、テーブルタイプで確認できます。
条件的な性能障害を解決するためには、多様な性能データを時間の経過により長い時間、継続的にモニタリングする必要があります。