ヒットマップトランザクションの検索
本ドキュメントでは、WhaTapモニタリングサービスのヒットマップトランザクションメニューを使用して、Webアプリケーションサーバ(Web Application Server)の問題を特定し、トラブルに対応する方法を紹介します。
アプリケーションモニタリングマネージャーは、業務内容に応じて、さまざまな要因をモニタリングしたいと考えています。サーバー担当者はCPU、メモリ、ディスク、ネットワークなどのリソースをモニタリングし、リソースをどの程度使用しているかを確認する必要があります。DB担当者は 、DBクエリのパフォーマンスを向上させるための指標を表示する必要があります。
一方、従来のモニタリング方法では、サービス(AP) 担当者は通常、(Heap)ヒープ使用量とCPU使用率を確認するだけです。しかし、この方法では、サービス(AP)の問題を特定することができません。サービス(AP)で最も重要なことは、ユーザーのリクエストに適切に応答するかどうか、どれだけ迅速に、エラーなく応答するかです。これらを把握するためには、ユーザーのリクエストが正しく満たされていることを確認するプロセスが必要です。ユーザーのリクエストの1つ1つをリクエストと呼び、このリクエストをサーバーで処理と応答するプロセスをトランザクション(Transaction)として定義されます。
WhaTapモニタリングサービスでは、トランザクションを「進行中のトランザクション」と「終了したトランザクション」に区分し、サービス(AP)のトラブル状況を把握することができます。アプリケーションダッシュボードメニューのヒットマップウィジェットでは、「終了した個々のトランザクション」を分布図形式のチャートで確認することができます。ヒットマップチャートは、5秒単位で終了したトランザクション情報を収集し、ポイント単位で表現するウィジェットです。このチャートから想定通りに1秒かかるトランザクションが想定とは異なり、2秒ほどかかる場合、つまり応答時間が2倍以上かかるトランザクションを見つけることで、トラブルの原因を分析できます。
パターン分析
分布図チャートの形状によってどのようなトラブルが発生したのかを確認する方法について説明します。
ヒットマップトランザクションは、時間の経過とともにユーザーのリクエストに対応する応答時間を分布図の形式で表現するチャートです。アプリケーションダッシュボードでヒットマップウィジェットの右上の
を選択すると、分析 > ヒットマップメニューで確認することができます。
横軸はトランザクションの終了時間、縦軸は応答時間です。トランザクションを終了した時間ごとにユーザのリクエスト(Request)に対する応答(Response) 時間をチャート上に四角形で表現します。これにより、ユーザーのリクエストに正常に応答したかどうかを把握できます。ヒットマップトランザクションチャートの四角いボックスの色は、次のような意味を持っています。
- 青色： 正常トランザクション
- オレンジ、赤色：エラーが発生したのか、応答リクエストが拒否されたのか、エラー頻度に応じて赤に近い色で表現されます。
このチャートで最も重要な点は、トランザクションボックスが縦または横に並んでいる状況です。次のヒットマップパターンを参照してください。
縦線が一時的に現れるパターンです。縦線が発生する場合は、トランザクションの応答時間は異なりますが、終了時間は同じであることを意味します。トランザクション処理中に一時的にロック(Lock)が発生すると、トランザクションの処理を待機します。(Lock)ロックが解除されると待機中のトランザクションは同じ時間に終了します。これにより、縦線が作成されます。
横線が現れるパターンです。10秒のタイムアウト条件でそのリソースが不足すると、多くのトランザクションは10秒待機後にタイムアウトエラーが発生します。この時、ヒットマップの10秒後に横線が発生します。タイムアウト後に再試行するロジックがある場合は、上図のように横線が10秒単位で繰り返します。
波のように見えるフライングパターンは、特定のリソースやログなどの共通リソースが不足しているために間隔を置いて表示されるパターンです。
過負 荷パターンは、全体または一部の応答に一時的に問題を引き落とすトランザクションが一度に密集するときに発生するパターンです。
暴走パターンは、大量のトランザクションのリクエストや負荷が発生した場合、応答時間が全体的に増加するパターンです。
パターンが発生した場合に、パターンの原因となっている要因がサーバーの内部にあるか外部あるかを特定することが重要です。次の図のような構造でシステムを設計したと仮定します。
チャート下の領域は、ほとんど応答時間が速いトランザクションであるため、パターンを探すことはそれほど意味がありません。上の領域の遅い区間で作成されたパターンの共通点を探すことが必要です。縦線パターンが発生した時、サービス(AP)でロック(Lock)が発生した場合、1つのウェブアプリケーションのみパターンが発生します。逆に、外部に接続されたDatabaseで(Lock)ロックが発生すると、すべてのウェブアプリケーションでパターンが発生します。
チャート領域をドラッグすると、ドラッグした領域のトランザクション情報を画面下のTXトレース一覧に読み込むことができます。右側のアプリケーションウィジェットは、エージェントをグループ化して一覧として表示します。
トラブルの原因に関する共通点を見つけることが目的です。まず、同じアプリケーションで問題が発生したかどうかを確認してください。次に、同じURLで問題が発生したかどうかを確認してください。また、クライアントIPが同じかどうかを確認することもできます。
区間およびスタック分析
トラブルの原因が外部ではなく内部の問題であるかをどのように判断できるでしょうか？WhaTapは、アクティブスタックという技術を使用して、実行中のトランザクションのスタック情報を収集します。スタック情報は10秒ごとに収集され、収集されたデータは統計情報として確認できます。 また、サービスのロジックを実行する各メソッド、SQL、外部呼び出し情報も含まれます。
内部的な問題の場合、各トランザクションの実行履歴を時間ごとに確認し、速度が遅くなった区間を特定することで、問題を見つけて解決することができます。外部の問題の場合は、SQLと外部呼び出し情報を確認できます。
例えば、縦線パターンでロック(Lock)が発生する原因を調べる場合は、同じパターン内で最も遅いトランザクションと最も速いトランザクションを確認する方法があります。ヒットマップトランザクションチャートでパターンが発生した領域をドラッグしてください。TXトレース一覧にドラッグした領域のトランザクション情報を読み込みます。TXトレース一覧を経過時間を基準で並べ替えて、最も時間がかかったトランザクションを選択します。選択したトランザクションに関する詳細情報が含まれたトランザクション情報ウィンドウが表示されます。
テーブルビュータブでは、段階別時間と経過時間を確認することができます。時間は各段階が開始または終了した時間で、経過は各メソッドの開始から終了までの合計所要時間です。時間差は、その前に実行したメソッド間の間隔です。
テーブルビュータブを使用して、遅くなった区間を見つけることができます。同様に、最も速かったトランザクションで遅くなった区間を確認してください。共通点を見つけることができます。速度低下の原因がサービス(AP)のロジックによって発生した状況の場合は、アクティブスタックを確認してください。アクティブスタックボタンをクリックすると、詳細情報が含まれたウィンドウが表示されます。ツリービュータブでは、アクティブスタックと以前に実行されたメソッドとの相関関係を確認すること ができます。タイムラインバーで区間をクリックすると、選択した区間に関する情報を展開して確認することができます。
-
アクティブスタックは10秒ごとにスナップショットを保存しているため、どの区間でも確認できます。応答時間が長くなる区間を確認する可能性が高いため、アクティブスタックを使用して区間が開いたポイントを見つけることができます。
-
TXトレース一覧でアクティブスタックを含むトランザクションは、 Aアイコンが表示します。
ヒットマップチャートでトランザクションを表示するトランザクションを見つけることが目的です。一緒に参照するトランザクションを確認して、応答時間や終了時間に影響を与える要因を特定する必要があります。アプリケーションですべてのメソッドを追跡すると、区間分析が可能ですが、オーバーヘッドが発生し、応答時間に歪みを与 える可能性があります。そのため、選択されたクラスメソッドのみを追跡する必要があります。その選択ポイントはシステム運用者の観点でのみ決定しますが、トラブルの原因となる(Lock)ロックやその他の要因が追跡から除外される場合があります。この除外される部分をサポートするのがアクティブスタックです。
WhaTapのモニタリングサービスは、アプリケーションサーバを運用する際に常時繰り返される問題を把握できるよう、定期的にアクティブスタックをスナップショットに記録し、トラブルを引き起こす根本的な要因をより高い確率で見つけられます。この方法で収集したデータを統計的に確認できるメニューが分析 > スタックです。スタックの詳細については、次の文書を参照してください。
-
トランザクション情報ウィンドウの レコード要約タブを選択すると、トランザクションに関する基本情報を検索することができます。クライアントIP、使用機器、OS、国の情報などを提供します。その他、フェッチ件数および時間、SQL件数および時間などを確認し、どれだけ多くの呼び出しを使用しているのかを把握できます。
-
トランザクション情報についての詳細は、次の文書を参照してください。
呼び出し関係分析
-
メソッド要約
メソッド要約タブを選択します。SQLと同様に、メソッドも１つのトランザクションでどれだけ多く呼び出された回数を確認することができます。
この情報に基づいて、繰り返し実行されるメソッドがあるかどうか、同じメソッドが繰り返し呼び出されているかを確認し、改善点を探すことができます。
-
SQL要約
トラブルの原因が内部ロジックではなくSQLである場合を説明します。１つのトランザクション内でSQLの実行を統計的に確認するには、SQL要約タブを選択します。
同じSQLをどれだけ繰り返して呼び出すかを確認してください。ロジックから呼び出す回数を減らしたり、他の解決策を見つけてDBの負担を軽減できる方法を見つける必要があります。Databaseの負担を軽減することは、サーバ運用にとって非常に重要です。アプリケーションサーバーはScale-Outができます。常にリソースを継続的に増やすことが可能です。一方、Databaseのパーティションを分割することは、アプリケーションに対して膨大な開発が伴います。パフォーマンスチューニングの基本は、アプリケーションのDatabaseの負荷を軽減するために、可能な限り適切である必要があります。
-
HTTPコール要約
HTTPコール要約タブを選択します。HTTPリクエストのリクエスト件数、合計時間、平均時間を提供します。
-
マルチトランザクション
モノリティック環境では単一のAPM構成でした。この場合、APMのトランザクションのみを確認します。最近では、マイクロサービスアーキテクチャなどの技術トレンドが主流です。単一のAPMが小さな単位に分割されると、それに応じて収集する必要のあるトランザクションの数が増加します。このような場合、分割されたトランザクションをすべて収集することは非常に負荷がかかるため、1つのトランザクションに連携したトランザクションをまとめて収集する必要があります。このように他のAPMに関連付けられたトランザクションを、WhaTapに よって、マルチトランザクションとして定義されます。TXトレース一覧でマルチトランザクションを含むトランザクションは、 Mアイコンを表示します。
マルチトランザクションタブを選択します。トランザクションごとの連携情報をチャートで確認できます。テーブル、ツリーボタンを選択して、テーブル形式またはツリー構造形式でトランザクション間の呼び出し関係を把握できます。
ノート-
マルチトランザクション追跡の詳細については、次の文書を参照してください。
-
トランザクションによっては、マルチTXタブをサポートしていない場合があります。
-
トランザクションログ分析
TXログタブでは、トランザクションが実行中に記録されたログから追加および改善する事項を確認することができます。
トランザクションログの詳細については、次の文書を参照してください。
最終作業
ヒットマップトランザクションからパターンを確認し、共通点を特定します。特定された共通点からメソッド間隔を分析します。十分なセグメント情報が不足の場合は、アクティブスタックを使用して詳細情報を確保してください。次にSQL、メソッド、HTTPリクエスト情報を確認して繰り返し負荷の大きいロジックの改善点を見つけます。