Dynatrace コラム

2種類のエンドユーザー体感監視方法

エンドユーザー体感監視ツールは、その名が示す通りエンドユーザーがITシステムにアクセスする際に体感するパフォーマンスを監視するツールで す。システムのリソース負荷などからパフォーマンスを図るのではなく、エンドユーザーの体感を基にするため、実際のパフォーマンス状況をより的確に捉える ことが可能です。

その方法ですが、パフォーマンス計測は大きく、仮想ユーザーがエンドユーザーのふりをして監視対象サイトにアクセスする「仮想ユーザー方式」と、ネットワーク上の実パケットをキャプチャする「パケットキャプチャ方式」の2つに分けられます。

どちらもエンドユーザー体感を計測するという目的は同じですが、それぞれの特長に応じて、できること・適した用途に違いがあります。具体的に、それぞれのメリット・デメリットを見てみましょう。

仮想ユーザー方式

仮想ユーザー方式ではまず、社内のいずれかの場所に設置したマシンに監視用のエージェントをインストールします。エージェントはあらかじめ決めら れた定義に従って、監視対象サイトにアクセスします。「ブラウザを使って監視対象サイトにHTTPリクエストを送信し、レスポンスデータを受信する」と いった一連の処理を、エージェントが定期的かつ自動的に行います。本当のユーザーではない、仮想のユーザーが計測を実行するという意味で、「仮想ユー ザー」方式と呼ばれます。

エージェントにおける定義は、例えば次のようになります。
エージェントはこの定義に従って定期的に監視を実行します。

・監視対象はwww.xxx.co.jp。ポータルサイトにログインし、特定の文字列を検索後ログアウトするまでの一連の処理とする
・監視実行間隔は10分に1回
・しきい値は6秒以上を警告、10秒以上をエラーとする
・エラーが3回連続した場合、運用担当者にメールで通知する

この監視方式ではエージェントをどこに置くかが重要なポイントとなります。エージェントがユーザーのふりをして監視対象サイトにアクセス するので、計測したい場所にエージェントを起きます。例えばADSLのような一般ユーザー向け回線を使ってアクセスするようにしておけば、より一般ユー ザーの体感に近い計測結果が得られるでしょう。あるいはWebサーバーと同じLAN上にエージェントを置くことによって、ネットワークの遅延に左右されな い、サイトの「本来の」レスポンスタイムを計測することができるでしょう。

同じロケーションの同じ環境から同じ処理の監視を定期的に行う仮想ユーザー方式は、サービスレベルの計測に有効です。サービスレベルを管理するためには、実ユーザーのアクセスにかかわらず、同じ場所で定期的にレスポンスタイムを計測する必要があるためです。

さらにエージェントを何カ所に置くかも監視の精度を上げるためには重要な考慮点です。サービスレベル情報の取得だけが目的であれば、社内 の一カ所に置けば十分かもしれません。しかし、例えば監視対象がイントラネットで、国内の全支店のレスポンスタイムを監視したい場合には、それらすべての 支店にエージェントを置く必要があるかもしれません。

パケットキャプチャ方式

こちらの監視方式は、ネットワーク上を流れるパケットをキャプチャしてレスポンスタイムを計測するものです。

まずパケットをキャプチャするためのソフトウェアがインストールされたマシンを準備します。このマシンを監視対象システム内のネットワーク機器（ルータ、スイッチなど）のモニターポートに接続します。モニターポートからはそのネットワーク機器を通過するパケットがすべて出力されるので、それを分析してレスポンスタイムを計測します。

パケットキャプチャ方式の最も大きなメリットは、すべての実ユーザーのレスポンスタイムを計測できる点です。あるシステムでパフォーマンス問題が発生した場合に、その影響が及んでいる場所や個人を特定できるため、例えばコールセンターのオペレータがアクセスする顧客システムや、代理店がアクセスする受発注システムなどは、パケットキャプチャ方式が向いていると言えます。こうしたケースでは、どのオペレータ、どの代理店のレスポンスが低下しているかを把握するのが重要だからです。ただし、実ユーザーからのアクセスがない時間帯には、そのときシステムに何らかの問題が起きていても検知できないのが、同方式のデメリットです。

また、パケットキャプチャ方式には、ハードウェアとソフトウェアをまとめてアプライアンスとして提供されるケースとソフトウェアのみ提供されるケースがあります。一般論として、アプライアンスは設置が比較的容易であり、一方ソフトウェアのみ提供の場合はスケーラビリティ（どれくらいの量のパケットを処理できるか）の面で優れていることが多いようです。

導入にあたって留意すべき点

サーバー監視ツールやネットワーク監視ツールに比べて認知度の低いエンドユーザー体感監視ツールを実際に導入された経験のある方はまだまだ少ないかもしれません。導入を検討する場合、どのような点に気をつけたらいいのでしょうか。

