失敗しないアプリケーションパフォーマンス管理製品の選び方：複雑化したシステムのパフォーマンスをどう守るか【第3回】
複数のベンダーから提供されているAPMツールは、当然ながら監視方式や搭載機能がそれぞれ異なっている。自社のニーズに最適な製品を選ぶためには、どのようなポイントに留意すればよいのだろうか？
前回の「【技術解説】アプリケーションパフォーマンスを測る4つの手法」では、APM（Application Performance Management）ツールで採用されている4つの監視方式――「仮想ユーザー方式」「パケットキャプチャー方式」「クライアントインストール方式」「JavaScript付加方式」と、それぞれのメリット、デメリットを紹介した。
今回はそれに基づき、自社のニーズに適切なAPMツールを選ぶための7つのチェックポイントを紹介する。
1. 監視すべきプロトコルは何か？
APMツールの選択に当たってまずチェックしたいのは、その製品が「監視できるプロトコル」だ。一般に、Webを介して使う業務システムはHTTPを使っているケースが多いが、SAPなど広く使われているパッケージシステムでは、HTTP以外のプロトコルが使われているケースがある。また、APMツールを「システムのレスポンスの把握」だけでなく、「パフォーマンス低下の原因分析」にも利用する場合、HTTPなどフロントエンドのプロトコルだけでなく、TCP/IPなどバックエンドのプロトコルにも対応している方が望ましい。
製品には、HTTPしか計測できないツールもあれば、数十種類のプロトコルを計測できるものまである。事前に「監視対象システムがどのプロトコルを使っているのか」「どのプロトコルを監視する必要があるのか」を明確化しておきたい。
APMの関連コンテンツ
- 責任問題を終結に導く――プロアクティブなアプリケーションパフォーマンス管理の第一歩（ホワイトペーパー）
- 運用を始めてからでは遅い！ 仮想化環境におけるアプリケーションパフォーマンス管理（ホワイトペーパー）
- クラウド時代におけるエンドユーザ目線によるWebサイトのパフォーマンス管理の必要性（ホワイトペーパー）
- Webアプリケーション開発におけるパフォーマンス・ボトルネック34の問題＆回答（ホワイトペーパー）
2. エンドユーザーが実際に感じているレスポンスタイムを把握する必要があるか？
これは「システムのレスポンスが、業務の遅滞を招く原因になっているかどうか」の調査などに当てはまる。例えば、監視対象システムがコールセンターの顧客対応システムで、「全オペレータの体感レスポンスタイムを正確に把握したい」といった場合だ。
仮想ユーザー方式は、APMツール自身が仮想ユーザーとしてパケットを送信する方式を取る。このためエンドユーザーが実際に感じているレスポンスタイムを計測することはできない。従って、エンドユーザーが送受信するデータを分析することでレスポンスを把握するには、その他の3方式から選ぶことになる。
ただし、クライアントインストール方式のみ、エンドユーザーのWebブラウザにエージェントをインストールする必要があるため、エンドユーザーの協力が不可欠となる。分析作業をよりスムーズに進める上では、パケットキャプチャー方式か、JavaScript付加方式の方が有利だろう。
監視対象が大規模なB2Cサイトで、「必ずしも全ユーザーが実際に体感しているレスポンス情報は必要なく、サンプルとなるレスポンスタイムを把握したい」という場合には、同じ場所から同じ処理を定期的に繰り返す、仮想ユーザー方式が適している。
3. パフォーマンスの問題原因分析も行う必要があるか？
多くのAPMツールは、レスポンス監視機能とともに、「レスポンス遅延の原因が、サーバ側とエンドユーザー側のどらちにあるかを切り分ける機能」を持つ。だがシンプルなツールの場合、レスポンス遅延の原因分析機能を備えていないものもあるので注意が必要だ。自社のシステム運用管理プロセスを整理し、どのような機能が必要か、あらかじめ明確化しておきたい。
なお、問題原因箇所の切り分け機能については、クライアント側から計測するクライアントインストール方式とJavaScript付加方式はクライアント側の分析に優れ、サーバ側から計測するパケットキャプチャー方式はサーバ側の分析に優れている傾向が強い。
統合運用管理の関連コンテンツ
4. エンドユーザーが気付く前に障害を検知する必要があるか？
パケットキャプチャー方式、クライアントインストール方式、JavaScript付加方式は、実際のエンドユーザーのパケットを監視するため、システムのレスポンスが遅延していても、エンドユーザーのアクセスがなければ遅延を検知できない。例えば、監視対象が夜間は誰もアクセスしないような業務システムの場合、夜間に何らかの障害が発生していても、エンドユーザーのアクセスがない以上、障害を検知できない。
その点、仮想ユーザー方式なら、ツール自ら定期的にシステムにアクセスするため、障害が起きていれば必ず検知できる。従って「障害のより早い発見」という目的がある場合、必然的に仮想ユーザー方式を選ぶことになる。ただし、仮想ユーザー方式は一定間隔での監視のためリアルタイムでの検知はできない。また、あらかじめ定義しておいたページしか監視しないため、特定のページの障害は検知できない可能性もある。
Copyright © ITmedia, Inc. All Rights Reserved.