News

最新のアプリケーションパフォーマンス管理についての綿密な概要記事

作者 Steven Haines, 翻訳者 金森諭 投稿日 2008年8月30日午前6時15分

コミュニティ
トピック: パフォーマンス&スケーラビリティ,; ソフトウェアトラブルシューティング,; アプリケーションサーバ
タグ: スケーラビリティ,; Java EE,; 性能評価

ADP（Automatic Data Processing社）の上級技術アーキテクトであるNicholas Whitehead氏が、Java run-time monitoring（Javaの実行時モニタリング）(リンク)という題の一連の論文をIBMのDeveloperWorksに掲載した。この論文ではアプリケーションパフォーマンス管理（APM：Application Performance Management）を3部にわけて紹介している。

第1部(リンク)では、APMシステムの特性、システムモニタリングにおけるアンチパターンやJVMのパフォーマンスモニタリングの方法、実行時にアプリケーションのソースコードへ効率よくアクセスするテクニックについて述べている。
第2部(リンク)では、コンパイル後の計測、特にインターセプト・クラスラッピング・バイトコード計測について述べている。
第3部(リンク)では、アプリケーション環境のパフォーマンスおよび可用性についてのモニタリングを議論して締めくくっている。

Whitehead氏は、ばらばらなモニタリングシステムの寄せ集めという企業が直面しているであろう問題の本質にある、APMのアンチパターンからこのシリーズを始めている。彼が挙げているアンチパターンには次のものがある。

盲点：ある部分はモニタリングしているがシステム環境全体ではできていないため、要領を得ない分析結果が現れること。
ブラックボックス：盲点と似ているが、これはアプリケーションまたはコンポーネントを対象にしている。ブラックボックスというのはその内部のパフォーマンスについてまでモニタリングできないコンポーネントのことだ。
支離滅裂で纏まりのないモニタリングシステム：このアンチパターンはサイロ化（外部と隔絶したIT）されたモニタリングと集約されたモニタリングとの違いをはっきりと示す。いくつかのアプリケーション環境（OS、JVM、データベースなど）を詳しくモニタリングしても、それらがまとまっていなければパフォーマンスの問題の本当の原因がどこかを特定することが難しくなることがある。Whitehead氏はこの点を上手く表した図を載せている。

後追いのレポート作成：異なるモニタリングツールからデータを集めて、それらを意味のある何かへと関連付けようとするのは、かなりチャレンジングなことになるのではないだろうか。
定期的あるいはオンデマンドでのモニタリング：多くのモニタリングシステムは、オーバーヘッドがあまりに大きいため問題が起きた後にしか実行できないように設定されている。このような場合だと、問題の本当の原因を突き止めるには遅きにすぎるモニタリングになってしまうだろう。
データ保存しないモニタリング：パフォーマンス指標をリアルタイムに表示するというのは素晴らしいことだが、もしそのデータが保存されなければ、現在のパフォーマンス指標を検討する上でそれまでの経過を知るのが困難になってしまう。
本番前のモニタリングに頼る：本番以前にモニタリングを行うのは良いことだが、ユーザの振る舞いは完全に予想できるものではないため、それだけに依存してしまうには不十分だ。

アンチパターンについて概説した後で、Whitehead氏は次のような理想的なAPMシステムの特性を挙げている（この部分は元の記事からそのまま抜き出してきた）。

行き渡ること：全てのアプリケーションコンポーネントやそれらが依存しているものをモニタすること
粒度が細かくあること：極めて低レベルの動作もモニタできること
集約されていること：全ての測定結果は集約して視覚化できる適切な単一のAPMに集められること
絶え間ないこと：毎日24時間モニタすること
効率的であること：パフォーマンスデータの収集がモニタリング対象に悪影響を与えないこと
リアルタイムであること：モニタリングされているリソース指標がリアルタイムに視覚化されレポートや警告がされること
履歴をもつこと：モニタリングされているリソース指標がデータストアに保存され、過去のデータを視覚化や比較、レポートができること

次にこれらの要求を満たす技術的な方法をWhitehead氏は定義している。彼はモニタリングコンポーネントからデータを取得し、それを「パフォーマンスデータソース」へと送る役割をもつ「トレーサ（tracer）」をいくつか定義している。彼が定義するトレーサには、それぞれの指標が、間をあけてサンプリングされるものか、差分であるか、あまり変化のないものであるか、突然現れるものかで種類分けされるという性質があり、賢いトレーサであれば収集したデータの性質に応じて自分の種類を自動的に検出する。その後で彼はポーリングやリスニング、インタセプタといった一般的な収集パターンについて吟味している。

Whitehead氏はコアなモニタリング仕様についても深く入り込んでいく。まずいくつかのJVM MBean（JMXにおけるモニタリング対象のリソースに対するインターフェース）について詳しく述べ、それらを収集するモニタリングフレームワークやアプリケーション向けのJMX（Javaでリソースを管理/監視するための仕様）指標の構想を立てる。それに続いて今度はモニタリング用のクラスやメソッドに関心を向け、主要な4つのモニタリング技術を概説している。

ソースコード計測：アプリケーションにマニュアル作業で計測の仕組みを加える
インターセプト：AOP（アスペクト指向プログラミング）などを通じて呼び出しをインターセプトし、計測指標を取得する
バイトコード計測：アプリケーションの実行時にバイトコードへパフォーマンス指標を集めるコードを埋め込む
クラスラッピング：対象となるクラスを計測ロジックをもった他のクラスでラップしたり置き換えたりする

第1部でどのようにソースコード計測をおこなうかを例で示した後、与えられた指標のうちどれを評価すべきかのルールと基準を設けている。

第2部ではコンパイル後における計測に関心を向けている。ここではアプリケーションパフォーマンスの指標を取得するための方法として、EJB3のインタセプタ、サーブレットフィルタインタセプタ、EJBのクライアントサイドインタセプタおよびコンテキスト渡し、そしてSpringインタセプタの使い方を概説している。そしてJDBCのドライバ、コネクション、ステートメント、リザルトセットオブジェクトのクラスラッピングについて説明し、JDBCしいてはデータベース呼び出しの計測方法を示している。最後にバイトコード計測（BCI：byte code instrumentation）がどのようなもので、JVMの起動パラメータにjavaagentを指定することでBCIを組み込むというJVM標準の仕組みについて説明している。そしてAPMベンダがクラスラッピングよりBCIを選ぶ理由として次のパフォーマンスチャートを載せている。

Whitehead 氏はこのシリーズを、Javaアプリケーションの環境、つまりOSやホスト環境であり、さらにデータベースやメッセージングインフラも含む環境に対するモニタリング戦略で締めくくっている。彼はまずエージェント型および非エージェント型のモニタリング双方の課題と利点を検討し、そしてLinux/Unux システムおよびWindowsシステムのモニタリングに深く入り込んでいく。その次にデータベースモニタリングとコンテキストトレーシングについて課題が議論されている。そしてJMS（Java Message Service）とメッセージングシステムについてと、それらを合成メッセージとJMXの組み合わせによってモニタリングする方法を述べている。第3部の終わりでは、視覚化とレポーティングについて述べ、ダッシュボードのような視覚化手法のいくつかをスクリーンショットで紹介している。

一言でいえば、この一連の論文はパフォーマンスモニタリングについての紹介と綿密な要約であり、既存のモニタリングシステムで採用されているであろう多くの技術について読者が理解できるほど詳しいレベルまで触れらている。

パフォーマンスとスケーラビリティについての情報は、InfoQのパフォーマンスとスケーラビリティの項(参考記事)を参照されたい。