エンドツーエンドのシステム・パフォーマンス根本原因分析
このチュートリアルでは、複数のデータ・プロバイダーのデータを分析することによってルート原因分析を実行する方法について、一連の手順を示した具体的なシナリオを使って説明します。このチュートリアルでは、zMobile Health Care アプリケーションで見つかったパフォーマンス障害の根本原因分析を行います。
前提条件
Trish はテスト・リーダーであり、zMobile Health Care アプリケーションの Inquire Patient フィーチャーの応答時間をテストしています。テスト中に、Trish は、 前のビルドでは 1 秒未満だった Inquire Patient フィーチャーの応答時間が最新の開発ビルドでは 2 分にまで増えたことを発見しました。開発リーダーとして、Trish からその報告を受けました。 そこであなたは、ADI のダッシュボードおよびレポートを参照してこの問題を調査します。
- ブラウザーで IBM ADDI Extension ホーム・ページ https://healthcare.example.com:9753/addi/web/workbook にアクセスします。
- 以下の資格情報でログインします。ログインすると、「ワークブック」ページが表示されます。
- E メール・アドレス: adiadmin@healthcare.example.com
- パスワード: adiadmin
zMobile Health Care アプリケーションの全体的な状況を要約するダッシュボードが表示されます。Marco は、Trish から報告された問題にすぐに気付きました。 zMobile Health アプリケーションの平均応答時はほぼ 7 秒です。これは、会社の SLA を超えています。また、コード・カバレッジのパーセンテージが警告域にあることも分かります。
- zMobile Health Care の名前をクリックして、詳細分析を表示します。 「zMobile Health Care」ページに、構成要素であるプロバイダーの要約グラフが読み込まれます。
- zMobile Health Care ページのワークブック要約ビューでレポートを表示します。「コード・カバレッジ」、「静的分析」、「パフォーマンス」という 3 つのタブとしてレポートが編成されます。
どのレポートも、この Analysis ワークブックに関連付けられている 3 つのデータ・プロバイダーに基づいて分析されます。
- コード・カバレッジ結果を収集する手動ビルド・データ・プロバイダー。
- zMobile Health Care アプリケーション内のトランザクション、プログラム、およびプロジェクト・レベルのメトリックについての静的分析データを収集する Application Discovery データ・プロバイダー。
- zMobile Health Care アプリケーションの CICS トランザクションのパフォーマンスをモニターする OMEGAMON for CICS データ・プロバイダー。
1 つのワークブックの複数プロバイダーからのレポートによって、異なるソースからの異なるデータを相関させることができます。 - 「静的分析」タブと「パフォーマンス」タブを選択して、静的分析レポートとパフォーマンス・レポートにそれぞれナビゲートします。
「パフォーマンス」タブでは、zMobile プロジェクト内のプログラムとトランザクションの詳細な分析結果を確認できます。HTRANS のパフォーマンス・レポートも表示されます。
HTRANS は、 OMEGAMON for CICS データ・プロバイダーのサービス・クラスです。サービス・クラスとは、関連するトランザクションのグループ化を可能にするために OMEGAMON for CICS が使用する概念です。サービス・クラスが定義されていない場合、OMEGAMON for CICS はデフォルトのサービス・クラスを定義します。
「Demo OMEGAMON provider: HTRANS」セクションで、Trish が報告したパフォーマンスの問題を調査できます。 平均応答時間がレッド・ゾーンにあるだけでなく、「パフォーマンスおよび信頼性に関する問題があるトランザクション」表で、*Inquire Patient* フィーチャーによって実行される HCP1 トランザクションに、目標応答時間しきい値を 400% を超える割合で上回っているというフラグが付いていることに気付きます。HCP1 では、 平均実行カウントも他のトランザクションよりもかなり大きい値になっています。そこで、アプリケーションが遅くなった原因はこのトランザクションだろうと考えます。注: 目標応答時間しきい値は、OMEGAMON for CICS での設定値であり、 企業が必要とする標準 SLA を応答時間が超えることの重大度を示すものです。「パフォーマンスおよび信頼性に関する問題があるトランザクション」表にある各種の警告アイコンは、さまざまなレベルの重大度を表しています。例えば、透明の赤い警告アイコンは、応答時間がしきい値を上回っている比率が 400% であることを示し、不透明の赤色の警告アイコンは、応答時間がしきい値を上回っている比率が 400% を超えていることを示しています。 - トランザクション詳細分析を表示するために、「パフォーマンスおよび信頼性に関する問題があるトランザクション」表で HCP1 トランザクションをクリックします。そうすると、平均応答時間、それと比較される応答時間内の DB2 およびファイル入出力の平均待ち時間、平均 CPU 時間、および実行カウントのヒストリーが表示されます。
レポートのヘッダーには、このビューに表示されている一定の時間フレームにおける、実行カウント、CPU 時間、および応答時間の最大数が示されます。
この図表から、平均応答時間が 2 秒から 26 秒に増えて、過去 3 日間、常にリスクが高い状態であることに気付きます。 同じパターンが DB2 待ち時間にも見られます。DB2 待ち時間は、約 20 - 30% であったものが 70% を超えるまでに増加しました。 これは、「応答時間内の DB2 およびファイル入出力の平均待ち時間」で赤い線で示されている推奨レベル 50% を超えています。
実行カウントが常に 200 に近いことに気付きます。 これは、このトランザクションが頻繁に実行されたことを意味します。あなたは、このトランザクション内のプログラムに 3 日前に変更が加えられたのではないかと考えます。
- この図表で、応答時間がしきい値を超えていて、平均 DB2 時間が高いエリアにカーソルを移動します。応答時間値および DB2 待ち時間のパーセント値が表示されます。
- さらに詳しく分析するために「OK」をクリックします。
- 右上にある「成果物構成」ボタンをクリックして、「成果物構成」ビューに移動します。 成果物構成分析は、 Application Discovery から収集される、プログラムおよびトランザクションに関する主要メトリックの分析です。このビューに表示される成果物構成グラフは、1 つのトランザクションで呼び出すすべての成果物 (トランザクション、プログラム、およびデータベース表) を接続したグラフです。矢印の方向は、呼び出しの方向を表しています。
- ヘッダー・エリアの右上にある「警告」 アイコン () を選択してリスク・エリアを表示します。
成果物の上部に警告アイコンが付いていることに注意してください。青い警告アイコンは、
成果物に対して何らかの変更があった可能性があることを示します。この場合、前のチュートリアルで分析コレクションをセットアップしたときに設定したインターバル時間中に、成果物メトリックが変更されたことがその理由です。この場合は、2020 年 10 月 13 日から 10 月 28 日までの間の 7 日間です。ADDI Extension では、成果物が変更されたことは、以下のいずれかの方法で確認できます。
- IBM Application Discovery からの LASTUPDATED メトリック収集があるかどうかを確認する。
- 定義した変更インターバル時間の間に、保守容易性指標とソース・コードの行数が更新されているかどうかを確認する。
赤い警告アイコンは、 成果物の変更が危険であることを示します。この図表に重ねて表示される「リスク・エリア」ダイアログ・ボックスに、 青いアイコンと赤いアイコンの意味と、主要メトリックのしきい値設定が表示されます。
- 成果物の上部に警告アイコンが付いていることに注意してください。青い警告アイコンは、
成果物に対して何らかの変更があった可能性があることを示します。この場合、前のチュートリアルで分析コレクションをセットアップしたときに設定したインターバル時間中に、成果物メトリックが変更されたことがその理由です。この場合は、2018 年 2 月 28 日から 3 月 7 日までの間の 7 日間です。ADI では、成果物が変更されたことは、以下のいずれかの方法で確認できます。
- IBM Application Discovery からの LASTUPDATED メトリック収集があるかどうかを確認する。
- 定義した変更インターバル時間の間に、保守容易性指標とソース・コードの行数が更新されているかどうかを確認する。
赤い警告アイコンは、 成果物の変更が危険であることを示します。この図表に重ねて表示される「リスク・エリア」ダイアログ・ボックスに、 青いアイコンと赤いアイコンの意味と、主要メトリックのしきい値設定が表示されます。
- 「リスク・エリア」ダイアログ・ボックスの右上にある X をクリックしてこのダイアログ・ボックスを閉じます。「リスク・エリア」ダイアログと警告アイコンが表示されなくなります。
- 「フィルター」ドロップダウンをクリックして、「DB2」を選択します。 「成果物構成」グラフが更新され、DB2 に接続された成果物のみが表示されます。
- トップ・メニューにある「リスク・エリア」アイコン () をクリックします。成果物構成グラフ上の警告アイコンとともに「リスク・エリア」ダイアログが表示されます。
HCIPDB01 の青い警告アイコンが表示されます。 これは、過去 1 週間に HCIPDB01 に何らかの変更が加えられた可能性があることを意味しています。
- 「リスク・エリア」ダイアログを閉じ、HCIPDB01 ボックスをクリックします。この成果物について Application
Discovery から収集された主要メトリックが表示されます。保守容易性指標が赤いエリアにあることが分かりますが、これは現時点での懸案事項ではありません。
コード・カバレッジが 82% であることが分かります。 HCIPDB01 のテスト・コード・カバレッジ・メトリック上の疑問符 (?) にカーソルを移動すると、最後のテスト・コード・カバレッジ・データの日付が、今日より 1 週間前であり、プログラムの最終変更日付より前であることが分かります。つまり、このプログラムが適切にテストされていないことを意味しています。
- 「メトリック」ヘッダーの横にある「トレンドの表示 (View Trends)」リンクをクリックします。
HCIPDB01.cbl
の「トレンド」ページが表示されます。 - 「日次 (Daily)」をクリックして、「週次 (Weekly)」 ビューから 「日次 (Daily)」ビューにビューを変更します。「トレンド」ページで保守容易性指標とソース・コード行数のトレンド行を確認します。ソース・コード行数が 4 日ほど前に増えています。
- 「保守容易性指標」ドロップダウン・リストを選択し、「ステートメント総数」を選択します。両方のメトリックが同じトレンドになっています。約 40 個のステートメントが
HCIPDB01.cbl
に追加されています。これで、開発リーダーとして、HCIPDB01 に問題があるに違いないという結論に達します。 開発者の Jane と話し合います。2 人でコードを詳しく調べて、過度な待ち時間の原因となっている余分な SQL Join ステートメントを見つけます。修正を行う前に、Jane とともに ADDI Extension に戻って検討します。
- 階層リンクで、「成果物構成」リンクを選択し、「成果物構成」テーブルに戻ります。
- 上部ヘッダーの「テーブル」 ()
アイコンをクリックして、ビューを「テーブル」ビューに更新します。
成果物構成表は、トランザクション内のすべてのプログラム成果物のリストを示します。この表は、変更のハイリスク分析に基づいてソートされます。変更リスクのランクは、以下の基準の組み合わせに基づいて計算されます。
- 成果物がリスク・エリアにあるかどうか: リスク・エリアは、しきい値の設定に基づきます。
- 成果物が外れ値であるかどうか: 外れ値の成果物は、分布の中心に対する各成果物のマハラノビス距離を利用した外れ値検出アルゴリズムに基づいて分析されます。 マハラノビス距離が大きい成果物は、多数派の値と非常に離れているため、外れ値または異常であることを意味します。
- メトリック値のソート: リスク・エリアと外れ値の状況が同じ場合、成果物は保守容易性指標、到達不能コード、および循環的複雑度の値によって最終的にソートされます。
- 成果物構成表で、
HCIPDB01 は中程度の変更リスクであることに、Jane とともに気付きます。別のプログラム HCAZERRS は高リスクです。したがって、さらに変更を加えても zMobile Health Care Application にはあまり影響がないと考えられます。
「リスク・エリア」アイコン () をクリックして、しきい値設定を更新し、その変更による影響を確認することができます。例えば、 保守容易性指標しきい値の低いほうのスライダーを 40% まで移動させます。そうすると、 保守容易性指標が 40% を超えているプログラムの警告アイコンが赤い警告アイコンから透明の黄色い警告アイコンに変わることを確認できます。
- 右上のメニューにある「グラフ・ビュー」アイコン () をクリックして、「成果物構成」グラフ・ビューに戻ります。
- 「成果物構成」グラフ・ビューの「HCIPDB01」ボックスをクリックすると、HCP1BA01 に関連した成果物の関係のみが表示されます。
- 「閉じる (X)」アイコンをクリックして、情報ダイアログ・ボックスを閉じ、「成果物構成」グラフの完全なビューを表示します。
HCIPDB01 に、変更リスクの高い HCAZERRS との従属関係があることに、あなたと Jane は気付きます。これら 2 つのプログラムには非常に大きな影響力があります。Jane は、SQL の問題の修正後に、HCIPDB01 を変更したことで HCAZERRS にリグレッションが生じることのないよう、両方のモジュールを十分にテストする必要があります。
- 上部にある「ヒート・マップ (Heat Map)」ドロップダウン・リストをクリックし、「保守容易性指標」を選択します。 表示されるグラフ内のノードには、色が付いています。色は、選択したメトリックのしきい値の状況を示しています。例えば、HCIPDB01 と HCAZERRS は、両方とも保守容易性指標が許容不可な値であることを示す赤色で表示されています。 コードを変更するときには、細心の注意を払う必要があります。
- 「閉じる (X)」アイコンをクリックして、HCIPDB01 情報ダイアログ・ボックスを閉じ、グラフの完全なビューを表示します。
- 「ヒート・マップ (Heat Map)」ドロップダウン・リストを再度クリックし、「コード・カバレッジ - Health Care 手動ビルド (Code Coverage – Health Care Manual Builds)」を選択します。
- 「閉じる (X)」アイコンをクリックして、HCIPDB01 情報ダイアログ・ボックスを閉じ、グラフの完全なビューを表示します。
色が付いたノードとともにグラフが更新されます。ノードの色は、グラフ内の各ノードのコード・カバレッジ状況を示しています。 色が付いていないノードは、ノードにメトリック・データが関連付けられていないことを示しています。
HCAZERRS のコード・カバレッジ状況が不良 (黄色) の領域にあり、HCP1BI01 のコード・カバレッジ状況が不十分 (赤) の領域にあります。これらは両方とも HCIPDB01 と依存関係にあります。つまり、変更を加えたら、必ず開発チームが両方のプログラムを十分にテストする必要があるということです。
次は Jane が Marco との話し合いのとおりに修正を行います。修正後の次のビルドで、Trish は、Inquire Patient フィーチャーの問題が解決され、応答時間が 2 秒に戻ったことを報告します。
ここまでで、パフォーマンス問題の根本原因分析を実行するために、OMEGAMON for CICS からのパフォーマンス・データと Application Discovery からの静的分析データを相関させる方法を説明しました。IBM ADDI Extension を使用すると、トランザクション内の成果物すべてを調べることなく、問題の原因となっている可能性のあるプログラムを特定できます。また、ADI は、Application Discovery データを使用して、変更するときに特に注意する必要のあるリスク・エリアについての勧告を出します。ユーザーは成果物の従属関係を調べて、将来のビルドにおいて確実にリグレッションが起きないようにすることができます。