“快適な操作性”を守る監視ツール選び、7つのポイントビジネス視点の運用管理(4)(1/2 ページ)

これまでの連載でエンドユーザー体感監視=APM(Application Performance Management)のポイントをあらゆる角度から紹介してきた。今回からは、いよいよAPMを実現するツール選択のポイントを伝授する。

» 2011年05月26日 12時00分 公開
[福田 慎(日本コンピュウェア ),@IT]

 これまでの連載で解説してきたように、エンドユーザー体感監視=APM(Application Performance Management)は専用ツールを使って行うのが一般的です。Pingなどの簡単な応答監視であれば自社でもツールを開発できるかもしれませんが、「ブラウザからの操作」といったアプリケーションレベルの応答まで監視しようとすると自ら開発するのは容易ではありませんから、何らかのツールを利用するのが現実的となります。

 今回と次回の最終回では、貴社にとって最適なエンドユーザー体感監視ツールは何か、その選び方を解説します。

パフォーマンスを計測・分析したい目的は何ですか?

 第2回「サイロ型のシステム監視が、問題解決を遅らせる 」で説明した通り、エンドユーザー体感監視には大きく分けて4つの手法があります。ただ、一般的に利用されているのは以下のいずれかの手法を採用しているツールです。

  • 仮想ユーザー方式
  • パケットキャプチャ方式

 これらについては第1回「サーバは無事でも、業務が遅滞しては意味がない」でも解説しましたが、これは大切な点ですので、ここでもう一度簡単に復習しておきましょう。

ALT 図1 仮想ユーザー方式は、いずれかの場所に設置した計測用エージェントが、“ユーザーのふり”をして監視対象サイトにアクセスして計測する。パケットキャプチャ方式は、監視対象サイト内のネットワーク機器を通過するパケットを分析して計測する

 仮想ユーザー方式では、いずれかの場所に設置した計測用エージェントが“ユーザーのふり”をして監視対象サイトにアクセスします。どのページにアクセスするかは、あらかじめ定義しておきます(例えばトップページからログインし、検索実行後、ログアウトする、といった流れを定義しておく)。計測は「10分に1回」「1時間に1回」など定期的に行われます。

 一方、パケットキャプチャ方式は、監視対象サイト内のネットワーク機器にパケットキャプチャ用装置を接続し、そのネットワーク機器を通過するパケットを分析します。

 仮想ユーザー方式では、監視ツール自体が「仮想ユーザー」となってパケットを送信する過程を監視するのに対して、パケットキャプチャ方式は実ユーザーのパケットをキャプチャします。この違いから、両方式で得られる情報には違いがあります(詳しくは第1回の「各社のツール、サービスを目的に応じて使い分けよう」を参照)。それらを十分に理解した上で、いずれかのタイプのツールを選択することになります。

“ツール選択の基礎力”が、シビアに問われるAPMツール選び

 では、さっそくエンドユーザー体感監視ツールを選択する際に考慮すべきポイントをご紹介しましょう。

実ユーザーのレスポンスタイムを把握する必要があるか?

 前述のように、仮想ユーザー方式のツールは、監視ツール自体が仮想ユーザーとなってパケットを送信するため、実ユーザーのレスポンスタイムは計測できません。一方、パケットキャプチャ方式はネットワーク機器からパケットを収集するため、基本的に全ての実ユーザーのレスポンスタイムを把握できます。つまり、実ユーザーが体感しているレスポンスタイムを知るにはパケットキャプチャ方式が正しい選択となります。

 例えば、監視対象がコールセンターの顧客対応システムで、「全オペレータの体感レスポンスタイムを正確に把握したい」ような場合はパケットキャプチャ方式を選択すべきでしょう。一方、監視対象が大規模なBtoCサイトで、「必ずしも全ユーザー の情報は必要ではなく、基準値となるようなレスポンスタイムを把握したい」場合には、同じ場所から同じ処理を定期的に繰り返す、仮想ユーザー方式の方が適していると言えます。

監視すべきプロトコルは何?

 「監視対象システムでは、どのようなプロトコルを使っているか」、また「どのプロトコルを監視する必要があるか」を明確にします。一般的にはHTTPを使うケースが多いとは思いますが、SAP、Citrixなど、広く使われているアプリケーションでも、HTTP以外のプロトコルを使っていることがあります。また、エンドユーザー体感監視ツールを「パフォーマンス問題の原因分析」のために利用する場合、HTTPなどのフロントエンドプロトコルだけでなく、バックエンドのプロトコル、例えばSQLなどを計測する必要もあるかもしれません。

 従って、まずは監視すべきプロトコルを明確化しておく必要があるのですが、計測できるプロトコルはツールによってまちまちです。HTTPしか計測できないツールもあれば、数十種類のプロトコルを計測できるものまでありますので、ニーズに応じて選択してください。

必要なのはパフォーマンスの計測だけ? 原因分析の必要は?

 エンドユーザー体感監視のメリットの1つは、「システムにパフォーマンス問題が発生した際に、問題原因を切り分ける有効な情報」を提供してくれることです。障害の内容にもよりますが、エンドユーザー体感監視を中心とした分析プロセスを取り入れることで、問題解決までに要する時間を劇的に短縮できるのです。

 ただし、「どのような分析機能を備えているか」はツールによって異なります。シンプルなツールの場合、レスポンスタイムの「計測機能」はあっても「分析機能」は全く備えていないものもあります。

 例えば、Webサイトのパフォーマンス分析機能の1つとして「レスポンスタイムのブレークダウン機能」があります。この機能は、パフォーマンスが悪化した際、その原因がWebサーバにあるのか、アプリケーションにあるのか、あるいはインターネット側、クライアント側にあるのかを切り分けるのに役立ちます。

ALT 図2 Webサイトのパフォーマンス分析機能の1つ、「レスポンスタイムのブレークダウン機能」のUIイメージ。ただ中にはこうした分析機能を持たないツールもあるので、目的に応じて選びたい

 しかし、そもそもそこまでの分析機能を必要としていない場合もあるでしょう。事前に自社のシステム運用プロセス、問題解決プロセスを整理し、「どのような機能が有効か」を明確にしておくと良いでしょう。

 なお、一般的には、パケットキャプチャ方式は全ユーザー、全トランザクションのレスポンスタイムを計測しているため、「地域的な傾向」や「ページごとのレスポンスタイム」などの情報を利用することによって、仮想ユーザー方式よりも詳細な分析が可能とされています。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