（1）実ユーザーの計測は必要か
実ユーザーのレスポンスタイムを計測する必要があるか、あるいは仮想ユーザーによる計測で要件を満たすのかは、ツールの選択肢を絞り込む上で重要なポイントとなります。

（2）製品にするかサービスにするか
仮想ユーザー方式を選択した場合、製品を購入して自社内に監視環境を構築する方法と監視サービスの提供を受ける方法があります。

自社に環境を構築する場合、外部から閉じたシステムであっても監視できたり、ほかの監視ツールとの連携が可能だったりする点がメリットで、運用管理の手間がかかる点がデメリットです。

一方、監視サービスを利用する場合、比較的設定や管理に手間がかからなかったり、マシンなどを新たに準備する必要がなかったりする反面、 外部からのアクセスを制限しているシステムでは監視が難しく、Webサイト（HTTP）以外のシステムに適用できないなどの制約があります。

また、監視サービスの中には世界中にエージェントを配置して非常に多くの場所からの監視を実現しているものもあり、よりエンドユーザーに近いレスポンスタイムを計測したい場合にはエージェントの選択肢が多いサービスを選ぶ、という選択肢もあります。

（3）監視対象システムのプロトコル
一般的にＩＴシステムに使用されるプロトコルはHTTPが多くなったとは言え、まだまだ多くのシステムでHTTP以外のプロトコルが使われていま す。またエンドユーザーのレスポンスタイム計測を補足する意味で、HTTPなどのクライアントプロトコルのほかにSQLなどバックエンドのプロトコルのレ スポンスタイムを計測したい場合があります。

計測できるプロトコルの種類はツールによって大きく差があり、HTTPしか計測できないツールもあれば数十種類のプロトコルを計測できるツールもあります。監視すべきプロトコルは何なのかをあらかじめ明確にしてからツールの選択を行う必要があります。

（4）パフォーマンス問題の原因分析に利用するか
エンドユーザー体感監視ツールのメリットのひとつは、パフォーマンス問題が発生した際にその原因を切り分けることができる点にあります。しかしどのような分析機能を持っているかはツールによって大きく異なります。

ツールによってはレスポンスタイムのみレポートし、分析機能を全く提供しないものもあります。（その分価格が安く抑えられているケースが 多いようですが）。多くのツールで見られる分析機能は、レスポンスタイムをサーバー処理時間、ネットワーク時間、クライアント時間などに分割する機能、 Webページ内のコンポーネント（各Gifファイル、HTMLファイルなど）ごとにレスポンスタイムを計測する機能などです。

また、仮想ユーザー方式かパケットキャプチャ方式かによっても、分析に使える機能は変わってきます。一般的に言って、実ユーザーのレスポ ンスタイムをロケーション毎、Webサーバー毎、ページ毎といった細かい単位で分析できるパケットキャプチャ方式のほうが、分析機能という意味では充実しています。

重要なのは、ツールをどんな目的で使用するかをはっきりさせることです。サービスレベル管理のための基準値としてレスポンスタイムを利用 するだけであれば、それほど細かい分析機能は必要ないかもしれません。逆に運用の現場での問題原因究明を目的として利用する場合には、実際の運用プロセス を考慮しつつ、分析機能がどのように活用できるかを想定しておく必要があります。

以上、仮想ユーザー方式・パケットキャプチャ方式の違いをまとめると以下のようになります。

 

では、現在求められている運用監視とは何でしょう。

みなさんはエンドユーザー体感監視という言葉をご存知でしょうか。ここで言うエンドユーザーとはサービスの利用者、例えばインターネットバンキングであれば自宅のPCからアクセスする一般消費者、企業内のポータルサイトであれば従業員です。これらエンドユーザーがサービスを利用する際、あるページを表示するのに何秒かかるか、これを監視するのがエンドユーザー体感監視です。

いま、このエンドユーザー体感監視の重要性が増しています。

従来、ITシステムの監視はサーバー、ネットワーク機器といった単位で行われてきました。サーバーは立ち上がっているか、CPU使用率は高くないか、ネットワーク機器のポートは立ち上がっているか（Ping監視）など、これらはオープン系のシステムが登場してから長らく行われてきた監視形 態（以下、インフラ監視と呼ぶ）でした。

当然ながら、クラウド環境、仮想化環境になったからといってこれらインフラ監視の重要性が変わるわけではありません。しかし、本来エンドユーザーが快適にサービスを受けられるようにするために行っているはずの監視が、その目的を達していないケースが多く見られます。これは、インフラ監視で検知できる障害とエンドユーザーが体感する障害が必ずしもイコールではないことから生じます。