TOP>製品/サービス>カテゴリから探す>システム運用管理>JENNIFER>事例>Vol.5 不定期に発生するレスポンス遅延、90%以上が1秒以下へ改善

JENNIFER

Vol.5 不定期に発生するレスポンス遅延、90%以上が1秒以下へ改善

JENNIFERケーススタディvol5

多くの企業が、基幹システムなどの業務アプリケーションをC/S(クラサバ)からWebへ移行しています。しかし、Webアプリケーションの大半は、Webサーバ/アプリケーションサーバ/データベースサーバの3層構成となり、問題発生時の切り分けや原因特定が困難です。

そこでシリーズ第5弾となる本コラムでは、不定期に発生したアプリケーションのレスポンス遅延を、性能監視ツール「JENNIFER」を利用して、わずか3ステップで原因特定に至った事例をご紹介します。同様の課題に悩まれているアプリケーション運用/開発に携わるご担当者にとって、解決の一助となれば幸いです。


お客様の課題

お客様の課題

(1)ユーザから「金曜日になると設備管理システムが遅くなる」とのクレームが発生。ただし、毎週遅くなるのではなく月2回程度発生する。
(2)アプリケーション処理状況/リソース/負荷状況を監視していない。
(3)正常時と異常時を比較する術が無い。
(4)複数のアプリケーションサーバ(APサーバ)で負荷分散していたが、どのAPサーバで事象が発生しているか不明。
(5)ユーザ部門から早期解決と報告形態(レポート)の改善を求められた。



解決方法

上述したお客様の課題は、アプリケーション性能監視ツール「 JENNIFER 」を導入し、以下の3ステップで解決しました。まずは、APサーバ内部で発生している事象を俯瞰視するために、様々な項目を幅広くモニタリング。次に、アプリケーションの応答時間やエラー発生状況などを細かく確認して、主だったException(例外処理)を特定しながら順次対応。最後に、メソッドレベル&スタックトレース情報を細かく調査して、事象の根本原因であるクラスファイルの特定に至りました。

それでは、全体把握から原因特定に至る3つのステップについて順を追ってご説明します。


STEP1:アプリケーションの現状把握

モニタリング対象は敢えて絞らず、アプリケーションの全体状況を漏れなく把握するために様々な項目を広く確認しました。その結果、事象発生時に数多くのExceptionが発生していることが分かりました。

■モニタリング対象
アプリケーション処理時間/SQL時間/発生Exception
アプリケーション利用ユーザ数/TPS(Transaction Per Second)
アクティブDBコネクション数/アイドルDBコネクション数
システムCPU使用率/プロセスCPU利用率
プロセスメモリ使用量/プロセスメモリ利用率
ヒープメモリ使用率 /ガベージコレクション発生状況など

STEP1:アプリケーションの現状把握


STEP2:Exceptionの特定とアプリケーションの部分修正

STEP2:Exceptionの特定とアプリケーションの部分修正

STEP1で取得したデータをもとに、アプリケーション内部を調査したところ、DBConnectionに関するExceptionが数多く発生していました。しかし、どのExceptionが起因となっているか判別がつかないため、対応可能なもの(以下4つ)から順次修正しました。その結果、若干のレスポンス改善が見られました。

同時に、Exceptionによる直接的な遅延現象とは別に、アプリケーション内部の遅延事象に関わる原因(可能性)を特定するため、対象のアプリケーションをより深く確認する必要がありました。

DBConnectionに関するException
SQL_Exception
IllegalArgumentException
HTTP IO Exception
404_ERROR


STEP3:アプリケーション遅延原因の特定と修正

STEP3:アプリケーション遅延原因の特定と修正

事象の根本原因を特定するため、メソッドレベル&スタックトレース情報を確認しました。手順は以下の通りです。

(1)正常日と事象発生日の運用情報を「比較」
(2)アプリケーション内部の詳細情報を確認するために「メソッドレベルの情報を収集」し、負荷高騰時にどのメソッド処理で遅延しているか確認
(3)一定負荷以上になると遅延が発生している各アプリケーションの「スタックトレースの情報を収集」し、滞留が発生しているクラス情報を確認

その結果、ほとんどのアプリケーションが同じクラスファイルで滞留しており、その原因がログ出力API機能「log4j」に関連するクラスファイルの遅延であることが特定できました。

矢印

以上の調査結果を受けて、アプリケーションから「log4j」ファイルに対して、複数のスレッド発行による不適切なロックが発生していないか?debugレベルの指定などが不適切なログ出力量になっていないか?などお客様にご確認いただき、ログの書き込み頻度を修正いただきました。その結果、高負荷時もアプリケーションのレスポンス状態が安定しました。
本事象は、複数エラーが発生したことで原因特定が容易ではありませんでしたが、JENNIFERを使ってExceptionを1つ1つ紐解き、アプリケーション内部を見える化することで解決に至りました。


導入効果

1秒以上かかっていたリクエスト処理のうち、90%以上が1秒以下に改善。クレームが無くなった。
アプリケーションの運用状態を監視し、蓄積情報からレポートを自動出力できるようになった。
アプリケーションのリリース前後の状態をリアルタイムに監視でき、サービス品質が向上した。


アプリケーション性能監視ツール「 JENNIFER 」なら、Webアプリケーションの性能劣化を、誰でも・簡単に・迅速に特定して、原因調査の工数を大幅に削減できます。さらに、正常時のレスポンスを定常的に把握し、 トラブルの予兆を自動検知することもできるため、 システム障害の未然防止も期待できます。

本コラムでご紹介したお客様事例やJENNIFERの詳細が知りたい方は、お気軽にお問い合わせください。専任スタッフより折り返しご連絡致します。


JENNIFER関連コラムのご紹介

本コラムは全5シリーズで連載しております。是非、他コラムもご覧ください。

2005年、株式会社アシスト入社。運用監視ツール担当歴10年、現在ではアプリケーション性能監視ツール「JENNIFER」のご紹介、サポート、技術支援を担当。
週のほとんどはお客様先へ訪問し、課題解決から製品設計まで、幅広くこなしている。週末は子どもを連れてキャンプに行くなど、子煩悩な一面を見せる。


JENNIFER詳細情報のご案内

概要

JENNIFERの製品概要をご紹介しています。

特長

JENNIFERの特長と、開発/運用フェーズでの活用方法をご紹介しています。

支援サービス

JENNIFERの導入支援サービスをご紹介しています。

システム要件

JENNIFERエージェントの導入要件とサーバのシステム要件を記載しています。

事例

JENNIFERの導入実績と導入事例をご紹介しています。

お求めの情報は見つかりましたでしょうか。

資料請求/お問い合わせはこちら(専門の担当者が確認し、ご対応します。)

お客様の状況に合わせて詳しい情報をお届けできます。お気軽にご相談ください。

ページの先頭へ戻る